How do interrupts in wine work?
Ove Kaaven
ovehk at ping.uio.no
Sat Feb 16 09:32:12 CST 2002
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.
More information about the wine-devel
mailing list