http://bugs.winehq.org/show_bug.cgi?id=3840
------- Additional Comments From focht@gmx.net 2007-10-05 09:06 ------- Hello,
just took this one as random pick.
The crash reason of the demos (probably written in .flat assembler) is simple: all imports are by ordinal only. This imposes problems because wine maintains most .spec files without explicit ordinals. If people add new/missing functions/exports without explicit ordinal spec they get automatically assigned (linear from beginning). These ordinals might not be the same as in windows.
Following is my analysis with one demo supplied by previous attachment (all others suffer from same problem):
============================== 2mPasM.exe demo (4k):
Wrong imports by ordinal (wine):
--- snip --- 00401020 33 CharNextExW USER32 0040101C 97 DdeCreateStringHandleW USER32 00401018 269 GetMessageTime USER32 00401010 510 SetWindowLongW USER32 00401014 655 USER32_655 USER32
00401000 562 GDI32_562 GDI32
00401008 183 DefineDosDeviceW KERNEL32 --- snip ---
Correct imports by ordinal (used windows xp to dump imports)
--- snip --- 00401020 33 ChangeDisplaySettingsA USER32 0040101C 97 CreateWindowExA USER32 00401018 269 GetDC USER32 00401010 510 PeekMessageA USER32 00401014 655 ShowCursor USER32
00401000 562 SetPixel GDI32
00401008 183 ExitProcess KERNEL32 --- snip ---
Yes, this is bad practice, because Micro$oft doesnt guarantee that ordinal numbers of the exports in Windows system Dlls are to be the same across different Dll versions (usually do but no 100% guarantee). I didnt search further, there could be more bug reports which suffer from same.
What's the developers consensus on this? Either fix to match windows ordinals (.spec/export files could be cross checked with script against windows ordinals) or mark all bug reports in this category as invalid (broken apps).
Regards
-
Wine Bugs