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.
