www.delorie.com/djgpp/v2faq/faq119.html

search

| Previous | Next | Up | Top |

Q: I malloc'ed a large chunk of memory, but when I check values returned by _go32_remaining_physical_memory or __dpmi_get_memory_information, I don't see any change!

Q: When I free allocated RAM, _go32_remaining_physical_memory reports there was no change in the available RAM...

Q: I'm looking for a way to tell how much memory is available, something like coreleft in Borland C?

When you call free, DJGPP library doesn't return memory to the system, it just adds it to its internal pool of free pages. So, from the system point of view, these pages are not "free".

In addition, several widely-used DPMI servers, such as those built into Windows, have their own quirks related to memory allocation. For example, some of them won't let you allocate more than half the available memory in a single chunk. As another example, under OS/2 _go32_remaining_physical_memory reports a constant very big value that doesn't change in the course of the program.

Because of these peculiarities, there's no convenient and easy way to return the amount of free memory available at any given moment. Some programs only care about available physical RAM (they don't want to page to disk, since that causes a considerable slow-down); for these, I recommend to call the _go32_remaining_physical_memory library function at program startup, and then track memory usage with sbrk(0);. Alternatively, disabling virtual memory altogether (by using CWSDPR0 or by loading CWSDPMI with -s- parameter), and checking values returned by malloc against NULL, might be all you need to know when you are about to run out of free physical memory. Programs that need to know when they are about to run out of virtual memory should call _go32_remaining_virtual_memory instead.

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)