Andreas Mohr wrote:
On Tue, Nov 05, 2002 at 06:47:35PM +0200, Jukka Heinonen wrote:
After this patch winedos contains almost complete int31 emulation. What has not been moved to winedos is mostly functions that require either W32S_WINE2APP or W32S_APP2WINE. This makes me wonder whether Wine still needs to support WIN32S...
Well, of course it does. Wine is supposed to run *all* reasonably new (i.e.: not "standard mode") Windows programs, and that does include Win32s IMHO.
Sure, I know that (I'm working on DPMI32 which isn't for standard mode Windows programs), I was probably being a bit unclear about what I was wondering about. It is quite difficult to find any information about Win32s nowadays and everything I have found was suggesting that Win32s was for running Win32 applications on Win16. Since Wine does run Win32 applications directly it just made me wonder whether Win32s support is something that was once needed when Wine only had Win16 support.
But, since I know very little about Win32s, I can only wonder. It all depends on how Win32s applications differ from Win32 and Win16 applications. The existence of Win32s dlls seems to suggest that Win32s applications are not regular Win32 applications as well as the text in "msdos/vxd.c" which talks about some strange pointer mangling required with Win32s applications. This mangling is probably something that is only required if Wine supports official Win32s dlls. Which makes me wonder if Win32s dlls provided by Wine actually do work because they don't seem to do any pointer mangling. Well, it could be that Win32s applications do this pointer mangling internally.
Anyway, I seem to have answered myself. If Wine is going to support Win32s applications using both builtin and official Win32s dlls, it needs pointer mangling. I just have to figure out how the required offset can be accessed from multiple dlls because I would really like to have all the interrupt handlers in one place. I still think that all the tricks required in order to support official Win32s dlls are quite ugly: all the routines that use linear addresses and are called directly by Win32s applications need to do pointer mangling and msdos/vxd.c actually modifies the official dlls in order to work around some problems. But since this most likely works already, I don't think I want to change anything.