DOS/Win16 interrupt handling architecture
Jukka Heinonen
jhei at iki.fi
Sat Oct 12 03:30:21 CDT 2002
I have been thinking about interrupt handling in Wine
because it needs some reworking in order to get DPMI32
programs to work. I have formed a proposal for refactoring
current interrupt handling code and I would like to
get some comments about this scheme before I decide whether
I want to work on it or not.
So, my proposal is to move all interrupt handlers to
winedos dll and have only single interrupt handler routine
per interrupt, instead of having separate real and protected
mode handlers. If an interrupt occurs in protected mode
ntdll would just load winedos and call single function from
winedos that simulates the interrupt.
A list of some things pro and con the proposal:
+ Win32 programs don't care about interrupt handlers.
It would seem reasonable to think that many Win16 programs don't
need them either. Also, architectures not supporting
DOS/Win16 probably don't want to have any interrupt code.
+ Real and protected mode interrupt handlers are heavily
interconnected. For example, protected mode handlers already
serve both real mode and protected mode interrupts. MSDN documentation
also says that nearly all interrupts under Win16 work just like they
do under DOS real mode.
+ Differences in handling interrupts depend more on whether we are running
DOS or Windows process than on whether the interrupt was called from
real or protected mode.
+ We would only have one place that handles interrupts. This
should make it easier to maintain interrupt code.
+ DLL separation would be easier because we would require
far fewer calls between winedos and ntdll.
- Win16 programs using interrupts take a bit longer to start and
they get all kinds of unnecessary stuff into their address space from
winedos.
- Restructuring stuff means lots of work and possibility for regression
bugs in Win16 support.
P.S. I have a good idea on what needs to be done to make Wine support
DPMI32. I have actually got some 32-bit DOS extenders to almost work.
However, this requires lots of interrupt related work and I would
like to wait until I get enough feedback about this interrupt
refactoring proposal in order to see whether to continue working using
the current interrupt code.
--
Jukka Heinonen <http://www.iki.fi/jhei/>
More information about the wine-devel
mailing list