How do interrupts in wine work?

[Nog]

  Nog wrote:

> Ove Kaaven wrote:
>
>> 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)
>>
> 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?

nog.