Message-ID: <39DA1E51.D0C53931@cyberoptics.com>
From: Eric Rudd <rudd AT cyberoptics DOT com>
Organization: CyberOptics
X-Mailer: Mozilla 4.72 [en] (Win95; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: get the amount of physical memory
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001003142803 DOT 12455B-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 32
Date: Tue, 03 Oct 2000 12:58:41 -0500
NNTP-Posting-Host: 38.196.93.9
X-Trace: client 970595922 38.196.93.9 (Tue, 03 Oct 2000 13:58:42 EDT)
NNTP-Posting-Date: Tue, 03 Oct 2000 13:58:42 EDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:

> Also, do you need to know the total size of physical memory, or the amount that is
> free at the moment of the call, and for what purpose?

I have encountered two very practical reasons to know the amount of memory on a machine
(not necessarily *physical* memory):

  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).  (Determining that size by a binary search is not reliable, since
     after a malloc-free pair the heap is not necessarily in the same state it was in
     before.)
  2. To predict how large a region of memory can be accessed without disk swaps.  (For
     instance, will a particular invokation of qsort be painfully slow, requiring a
     call to a special-purpose disk-based sort?)

> 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?

-Eric Rudd
rudd AT cyberoptics DOT com