X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DJGPP's NULL pointer protection seems to violate DPMI spec
Date:	Tue, 07 Sep 2004 22:59:23 CDT
Organization:	Rice University, Houston, TX
Lines:	42
Message-ID:	<413e839b.sandmann@clio.rice.edu>
References:	<chip62$4sb$1 AT lust DOT ihug DOT co DOT nz> <200409070107 DOT i8717c0u020207 AT envy DOT delorie DOT com> <413d20ff DOT sandmann AT clio DOT rice DOT edu> <chjrri$se0$1 AT lust DOT ihug DOT co DOT nz>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1094616973 8884 128.42.105.3 (8 Sep 2004 04:16:13 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	Wed, 8 Sep 2004 04:16:13 +0000 (UTC)
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> DJGPP's crt0.s could be modified to use 0504H before trying 0501H so it 
> will be able to support NULL pointer protection on DPMI servers that 
> don't provide this extension. But then if all known DPMI servers that 
> support 0507H implement this extension, why should it (practical reason)?

The code must go in stub.asm (crt0.s is too late).  It already exists 
there, was tested, and is commented out since it caused problems on systems
with certain Borland extensions installed.  Best case was DJGPP images
wouldn't run at all under Windows.  Worst case was running a DJGPP image
caused Windows to reboot.  It's possible that all that bad Borland VxD
code is long gone, but you never know.

There would also need to be changes to sbrk() in crt0.s to call 0x504
so pages could be uncommited elsewhere in the memory space, but the
NULL pointer protection page is allocated with the first memory block in
stub.asm.

> Otherwise DJGPP's crt0.s could be modified to use 0504H before trying 
> 0501H so it will be able to support NULL pointer protection on DPMI 
> servers that don't provide this extension. 

That's actually exactly what the (commented) code in stub.asm does.  
And Borland is why it's commented out.

> But then if all known DPMI servers that support 0507H implement this 
> extension, why should it (practical reason)?

At the time it was written we were still collecting DPMI servers and
trying to be as DPMI compliant as possible.  I don't know for sure how
far OS/2 took their DPMI server with features - most of that development
was after we quit testing with OS/2 2.0

> As to the problematic program we'll try to contact the original author
> or otherwise binary patch it. Hopefully there aren't too many of these 
> -- if this is the only program that is so buggy then a DOSEMU option to 
> disable uncommitted memory is overkill.

crt0 supports a flag to turn off the null page protection; you can also 
just binary patch it to NOP the code that turns on the null page protection.

CWSDPMI also supports a flag to turn off extensions, just to solve problems
like these ... but it works under Windows !!! :-(

- Raw text -