From: Charles Sandmann 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).