From:	Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject:	Re: v2 & descriptors
To:	babcock AT cfa DOT harvard DOT edu
Date:	Sun, 27 Nov 1994 23:08:18 -0600 (CST)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

> > It will come out when it is finished, hopefully 1Q95.  New features:
> > faster, small low memory requirements (GO32 goes away), single API
> > for programming (DPMI), signals, ansi/posix, etc.
> 
> Will v2 allow you to bind the DPMI provider to your executable so that the
> user doesn't have to worry about whether or not it needs to be installed?
> I think this is important for end users who have no idea what DPMI means.

The way it works (and this is pretty polished code, probably close to done):

The 2K stub sees if DPMI is present.  If not, it then execs a program
(named in the editable stub) which should provide DPMI services.  This
program is searched for in the following places:
 1) same directory as the image itself (for easy distribution)
 2) path
 3) current directory
 
Since the 2K stub is much smaller than the current stub, and the free DPMI
is less than 1/3 the size of GO32, this is a win/win even if DPMI is not
present.  If you are running make or gcc which invokes nested programs,
they see the loaded dpmi from the top level and use it (not loaded again).

The free DPMI is set up so it de-installs itself after the last client
is done, freeing the memory.  You can also load it as a TSR if you have
the memory and want slightly faster loads.

It even loads in UMB's if you have the space.

Since the emu387 library can be linked into the image, to distribute an
exe image all you would need would be the image and cwsdpmi.exe in the
same directory.  The free dpmi would not be used if another DPMI was
present (unless you load it as a TSR).

I am really pleased with how well it works (probably easier than V1.x).

- Raw text -