indra@brahms.amd.com (Indra Singhal) (04/30/91)
Well, as I type this I am on the phone with Windows tech support and
they are putting me on and off hold trying to figure this out... So I go
to the better support source: The Net!!
With 12Meg Ram and 4Mb Cache, 2Mb Ram disk 16Mb permanent swap, with a
dozen windows including 3-4 hDC microapps I run 'out of memory or other
windows resource'. Even though hDC memory viewer shows I have 11Mb or
memory available (must include swap)...
I combed the ini files and could not find any resource description that
I could increase...
I just concluded with MS... they are going to try to recreate my problem
and get back to me... I will keep you all posted if I find out from them
before I do from the net!
Any word on a postscript driver that does not download the fonts again
and again on each page?
--
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 94088coxs@itsgw.rpi.edu (Sean Cox) (04/30/91)
indra@brahms.amd.com (Indra Singhal) writes: >Well, as I type this I am on the phone with Windows tech support and >they are putting me on and off hold trying to figure this out... So I go >to the better support source: The Net!! >With 12Meg Ram and 4Mb Cache, 2Mb Ram disk 16Mb permanent swap, with a >dozen windows including 3-4 hDC microapps I run 'out of memory or other >windows resource'. Even though hDC memory viewer shows I have 11Mb or >memory available (must include swap)... I seem to recall (i.e. I read it >somewhere<) that the windows "resources available" is simply an indication of how much space is available on teh 2 application stacks (each a 64k segment for obvious :( reasons). What's probably happeneing is that your applications are taking up most of the available space on these stacks and windows won't run anything else because it thinks you're machine is "full." Gotta love backwards compatibility. :) -Sean -- ___________________________________________________________________________ | / coxs@rpi.edu \ | | Sean Cox / coxs@mts.rpi.edu \ Your imprint here | |________________________/ coxs@RPITSMTS.BITNET \_________________________|
dorsai@iear.arts.rpi.edu (gregory d moncreaff) (04/30/91)
reguarding this thread, has anyone noticed that if you open up a an iconized group in program.exe there is an unrecoverable loss of system resources? ie. before open, 77% free; while open 70%; but when you close it it stays at 70% i really noticed this when i re-installed whinedows; there were so many little pieces of quasi usefull (_)ware on my disk that when i rebooted an ran windows, all the program groups were open, and i had only 6% free resources! perhaps someone from the programming group can tell us if this 'free system resources' actually coresponds to the # of program.rc info, aka icons that have been used? -- "A perfect democracy, a 'warm body' democracy in which every adult may vote and all votes count equally, has no internal feedback for self-correction. It de- pends solely on the wisdom and self restraint of citizens ... which is opposed by the folly and lack of self-restraint of other citizens. What is supposed to
mmshah@athena.mit.edu (Milan M Shah) (04/30/91)
WRT running lots of apps on a machine with lots of memory and still running out of resources, I believe the culprit is a type of resource called a handle. In very general terms, a handle is a "magic cookie" that identifies all types of windows objects. For example, if an app allocates a chuck of memory, opens a application window, and creates a pop up menu, it *might* take up 3 handles. When the application wants to manipulate the object, it identifies it via the handle. Now, an application that displays lots of icons, like progman) might allocate a handle for each icon. Now, the main reason that people are running out of resources is that windows can allocate at most 8192 handles, from which it draws whatever *it* needs. Moreover, a lot of poorly written applications allocate handles but never release them, even after you quit the app. (For example, every time you select the About... dialog box, most apps will allocate a handle. Quite a few never bother to release the handle even after you are done with the dialog box). These handles are lost until the next session. The severe limit on the number of handles is hopefully going to be addressed in the next version of windows. One might think that one is never going to have 8192 objects (most of them displayable). However, this is not the case; consider a naive implementation of a spreadsheet, where each cell is its own window and has its own handle. Hope this helps. Milan .
grantk@manta.NOSC.MIL (Kelly J. Grant) (04/30/91)
In article <1991Apr29.184300.13990@amd.com> indra@brahms.amd.com (Indra Singhal) writes: >With 12Meg Ram and 4Mb Cache, 2Mb Ram disk 16Mb permanent swap, with a >dozen windows including 3-4 hDC microapps I run 'out of memory or other >windows resource'. Even though hDC memory viewer shows I have 11Mb or >memory available (must include swap)... > In this month's BYTE magazine is a great article on standard Windows problems. Sorry I can't give a page reference, but the magazine is at home in the library :-). I believe it was in the 'Hands On' column. (Also, there is a fabulous article on packet drivers, what they are, how they work, etc..) Anyway, the gist of the article is that there is are a couple of 64K stacks in the main executables (USER.EXE was one of them...) that keep a lot of information about running processes. The 'resources available' from the about box is actually the stack space available, not the percentage of free memory. It doesn't matter how much memory you have if these stacks fill up. It seems certain programs will hog these stacks if you let them. One suggestion is to load the programs in a different order; this can change the way the individual programs allocate space in these stacks. Anyway, the article is good reading. If you can't find it, email to me and I will send the volume/page reference. Kelly -- Kelly Grant grantk@manta.nosc.mil (619) 225-2508 Computer Sciences Corp ^^^^^^^^ Important: manta.UUCP won't get to me 4045 Hancock Street "If you are given lemons.....see if you can trade for San Diego, CA 92110 chocolate" - me
hamilton@nwnexus.WA.COM (Dick Hamilton) (05/02/91)
In article <1950@manta.NOSC.MIL> grantk@manta.NOSC.MIL (Kelly J. Grant) writes: >in the main executables (USER.EXE was one of them...) that keep a lot of >information about running processes. The 'resources available' from the >about box is actually the stack space available, not the percentage of >free memory. It doesn't matter how much memory you have if these stacks >fill up. It seems certain programs will hog these stacks if you let them. >One suggestion is to load the programs in a different order; this can change >the way the individual programs allocate space in these stacks. I have heard that you can actually compact some of the allocated space on the stacks by simply viewing the "system resources free" db in Program Manager or by viewing the hDC FirstApps Memory Viewer with the "Include Discardables" switch toggled. This slight increase results in the memory area allocated to USER.EXE and GDI.EXE being compacted, well not the memory area itself, it's fixed at 64k each, but the space that is currently occupied. Dick Hamilton hDC Computer Corporation
07790@tanus.oz.au (Brant Campbell) (05/13/91)
The System Resources reported in the help about program manager is a more
accurate measure of the performance of your system than is the amount of
memory reported by the same or any other free-memory utility. The reasons for
this are as follows:
In the Windows memory management scheme there is two segments of memory set
aside to "remember" what's what. By this I mean if a window is minimized then
this memory stores the RESTORED window size and position and what was
happening - i.e. where the cursor was, if something was highlighted or
selected, position of icons and a few others.
Now assume that you have several windows (programs) running and the amount of
memory it would take to store this info, don't forget to add all the info for
EACH group in the program manager - yes the more groups and icons the lower
you push your system resources! You now can begin to imagine what's happening
- and due to certain DOS restrictions this memory area that holds this info is
restricted to equal segments of 32K (64?) -either way that's not much. So you
can have 11 meg free but no resources because you have lots of windows and no
more room to store the necessary info for general memory management.
Now you say this should easily be able to be overcome - just think though how
DOS allows memory allocation and the picture begins to come into place -
obviously improvements will be made due to the large chunk of resources that
some single programs can take up with all their windows.
General rule of thumb - as little as possible groups in program manager or
better still not use it if you insist on more resources. I tested this but
making over 30 groups in progman and tried to run an app - no app "Not enough
memory to run application, close one or more windows...". Hard to believe when
the only thing running is windows and progman!! TOO MANY GROUPS. Allt hese
groups and over 17000K memory free but 2% resources and a UAE!
Brant Campbell.
UUCP: {munnari}!jabaru!anthos!tanus!07790
INET: 07790@tanus.oz.au