Loading your MAINICON and VersionInfo through plain text .RC resource files.
Posted by jpluimers on 2016/10/19
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:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <RcCompile Include="MAINICON.rc"> | |
| <ModuleName>MAINICON.rc</ModuleName> | |
| <Form>MAINICON.res</Form> | |
| </RcCompile> | |
| <RcCompile Include="VERSIONINFO.rc"> | |
| <ModuleName>VERSIONINFO.rc</ModuleName> | |
| <Form>VERSIONINFO.res</Form> | |
| </RcCompile> |
Here are the example files:
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:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Atom 0xD8F8 with name "-%D4#!““`(W!“““`@W#““““" | |
| Atom 0xD8F9 with name "-%D4#!““`HT!“““`@W#““““" | |
| Atom 0xD8FA with name "-%D4#!““`+R!“““`@W#““““" | |
| Atom 0xD8FB with name "-%D4#!““`3P!“““`@W#““““" | |
| Atom 0xD8FC with name "-%D4#!““`*S!“““`@W#““““" | |
| Atom 0xD8FD with name "-%D4#!““`KO!“““`@W#““““" | |
| Atom 0xD8FE with name "-%D4#!““`,T!“““`@W#““““" |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Global Atom 0xEE11 with name "MSAA:000034C0:00001950:00000701:000034C0:" | |
| Global Atom 0xEE12 with name "MSAA:000034C0:000018C8:00000702:000034C0:" | |
| … | |
| Global Atom 0xEE25 with name "MSAA:000034C0:00001758:000006EC:000034C0:" | |
| Global Atom 0xEE26 with name "MSAA:000034C0:0000197C:000006ED:000034C0:" |
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 [WayBack] 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
The Wiert Corner - irregular stream of stuff 
kmorwath said
Just two advices: uses the RC.exe compiler from the Windows SDK to compile resources – it will support features the BRCC32 compiled doesn’t. Resources can be localized, so ensure they contain the correct ones for the languages you support. AFAIK, your resource script is set for Netherlands (if there is only one resource Windows can use that anyway).
jpluimers said
Thanks for the tips!