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.