http://bugs.winehq.org/show_bug.cgi?id=34868
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW URL| |http://www.femm.info/Archiv | |es/bin/femm42bin_x64.exe Keywords| |download, win64 Component|-unknown |ntdll CC| |focht@gmx.net Ever Confirmed|0 |1 Summary|FEMMx64bit does not start. |64-bit FEMM 4.2 (finite |Deficiency in Wine |element solver app) crashes | |on startup | |(SetWindowLong/winproc | |pointer truncation due to | |image base address > 4 GiB) Severity|major |normal
--- Comment #1 from Anastasius Focht focht@gmx.net 2013-11-06 18:01:36 CST --- Hello folks,
confirming.
The 64-bit PE has an image load base address of 0x0000000140000000 (> 32-bit address space range). It sets window proc using SetWindowLong() which only supports 32-bit (long) value leading to pointer truncation for 64-bit addresses. Because the window proc lives in 64-bit range it crashes as soon as the windows proc gets called.
There is no app code for calling SetWindowLongPtr() in main executable so I assume this is just another not-really-fit-for-win64 app which just gets away on Win64 because it's still loaded in 32-bit range despite the 64-bit load address in PE header.
See bug 30329 ("Total Commander 8.0 64-bit installer crashes due to LB_INSERTSTRING pointer truncation (image base address > 4 GiB)") for a similar issue with 64-bit.
Another case where Wine is actually useful for verifying Win64 standards :-)
Windows just plays dirty by employing lots of workarounds under the hood to support all kinds of broken 64-bit apps.
--- snip --- $ pwd /home/focht/.wine/drive_c/femm42/bin ... $ WINEDEBUG=+tid,+seh,+relay wine ./femm.exe >>log.txt 2>&1 ... 0026:Starting process L"C:\femm42\bin\femm.exe" (entryproc=0x1401d3fc0) ... 0026:Call user32.SetWindowLongA(0001015c,fffffffc,1401d2970) ret=1401d2d22 0026:Ret user32.SetWindowLongA() retval=786e0538 ret=1401d2d22 0026:Call user32.GetClientRect(000a0156,0023d520) ret=1401d2b11 0026:Ret user32.GetClientRect() retval=00000001 ret=1401d2b11 0026:Call user32.SetWindowPos(0001015c,00000001,000001be,000000be,00000000,00000000,00000211) ret=78723b58 0026:Call window proc 0x401d2970 (hwnd=0x1015c,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=0023d300) 0026:trace:seh:raise_exception code=c0000005 flags=0 addr=0x401d2970 ip=401d2970 tid=0026 0026:trace:seh:raise_exception info[0]=0000000000000000 0026:trace:seh:raise_exception info[1]=00000000401d2970 0026:trace:seh:raise_exception rax=00000000401d2970 rbx=00000000000ed200 rcx=000000000001015c rdx=0000000000000046 0026:trace:seh:raise_exception rsi=0000000000000000 rdi=000000000023d300 rbp=000000000023c870 rsp=000000000023c818 0026:trace:seh:raise_exception r8=0000000000000000 r9=000000000023d300 r10=0000000000000000 r11=00000030b85814e0 0026:trace:seh:raise_exception r12=0000000000000001 r13=00000001401eeda0 r14=0000000000000110 r15=0000000000000001 --- snip ---
Dump of PE optional header:
--- snip --- Magic: 0x020B (HDR64_MAGIC) MajorLinkerVersion: 0x09 MinorLinkerVersion: 0x00 -> 9.00 SizeOfCode: 0x001E6800 SizeOfInitializedData: 0x000A9400 SizeOfUninitializedData: 0x00000000 AddressOfEntryPoint: 0x001D3FC0 BaseOfCode: 0x00001000 ImageBase: 0x0000000140000000 SectionAlignment: 0x00001000 FileAlignment: 0x00000200 MajorOperatingSystemVersion: 0x0005 MinorOperatingSystemVersion: 0x0002 -> 5.02 MajorImageVersion: 0x0000 MinorImageVersion: 0x0000 -> 0.00 MajorSubsystemVersion: 0x0005 MinorSubsystemVersion: 0x0002 -> 5.02 Win32VersionValue: 0x00000000 SizeOfImage: 0x00296850 SizeOfHeaders: 0x00000400 CheckSum: 0x0029D33F Subsystem: 0x0002 (WINDOWS_GUI) DllCharacteristics: 0x8000 (TERMINAL_SERVER_AWARE) SizeOfStackReserve: 0x0000000000100000 SizeOfStackCommit: 0x0000000000001000 SizeOfHeapReserve: 0x0000000000100000 SizeOfHeapCommit: 0x0000000000001000 LoaderFlags: 0x00000000 NumberOfRvaAndSizes: 0x00000010 --- snip ---
I'd rather force the developers of the app to fix their code (making use of SetWindowLongPtr)...
Regards