Explanation of System Resources in Windows 95ID: Q117744
|
The use of system resources in Windows 95 is improved over that in Windows 3.x and Windows for Workgroups 3.x. The 32-bit architecture of Windows 95 makes this improvement possible.
NOTE: In this article, the term "Windows" refers to Windows 3.x and
Windows for Workgroups 3.x.
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. This address space is shared by all cached objects in Windows 95
(for example, the disk I/O cache, the network cache, the GDI cache, and
third-party shared application data). This region of memory is as large as
your physical memory plus your swap file.
Windows 95 incorporates the Windows 64-kilobyte (K) system-resource limit
for better performance when it is providing backward compatibility. Items
that remain in one or more 64K segment(s) are mostly for use in the GDI
heap and include logical pens, logical brushes, logical fonts, bitmaps,
and palettes. To improve the use of system resources, Windows 95 moves the
following items into the 32-bit shared address space: device contexts,
physical pens, physical brushes, and so on. Another improvement in Windows
95 is that the limit for device contexts is now over 4,000 system wide. In
contrast, device contexts are limited to between 150 and 200 system wide
in Windows.
The USER heap in Windows has a limit of 200 menu and window handles
(combined) for the entire system. Some programs tend to allocate many of
these handles when they are performing large tasks, which causes the
system to run out of resources quickly. To avoid such problems, Windows 95
moves the data for these menu and window handles to the 32-bit shared
address space, thereby raising the total limit to 32,767 each per process
(compared to the system-wide limit of 200 in Windows). In addition, the
USER heap data for list boxes now resides in the 32-bit shared address
space. The USER heap in Windows 95 also provides a new 32-bit edit control
that imposes no limits on the size of the data that you can store in it.
The following table is only approximate because it is difficult to list
exact limits for GDI objects in Windows 3.1 because all regions, physical
objects, logical objects, DCs, and installed fonts have to fit in a single
64K segment. Moving these into the 32-bit heap in Windows 95 provides more
room for the remaining (small) items such as logical pens and brushes. The
remaining items in the Windows 95 local heap are all less than 10-20 bytes
each.
Resource Windows Windows 95 Windows NT
---------------------------------------------------------------------
Window/Menu Handles about 200 32K (each) Unlimited
Timers 32 Unlimited Unlimited
COM/LPT ports 4 each Unlimited Unlimited
Listbox items 8K 32K Unlimited
(per listbox)
Listbox data 64K Unlimited Unlimited
(per listbox)
Edit control data 64K Unlimited Unlimited
(per control)
Regions All in 64K segment Unlimited Unlimited
Physical pens, brushes All in 64K segment Unlimited Unlimited
Logical fonts All in 64K segment 750-800 Unlimited
Installed fonts 250-300 (best case) 1000 Unlimited
Device Contexts 200 (best case) 16K Unlimited
Logical pens, brushes All in 64K segment 64K segment Unlimited
NOTE: The limits in Windows NT are for Win32-based applications. In many
cases, there are 32K or 64K limits on most of these resources for 16-bit
Windows-based applications due to limits on the size of the 16-bit
Windows-based application handles. You can avoid these limits in Windows
NT 3.5 by running more than one copy of WOW.
Additional query words: gdi.exe user.exe
Keywords : kbother diskmem win95
Version : 95
Platform : WINDOWS
Issue type :
Last Reviewed: May 18, 1999