GDI Objects and Windows 95 Heaps

• Microsoft Win32 Application Programming Interface (API) included with:

      - Microsoft Windows 95 version 4.0
  

Under Windows version 3.1, GDI allocates all resources from a single 64K heap. This limit has caused many applications to run out of GDI resources, especially when using objects that can really take up a lot of the heap, like elliptical regions. This caused GDI resources to be dangerously low when executing several applications at once.

Windows 95 has now introduced a combination of a 16-bit heap and an additional 32-bit heap. The 16-bit heap is still limited to 64K but the 32-bit heap can grow as large as available memory.

As in Windows version 3.1, the 16-bit GDI.EXE of Windows 95 continues to have a 16-bit DGROUP segment with a local heap within it, and most logical objects are still stored in this local heap. The data structures that describe brushes, bitmap headers, and pens, for example, stay in the 16-bit heap. All physical objects, like fonts and bitmaps, are now stored in the 32-bit heap. GDI regions have also been moved to the 32-bit heap. Moving these GDI resources to the 32-bit heap takes the pressure off of the 64K 16-bit heap.

Regions can take up a large amount of resources and were the main source of problems with GDI memory in Windows version 3.1. This will not be a limitation in Windows 95 because regions are stored in the 32-bit heap. Applications will be able to use much more complex regions, and regions will be more useful now that they are not limited to a local 64K heap.

Windows 95, like Windows NT, will free all GDI resources owned by a 32-bit process when that process terminates. Windows 95 will also clean up any GDI resources of 16-bit processes marked as a 4.0 application. Because GDI objects were sharable between applications in Windows version 3.1, Windows 95 will not immediately clean up GDI resources for 16-bit applications marked with a version less than 4.0. However, when all 16-bit applications have finished running, all GDI resources allocated by previous 16-bit applications will be cleaned up.