From:	<sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: big fat swap
Date:	Sun, 9 Feb 1997 12:40:12
Organization:	Rice University, Houston, Texas
Lines:	23
Message-ID:	<32fdc5ac.sandmann@clio.rice.edu>
References:	<5dkb7n$mt3 AT flex DOT uunet DOT pipex DOT com>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> and almost no free memory 
> the config.sys and autoexec.bat are uneditable on the second machine (it
> boots from a remote network) so do i have any other options here? 

Maybe.  I need a lot more information on the problem system (OS vers, copy of 
config.sys, output of mem command).  I'm going to guess that this system is
configured to provide some very small amount of VCPI memory, and does not pool 
XMS/EMS memory.  DOS 5 EMM386 versions did this - most other memory managers
and DOS 6 don't have this problem.  There is an option inside of CWSDPMI 
which can handle this on old "NOEMS" systems.  But it's only turned on if 
the VCPI memory is zero.  A typical bad configuration in DOS 5 EMM386 just
used "RAM" with no EMS size and defaulted to 256K of VCPI memory.  One option
I considered was to use the maximum of the XMS or EMS memory; but this also 
causes problems in some weird pooling systems (the pooling systems are also 
the reason you can't use both without causing mega problems).

If the memory is misconfigured as I guess, and you can't change it, there
could potentially be two fixes.  One would be to run a shell/tsr which 
consumes the small amount of VCPI memory, in which case CWSDPMI would try
to use XMS memory (which may not work at all on some systems, but it's
worth a shot).  The second would be to hack up a copy of valloc.c in 
CWSDPMI to try and handle this screwed up configuration - but I don't have
the box, or the time, but someone with tcc/bcc could experiment with it.

- Raw text -