delorie.com/archives/browse.cgi | search |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |