wpw_w32_mem_95.html

VC programing

memory from the operating system.  When you free an object,
malloc adds the freed memory to its "free list" or "free store" --
That is, all the memory that malloc has requested from the operating
system and isn't in use by the application.  Malloc doesn't actually
return the memory to the OS.

The next time you allocate an object, malloc will attempt to
use memory from its free list first, and then go to the operating
system only if it can't find a large enough block.

So, the reason your freed arrays aren't acknowledged is that the
memory is still inside your application, ready to be reused.

To actually free memory back to the OS, you need to use a method 
like _heapmin.  However, (there's a BUT) due to how modern operating
systems deal with memory and how malloc algorithms work, using
_heapmin doesn't neccesarily have any effect and its effect 
isn't neccessarily positive (like it might just slow down your
application and do nothing else).  Email me for more details on 
this if you're interested.

But that's not too worry -- Part of the advantage of NT is that it
has a fairly sophisticated memory system.  If some memory isn't
being used, then that memory doesn't really exist, except as a spot
of reserved disk space.  (And on some Unixes like AIX, not even
there...)  The actual mechanism is fairly detailed, there are some 
old MSJ articles which do it justice...

However, the upshot of the mechanism (and this is the same with
other operating systems like OS/2) is that you can't really determine
before hand how much "free memory" there is.  NT itself constantly
allocates memory, so the amount of available "free memory" changes
constantly.  And if you really ask NT for a lot of memory, NT will
scrounge around and create more.

For your application, if you are allocating big arrays (>64K), then
you will find that using VirtualAlloc/VirtualFree for the big
arrays will help out your application.

Also, you may wish to consider using a 3rd party memory manager.
Compiler-supplied mallocs rarely use the latest memory managment
algorithms, and commercial memory managers like Reflective
Software's WGC can seriously boost the performance of applications
like yours.

Regards,
Kevin

____
Kevin Warne / [e-mail] / CEO, Reflective Software Corporation
[phone] / 560 West 16th Ave, Vancouver, BC, CANADA  V5Z 1S4
WGC is the best way to allocate memory in C++ -- Call/email for details
<HR>
In article <3trccm$[e-mail]>
[e-mail] (David Bradley) wrote:

> Ole Matzura <[e-mail]> wrote:
> 
>>How does the standard About Box in i.e. the Program Manager
>>check free mem?
> 
> It doesn't, it reports the total physical memory of your computer, at
> least mine does under NT 3.5
> 
> This question, though, is something I've wondered myself, I'll be
> interested in seeing the replies to your message.

Well, the registry resource list at:

HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\Physical Memory

does contain the information, albeit in a rather encrypted form.

I'd expect that there's an easier way to get it though.
<HR>
[e-mail] (David Boreham) writes:
>Well, the registry resource list at:
>
>HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\Physical Memory
>
>does contain the information, albeit in a rather encrypted form.
>
>I'd expect that there's an easier way to get it though.

GlobalMemoryStatus() is the call to get information about both total memory
and free memory.

        -- Jim

---------------------------------------------------------------------------
 Jim Edwards-Hewitt            [e-mail]           Visix Software Inc.
---------------------------------------------------------------------------
  Beware of geeks bearing GIFs.
---------------------------------------------------------------------------
</PRE>



<HR><A NAME=WIN32_WINNT_DLL_SHAREDATA_MORE>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: More on sharing data between DLL and exe (memmap file)</H4><PRE>
|> >
|> >I have a problem with DLLs. We want to have a global variable
|> >in the DLL, that is global for all applications that use that
|> >DLL. We are working with Borland C++ 4.5. The following code 
|> >should make our problem clearer:
|> >
|> >
|> >DLL-Code:
|> >
|> >
|> >int GlobalInt;
|> >
|> >
|> >
|> >void InitGlobalVars ()
|> >{
|> >  GlobalInt = 10;
|> >}
|> >
|> >
|> >Each Application should see that GlobalInt has the value 10, after
|> >ONE Application has called InitGlobalVars.
|> >
|> >In Windows 3.1 it works, but
|> >under Windows NT, each application seems to have its own 
|> >instance of GlobalInt.
|> 
|> Use a memory mapped file - this is EXACTLY the type of thing they
|> are designed for. Refer to Richter (on MSDN Dev Lib CD) for details.
|> 

Although you can use a memory mapped file, it is overkill in the case where
a DLL only needs a few global variables.  In that case place the variables
in a shared region and make them global.  This works for DLL and EXE.
Refer to Richter (on MSDN Dev Lib CD) for Details.  Even better buy the
book _Advanced Windows_ by Richter.  Even better read the book!

</PRE>

<HR><A NAME=WIN32_WINNT_MEM_RECLAIM>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Windows NT 3.51 and reclaiming memory</H4><PRE>

In article <3uufq7$[e-mail]>
           [e-mail] "Kevin Warne" writes:

>In article <[e-mail]>, Chris Marriott
> <[e-mail]> says:
>
>>If you want to explicitly return memory to the operating system, call
>>"_heapmin" once in a while. A good strategy is to have a "worker thread"
>>which wakes up once every few minutes, calls "_heapmin", then goes back
>>to sleep.
>
>Except this only frees memory that is contiguous and at the end of
>one of their internal allocation blocks, right?

Yes, but if your program is regularly allocating and freeing memory
it will help a lot - you should fairly quickly reach a roughly static
level of memory usage, because freed memory will be reused in future
allocations.

Chris
-- 
--------------------------------------------------------------------------
 Chris Marriott, Warrington, UK      | Author of SkyMap v2 award-winning 
 [e-mail]            | shareware Windows planetarium.
            For full info, see http://www.execpc.com/~skymap  
      Author member of Association of Shareware Professionals (ASP) 
-------------------------------------------------------------------------- 

</PRE>

<HR><A NAME=WIN32_WINNT_MEM_MMFILE>
Return to <a href="wpw_w32_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Using Memory-mapped files.</H4><PRE>

>I need Win32 to hold a series of bitmaps (that the user has requested)
>in memory.  I don't want these to be offloaded to virtual memory;
>instead, I would like Win32 to discard the least-recently-used ones
>when memory gets full.  Do you think memory-mapped files are suitable
>for this task?  Is there a similar mechanism under Windows 3.1?

Hi!

I have implemented memory mapped BMP files.
Basicaly, the advantage is that when you open such a file,
it doesn't get loaded into memory until you start using it.

Works very nice on WinNT.
Works somewhat slow on Win95 (I'm not sure why).
Doesn't work on Win32s (SetDIBitsToDevice fails).

I can give you the source, if you wish.

Boris.


</PRE> 

</HTML>