cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/02/11/14:13:08

From: nikki AT gameboutique DOT co (nikki)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: big fat swap
Date: 11 Feb 1997 10:28:23 GMT
Organization: GameBoutique Ltd.
Lines: 39
Message-ID: <5dphk7$qoo@flex.uunet.pipex.com>
References: <5dkb7n$mt3 AT flex DOT uunet DOT pipex DOT com>
<32fdc5ac DOT sandmann AT clio DOT rice DOT edu>
NNTP-Posting-Host: www.gameboutique.com
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> 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 
dos 6, config.sys i couldn't locate sadly :( mem command output is in a 
previous post, see above somewhere :)

> 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).

i find that if i try to boot into windows95 or win3.1 i get significantly more
memory available, but then the programs i try to run say 'im sorry you cant
run this from a dos box' :) which is rather ironic.

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

this former idea sounds interesting, in particular because mem reports
having 15meg free xms (ems isnt configured on this machine) it's infuriating
as the program in question needs to run on this machine but i cant edit any
of the files or change the setup in any way :(

regards,
nik


-- 
Graham Tootell           
nikki AT gameboutique DOT com  

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019