Mail Archives: djgpp/2000/03/13/14:48:46
Damian Yerrick wrote:
[...]
> >> 1. DJGPP's method of handling signals (cause an intentional GPF)
> >> trips up NT.
> >
> >Depending on the DPMI host, DJGPP's sub- optimal method of handling
> >signals, altering the DS- (but implicitely also the SS-) segment limit,
> >can generate a stack fault instead. Generally, pulling away one's own
> >stack is not a particularly smart thing to do and destined to fail under
> >virtually any CPL 0 DPMI host anyway. There are better ways.
>
> If you know any better ways, tell us. (DJGPP NG added)
>
IIRC even FPU exception handling is done using the segment limit
alteration kludge. A way that would also work under NT is to make the
IRQ 13 handler just set the EM bit in CR0 by trying both, DPMI function
0xE01 and direct writes to CR0. Works in any DPMI environment I've seen
so far. Under a CPL 0 host, conditionally setting the NE bit (just once
at startup) allows for exception 16 instead of involving the interrupt
controller.
Using the EM bit method, however, will let the next FPU instruction
trigger an exception 7, which then can be normally processed, having
full access to the main context etc blah blah blah
Source code for this is available (The WDOSX Win32 API emulation handles
FPU exceptions that way).
CTRL-C and friends are a bit trickier.
One possibility would be to conditionally alter the CS limit instead,
_IF_ the DPMI host is CPL0 OR NTVDM (should work with both).
OR,
have the run time environment maintain SS as a mere alias to DS.
OR,
one somewhat more memory intense, albeit pretty generic approach would
be to let the interrupt handler make a copy of the code section and fill
the original with some opcode to trigger an exception - just all FF's
should do. 0xCC, anyone? The exception handler, that like magic does not
reside in aforementioned code section could then restore the original
from the copy and do whatever its actual business is.
More than one way to skin a cat, really.
Regards,
Michael Tippach
- Raw text -