I like repositories to have as much of the information in text format.
Delphi traditionally puts both the MAINICON and the VersionInfo resources in a binary .res file and also updates that file on almost every recompile.
There are quite a few posts explaining how to get them from text, but a version controlled example works best for me, so there is one at https://github.com/jpluimers/atom-table-monitor/blob/master/ATOMScannerConsole
The trick is to:
put your resources in a text RC file that can be compiled through a resource compiler
add these to your Delphi project via the project manager, so it generated RcCompile elements which instructs the build process to run the resource compiler first:
Here are the example files:
ATOMScannerConsole.dpr
ATOMScannerConsole.dproj
MAINICON.rc
VERSIONINFO.rc
The MAINICON is based on the public domain Nuclear Atom Atomic / The Noun Project (National Park Service) / 128px / Icon Gallery.
Note that if you include 256×256 or larger 32-bit icons in your ICO file, you will most likely get an “allocate failed” error during compile. Somehow older Delphi versions (TODO: which ones <g>) don’t support these large icons.
The project in fact was to assist me researching the cause for .net – How to research what resources are leaked by which application (not a full ATOM table issue) – Stack Overflow.
The original source was only half there in the repository missing the most important piece and having seriously flawed logic. So I reconstructed a command-line application that now can:
Scan for Global Atoms, global registered WindowsMessages
Identify two kinds of Atoms: Delphi program related and “Special” (most likely leaked by Microsoft Test Manager)
Reasonably successfully determine the Process Id for Delphi program related Atoms (to figure out of the process is still running)
Release both the Delphi program related and “Special” atoms from memory
Enjoy (:
The Special Global Atoms it finds all have to do with MSAA and are formatted like:
The Delphi related Global Atoms and RegisterWindowsMessages it correspond to the below table:
Prefix
Kind
Id kind
Unit
Delphi
GlobalAddAtom
Process Id
Controls/Vcl.Controls
ControlOfs
GlobalAddAtom + RegisterWindowMessage
Thread Id
Controls/Vcl.Controls
WndProcPtr
GlobalAddAtom
Thread Id
Controls/Vcl.Controls
WideWndProcPtr
GlobalAddAtom
Thread Id
???
DlgInstancePtr
GlobalAddAtom
Thread Id
Dialogs/Vcl.Dialogs
The RegisterWindowMessage of ControlOfs is supposed to be fixed in Delphi XE3 (version 17.0.4625.53395), but lots of people qre quite a few Delphi versions behind as RTL, VCL and IDE haven’t improved dramatically for them (very few clients use FMX as it has had a troublesome start).
Even though Resource leak caused by RM_GetObjectInstance message: QualityCentral indicates the atoms are released, I’ve empirically observed often they don’t. It looks like either the finalization section of the Controls unit or the DoneControls method isn’t always successfully called upon program termination or DLL unload.
It did fox the RegisterWindowMessage for XE3 and up, but not for lower versions. So Andy (Andreas Housladen) wrote Fix for QC 90511 (Atom leak) for Delphi 6 – XE which you can download through the VCL Fix Pack page.
–jeroen
PS: related background information
Embarcadero Discussion Forums: Serious bug in VCL eats up global atoms…
http://web.archive.org/web/20150811055156/http://forums.embarcadero.com/thread.jspa?threadID=47678
Resource leak caused by RM_GetObjectInstance message: QualityCentral
Filed under: Delphi, Delphi 10 Seattle, Delphi 2007, Delphi 2009, Delphi 2010, Delphi XE, Delphi XE2, Delphi XE3, Delphi XE4, Delphi XE5, Delphi XE6, Delphi XE7, Delphi XE8, Development, Software Development
