Date: Wed, 04 Oct 2000 19:13:57 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT inter DOT net DOT il
To: Eric Rudd <rudd AT cyberoptics DOT com>
Message-Id: <3405-Wed04Oct2000191356+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.5h
CC: djgpp AT delorie DOT com
In-reply-to: <39DA1E51.D0C53931@cyberoptics.com> (message from Eric Rudd on
	Tue, 03 Oct 2000 12:58:41 -0500)
Subject: Re: get the amount of physical memory
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001003142803 DOT 12455B-100000 AT is> <39DA1E51 DOT D0C53931 AT cyberoptics DOT com>
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

> From: Eric Rudd <rudd AT cyberoptics DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Tue, 03 Oct 2000 12:58:41 -0500
> 
>   1. To predict how large a region can be successfully malloc'ed.  One
>   might well ask why this can't be done simply by testing for a null
>   pointer returned from malloc.  Unfortunately, this works poorly
>   with some algorithms.  For instance, a routine that creates an
>   array of pointers, each element pointing to the beginning of a
>   line in a text file, can't predict how much space it needs for the
>   array until it has counted the number of lines in the file.  This
>   means either making two passes over the file (slow), doing a lot
>   of realloc calls along the way (also slow), or reserving space at
>   the outset for the largest array one might need (fast and
>   expedient).

Let's say that there is a way to know the amount of available
memory--how would this help you in the scenario you've just described?
You still won't know whether that memory will be enough to read the
file, since you don't know how many lines there are in the file,
right?

> 2. To predict how large a region of memory can be accessed without
> disk swaps.

This is impossible with most modern OSes.  Plain DOS and, sometimes,
Windows 9X are the only ones that report available physical memory
reliably (on Windows 9X, the report is only accurate if no other
program works at the same time consuming memory).

> > The DJGPP library provides the
> > `_go32_dpmi_remaining_physical_memory ' function for
> > this purpose.  Another possibility is to call the function
> > `_go32_dpmi_get_free_memory_information'.
> 
> Do these functions accomplish either of the above goals?

The second one should return the total amount of memory available to a
DPMI program (physical + virtual), at least according toe the DPMI
spec.  I'm not sure this is good enough for the first goal (since I
don't understand how would that help).  It certainly does NOT help for
the second goal.