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: Mon, 06 Sep 2004 21:46:23 CDT Organization: Rice University, Houston, TX Lines: 34 Message-ID: <413d20ff.sandmann@clio.rice.edu> References: <200409070107 DOT i8717c0u020207 AT envy DOT delorie DOT com> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1094526439 5712 128.42.105.3 (7 Sep 2004 03:07:19 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: Tue, 7 Sep 2004 03:07:19 +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 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. The DPMI spec tries to support both 16-bit and 32-bit environments - which is why page alignment might not be supported. But any 32-bit environment which might potentially support the DPMI 1.0 functions probably returns handles page aligned anyway. It just so happens that when CWSDPMI was being written, there was only one existing DPMI 1.0 implementation, which was 386MAX. It supported DPMI 1.0 features on DPMI 0.9 handles. I didn't want to duplicate code in CWSDPMI, and compatibility is a good thing, so I chose to handle things the same way. We coded DJGPP to work with either one, and it's been that way for about 9 years now. > The reason we do it this way is because 0504 is a DPMI 1.0 function so > we can't rely on it being available to allocate the memory. However, > if 0507 *happens* to work (which it does for CWDPMI), we get NULL > protection. 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.