From: kagel AT quasar DOT bloomberg DOT com Date: Thu, 9 Jan 1997 13:33:20 -0500 Message-Id: <9701091833.AA13864@quasar.bloomberg.com > To: pajonk AT ajax DOT umcs DOT lublin DOT pl Cc: djgpp AT delorie DOT com In-Reply-To: (message from Grzegorz Ludorowski on Thu, 9 Jan 1997 19:28:41 +0100 (MET)) Subject: Re: how to free memory? Reply-To: kagel AT dg1 DOT bloomberg DOT com Errors-To: postmaster AT ns1 Date: Thu, 9 Jan 1997 19:28:41 +0100 (MET) From: Grzegorz Ludorowski 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