Message-Id: <200004050358.FAA09413@smtp.hccnet.nl>
From: "Willy J. Hoogstraten" <w DOT j DOT hoogstraten AT hccnet DOT nl>
Date: Wed, 05 Apr 2000 05:38:00 +0100
X-Mailer: Arachne V1.61
To: opendos AT delorie DOT com
Subject: Re: DPMI Continued
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Reply-To: opendos AT delorie DOT com

Hi,

On Tue, 04 Apr 2000 23:20:26 +0400, Mark at Cross+Road's wrote:

(I cut off my original message from yesterday).
> This is interesting what then was the size you chose?  Or didn't that make
> any difference?, wouldn't think so though.
> Please let us know.
>    Mark

I guess you mean the size of NWCACHE. I use the maximum size, which
is 7670 kB.
BTW, I know two programs which are _not_ compiled with DJGPP that also
want to lend memory from NWCACHE (which does not get it back).
I guess this is a fault from emm386. When I used SMARTDRV instead of
NWCACHE and gave it a minimum size which not equalled the maximum,
the same thing happened: memory seems to go back to XMS, but this is
not true, only the mem command shows that it's back.
So every time I run a program which causes this problem, the cache is
flushed and there is 1 MB less cache. If the available amount of XMS
is over ca 9 MB, than programs don't take it from the diskcache.
This limit (ca 9 MB) is the same for every DJGPP program, ViewHTML
and AcroDos. Even if a small program is executed w/o input file,
this trouble occures.
I tried it on various machines from a 386 to a P-75, with various
amounts of installed RAM and with some different emm386 settings,
but always, if available XMS is below ca 9 MB, this happens.
But again, if the diskcache is 'protected' (minimum = maximum),
than it's alright.


- Best regards,
- Willy J. Hoogstraten.

- End of message -