DOS/Win16 interrupt handling architecture

[admiral coeyman]

Jukka Heinonen,
> 
> 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.
>
	My C is not as good as it should be, however, I will test anything that I
get.  (Does winehq have a paper on applying patches?)  
 
> 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);
>
	And test to see if the Dos System has already been loaded.  Is there a reason
why you could not have more than one wine instance running, drawing on a single
wine server which has a single winedos module loaded?

> 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).

	That looks good to me.  I had a hard time figuring out which of the two
locations I was supposed to add code to.

> 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.

	There may be a few interrupts, like those mentioned earlier, which should be
left where they are.

> 5. Migrate the code of all handlers that can be easily migrated to winedos there
>    (int21 handler might not be easy to migrate).

	A number of the handlers might not be easy to migrate.  This is a good time to
look over what we have and see if we can do better.  This is something that
only has to be done once.

> 6. Refactor real mode interrupt handling code (for example, get default interrupt
>    handlers using GetProcAddress from 32-bit winedos instead of using fixed list).
> 
	Will you have a hard time with programs that need interrupt vectors in
seg:offset form?  When I was doing self-modifying code for fpu emulation, I was
told that there's no easy way to convert to seg:offset from linear addresses. 
Some software, like anti-debugger routines, will replace interrupt handlers in
real mode.  I'd like to see a way of converting linear addresses back to real.
	You also have to set up the dos environment so that the interrupt pointer list
is at the bottom of the dos ram to avoid having trouble with software which
calls the interrupt routines directly rather than through interrupt calls. 
And, we must account for intercepted hooks where a replaced handler calls the
real handler.  If you can do this with the dynamically loaded list, then I'm
all for it.

> 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:
>
	That is reasonable.
 
> 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).
> 
	Maybe we can even clean the code a bit to make speed gains.  Load time on some
software is a nightmare.

> 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.
> 
	Possibly.  We will run into this with some of the interrupts, like int 21h.
	God Bless,
		--Robert 'Admiral' Coeyman

-- 
---
May you live as long as you wish and age but a single day.
http://www.dotguy.net/                 admiral at corner.net
Webmaster/ Linux Administrator         Computer Co-Op/CornerNet