From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: CWSDPMI/DJGPP integration [was Re: Peculiar behavior of program.]
Date:	Fri, 29 Jun 2001 0:56:41
Organization:	Aspen Technology, Inc.
Lines:	20
Message-ID:	<3b3bd249.sandmann@clio.rice.edu>
References:	<3b3bcc05 DOT sandmann AT clio DOT rice DOT edu> <3b3c14b3 DOT 264226436 AT news DOT primus DOT ca>
NNTP-Posting-Host:	dcloan.hou.aspentech.com
X-Trace:	selma.aspentech.com 993794519 9881 10.32.115.107 (29 Jun 2001 06:01:59 GMT)
X-Complaints-To:	postmaster AT aspentech DOT com
NNTP-Posting-Date:	29 Jun 2001 06:01:59 GMT
X-NewsEditor:	ED-1.5.8
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> The DJGPP code that sets some of this stuff up wounld, of course, need
> to detect DPMI 1.0 feature availability and act accordingly.

It's the exact same call the crt0.s makes to set the null page.  Actually
it just does it and ignores the return code.  You would just make the same
call to set some memory read-only.

> What about stack overruns?

Just like the null page, set 64K (or some amount) of memory at the bottom
of the stack to be not-mapped (invalid) just like the null page.  On the
basis of ESP/EBP pointing anywhere near this section you could state this
is the error in the DJGPP traceback.

This won't catch huge overruns, but if you write-protect the entire text
section you will at least prevent overwrite of executable code and catch
errors sooner with correct error messages.

Critical writeable data could be even toggled to be read-only, read-write,
read-only for the really paranoid.

- Raw text -