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.