How do interrupts in wine work?
nog at sdf.lonestar.org
Tue Feb 19 11:39:36 CST 2002
> Ove Kaaven wrote:
>> On Sat, 16 Feb 2002, Nog wrote:
>>> Ove Kaaven wrote:
>>>> On Sat, 16 Feb 2002, Nog wrote:
>>>>> 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
>>>> (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
>> the stack) is 16-bit. So it's all taken care of by the 16/32 relay
>> 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
>>> 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
>> to winedos and its interrupt tables, so you don't have to do anything
>> this to work (except make int31 (DPMI call) work in 32-bit, of course)
> Ok, I have hacked togher something, but there is still something that
> I'm not sure about: What to add to Eip? This seems to be 2, looking at
> how other istructions are emulated. If this is so then there is
> something else wrong because all dpmi programs that I have come up to
> emulate a couple 32-bit instructions and then simply chocke when they
> execute another one with privileged instruction. Anyway here's the
> first draft of this code...
Ok, I have made some headway in this. I have confirmed that we have to
add on 2 to Eip. What that exception realy is, is that the program does
an LEA (Load Effective Address), and this aborts with a General
Protection fault probably because the address to the lea instruction is
invalid. How would one debug this?
More information about the wine-devel