Mail Archives: djgpp/2000/03/15/21:12:24
On Tue, 14 Mar 2000, Michael Tippach wrote:
> > > 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.
> >
> > I'm not sure I understand what problem does this solve. Currently,
> > the EM bit is set by calling function 0E01h at startup.
>
> Setting the EM bit TEMPORARILY from within the IRQ 0x13 interrupt
> handler to cause a single INT 0x7 upon the next FPU instruction.
And what if the next FPU instruction never comes, or comes too late?
> Once you are in the context of a DPMI exception handler, you can
> continue execution wherever you desire. IOW: as opposed to a hardware
> interrupt handler where that isn't possible, one can do a complete
> context switch from within an exception handler.
Exceptions are easier than interrupts, but it is still not trivial to
run arbitrary code from them.
> That is, BTW what DJGPP
> does when it receives the GPF or stack fault or whatever would be the
> outcome of the segment limit alteration thing.
Not before it does quite a bit of trickery to get things to their
normal state again.
> As soon as an IRQ is
> converted into a DPMI exception, the problem is essentially solved.
The problem is not solved until you eliminate the reason for the
exception; if you don't, you will get the same exception again when
the faulting instruction is restarted. For fake exceptions triggered
by deliberately lowering the DS limit, this is easily done, since we
lowered the limit ourselves. For real exceptions, it's not so easy.
> > CPL 3 environment for writing ``normal'' application programs.
> > Writing low-level stuff like OS kernels is not something DJGPP is
> > meant to be well suited for.
>
> I meant a DPMI host that runs the client at ring 0 for convenience
> reasons. In a non- multitasking, non- VM- environment there is very
> little reason left to maintain all that ring switching overhead.
Why ``non-VM''? DJGPP (and DPMI in general) does support VM. (I'm
assuming that VM means Virtual Memory.)
> > > One possibility would be to conditionally alter the CS limit instead,
> > > _IF_ the DPMI host is CPL0 OR NTVDM (should work with both).
> >
> > Not good. CPL 0 and NT are among the least interesting DJGPP targets.
>
> This discussion started with someone complaining about NTVDM screwing up
> DJGPP signal handling.
The point is that it hardly makes sense to futz with CS just to fix
NT, which has a few other serious DJGPP- and DPMI-related bugs anyway.
You can see them listed in section 3.3 of the DJGPP FAQ list.
> it takes 3 more lines of assembly code to detect NT.
That's not really true, especially now that you need to distinguish
between NT and W2K.
> > > OR,
> > > one somewhat more memory intense, albeit pretty generic approach would
> > > be to let the interrupt handler make a copy of the code section
> >
> > ALL of the code section? That might be megabytes to move inside an
> > interrupt handler, right?
>
> Very few applications contain megabytes of code. Initialized data is
> what makes applications fat.
The DJGPP setup makes CS and DS reference the same memory. So you
don't always know where you code ends and the data begins (a program
could put code in some data variable in malloc'ed storage).
So you will end up moving the entire CS/DS segment, which frequently
*is* many megabytes.
> > Moving the code also makes debug support next to impossible (if you
> > want to debug programs which install signal handlers).
>
> Different issue, admittedly.
Different, but important. Without good debugging support, you don't
really have a sound development environment.
- Raw text -