Address space translation is not a small thing to do in the win32 API. Not only do you need to translate pointer parameters and return values for thousands of API function calls, you also need to translate pointers in (possibly nested) structures, and also to do the same for each and every possible window message, where the general message payload may be any one of a combination of integers, pointers, and structures of (structures of) pointers. The pointers may be data pointers where the pointed-to object may be data such as a string that needs to be readable and writable from either side of the address space, or functions that can be called from either side.
Why would you do that? They can just include the 32-bit libraries.
Wine works by changing enough of the windows system that the libraries can communicate with the host operating system.
Microsoft already has the 32-bit libraries, 'all' they have to do is make sure the parts of the libraries that interface with the rest of the system do the translation, which is much less work and a reasonably well defined edge.
Wow. Now I'm wondering whether WoW64 does all that, then - one missed API call reference or data structure and boom goes the 32-bit app.
I actually forgot memory managers were a thing when I was writing the parent comment, and momentarily thought the lack of address space translation would mean all 32-bit processes were stuck in the first 4GB of RAM. AST is indeed more of a thunking issue.
Thanks for the info about Win3emu, that's awesome!
See for example this effort at writing a win16 thunking layer in c# https://medium.com/@CantabileApp/implementing-window-messagi...