From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: cwsdpmi Date: Wed, 27 Aug 2003 09:12:25 CDT Organization: Rice University, Houston, TX Lines: 21 Message-ID: <3f4cbc49.sandmann@clio.rice.edu> References: <20030827034014 DOT 28093 DOT 00001084 AT mb-m29 DOT aol DOT com> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1061994788 9332 128.42.105.3 (27 Aug 2003 14:33:08 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: Wed, 27 Aug 2003 14:33:08 +0000 (UTC) X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > Only when no other version of CWSDPMI is found, > it should use the version included in the executable. If the other version of CWSDPMI is loaded into memory and providing DPMI services CWSDSTUB will use it instead of loading up another DPMI. If the other version is on disk and not loaded, CWSDSTUB won't search for it and will provide DPMI services (for that image and any nested DPMI image that might need them). I've always recommended using the standard stub instead of a stub with DPMI services. The only downside is an extra file in the distribution. If you need any files other than the .EXE to run, then there is no reason to insist on the DPMI being in the stub. Only when you distribute a single EXE image (like unzip.exe or ghost.exe) which is completely self contained does the extra file become an issue. But in that case you know the image works well with the included DPMI, so there isn't a need to search for an external one.