From: "Charles Sandmann" 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 Precedence: bulk > 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?