System Resources versus RAM

"PCR" wrote in message ...
Bill Blanton wrote:
"Bill in Co." wrote in message
...
Tim Slattery wrote:
"PCR" wrote:

"The lists point
to areas of memory where user interface elements (and other items)
are stored -- things like dialog boxes, windows, and so on." From
that, I divine these are lists of POINTERS to locations in RAM.

No, its the space for the dialog definitions, cursors, icons,
paintbrushes, menus, etc, etc themselves, not pointers to them.
Programs are supposed to create these things when they're needed
then release them when they're no longer needed. Even if programs
are well behaved (not all of them are), you can have enough
programs running at once to exhaust these heaps.

OH, this IS interesting. So what IS being stored in those heaps IS
the GDI (or whatever it is called) data itself, and NOT addresses or
pointers to that data. No wonder it can run out so soon (in
comparison to if it were just storing addresses to that special
data, which apparently would be useless).

The pointers are stored in the "handle" of the object, in an internal
list outside
the resource allocated heap. The object data stored in the resource
heap may
or may not contain pointers to data attributes outside the heap.

You could for example have a graphic object defined, but the bitmap
attribute
of the object may be pointed elsewhere.

How can an internal list be outside???

I meant internal to "Windows". The GDI, User or possibly app space.
A table of the object handles not stored in the resource heap.


Have you seen this table from
"Windows 98 Secrets (Livingston/Straub), p.1127...?...

Table 35-1 System-Wide Resources Then and Now
Resource Windows 3.1 Windows 98
----------- ---------------- -------------
Window/menu handles About 299 32K (each)
Timers 32 Unlimited
Listbox items (per listbox) 8K 32K
Listbox data (per listbox) 64K Unlimited
Edit control data (per ctrl) 64K Unlimited
Regions All in 64K Unlimited
Phys. pens, brushes, etc. All in 64K Unlimited
Logical fonts All in 64K 750-800
Installed fonts 250-300 1000
Device contexts 200 (best case) 16K

That looks suspiciously like this old KB article, which is no longer
available at microsoft.com -
http://ftp.telekabel.at/pub/chello/M.../Q117/7/44.TXT



I'm still thinking the heaps contain pointers only. The pointers point
to memory addresses that contain the stuff of that table. But I'm 50%
less sure!

All this has me wondering now too..

"Tim Slattery" wrote in message ...
"PCR" wrote:

I'm still having trouble visualizing what resources are about. I guess
there's not enough information in the book, & I should look elsewhere to
fill in the gap. Can it be...?... the heaps do contain pointers to
storage areas (as I said), but the lengths of the storage areas were
uniformly limited to 64K under Win3.1x. Now, most of it under Windows 98
can be larger.

The resource heaps do not contain pointers, they contain the things in
that list. If a program needs to create another paintbrush (used in
putting an image on the screen), for example, and there's not enough
space in the resource heap for it, it will report "not enough memory",
even though there's plenty of other RAM lying about.

I'm not certain, but I don't think that the "whole object" is contained in the
heap.(?), and that it is only the definition of the object. Consider a 32x32
bitmap icon using 32-bit color. That would only allow 16 icons of that size
in a 64k heap.

"Tim Slattery" wrote in message ...
"PCR" wrote:

I'm still having trouble visualizing what resources are about. I guess
there's not enough information in the book, & I should look elsewhere to
fill in the gap. Can it be...?... the heaps do contain pointers to
storage areas (as I said), but the lengths of the storage areas were
uniformly limited to 64K under Win3.1x. Now, most of it under Windows 98
can be larger.

The resource heaps do not contain pointers, they contain the things in
that list. If a program needs to create another paintbrush (used in
putting an image on the screen), for example, and there's not enough
space in the resource heap for it, it will report "not enough memory",
even though there's plenty of other RAM lying about.

I'm not certain, but I don't think that the "whole object" is contained in the
heap.(?), and that it is only the definition of the object. Consider a 32x32
bitmap icon using 32-bit color. That would only allow 16 icons of that size
in a 64k heap.

This reminds me of a "bug" in *Win9x*, that limits several applications or
file copying operations to 2 GB max file sizes, and NOT the expected 4 GB -

I think that is fixed by the '2-4 GB Files Errors Kernel Fix'
http://www.msfn.org/board/index.php?showtopic=81200
the downloads there doesn't work anymore(?) but there
is a patcher at http://www.mdgx.com/files/COPY2GB.EXE
and I guess it is included in win98se Servicepack2/3 too.

I think that problem in shell32 was fixed in WinME.

Yes WinME shell avoids the problem but for other programs
copying files 2GB with the same API the kernelpatch for ME
could be usefull too.

Bill Blanton wrote:
"PCR" wrote in message
...
Bill Blanton wrote:
"Bill in Co." wrote in message
...
Tim Slattery wrote:
"PCR" wrote:

"The lists point
to areas of memory where user interface elements (and other
items) are stored -- things like dialog boxes, windows, and so
on." From that, I divine these are lists of POINTERS to
locations in RAM.

No, its the space for the dialog definitions, cursors, icons,
paintbrushes, menus, etc, etc themselves, not pointers to them.
Programs are supposed to create these things when they're needed
then release them when they're no longer needed. Even if programs
are well behaved (not all of them are), you can have enough
programs running at once to exhaust these heaps.

OH, this IS interesting. So what IS being stored in those heaps
IS the GDI (or whatever it is called) data itself, and NOT
addresses or pointers to that data. No wonder it can run out so
soon (in comparison to if it were just storing addresses to that
special data, which apparently would be useless).

The pointers are stored in the "handle" of the object, in an
internal list outside
the resource allocated heap. The object data stored in the resource
heap may
or may not contain pointers to data attributes outside the heap.

You could for example have a graphic object defined, but the bitmap
attribute
of the object may be pointed elsewhere.

How can an internal list be outside???

I meant internal to "Windows". The GDI, User or possibly app space.
A table of the object handles not stored in the resource heap.

All right. I think I finally saw that by standing on my head.

Have you seen this table from
"Windows 98 Secrets (Livingston/Straub), p.1127...?...

Table 35-1 System-Wide Resources Then and Now
Resource Windows 3.1 Windows 98
----------- ---------------- ----------
---
Window/menu handles About 299 32K (each)
Timers 32 Unlimited
Listbox items (per listbox) 8K 32K
Listbox data (per listbox) 64K Unlimited
Edit control data (per ctrl) 64K Unlimited
Regions All in 64K Unlimited
Phys. pens, brushes, etc. All in 64K Unlimited
Logical fonts All in 64K 750-800
Installed fonts 250-300 1000
Device contexts 200 (best case) 16K

That looks suspiciously like this old KB article, which is no longer
available at microsoft.com -
http://ftp.telekabel.at/pub/chello/M.../Q117/7/44.TXT

That looks like source material to Livingston/Straub's description of
resources. The tables match fairly well. I see no mention of pointers in
the document or even of "lists of memory" that I saw in
Livingston/Straub, pp.1126-1127...

"RESOURCES are essentially lists (referred to as HEAPS) of memory. The
lengths of the lists under Windows 3.1x were quite small. The lists can
be much longer with Windows 98. The lists point to areas of memory where
user interface elements (and other items) are stored -- things like
dialog boxes, windows, and so on."

In the document (& in the book too), the workings of Windows resource
management isn't really described, but just hinted at (more so in the
book). I guess the authors filled in some gaps. Like Slattery, the
document does appear to define the two heaps to be the memory addresses
that hold the resources...

"In Windows 95, large portions of the graphics device interface (GDI)
and
USER heaps reside in the shared 32-bit virtual flat-address space of the
system."

"In addition, the USER heap data for list boxes now resides in the
32-bit shared address space."

...., where I thought the heaps were simply lists of pointers to memory
areas. Maybe both do exist. The heaps have to managed some way!

I'm still thinking the heaps contain pointers only. The pointers
point to memory addresses that contain the stuff of that table. But
I'm 50% less sure!

All this has me wondering now too..

More documentation is required.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

Bill Blanton wrote:
"PCR" wrote in message
...
Bill Blanton wrote:
"Bill in Co." wrote in message
...
Tim Slattery wrote:
"PCR" wrote:

"The lists point
to areas of memory where user interface elements (and other
items) are stored -- things like dialog boxes, windows, and so
on." From that, I divine these are lists of POINTERS to
locations in RAM.

No, its the space for the dialog definitions, cursors, icons,
paintbrushes, menus, etc, etc themselves, not pointers to them.
Programs are supposed to create these things when they're needed
then release them when they're no longer needed. Even if programs
are well behaved (not all of them are), you can have enough
programs running at once to exhaust these heaps.

OH, this IS interesting. So what IS being stored in those heaps
IS the GDI (or whatever it is called) data itself, and NOT
addresses or pointers to that data. No wonder it can run out so
soon (in comparison to if it were just storing addresses to that
special data, which apparently would be useless).

The pointers are stored in the "handle" of the object, in an
internal list outside
the resource allocated heap. The object data stored in the resource
heap may
or may not contain pointers to data attributes outside the heap.

You could for example have a graphic object defined, but the bitmap
attribute
of the object may be pointed elsewhere.

How can an internal list be outside???

I meant internal to "Windows". The GDI, User or possibly app space.
A table of the object handles not stored in the resource heap.

All right. I think I finally saw that by standing on my head.

Have you seen this table from
"Windows 98 Secrets (Livingston/Straub), p.1127...?...

Table 35-1 System-Wide Resources Then and Now
Resource Windows 3.1 Windows 98
----------- ---------------- ----------
---
Window/menu handles About 299 32K (each)
Timers 32 Unlimited
Listbox items (per listbox) 8K 32K
Listbox data (per listbox) 64K Unlimited
Edit control data (per ctrl) 64K Unlimited
Regions All in 64K Unlimited
Phys. pens, brushes, etc. All in 64K Unlimited
Logical fonts All in 64K 750-800
Installed fonts 250-300 1000
Device contexts 200 (best case) 16K

That looks suspiciously like this old KB article, which is no longer
available at microsoft.com -
http://ftp.telekabel.at/pub/chello/M.../Q117/7/44.TXT

That looks like source material to Livingston/Straub's description of
resources. The tables match fairly well. I see no mention of pointers in
the document or even of "lists of memory" that I saw in
Livingston/Straub, pp.1126-1127...

"RESOURCES are essentially lists (referred to as HEAPS) of memory. The
lengths of the lists under Windows 3.1x were quite small. The lists can
be much longer with Windows 98. The lists point to areas of memory where
user interface elements (and other items) are stored -- things like
dialog boxes, windows, and so on."

In the document (& in the book too), the workings of Windows resource
management isn't really described, but just hinted at (more so in the
book). I guess the authors filled in some gaps. Like Slattery, the
document does appear to define the two heaps to be the memory addresses
that hold the resources...

"In Windows 95, large portions of the graphics device interface (GDI)
and
USER heaps reside in the shared 32-bit virtual flat-address space of the
system."

"In addition, the USER heap data for list boxes now resides in the
32-bit shared address space."

...., where I thought the heaps were simply lists of pointers to memory
areas. Maybe both do exist. The heaps have to managed some way!

I'm still thinking the heaps contain pointers only. The pointers
point to memory addresses that contain the stuff of that table. But
I'm 50% less sure!

All this has me wondering now too..

More documentation is required.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR