X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Charles Sandmann 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: <200409070107 DOT i8717c0u020207 AT envy DOT delorie DOT com> <413d20ff DOT sandmann AT clio DOT rice DOT edu> 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 !!! :-(