Hutch, Sinsi,
Thanks. In my own proggies,
Dll & Declare perform the FreeLibrary; perhaps it's not needed... OTOH, I never indulge in DeleteObject orgies in a WM_DESTROY handler, although you may find such stuff in Windows programming tutorials.
Below a small collection of related sources.
The Old New Thing: Quick overview of how processes exit on Windows XP3 May 2007
The kernel will close all your open handles to
kernel objects. Any memory you allocated will be freed automatically when the process's address space is torn down.
ExitProcess function6. All of the object handles opened by the process are closed.
Terminating a process has the following results:
Any remaining threads in the process are marked for termination.
Any resources allocated by the process are freed.
All kernel objects are closed.
The process code is removed from memory.
The process exit code is set.
The process object is signaled.
While open handles to kernel objects are closed automatically when a process terminates,
the objects themselves exist until all open handles to them are closed. Therefore, an object will remain valid after a process that is using it terminates
if another process has an open handle to it.
CodeGuru Alexey BRegardless of how the process terminates, the system guarantees that all allocated memory,
all User and GDI objects are freed, all open files are closed and the usage count on all kernel objects is decremented.
Mark Russinovich's Blog: Pushing the Limits of Windows:
USER and GDI ObjectsUser Objects
With the fundamental concepts in hand, let's turn our attention first to USER objects. USER objects get their name from the fact that they represent user interface elements like desktops, windows, menus, cursors, icons, and accelerator tables (menu keyboard shortcuts). Despite the fact that USER objects are associated with a specific desktop, they must be accessible from all the desktops of a session, for example to allow a process on one desktop to register for a hotkey that can be entered on any of them. For that reason, the window manager assigns USER object identifiers that are scoped to a window station.
A basic limitation imposed by the window manager is that no process can create more than 10,000 USER objects. That limitation attempts to prevent a single process from exhausting the resources associated with USER objects, either because it’s programmed with algorithms that can create excessive number of objects or because it leaks objects by allocating them and
not deleting them when it's through using them. You can easily verify this limit by running the Sysinternals Testlimit utility with the –u switch, which directs Testlimit to create as many USER objects as it can
Debugging a GDI Resource Leak --Definitions--
GDI Objects are resources that are managed by GDI32.DLL on behalf of an application. Some of the most common types of GDI objects are Device Contexts (DCs), Bitmaps, Brushes, Fonts, Metafiles, Pens, and Regions. GDI Objects are stored in
Kernel Memory (specifically the Paged Pool or Session Pool portions of kernel memory – more on this later).
GDI Handles are unique identifiers of a GDI Object. Each GDI Object can have only one handle. Each GDI Handle is process-specific (cannot be used by other processes).
The GDI Handle Table is a table (array) of GDI entries. Each entry contains 32-bits of information about a GDI object, including the handle, the type of the object (i.e. bitmap, DC, pen, font, etc.), the process for which that handle is valid, and a pointer to the actual GDI object in Kernel Memory. This table exists in User Memory.
