Mail Archives: djgpp/2000/10/04/17:34:18
> 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.
- Raw text -