From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9602212301.AA12449@clio.rice.edu>
Subject: Re: v2 and dpmi
To: a DOT appleyard AT fs2 DOT mt DOT umist DOT ac DOT uk
Date: Wed, 21 Feb 1996 17:01:25 -0600 (CST)
Cc: djgpp AT delorie DOT com
Content-Type: text
Content-Length: 1651      

>   (1) Perhaps I don't want to write extra rhubarb to the hard disk of whatever
> PC I am running a GFnu C/C++ program on from a floppy or CD-ROM or net.

Currently there is no fix at all then, and won't be until someone finds the
time and motivation to provide one.  Since I don't have the motivation or time
to work on this (I think libc optimization and a real termio library would
be much more productive use of my time right now).  Maybe in a year or so.

>   (2) <<if it can't find DPMI>>: it would be hostage to any risk of there
> being a defective existing DPMI already in the PC.

You are always hostage to bugs in whatever environment you are using.  So
far this hasn't been a big problem with any other DPMI out there.
If you have a buggy DPMI, disable it, or get a patch.  One of the things 
which always prevented v1.x from proper hardware interrupt handling and
signal support was the maintenance of GO32.  

>   I want DJGPP to embed its proper DMPI in the compiled *.exe file if desired,
> same as it embeds copies of the maths library routines and fprint() etc if the
> user wants it to.

The source for the old GO32 is available, as is the source to the new stub,
and the source to CWSDPMI.  If you want it bad enough you will code it up
yourself.  But wanting things doesn't make it happen, unless you have enough
resources at your disposal to change wants into actions.

It's anticipated that improvements in DPMI providers will be made in the
future (faster, smaller footprint, more features) and with the current 
setup any V2.0 image can be instantly upgraded with a stubedit to a different
dpmi provider (and/or restubbing).