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:
- 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?
- Move routines INT_GetPMHandler* and INT_SetPMHandler* to winedos.
- 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.
- 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.
- 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.
- 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.
- Fix interrupt handlers so that they support DPMI32.
- 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.
- 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