First post, by kjliew
No sure if anyone has ever done this or there are available resources online that were archived. It seems to me that Microsoft has never shown any interests to make such information public so that 3rd-parties can provide solution to bridge compatibility issues without resorting to emulation, but I have no insights on those with access to MSDN developers' subscription. Obviously, my great interests is to restore Win9X games play-ability on Win2K/XP or more recent Windows if possible.
The most notorious example is the GDI32 BitBlt(). Many Win9x era games simply failed because the API returned value changed from "number of lines blt'ed" to boolean "TRUE/FALSE". Other examples on my radar such as FreeLibrary() returned reference count instead of boolean TRUE/FALSE. Those information were hard to come by and buried deep within community patches, APIs hookers and DxWnd-like enhancements. I guess Windows ACT is somehow also a layer of translation that provides such solution.
Today's mingw-w64-i686 toolchain can easily build proxy DLL. Only the hooked APIs need to be implemented while the tools generate forwarder RVAs for the rest of the APIs using DLL .DEF file. Kontza published a good article for MSVC toolchain here, but I prefer the mingw GNU toolchain. Kontza's method uses LoadLibrary()/GetProcAddress() for the hooked API. This is no longer needed with mingw GNU toolchain, and it is as simple as calling the API directly.
int WINAPI wrap_BitBlt(
HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight,
HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop
// Call the real blitter, and store its return value.
BOOL retVal = BitBlt( hdcDest,
return (retVal)? nHeight:0;
And the DLL .DEF file takes care of the symbol redirection.
BitBlt = wrap_BitBlt
OtherFunc = gdi32.OtherFunc
Similar technique can be used for timeGetTime() in WINMM.DLL discussed here.