On Sat, 16 Feb 2002, Nog wrote:
Ove Kaaven wrote:
On Sat, 16 Feb 2002, Nog wrote:
[SNIP]
And if so then why does it assume that the insterrupt it is emulating is not builtin?
The table of 16-bit interrupt entry points is initialized from wprocs.dll (dlls/kernel/wprocs.spec), so it doesn't need to assume anything.
This was my point. When emulating these interrupts it pushes the values of Eflags, Cs and Eip onto the stack but none of the interrupt handlers call the iret instruction or pop anything off the stack. What have I missed?
They can't do that, of course, as they're 32-bit code, and the caller (and the stack) is 16-bit. So it's all taken care of by the 16/32 relay thunks generated by winebuild from the .spec file.
What all of this probable garbage came from is: What will it take to emulate int xx from 32-bit code?
A sane mechanism to handle those interrupt vectors, probably.
I assume that the Would this be somthing like the code in msdos/interrupts.c?
Perhaps.
But then why do we need to have 2 tables for interrupts (one in msdos/interrupts.c, the other in dlls/winedos/dosvm.c)? The only explanation I can come up with is that mabe, just mabe, the interrupts in wproc.spec get called from 16-bit windows.
From 16-bit protected mode, which typically means Win16, yes.
The winedos tables are for 16-bit real mode (v86 mode).
Back to implementing int xx from 32-bit code, are all of the interrupts availible in real mode availible in protected mode?
No. Almost no interrupts are available. Calling DOS interrupts from protected mode requires explicit thunking, and apps typically requests such services from DPMI. Some thunks are provided by Windows (for compatibility) in 16-bit mode, but AFAIK none are provided in 32-bit.
If an app does use DPMI in Wine, then the request will be properly routed to winedos and its interrupt tables, so you don't have to do anything for this to work (except make int31 (DPMI call) work in 32-bit, of course)