Date: Tue, 26 Jun 2001 16:12:47 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.