How do interrupts in wine work?

[Ove Kaaven]

On Sat, 16 Feb 2002, Nog wrote:

> The way that I see Interrupt handling in wine is that when a real-mode
> dos executable is loaded, the processor (or the os mabe?) is forced
> into v86 were the int xx intruction is not privilaged.

Well, int is sorta privileged in vm86 mode, otherwise an exception
wouldn't be raised...

> In this mode an exception is issued when an int xx is encountered and
> is then handeld by the exception handler is dosvm.c.  Which in turn
> checks if the we have a builtin handler for the interrupt and if so
> then we simply call its handler as defined in real_mode_handlers.
> But when the app switches to protected mode, the int xx instuction
> becomes privilaged and gets handeld by EmulateInstruction.  In this
> function the 32-bit version is not implemented but the 16-bit version
> is (Is this correct (the one is 16-bit the other 32-bit)?

That's correct.

> If not then what does long_op symbolise?)  Is it likley that this
> piece of code will ever get called?

It should never be called by Win32 apps, which is why 32-bit ints aren't
implemented. It's probably different for DOS apps that use 32-bit DPMI,
though, but those apps were never Wine's primary goal...

> 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.

> 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.