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 :-)

- Raw text -