From: 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.