Xref: news-dnh.mv.net comp.os.msdos.djgpp:1926
Path: news-dnh.mv.net!mv!news.sprintlink.net!howland.reston.ans.net!swrinde!news.uh.edu!uuneo.neosoft.com!news!sandmann
From: Charles Sandmann <sandmann AT praline DOT no DOT NeoSoft DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: emm386 woes
Date: Tue, 05 Sep 1995 00:19:23 CDT
Organization: NeoSoft Internet Services +1 713 968 5800
Lines: 20
References: <DEEvwE DOT GCq AT cfanews DOT harvard DOT edu>
Reply-To: sandmann AT praline DOT no DOT NeoSoft DOT com
Nntp-Posting-Host: praline.no.neosoft.com
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

> 3. EMM386 with no amount memory specified in config.sys defaults to 256K.
>    Both v1 and v2 use only this amount of memory before swapping.
> 
> Number 3 is worrisome because it seems to apply to v2.  
> Is there any way to tell v2 what type of memory to use?

This is a DPMI issue, not a V2 issue.  Of course, you are in this case
dealing with CWSDPMI (hacked up GO32...), so you need to scream at me to
fix this.  I have two ideas on this:

1) Use the larger of XMS or EMS memory, whichever is available.  Currently
   we use XMS memory with VCPI only if EMS memory is zero (NOEMS).  This
   could probably be changed to use the larger, but I fear what it might
   break on more intelligent memory managers.
2) Try to use multiple types of memory if the EMM looks braindead.  Hazard:
   more recent EMM386 and all aftermarket memory managers pool the memory,
   so it can look like you have twice as much as you really do.

This is already on my list (along with making it resize the disk cache like
Win does) but low priority.