Date: Thu, 26 Jul 2001 09:41:16 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp AT delorie DOT com Subject: Re: Pharlap 286 In-Reply-To: <3b5edd8f.sandmann@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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?