X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Bart Oldeman Newsgroups: comp.os.msdos.djgpp Subject: Re: DJGPP's NULL pointer protection seems to violate DPMI spec Date: Tue, 07 Sep 2004 20:34:57 +1200 Organization: Ihug Limited Lines: 47 Message-ID: References: <200409070107 DOT i8717c0u020207 AT envy DOT delorie DOT com> <413d20ff DOT sandmann AT clio DOT rice DOT edu> NNTP-Posting-Host: 222-152-121-96.adsl.ihug.co.nz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: lust.ihug.co.nz 1094546098 29120 222.152.121.96 (7 Sep 2004 08:34:58 GMT) X-Complaints-To: abuse AT ihug DOT co DOT nz NNTP-Posting-Date: Tue, 7 Sep 2004 08:34:58 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en In-Reply-To: <413d20ff.sandmann@clio.rice.edu> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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 Charles Sandmann wrote: >DJ Delorie wrote: >>DJGPP does not violate the DPMI spec because DJGPP does not >>*implement* the DPMI spec. When it calls DPMI 0507 to uncommit the >>zero page, the DPMI server is permitted to do one of two things: > > >>1. Uncommit the page. >>2. Report an error 8023H (invalid handle). > > >>DJGPP programs will accept either of these results. If your DPMI server >>does anything else, your DPMI server is broken. > > > DJ is completely correct here, and let me add a bit of history. DJ and I corresponded using some more private emails. I agree now, too. As far as I understand it now it's an extension of the DPMI server that DPMI clients can try to use, not a violation -- the spec doesn't explicitly disallow it, it only says it's not guaranteed. 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)? > It also works for 386MAX. In addition, some Borland add-ons for Windows > did NOT support DPMI 0x504 correctly, so calling this function could > result in crashes. You can still see commented code in the stub about > calling 0x504 for a handle and the comment about why it's a bad idea. :( I see. That would require the client to check for the server before calling 504H. 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. But then if all known DPMI servers that support 0507H implement this extension, why should it (practical reason)? 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. Bart