Date: Wed, 3 Nov 1999 09:46:40 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Waldemar Schultz <schultz AT ma DOT tum DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: CWSDPMI - CWSPARAM
In-Reply-To: <381EF430.C6CC9270@ma.tum.de>
Message-ID: <Pine.SUN.3.91.991103094622.29562B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


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.