indra@brahms.amd.com (Indra Singhal) (05/06/91)
I must thank:
From: dorsai@iear.arts.rpi.edu (gregory d moncreaff)
From: mmshah@athena.mit.edu (Milan M Shah)
From: grantk@manta.NOSC.MIL (Kelly J. Grant)
From: hamilton@nwnexus.WA.COM (Dick Hamilton)
From: Joel Spolsky <spolsky-joel@CS.YALE.EDU>
From: Vesa Komulainen <KTK-VK%finou.oulu.fi@SEARN.SUNET.SE>
for either replying or posting on the subject. In order to keep this
posting as brief as possible, I am not including all their postings
again! Just the facts...
Learnt from you folks that something called 'handles' was the real
resource that Progman/Help/About reports, that these beasts are limited
to 8,192 pieces... that they could run out much before real memory, as
it happened in my case.
I did a test, results follow, I systematically opened up applications
within windows and looked at the Resource figure upon opening and
subsequent closing of the application to get a feel for the resource use
and how well each application returned the resource. Note: the only
tool that measures this, is Progman/Help/About and the accuracy is
rounded to the nearest digit with no real units just %. [Any takers for
a better tool?]
Following the raw numbers, I will have conclusions I drew and a word
about what I got from Microsoft Tech Support on this issue.
Application: Start End Used Comments
Program Mgr 86 14 All groups closed.
+ 4 icon group 85 85 1
+ 9 icon group 81 81 4
+11 icon group 78 78 3
+10 icon group 75 75 3
+20 icon group 70 70 5
+ 4 icon group 68 68 2 No Resource returned.
Subsequent tests started at this level:
hDC MicroApps with/ (*)StLine is not a uApp.
System Enhancer 55 59 4 It was in my Wkset so I
Work Sets 62 3 Let it be.
Straight Line(*) 64 2
Close Micro Apps 67 3
I beleive hDC uApps Mgr returns resources... 68-67% could be due to rounding
errors. After uApps Mgr started I began closing each uApp and checking the
Resource until I closed them all. Other uApps checked follow:
hDC uApps (as above) 55
+Disk Viewer 52 55 3
+Memory Viewer 54 55 1
+Font Viewer 54 54 1
+Desktop 52 54 1 1 lost somewhere
Close hDC & stline 67
Restart hDC as above 55
+Memory Viewer 54
(Inc. Discardable
Memory) 54 55 1 This did not reclaim
any resource as was
suggested in a response.
Close hDC & Stline 67
BeckerTools 32 65 35 2% lost
again 32 67 33 2% returned
again 31 65 34 2% lost again
again 31 65 34 2% lost for good?
I don't keep it open
anymore!
4Dos Shell 63 65 2
Command Com 63 65 2
ATM Control Panel 62 65 3
CorelDRAW 2.0 59 65 6 No Data file
PowerPoint 2.0 49 65 16 No Data file
Word 4 Windows 1.1 54 65 11 No Data file
Ventura 3.0 4 windows 62 63 3 2% lost (no data file)
Again -- 63 - Sys div/0 error
Again 60 62 3 2 page document +1 lost
Again -- 62 - Sys div/0 error (nodoc)
Excel 3.0 47 62 15 No data file
Microphone II 1.01 55 62 12 No connection
Conclusions: [Mine and mine alone, my employer doesn't pay me for this, and
all testing was done on personal time]
Becker Tools and Ventura need to have their code reviewed by those
who know Windows programming better. So does the code for Program
Manager.
There are no tools out there that measure the restricting resource.
Watching memory is of little use when bottleneck is elsewhere.
Microsoft Tech support outcome:
1st required me to get rid of 386Max, PC Tools' cache & ram disk,
then asked to have files=40 up'd to 100, buffers=5 up'd to 10, use
himem.sys, smartdrv and ramdrive.
I did all that it made no change. By then I knew it was futile, thanks
to you all! Now I will go back and tell them!
Flames > /dev/null. Constructive comments: please e-mail. Hope this exercise
of mine is useful to some of you!
--
iNDRA | indra@amd.com or {ames apple uunet}!amd!indra
| (Indra Singhal) (408) 749-5445; Advanced Micro Devices
| MS 167; Box 3453; 901, Thompson Pl., Sunnyvale, CA 94088Thomas_Hornschuh@p1.f36.n245.z2.fidonet.org (Thomas Hornschuh) (05/07/91)
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. keithp@nwnexus.WA.COM (Keith Pleas) (05/09/91)
In article <1991May6.075011.14338@amd.com> indra@brahms.amd.com (Indra Singhal) writes: >Note: the only >tool that measures this, is Progman/Help/About and the accuracy is >rounded to the nearest digit with no real units just %. [Any takers for >a better tool?] Well, the HEAPWALKER utility that comes with the MS Windows SDK will let you explore this in greater detail. FWIW, my understanding is that Systems Resources is equal to the 64K segment set aside for the global heap. I also understand that this relatively small limit will be greatly increased with Windows 3.1. I looked into a specific situation where system resources seemded to disappear when Shelling out to a TPW generated program from WFW. I found that the application destroyed itself, but left some heap memory unrecovered in the User segment. Also, I am running ATM, which will increase in size to accomodate additional fonts; some of this memory is not reclaimed when the application terminates.