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/