Nog wrote: > Ove Kaaven wrote: > >> 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) >> > Ok, I have hacked togher something, but there is still something that > I'm not sure about: What to add to Eip? This seems to be 2, looking at > how other istructions are emulated. If this is so then there is > something else wrong because all dpmi programs that I have come up to > emulate a couple 32-bit instructions and then simply chocke when they > execute another one with privileged instruction. Anyway here's the > first draft of this code...
Ok, I have made some headway in this. I have confirmed that we have to add on 2 to Eip. What that exception realy is, is that the program does an LEA (Load Effective Address), and this aborts with a General Protection fault probably because the address to the lea instruction is invalid. How would one debug this? nog.