From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9610282300.AA16621@clio.rice.edu>
Subject:	Re: function _exit() and about dbgcom.c
To:	billc AT blackmagic DOT tait DOT co DOT nz (Bill Currie)
Date:	Mon, 28 Oct 1996 17:00:38 -0600 (CST)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<3275EE1F.3DC@blackmagic.tait.co.nz> from "Bill Currie" at Oct 29, 96 11:44:31 am

> > When I wrote the debug stuff, there was no undocumented feature usage in DJGPP,
> > thus no problems with the pseudo PSP (used for command line passage only).
> > Since DPMI providers mess with the PSP themselves, you are asking for trouble.
> > This is part of the reason the debuggers originally had a one pass design.
> 
> Should I experiment with it?  What does cwsdpmi do to the psp (if anything)?
> If windows messes with the psp, surely it would hook the create/set psp calls (but then again, 
> look at cli/sti).

The PSP stores the segment (converted to selector) of the environment.  Some
DPMI providers use the PSP current at the time of an int 21h, ah=4c PM call
to clean up their structures (to decide which nested clients need to be
purged, etc).  CWSDPMI just blindly assumes you don't mess with the PSPs
and the internal stack is consistent with it's assumed value for your PSP.
But each DPMI is different - if you plan to play with this you need to collect
one of each type of DPMI for testing (or find people willing to test it for
you).  If you perfectly wind/unwind your PSP calls and don't do anything 
which would cause the current PSP to be inconsistent with what the DPMI 
might think it is, you might get away with it.  Be careful what you do with
PSPs in protected mode under things like windows with built in extenders,
they have their own interpretation of what they do with this stuff with
protected mode I/O.

- Raw text -