From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: CWSDPMI problem
Date: Mon, 21 Apr 1997 22:46:58
Organization: Aspen Technology, Inc.
Lines: 57
Message-ID: <335bee62.sandmann@clio.rice.edu>
References: <97Apr21.114024gmt+0100 DOT 21891 AT internet01 DOT amc DOT de>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: spica.dmccorp.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

> >Why not change CWSDPMI to use an environment variable to compute the
> >name of the swap file?
> 
> Sorry, that's what I meant by my last sentence.  I haven't had time to
> look at the CWSDPMI sources yet to see how easy that is, but it seems
> to me to be the cleanest and most general way of doing it.

This isn't quite as easy as it sounds.  The original GO32 used the environment
variables TEMP, TMP, and GO32TMP to determine where to put the pagefile, and
if all else failed, put it in the current directory.

When distributing software, it turns out that TEMP or TMP are frequently
set to a RAM drive, which seriously limits swap space, and was bad.

The default directory was a really bad idea, since software was being
distributed on CDROM (which is a bad device for a swapfile) or floppy
(and you thought paging was slow?  heh, heh...)

So, I asked for comments.  The most universal configuration was most people
have a writeable C: drive, it always has a root, and thus is the most 
common denominator on 386+ PC equipment.  It required no environment 
variables to be set (a requirement from some commercial software 
developers).

To determine the free space on the drive - you need the real drive letter.
So - instead of bloating the code with 100 trick ways to try and figure
out what you want - you must specify a real device so I can easily figure
out how much free space there is.

CWSDPMI doesn't use any run time library calls from turboc or borlandc -
so there is no "single call" to get an enviroment variable.  You would
have to load up the environment and manually search it.

What I was thinking about when I quit working on CWSDPMI was this:
 If the first letter of the swapfile (ie "drive") stubedited into
 the image was "$", the remaining string would be treated as an environment
 variable, copied from the environment, and used thusly - but would still
 require the syntax of the enviroment variable value to be a full 
 disk:\directory\file specification.

But then I came to my senses - realized what's there met 99.9% of the needs
of everyone, and the other 0.1% of the people could pop $60 bucks on a real
memory manager if reasonably well off, or personally hack the source if 
really poor.  Alternatively, you can cwsparm 100 copies of cwsdpmi to be
cwsdp1.exe = c:\swp1.fil, cwsdp2.exe = c:\swp2.fil, etc, and make every
image you might run separately have a different dpmi provider specified.

For the poor souls on networks, with no writeable C:, tiny memory, no
common named writable directory ... you could maybe join a drive letter
to a directory on your writable space, copy cwsdpmi there, cwsparam your
swap area location into it, make all images load x:csdp.exe ... or see the 
previous paragraph about buying/hacking something.

Or in other words, I got lazy and like making excuses better. :-)

Solving large scale nonlinear optimization problems is much more
interesting than hacking 16 bit real mode dos code. :-)