From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Memory amount and PMODE Date: Sun, 15 Oct 2000 12:37:51 Organization: Aspen Technology, Inc. Lines: 44 Message-ID: <39e9a51f.sandmann@clio.rice.edu> References: <39e71d75 DOT sandmann AT clio DOT rice DOT edu> <8sbrrp$15jh$1 AT news DOT itfs DOT nsk DOT su> NNTP-Posting-Host: dcloan.hou.aspentech.com X-Trace: selma.aspentech.com 971633741 13542 10.32.115.107 (15 Oct 2000 18:15:41 GMT) X-Complaints-To: postmaster AT aspentech DOT com NNTP-Posting-Date: 15 Oct 2000 18:15:41 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 was able to take a look at PMODE's raw and XMS code, and > > verified it does not support more than 64Mb total memory in > > either case. I was able to upgrade the raw mode code > > fairly easily (and was able to repeatedly access almost 1Gb > > of memory under the updated PMODETSR code). I'll dump this > > into the next alpha-test build. > > > The Extended XMS code is more of a mess because of the way > > PMODE is coded. I will probably be able to fix this also > > before the next release of PMODE. > > Why not to bury it (isnt it easy to support only one program :)? > because of size ? 1) PMODE has some advantages over CWSDPR0 (or a stub built on it). For example, it's smaller, in some cases faster, and in some cases has capabilities that CWSDPR0 doesn't. For example, since CWSDPR0 enables paging for raw mode and XMS modes it must hold the page tables in memory. This currently limits it to around 500Mb or so of maximum memory. Since PMODE doesn't use paging in those cases, it has no pagetable limits and lower DOS memory consumption. With the modifications in the next release I'll make, PMODE will easily allow you to use 2Gb of memory (maybe more). If you need a ring 0 DPMI, I generally recommend PMODE over CWSDPR0. For this reason, I'm not distributing a stub with CWSDPR0 built into it (even though the makefile builds one). 2) PMODE uses very different algorithms for some features, so it will have different bugs than CWSDPMI based tools do. It's an excellent additional free way to point the finger at your code or CWSDPMI when something goes wrong. 3) I'll never put much time into PMODE - just some maintenance upgrades and fixes. I think the time I'll put into it's worth it. I may break some obscure features (try and find them...) > If so wouldnt it be simpler > just to have possibility to compile CWSDSTUB w/out page file support > (closed with #defines). Actually you can use CWSPARAM to modify CWSDSTUB in a supported way to disable page file support (even after stubing the image). As I noted above, you can build a ring 0 stub including CWSDPR0. But, I think that for the purposes that PMODE was built for it's a better ring 0 provider for specialty uses than CWSDPR0 is. For typical programs I think a ring 3 provider (like CWSDPMI or CWSDSTUB) is a better choice - which is one of the reasons I've finally finished up the CWSDSTUB for r5.