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)



Reply via email to