www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/08/02/19:45:22

From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DPMI with physical memory > 256 MB
Date: Sun, 2 Aug 1998 17:15:48
Organization: Aspen Technology, Inc.
Lines: 38
Message-ID: <35c49ec4.sandmann@clio.rice.edu>
References: <000501bdb507$26d195b0$1901030a AT WS-hkatirai DOT netpartners DOT com> <35BA579A DOT F67773CE AT cartsys DOT com>
Reply-To: sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host: dmcap2.aco.aspentech.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

> Hooman Katirai wrote:
> > I will be writing an application shortly that requires > 256 MB of memory --
> > probably around 512 MB of physical + some swap. Does anyone know of a DPMI
> > manager compatible with DJGPP, and preferably free,  that can be used for
> > this application?
> 
> The 256+256 limit of CWSDPMI seems arbitrary.  I wonder if it's
> something you can just bump and recompile, perhaps at the expense of a
> larger conventional memory.  Charles?

The virtual/swap/disk-based memory limit is arbitrary, and is chosen at
256Mb since this is the largest amount that will fit in a short word.  The
source for CWSDPMI allows you to define this larger, which changes the type
to a long integer automatically.  This makes the code bigger, since the
long integer arithmetic requires a lot more operations under TC/BC's 16-bit
compiler, makes it slower, takes more memory, etc.  It requires alot more
DOS memory also.  I have built previous versions for people requesting up
to 2Gb of virtual memory and they used it successfully.  But at this point
they were never really happy about the performance.  I suggested moving to
a simple Linux dual install in these cases - and the paging performance was
around 2 times faster - mostly due to the linux protected mode disk drivers
instead of going through the BIOS.  So, consider the 256Mb limit my strong
endorsement for an OS upgrade if you need that much paging space.

The 256Mb physical memory limit is also there because of the short integer
arithmetic and storage issues.  I've never had anyone request support for
more than 256Mb before, so it's automatic change of types/sizes/testing
like for the virtual limits has never been coded or tested.  But I did 
start to mess with it for r4 - but didn't complete the task.  The concept
of 300Mb of RAM in a "DOS" system does seem extreme to me - but if the
requests start rolling in for more than 256Mb memory support ... maybe
it will happen.  But remember, a few years ago there were no VCPIs which
would support more than 64Mb memory (SET's discussion on the current 
EMM386 only supporting 32Mb is a strong reminder of this!) and the XMS
specification only supporting 64Mb until the extended XMS spec a couple
of years ago ... and there is no direct universal BIOS call to support
more than 64Mb ... what memory types should be supported for this 300+Mb
DOS system?

- Raw text -


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