Date: Sun, 7 Apr 1996 12:26:19 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Arcanix <arcanix AT aol DOT com>
Cc: djgpp AT delorie DOT com
Subject: Re: DPMI hosts
In-Reply-To: <4k2adi$5kt@newsbf02.news.aol.com>
Message-Id: <Pine.SUN.3.91.960407115636.22664B-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On 5 Apr 1996, Arcanix wrote:

> This isn't too relevant to DJGPP, but I thought some of you might want to 
> hear this anyway. It seems like some DPMI hosts are flawed
> in unusual ways.  I wrote a small program that gives info about the
> user's computer.  Here it is: (Note that some of the code is unused, but

I've learned from my own bitter experience to not trust the names of
functions and the fields of data structures they return, but instead to
keep my DPMI spec handy and read it through the eyes of a lawyer. 

> the info that I got:
> Field 1: Physical mem remaining.

The DPMI spec calls this ``the number of physical pages that currently are
not in use''.  But it doesn't say anywhere what does ``in use'' mean.  See
below for some ingeneous reading of this by some DPMI servers. 

> Field 2: Virtual mem remaining (without physical, so it should be = to 
> HD space remaining)

This field is called ``Largest available free block size'' in the DPMI
spec.  Therefore, it doesn't necessarily return the total unused physical
memory, because some DPMI hosts won't let you allocate all of the
available memory in one piece (example: Windows). 

> Field 4: Type of CPU

The DPMI v0.90 spec doesn't define the values beyond 4 (=486) returned in 
this field, so you shouldn't rely on this.

> 32rtm:
> 1: 3,563,520 (Must be a HUGE ram hog)

Actually, every DPMI host I've seen uses much more memory than CWSDPMI 
(which even has been tested to work--slowly--on a machine that has only 
64KB free conventional memory and NO extended memory).  32rtm is actually 
an extender in disguise, so 1MB is not too much for it.

> 2: 4,294,926,336 (!!!!!!!!)

This looks suspiciously like -1 interpreted like an unsigned long.  The 
DPMI spec says that any field that are not returned by the DPMI 
implementation will be set to -1 (although this field should always be 
rturned).  So it might even be a DJGPP bug.

> Win 3.1:
> 1: 954,368 (As we know, windows is a massive ram eater)

Windows actually takes over the entire memory, but swaps itself out to let
application get as much memory as it thinks they need, see below.

> 2: 31,113,216 (I am running a 5MB swap file, so this number is exactly
> twice as big as the correct amount of virtual memory)

Not necessarily.  Under Windows, these two values additionally depend on 
the amount of memory your PIF file for that specific DOS box specifies.  
Without knowing what is the maximum XMS and EMS usage you allowed in that 
PIF file, it is impossible to tell whether the above values are 
reasonable or not.

Bottom line: given that your system is configured correctly (i.e., some 
memory manager doesn't get hold on all of the memory and doesn't let 
others use it, or you have incorrect settings on your PIF file), the only 
thing you can hope to trust is that an allocation as large as what 
`_go32_dpmi_remaining_physical_memory' returns, will succeed.  I say 
``hope to trust'', because I saw cases where even that is not true...