From: Martin Str|mberg <ams AT father DOT ludd DOT luth DOT se>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Pharlap 286
Date: Wed, 25 Jul 2001 09:14:32 +0000 (UTC)
Organization: University of Lulea, Sweden
Lines: 21
Message-ID: <996052472.673367@queeg.ludd.luth.se>
References: <68C4CF842BD2D411AC1600902740B6DA02CDC45D AT mcoexc02 DOT mlm DOT maxtor DOT com> <3b5df3e1 DOT sandmann AT clio DOT rice DOT edu>
X-Trace: news.luth.se 996052472 5905 130.240.16.109 (25 Jul 2001 09:14:32 GMT)
X-Complaints-To: abuse AT luth DOT se
User-Agent: tin/pre-1.4-981225 ("Volcane") (UNIX) (SunOS/4.1.4 (sun4m))
Cache-Post-Path: queeg.ludd.luth.se!unknown AT father DOT ludd DOT luth DOT se
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Charles Sandmann <sandmann AT clio DOT rice DOT edu> 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?

: No good way, but you could purposely write an application to look at XMS
: memory, fragment it on purpose (by allocating say 1Mb, then 1Kb, then 
: freeing the 1Mb) which would cause CWSDPMI to manage the larger block
: leaving the smaller block potentially to the Pharlap application.  It 

This is very possible. Setup a resizeable RAMDISK that uses XMS (TDSK
or XMSDSK works fine). Init it to how much memory you don't want
CWSDPMI to use. Start CWSDPMI. Now all XMS memory is allocated. Resize
the RAMDISK to 0. Voila, suitable amount of XMS memory free!


Right,

						MartinS