Interrupts / Move most of int31 to winedos
jhei at iki.fi
Wed Nov 6 02:27:23 CST 2002
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
Jukka Heinonen <http://www.iki.fi/jhei/>
More information about the wine-devel