https://bugs.winehq.org/show_bug.cgi?id=56951
Bug ID: 56951 Summary: psql 16: unrecognized win32 error code: 127 invalid binary: Invalid argument / could not find a "psql.exe" to execute Product: Wine Version: 9.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@winehq.org Reporter: alex@willner.ws Distribution: ---
**Version:** 9.11
**Steps that will reproduce the problem:**
1. curl -Os https://get.enterprisedb.com/postgresql/postgresql-16.3-2-windows-x64-binari... 2. unzip -q postgresql-16.3-2-windows-x64-binaries.zip 3. wine pgsql/bin/psql.exe --version
**What is the expected result:**
psql (PostgreSQL) 16.3
**What happens instead:**
unrecognized win32 error code: 127invalid binary "Z:\pgsql\bin\psql.exe": Invalid argument psql (PostgreSQL) 16.3
**Possible workaround:**
Downgrade to psql 15
*Any additional information:**
% curl -Os https://get.enterprisedb.com/postgresql/postgresql-15.7-1-windows-x64-binari... && unzip -q postgresql-15.7-1-windows-x64-binaries.zip && wine pgsql/bin/psql.exe --version psql (PostgreSQL) 15.7 %
% curl -Os https://get.enterprisedb.com/postgresql/postgresql-16.3-2-windows-x64-binari... && unzip -q postgresql-16.3-2-windows-x64-binaries.zip && wine cmd Z:> cd pgsql\bin Z:\pgsql\bin>psql.exe --version unrecognized win32 error code: 127unrecognized win32 error code: 127unrecognized win32 error code: 127unrecognized win32 error code: 127unrecognized win32 error code: 127unrecognized win32 error code: 127unrecognized win32 error code: 127un recognized win32 error code: 127unrecognized win32 error code: 127could not find a "psql.exe" to execute psql (PostgreSQL) 16.3
https://bugs.winehq.org/show_bug.cgi?id=56951
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |xerox.xerox2000x@gmail.com Status|UNCONFIRMED |NEW
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Confirming
Seems to come from missing entry for NtFlushBuffersFileEx, see trace below;
Patch below is enough to fix it.
diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec index 9147cdca3cd..5b0b5703506 100644 --- a/dlls/ntdll/ntdll.spec +++ b/dlls/ntdll/ntdll.spec @@ -3,6 +3,7 @@ #if you change a Nt.. function DON'T FORGET to change the #Zw one too.
+@ stub NtFlushBuffersFileEx @ stdcall A_SHAFinal(ptr ptr) @ stdcall A_SHAInit(ptr) @ stdcall A_SHAUpdate(ptr ptr long)
Trace: 0024:Call KERNEL32.GetProcAddress(6fffffc50000,140081d80 "NtFlushBuffersFileEx") ret=14004a3dd 0024:Ret KERNEL32.GetProcAddress() retval=00000000 ret=14004a3dd 0024:Call KERNEL32.GetLastError() ret=14004a416 0024:Ret KERNEL32.GetLastError() retval=0000007f ret=14004a416 0024:Call ucrtbase.__acrt_iob_func(00000002) ret=14004a332 0024:Ret ucrtbase.__acrt_iob_func() retval=6ffffebc42d0 ret=14004a332 0024:Call ucrtbase._errno() ret=140046d10 0024:Ret ucrtbase._errno() retval=7ffffe579810 ret=140046d10 0024:Call ucrtbase.memmove(7ffffe4fdb00,140081cf8,0000001f) ret=14004766f 0024:Ret ucrtbase.memmove() retval=7ffffe4fdb00 ret=14004766f 0024:Call ucrtbase.memmove(7ffffe4fdb1f,7ffffe4fd7ad,00000003) ret=14004766f 0024:Ret ucrtbase.memmove() retval=7ffffe4fdb1f ret=14004766f 0024:Call ucrtbase.fwrite(7ffffe4fdb00,00000001,00000022,6ffffebc42d0) ret=14004698c 0024:Call KERNEL32.WriteFile(00000010,7ffffe4fc930,00000022,7ffffe4fc92c,00000000) ret=6ffffeb3cd60 0024:Call ntdll.NtWriteFile(00000010,00000000,00000000,00000000,7ffffe4fc810,7ffffe4fc930,6fff00000022,00000000,00000000) ret=6fffff481520 unrecognized win32 error code: 1270024:Ret ntdll.NtWriteFile() retval=00000000 ret=6fffff481520
Add
https://bugs.winehq.org/show_bug.cgi?id=56951
--- Comment #2 from Louis Lenders xerox.xerox2000x@gmail.com --- As a guess adding simple stub also means adding things to ntsyscalls.h etc.
Anyone more familiar with this could take this up? Seems like easy fix for anyone who knows more about this than me ;)
https://bugs.winehq.org/show_bug.cgi?id=56951
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=56951
--- Comment #3 from Alex alex@willner.ws --- Hi Luis,
Patch below is enough to fix it.
thanks a lot for the confirmation and initial fix! As version 4.13 does (obviously) not fix this issue magically, may I suggest we start with your proposed preliminary change for 4.14?
https://bugs.winehq.org/show_bug.cgi?id=56951
--- Comment #4 from Alex alex@willner.ws ---
Seems to come from missing entry for NtFlushBuffersFileEx
fwiw, here is the relevant change that was introduced for version 16 that is not part of version 15: https://github.com/postgres/postgres/commit/9430fb407bb64cc842e56fb5844265a9...
https://bugs.winehq.org/show_bug.cgi?id=56951
Thomas Munro thomas.munro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.munro@gmail.com
--- Comment #5 from Thomas Munro thomas.munro@gmail.com --- Hi,
I think a real implementation of NtFlushBuffersFileEx() probably just needs to take the existing body of NtFlushBuffersFile(), but where it does[1]:
if (fsync(fd)) ret = errno_to_status( errno );
... it should use fdatasync() instead, if the Flags argument contains FLUSH_FLAGS_FILE_DATA_SYNC_ONLY. One small complication is that macOS lacks fdatasync(). Well, it has the symbol and it works, but there is no declaration in <unistd.h> for reasons unknown to open-source-hacker-kind, so you'd need some compile-time conditional workaround (either supply the missing declaration like PostgreSQL does or fall back to the fsync() path, if macOS detected either by name or, better, by configure probe for the declaration). Every other Unix on your target list has it (it's from POSIX/SUSv2).
Then NtFlushBuffersFile() becomes just a call to NtFlushBuffersFileEx() with zero flags.
(I'm the author of that PostgreSQL change. Unfortunately I'm not in a position to submit a WINE patch for bureaucratic reasons, but I hope the above helps. I would like to be able to test cross-builds of PostgreSQL on WINE myself! This isn't the only obstacle to that, but it is the first one that comes up, ie early in program startup.)
[1] https://github.com/wine-mirror/wine/blob/88a28aa5757ae74d9997b470d70216f1097...