Mail Archives: djgpp/1999/11/03/23:41:54
On Tue, 2 Nov 1999, Waldemar Schultz wrote:
> 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
This is correct. This logic is in the stub loader.
> 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)
I think this is the right way to do it. CWSPARAM should find the same
CWSDPMI that the stub would.
> 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 don't think this is a good idea, since some programs grab the screen,
and the info will disappear.
- Raw text -