Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uunet!mcsun!unido!rwthinf!slcdec!hippo!f1.n6000.z2.fidonet.org!p1.f36.n245.z2.fidonet.org!Thomas_Hornschuh
From: Thomas_Hornschuh@p1.f36.n245.z2.fidonet.org (Thomas Hornschuh)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Out of Resources in Windows3? [Summary, long]
Message-ID: <217565947@p1.f36.n245.z2.fidonet.org>
Date: 7 May 91 13:36:46 GMT
Reply-To: Thomas_Hornschuh%p1.f36.n245.z2@hippo.dfv.rwth-aachen.de (Thomas Hornschuh)
Organization: Thomas Hornschuh, SoftStream 2, Dortmund (FRG)
Lines: 72
Comment-To: Indra_Singhal@f1.n6000.z2.fidonet.org (Indra Singhal)

IS> 
IS> Learnt from you folks that something called 'handles' was the real
IS> resource that Progman/Help/About reports, that these beasts are limited
IS> to 8,192 pieces... that they could run out much before real memory, as
IS> it happened in my case.

The magic 8192 is the number of global handles, which are references to the 
global memory objects an application allocates. This is a hardware limitation, 
because 8192 is the maximal number of descriptors in al local descriptor table 
(LDT) of the 286 and higher Intel processors in protected mode.
But I think that this number isn't the reference for the resource display of 
the progman.
Mircosofts writes an the file "tips.txt" supplied with the SDK:

------------------------------------
1.8  Limitations on System Resources
------------------------------------


1.8.1   Limitation on number of Windows in system

There is a limit to the number of windows that can be
created system-wide. Each window creates a window structure
that is allocated out of USER's heap, a data segment, which
is limited to 64K. This is the limitation. Since there are a
number of items that effect the USER's heap, there is no way
to determine how much space will be around at any given
time.  You can use Heap Walker to check the size of USER's
data segment.


1.8.2   Menus and their effect on system resources

Menus are stored in USER's heap and they have a large effect
on system resources available. If an application loads a
menu and doesn't associate it with a window, it must destroy
the menu itself. (Menus used with the TrackPopupMenu
function won't automatically be freed when the application
exits.)


1.8.3   Calculating Free System Resources

The Free System Resources figure in Program Manager's About
dialog box is calculated as follows:

The calculation is the same for all modes (although not done
for real mode).

% free = min (% free of USER's heap, % free of GDI's heap)

                           (Max heap size - heap used) 
% free USER or GDI heap =  --------------------------- * 100
                                  Max heap size

The maximum heap size is 64K less the sum of the size of the 
static variables and the stack.

There is no external API defined to calculate these values.


In short words:
There are 2 memory blocks of 64K each, the USER and the GDI heap. If either of 
these heaps is completly eat up, the free system resources are 0 %. Every 
window (technically each Button, Scrollbar, Checkbox, etc. is at least one 
window), every Icon consumes some of this space. How much, depends on the 
design of an application. If an application would create all dialogboxes at 
beginning, and only show and hide them, it would be use much of the resources. 
Applications that creates only windows of the currently open dialogboxes and 
destroy them immedatly after closing the dialog consumes less memory, but would 
be slower.