From:	Waldemar Schultz <schultz AT ma DOT tum DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	CWSDPMI - CWSPARAM
Date:	Tue, 02 Nov 1999 15:24:48 +0100
Organization:	[posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Lines:	78
Distribution:	world
Message-ID:	<381EF430.C6CC9270@ma.tum.de>
NNTP-Posting-Host:	pcritter1.mathematik.tu-muenchen.de
Mime-Version:	1.0
X-Mailer:	Mozilla 4.6 [de] (Win95; I)
X-Accept-Language:	de,en-US
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Maybe it is in the DOCs already, but just to inform you where I was
caught:

For some (few?) DJGPP applications (like mine) it IS necessary to set up
the
CWSDPMI parameters by using CWSPARAM.EXE.
(perhaps to work around the r4-bug for machines with very much
physical memory as well as with very much free swap space.
Charles Sandman reported this earlier)

So what happened to me (and could easily happen to anyone) is the
following:

My %PATH% looks like '.;c:\djgpp\bin'
For my convenience :-) in experimenting with cwsdpmi parameters I had
put
a copy of c:\djgpp\bin\cwsdpmi.exe to my current directory some day.
I experimented with things like compiling some sample '.\allocate.c' and
finding
the appropriate parameters utilizing 'cwsparam maxswap=255' for example.

Fine so far.

Then I switched to the "real" application to apply my new insights:
'c:\usr\src\prog.c' compiled to 'c:\djgpp\bin\prog.exe'
But executing prog.exe crashed as it did before finding
the optimal parameters!

After intensive looking on all that stuff the reason is clear:

As CWSPARAM without specifying the CWSDPMI target on the command line
tries
to find CWSDPMI.EXE in the current directory, the user (stupid me)
might presume that a compiled stubbed DJGPP-program would do so too!

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

Thus in my example by using 'cwsparam maxswap=255' I changed
.\cwsdpmi.exe.
By typing prog.exe yet c:\djgpp\cwsdpmi.exe was loaded
to run c:\djgpp\bin\prog.exe, which of course wasn't my intent.


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)

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.

If I'm completely mistaken please excuse bothering you!

--
 Gruss Waldemar Schultz.
 Technische Universität München, Zentrum Mathematik M1, D 80290 München
 Tel: +49 (0)89 2892 8226        FAX: +49 (0)89 2892 8228

- Raw text -