From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Pharlap 286
Date: Thu, 26 Jul 2001 10:39:12
Organization: Aspen Technology, Inc.
Lines: 17
Message-ID: <3b5ff350.sandmann@clio.rice.edu>
References: <68C4CF842BD2D411AC1600902740B6DA02CDC45D AT mcoexc02 DOT mlm DOT maxtor DOT com> <3b5df3e1 DOT sandmann AT clio DOT rice DOT edu> <996052472 DOT 673367 AT queeg DOT ludd DOT luth DOT se> <3b5edd8f DOT sandmann AT clio DOT rice DOT edu> <Pine DOT SUN DOT 3 DOT 91 DOT 1010726094053 DOT 28739C-100000 AT is>
NNTP-Posting-Host: dcloan.hou.aspentech.com
X-Trace: selma.aspentech.com 996163537 13436 10.32.115.107 (26 Jul 2001 16:05:37 GMT)
X-Complaints-To: postmaster AT aspentech DOT com
NNTP-Posting-Date: 26 Jul 2001 16:05:37 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

> There might be one way out of this, although it's not very nice: page
> the DPMI client completely out of extended memory, either
> automatically whenever it spawns another program, or (better) when the
> spawned program requests memory via the XMS API.

I dislike the paging out of all memory - it really hurts performance on
the 99% of applications that don't need it.

It has been suggested before to have CWSDPMI hook XMS calls when it loads
to provide some support - this would make DMA buffers easier, allow 
nesting programs, etc.  But doing a partial XMS is a can of worms.  Doing
a full XMS is re-inventing the wheel.  Just paging out the memory, releasing
it on XMS call - what happens if application calls XMS inside a DPMI
program (not spawned? - difficult to tell when they use a real mode 
far call what's happening).  I'd still argue this is mostly a 
non-problem in the real world.  Let's get DJGPP stable on W2K and
XP first :-)