Mail Archives: djgpp/2004/09/06/23:15:27
> 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.
- Raw text -