FPU handling got broken over half a year ago when
I removed separate interrupt DLL and added support
for DPMI32. Interrupt DLL made sure that builtin
protected mode interrupt handlers saw regular IRET
return record on stack. Current protected mode
interrupt code does not provide an IRET record and
Jukka Heinonen,
FPU handling got broken over half a year ago when
I removed separate interrupt DLL and added support
for DPMI32. Interrupt DLL made sure that builtin
protected mode interrupt handlers saw regular IRET
return record on stack. Current protected mode
interrupt code does not
Sylvain Petreolle,
Actual implementation of the int 3d call (Standalone FWAIT)
is to patch the code to an fwait(9b) and a noop(90).
This is what emmulators do when a real FPU is present in the system. With
wine, it is safe to assume that an FPU of some kind will always be present so
Sylvain Petreolle,
After doing some winedbg work, it appears that :
- my call appears at 0x36f:0xc and should return at 0x36f:0xe
Wine-dbgdisass 0x36f:0xc
0x036f:0x000c: int $0x3d
0x036f:0x000e: movw 0xfffc(%bp),%ax
0x036f:0x0011: movw 0xfffe(%bp),%dx
Seems we have all dword pointers on the stack.
This is the stack I have for the DOSVM_EmulateInterruptPM call,
Cs and Eip have been pushed on the stack. 0x36f and 0xc are the
location the location of the call to the interrupt.
Wine-dbginfo stack
Stack dump:
0x41a60948 (_end+0x10bff4): 4008de8b
interrupt handling, as perhaps they affected the EIP that the
interrupt
handlers get, making it point before the int instruction instead of
after. Robert Coeyman's code assumes the latter (after the int,
requiring the subtraction), and that's what's happen in real
DOS/Win16
to my knowledge,
Actual implementation of the int 3d call (Standalone FWAIT)
is to patch the code to an fwait(9b) and a noop(90).
It seems that it corrupts the stack in FPU_ModifyCode and prevents vb3
programs
to start. (tests made with current CVS)
Since we do nothing apart an emulated fwait, I commented the
