From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: CWSDPMI - CWSPARAM Date: Tue, 2 Nov 1999 22:46:02 Organization: Aspen Technology, Inc. Lines: 43 Message-ID: <381f69aa.sandmann@clio.rice.edu> References: <381EF430 DOT C6CC9270 AT ma DOT tum DOT de> NNTP-Posting-Host: dcloan.aco.aspentech.com X-NewsEditor: ED-1.5.8 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > But obviously the strategy for locating the DPMI-host for a given stubbed > executable (e.g.: c:\djgpp\bin\PROG.EXE) is quite different. > (please correct me when I'm wrong) > 1. if any DPMI-host is already memory-resident don't load > (e.g. under WINx or cwsdpmi TSR'd) > 2. else if CWSDPMI.EXE can be found in that directory where the executable > resides, that one is loaded. (e.g.: c:\usr\bin\CWSDPMI.EXE) > 3. else if CWSDPMI.EXE can be found on the users %PATH%, that one is > loaded. (e.g.: c:\djgpp\bin\cwsdpmi.exe) > 4. else if CWSDPMI.EXE can be found in the current directory, that one is > loaded (e.g.: .\cwsdpmi.exe) > 5. else emit the 'NO DPMI' message You are right. Some logic behind this: 1) If DPMI is there already, you don't have a choice. 2) If there is one in the same directory, it may have custom parameters, be shipped with the application and you don't want to modify the path, and is the fastest place to find it (the directory should still be in a DOS buffer, no searching needed). Convenient for the DJGPP distribution also. 3 & 4) Path then local directory was easier to code, and sort of a unix compromise (which doesn't search . by default). You can argue it should be the other way I guess, but it's not ... > So one idea to get around could be to recode cwsparam.c to use the above > strategy for locating the cwsdpmi target when typing something > like 'cwsparam prog.exe maxswap=346' (I offer to do that if desired) This might drive me crazy building the distribution with multiple CWSDPMIs in my path, but wanting to modify the make'ed image. A warning about ambiguous CWSDPMIs in the local + path might make sense. > Another idea could be to recode cwsdpmi.c to display its internal parameters > when started if a given environment is set (e.g.: set GO32=VERBOSE) > to have the possibility of verifying the cwsdpmi parameters when > launching a DJGPP application. I really don't want to add the bloat to every copy of CWSDPMI out there to add enviroment checking code plus print formats (many people keep it memory resident). A better idea is to fix the release so a single set of parameters works well everywhere needed (maxswap really should not need much tweaking if it were not for the 255Mb total address space bug).