Date:	Tue, 26 Jun 2001 16:12:47 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Peculiar behavior of program.
In-Reply-To:	<3b37e10a.286661752@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010626161231.17201D@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 26 Jun 2001, Graaagh the Mighty wrote:

> >> Well, why is there no traceback for the user code then?
> >
> >Because the traceback you are used to see comes from the application, not 
> >from CWSDPMI.
> 
> Okay, so you're saying an application crashes, whereupon either a
> traceback is emitted or not, depending apparently on whether the DPMI
> host or some other associated "attachment" detects the access
> violation. The DPMI host produces poorer info.

Yes.

> Is there a way to ensure the other "attachment" is always the first
> one to detect the violation?

No.  The DPMI host always gets the first chance to look at any
exceptional condition.

> >But, however cautious that code is, it cannot cope with all possible 
> >problems.  For example, imagine that the SS selector is invalid: in that 
> >case, calling library functions will just cause another exception.
> 
> Exactly what would user code have to be doing to mangle the SS
> selector?

Any number of things.  It could simply load some value into SS in
inline assembly.  Or call int86x with wrong arguments.  Or installe a
real-mode callback with wrong parameters.

> >The application is dying horribly, not the DPMI host.
> 
> Your original statement was either incorrect then or unclear and
> ambiguous; I read it as saying that CWSDPMI crashed.

I knew you won't want to understand.

- Raw text -