From: "Charles Sandmann" 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 :-)