From:	"Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Announce: CWSDPMI r5 public beta
Date:	Fri, 20 Oct 2000 14:44:59
Organization:	Aspen Technology, Inc.
Lines:	27
Message-ID:	<39f05a6b.sandmann@clio.rice.edu>
References:	<8sq0ld$208k$1 AT news DOT itfs DOT nsk DOT su>
NNTP-Posting-Host:	dcloan.hou.aspentech.com
X-Trace:	selma.aspentech.com 972071805 5182 10.32.115.107 (20 Oct 2000 19:56:45 GMT)
X-Complaints-To:	postmaster AT aspentech DOT com
NNTP-Posting-Date:	20 Oct 2000 19:56:45 GMT
X-NewsEditor:	ED-1.5.8
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> Looks like CWSDPMI R5 eats all DOS memory on some computers.
> This is MSDOS 6.22 on Compaq server 1850, Intel P3, 600Mhz, 512MB,
> What can we do ? [r5 workaround?] 

See my other note - I just thought of something you probably can do,
which is to set the page tables to allocate in CWSPARAM.  This will
override the automatic allocation (but read the notes about extra
space for bitmaps).

For example, if you specified 12 page tables you probably would be
OK on this machine.
  16Mb     = 4 pagetables
  Dos area = 1 pagetable
  Mapping? = 1 pagetable
  Bitmaps = 512Mb => 128K pagetable bits = 16Kbytes = 4 extra pagetables
  rounding = 1 pagetable
  contingency = 1 pagetable
You could set this value to 24 to probably handle any machine out there
if your needs are less than 16Mb total.

I'd still like to hear comments from users on what to do about this.
For example, the current beta configuration would prevent someone 
with a 512Mb machine from running nested DJGPP applications without
modifying CWSDPMI with CWSPARAM.   This is probably a bad thing, with
512Mb of memory costing $250 ...

Now you know why we have betas :-)

- Raw text -