Date:	Thu, 26 Jul 2001 09:41:16 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp AT delorie DOT com
Subject:	Re: Pharlap 286
In-Reply-To:	<3b5edd8f.sandmann@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010726094053.28739C-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 25 Jul 2001, Charles Sandmann wrote:

> > : XMS memory and manage it for DPMI applications.  If a non-32-bit-DPMI
> > : protected mode application tries to run, it won't be able to get any XMS
> > : memory (bad things can happen in the raw memory management world).  If
> > 
> > Can you be more specific about what these bad things are?
> 
> In raw memory management, the size of the memory is obtained from Int 15,
> and the A20 state is set by changing port registers.  So there is not a
> good clean way to coordinate between PM programs.  In addition, the 
> "standard" way of doing this is to hook Int 15 and decrease the amount
> of memory reported and do top down allocation.  CWSDPMI doesn't do this
> for a long list of reasons (DMA buffers must be in first 16Mb for ISA
> cards, multiple Int 15 calls to get memory size, exit stability, etc).
> So, in a raw environment an application may see all the extended memory
> free and trash the DPMI memory.

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.

Would that work?

- Raw text -