From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: OpenDos acting up...
Date: Thu, 10 Jul 1997 22:30:39
Organization: Aspen Technology, Inc.
Lines: 16
Message-ID: <33c5628f.sandmann@clio.rice.edu>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970710192500 DOT 20790A-100000 AT is>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: spica.dmccorp.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

> This must be false, or at least inaccurate: DJGPP programs don't use any 
> DPMI 1.0 extensions, unless you explicitly call functions from DPMI 1.0.  

Not true.  crt0.s attempts to use a DPMI 1.0 extension to enable the 
null page protection (but this doesn't seem to cause OpenDOS's dpmi problems).
npxsetup uses a DPMI 1.0 extension to enable FPU exceptions to be sent to
the 32-bit client instead of the OS (for emulation).  All DPMI 0.9 servers
except Windows 3.0 support this (uhh, until OpenDOS, that is...).  FPU
support is the one and only DPMI 1.0 extension Windows supports.  I expect
usage of this DPMI call causes OpenDOS problems since it is a larger number 
than any of the other function values and runs off the end of a function table
which is not checked for validity.

If DJGPP V2.x supported the "387=Y" flag, use of this DPMI 1.0 feature 
could be avoided, and the OpenDOS DPMI might work out of the box on machines
with floating point hardware.