Mail Archives: djgpp/1997/01/09/14:02:40
Errors-To: postmaster AT ns1
Date: Thu, 9 Jan 1997 19:28:41 +0100 (MET)
From: Grzegorz Ludorowski <pajonk AT ajax DOT umcs DOT lublin DOT pl>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 497
> No problem! The memory is not returned to DPMI when free()'d only to the
> malloc() memory pool. This is why _dpmi_remaining_physical_memory() &
> _go32_dpmi_remaining_virtual_memory() report no change.
>
> --
> Art S. Kagel, kagel AT quasar DOT bloomberg DOT com
Hi!
So, I've got one question more (I must say, that I'VE READ faqs,
but didn't find any remedy) - could you tell me, how detect free memory
then? If _go32_dpmi....blabla doesn't report any memory changes?
Thanx in advance, LUDO
You cannot with the default malloc() library. It does not keep track. You can
get the source and add a free pool function (there may even be such a function
available if you enable the debugging code I do not remember from my brief
visit to the malloc() code last year). Once you have done that you could
implement a wrapper function to find the malloc() free pool plus the
dpmi_remaining_physical... plus dpmi_remaining_virtual... (Does virtual include
physical? Anyone?)
Another option is to wrapper malloc() and free(), etc and keep track yourself
of the currently allocated and/or freed memory blocks in a local data structure
maintained by the wrapper functions. (Remember that malloc()
requests/allocates memory blocks with their size rounded up to the next power
of 2!)
--
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com
A proverb is no proverb to you 'till life has illustrated it. -- John Keats
- Raw text -