Xref: news2.mv.net comp.os.msdos.djgpp:1280
From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: v2 and dpmi
Date: Mon, 19 Feb 1996 18:22:08 CST
Organization: Rice University, Houston, Texas
Lines: 20
Message-ID: <31291430.sandmann@clio.rice.edu>
References: <199602182216 DOT XAA25320 AT plato DOT algonet DOT se> <2q7JxUaapmWX090yn AT ibm DOT net> <4gavk6$k83 AT leonard DOT anu DOT edu DOT au>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: clio.rice.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> It would be nice to be able to just copy the EXE and know that it was 
> going to run - it is easy to forget CWSDPMI and have to come back for it.

Well, I have this working, right now it's just not trivial to use, and
I wasn't sure it was worth making things more complicated.

> I seem to remember that the CWSDPMI image is just a few kB ? 

Actually around 26Kb.

> embedding ought to be the default behaviour, used when no external copy.

Well, I disagree here, but I think having an option to imbed it (or other 
DPMI providers) should be discussed.  The way it currently works is if it
can't find DPMI, it WRITES CWSDPMI.EXE to the application directory, then
executes it.  This wouldn't work on CDROM, write protected Net drives, or
write protected floppies, but I didn't see that as being a huge problem.

This is still all in the playing with it stage as far as I'm concerned,
not ready for production code.