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 21:45:50
Organization: Aspen Technology, Inc.
Lines: 8
Message-ID: <39f0bd0e.sandmann@clio.rice.edu>
References: <8sq0ld$208k$1 AT news DOT itfs DOT nsk DOT su> <5 DOT 0 DOT 0 DOT 25 DOT 0 DOT 20001020150433 DOT 03509060 AT mail DOT subdimension DOT com>
NNTP-Posting-Host: dcloan.hou.aspentech.com
X-Trace: selma.aspentech.com 972096490 1968 10.32.115.107 (21 Oct 2000 02:48:10 GMT)
X-Complaints-To: postmaster AT aspentech DOT com
NNTP-Posting-Date: 21 Oct 2000 02:48:10 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

> I think both of those suggestions would be good... That way if the system 
> only has, say, 64MB of RAM, it still is possible to prevent it all from 
> being eaten...

The problem is really only observed on systems with more than 256Mb of 
physical memory.  Systems with 256Mb or less act identically under r4 and
r5 (if CWSDPMI saw all the memory).  It was limited in seeing more than 
64Mb on raw systems.