DOS/Win16 interrupt handling architecture

[Jukka Heinonen]

On Sun, Oct 13, admiral coeyman wrote:
> 	As I understand this, what you are asking has been a design goal for some time
> now.  Since the DOS section is where I stay when I submit patches, I would like
> to volunteer what limited assistence I can.  This looks like something which
> would benefit wine.  Making the whole system more modular allows for easier
> modification of the whole project and gives us a potential for special
> modules.  This will also help developers to find the code that they are looking
> for.  I had a horrid time adding the FPU interrupts because I couldn't track
> down where to attach the interrupts.

Okay, any assistance is welcome. Especially critic on my approach to
interrupt handling would be welcome as well as auditing interrupt handling
patches and testing interrupt code on Win16, DOS RM, DOS DPMI16 and DOS DPMI32.

Here is my plan for interrupt handling, please comment if this does
not look reasonable:

1. Move interrupt handling code from INSTR_EmulateInstruction to winedos and
   convert INSTR_EmulateInstruction to do something like this when interrupt
   is to be emulated:
     if(!Dosvm.EmulateInterruptPM && !DPMI_LoadDosSystem())
       ERR(...);
     else
       Dosvm.EmulateInterruptPM(context);
2. Move routines INT_GetPMHandler* and INT_SetPMHandler* to winedos.
3. Add interrupt handlers for all wine/msdos/*.c interrupts to winedos 
   (these may just delegate handling by calling INT_Int*Handler).
4. Add 16-bit interrupt handler entry points to winedos (similar to wprocs.dll).
   Make routines INT_GetPMHandler* and INT_SetPMHandler* default to
   winedos handlers instead of wprocs.dll handlers.
5. Migrate the code of all handlers that can be easily migrated to winedos there
   (int21 handler might not be easy to migrate).
6. Refactor real mode interrupt handling code (for example, get default interrupt
   handlers using GetProcAddress from 32-bit winedos instead of using fixed list).

At this point, Wine functionality should not have changed but interrupt
handlers have been migrated to winedos. Now it would be possible to really start
improving Wine interrupt handling:

1. Fix interrupt handlers so that they support DPMI32.
2. Add support for asynchronous interrupts in PM when using DPMI16 or DPMI32
   (IRQs, timer, keyboard). This probably requires some VIF/VIP magic to prevent
   nested interrupt handling and interrupt handling while in Wine code.
3. Add support for interrupt reflection (both DPMI16 and DPMI32 should reflect 
   many interrupts from protected mode handlers to real mode handlers and
   in some cases from real mode handlers to protected mode handlers).

Finally, when interrupt code works fine, it can be checked if parts of
DOSMEM could be moved to winedos, too. DOSMEM unfortunately has lots of 
intricate interactions with other parts of Wine which might make this 
too complicated.

--
Jukka Heinonen <http://www.iki.fi/jhei/>