Contacted by a developer, WINE supports Windows 9x Win16 thunks and, unlike Windows 9x/ME, will not prevent use of GetProcAddress() to use them.
Update this code:
|
/* This hack relies on undocumented Win16 support routines hidden in KERNEL32.DLL. |
|
* They're so super seekret, Microsoft won't even let us get to them through GetProcAddress() */ |
|
kern32 = GetModuleHandle("KERNEL32.DLL"); |
|
if (windows_emulation == WINEMU_WINE) { |
|
/* FIXME: Direct ordinal lookup doesn't work. Returned |
|
* addresses point to invalid regions of KERNEL32.DLL. |
|
* I doubt WINE is even putting a PE-compatible image |
|
* of it out there. |
|
* |
|
* WINE does allow us to GetProcAddress ordinals |
|
* (unlike Windows 9x which blocks it) but I'm not |
|
* really sure the returned functions are anything |
|
* like the Windows 9x equivalent. If we assume they |
|
* are, this code seems unable to get the address of |
|
* KRNL386.EXE's "GETVERSION" function. |
|
* |
|
* So basically WINE's Windows 9x emulation is more |
|
* like Windows XP's Application Compatability modes |
|
* than any serious attempt at pretending to be |
|
* Windows 9x. And the entry points may well be |
|
* stubs or other random functions in the same way |
|
* that ordinal 35 is unrelated under Windows XP. */ |
|
return 0; |
|
} |
Contacted by a developer, WINE supports Windows 9x Win16 thunks and, unlike Windows 9x/ME, will not prevent use of GetProcAddress() to use them.
Update this code:
doslib/hw/dos/w9xqthnk.c
Lines 54 to 77 in fbe2e57