Too bad the whole mechanism involving TRegGroups.UnregisterModuleClasses is not documented anywhere

It is the underlying storage to support TClassFinder, which was introduced in Delphi 6, documented on-line in Delphi 2007, documented slightly in Delphi 2009, and since Delphi 2010 only one line of documentation was added (including the unchanged “instatiated”):

• Delphi 2007: [WayBack] TClassFinder Class
  

  This is class Classes.TClassFinder.

• Delphi 2009:[WayBack] TClassFinder Class
  

  The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

• Delphi 2010:[WayBack] Classes.TClassFinder – RAD Studio VCL Reference
  

  TClassFinder allows registered persistent classes to be retrieved.

  The TClassFinder allows the list of registered persistent classes to be retrieved. Objects instatiated from persistent classes are those that can be stored (serialised) beyond the operation of the current application.

Back to TRegGroups.UnregisterModuleClasses: it takes a HMODULE parameter and ultimately gets called through the (since Delphi 2007) on-line documented [WayBack] Classes.UnRegisterModuleClasses Function

procedure UnRegisterModuleClasses(Module: HMODULE);

Call UnRegisterModuleClasses to unregister all object classes that were registered by the module with the handle specified by the Module parameter. When a class is unregistered, it can’t be loaded or saved by the component streaming system.

After unregistering a class, its name can be reused to register another object class.

To get more context about the access violation, I used both the stack trace and a debugging watch for GetModuleName(Module) (using the [WayBack] SysUtils.GetModuleName Function).

In order to see which classes were registered by what module, I set a breakpoint at in TRegGroup.AddClass (which can be called through various code paths):

procedure TRegGroup.AddClass(AClass: TPersistentClass);
begin
  FGroupClasses.Add(AClass);
end;

HModule

That gave me the class, but I also needed the HModule for a class, so I did a windows get module of currently executing code – Google Search, giving me these links, all C/C++ related:

• [WayBack] c++ – How do I get the HMODULE for the currently executing code? – Stack Overflow
  

  I currently use the following trick (inspired from this forum):

  const HMODULE GetCurrentModule()
  {
      MEMORY_BASIC_INFORMATION mbi = {0};
      ::VirtualQuery( GetCurrentModule, &mbi, sizeof(mbi) );
  
      return reinterpret_cast<HMODULE>(mbi.AllocationBase);
  }

  Is there a better way to do this that doesn’t look so hacky?

• [WayBack] Accessing the current module’s HINSTANCE from a static library | The Old New Thing
  

  If you are using a Microsoft linker, you can take advantage of
  a pseudovariable which the linker provides.

  EXTERN_C IMAGE_DOS_HEADER __ImageBase;
  #define HINST_THISCOMPONENT ((HINSTANCE)&__ImageBase)
  

  The pseudovariable __ImageBase
  represents the DOS header of the module, which happens to
  be what a Win32 module begins with.
  In other words, it’s the base address of the module.
  And the module base address is the same as its HINSTANCE.

Here you already see some confusion: there is HINSTANCE and HMODULE. That’s a historic thing, as described by Raymond Chen in [WayBack] What is the difference between HINSTANCE and HMODULE? | The Old New Thing:

They mean the same thing today, but at one time they were quite different.
It all comes from 16-bit Windows.
In those days, a “module” represented a file on disk that had been loaded into memory, and the module “handle” was a handle to a data structure that described the parts of the file, where they come from, and where they had been loaded into memory (if at all). On the other hand an “instance” represented a “set of variables”.
One analogy that might (or might not) make sense is that a “module” is like the code for a C++ class – it describes how to construct an object, it implements the methods, it describes how the objects of the class behave. On the other hand, an “instance” is like a C++ object that belongs to that class – it describes the state of a particular instance of that object.
In C# terms, a “module” is like a “type” and an instance is like an “object”. (Except that modules don’t have things like “static members”, but it was a weak analogy anyway.)

GetModuleName

Searching for delphi “__ImageBase” – Google Search then got me [WayBack] c++ – Get DLL path at runtime – Stack Overflow with a nice Delphi related answer by [WayBack] Ian Boyd:

For Delphi users:

SysUtils.GetModuleName(hInstance);              //Works; hInstance is a special global variable
SysUtils.GetModuleName(0);                      //Fails; returns the name of the host exe process
SysUtils.GetModuleName(GetModuleFilename(nil)); //Fails; returns the name of the host exe process

In case your Delphi doesn’t have SysUtils.GetModuleName, it is declared as:

...

This reassured my use of [WayBack] SysUtils.GetModuleName code was OK:

function GetModuleName(Module: HMODULE): string; 
var
  ModName: array[0..MAX_PATH] of Char; 
begin
  SetString(Result, ModName, GetModuleFileName(Module, ModName, Length(ModName))); 
end;

HInstance in Delphi

The example from Ian Boyd also brought back memories from long ago about the [WayBack] HInstance Variable – Delphi in a Nutshell [Book]:

Delphi in a Nutshell by Ray Lischner

Name

HInstance Variable

Syntax

unit SysInit;
var HInstance: LongWord;

Description

The HInstance variable stores the instance handle for the module (application, library, or package) that contains the HInstance reference.

Tips and Tricks

• The most common use for a module’s instance handler is to load resources from the module. A unit can use HInstance to load resources that are linked with that unit (using the $R compiler directive). To load resources that are linked with a different unit (which might reside in a different package), see the FindHInstance function.
• To load resources that must be localized (e.g., forms, strings), see FindResourceHInstance.
• The instance handle of the main application is stored in MainInstance.
• Earlier versions of Delphi stored the main instance handle in HInstance, requiring a call to FindHInstance to learn a module’s instance handle. The current release stores the module’s instance handle in HInstance.

Example

// Use the Image Editor to create a .RES file that
// contains the company logo as the resource named LOGO.
// The GetLogo procedure sets its Bitmap argument
// to the company logo bitmap.

{$R 'Logo.res'}

procedure GetLogo(Bitmap: TBitmap);
begin
  Bitmap.LoadFromResourceName(HInstance, 'LOGO');
end;

See Also

FindClassHInstance Function, FindHInstance Function, MainInstance Variable

The HInstance variable – surprisingly – is in the SysInit unit, not the System unit, which is not documented in Delphi [Archive.is] 2007, [Archive.is] 2009, through [WayBack] XE2, and got only a slightly bit of documentation added in Delphi XE3:

• [WayBack] SysInit – XE3 API Documentation and Delphi Rio [WayBack] SysInit – RAD Studio API Documentation
• [WayBack] SysInit.HInstance – XE3 API Documentation and Delphi Rio [WayBack] SysInit.HInstance – RAD Studio API Documentation
  

  HInstance: HINST;             { Handle of this instance }

  Embarcadero Technologies does not currently have any additional information.

The Delphi XE2 RTL added [WayBack] SysInit.__ImageBase which is an alias for the (also added in XE2) [WayBack] SysInit.ImageBase (both sort of documented as of Delphi XE3):

ImageBase: Pointer;           { Special symbol that is actually located at the module load address. @ImageBase. }

Getting the HModule from a class: use FindClassHInstance

You might think that when a method is called UnregisterModuleClasses, similar methods about HModule would also include Module in their name. But in practice, it is confusing, especially since most of these methods have been there since the Delphi 3 era, just looking at these names:

procedure RegisterModule(LibModule: PLibModule);
procedure UnregisterModule(LibModule: PLibModule);
function FindHInstance(Address: Pointer): HINST;
function FindClassHInstance(ClassType: TClass): HINST;
function FindResourceHInstance(Instance: HINST): HINST;
function GetResourceModuleName(HostAppName, ModuleName: string): string;
function LoadResourceModule(ModuleName: PChar; CheckOwner: Boolean = True): THandle;
procedure EnumModules(Func: TEnumModuleFunc; Data: Pointer); overload;
procedure EnumResourceModules(Func: TEnumModuleFunc; Data: Pointer); overload;
procedure EnumModules(Func: TEnumModuleFuncLW; Data: Pointer); overload;
procedure EnumResourceModules(Func: TEnumModuleFuncLW; Data: Pointer); overload;
procedure AddModuleUnloadProc(Proc: TModuleUnloadProc); overload;
procedure RemoveModuleUnloadProc(Proc: TModuleUnloadProc); overload;
procedure AddModuleUnloadProc(Proc: TModuleUnloadProcLW); overload;
procedure RemoveModuleUnloadProc(Proc: TModuleUnloadProcLW); overload;

These methods below are what I was after; just recall the same usage as the above [WayBack] VirtualQuery function (memoryapi.h) | Microsoft Docs (using a structure typed [WayBack] _MEMORY_BASIC_INFORMATION | Microsoft Docs):

function FindHInstance(Address: Pointer): HINST;
var
  MemInfo: TMemoryBasicInformation;
begin
  VirtualQuery(Address, MemInfo, SizeOf(MemInfo));
  if MemInfo.State = $1000{MEM_COMMIT} then
    Result := UIntPtr(MemInfo.AllocationBase)
  else
    Result := 0;
end;

function FindClassHInstance(ClassType: TClass): HINST;
begin
  Result := FindHInstance(Pointer(ClassType));
end;

Getting class and module in one line

The breakpoint expression GetModuleName(FindClassHInstance(AClass)) + ' : ' + AClass.ClassName during debugging some of the time:

Breakpoint Expression GetModuleName(FindClassHInstance(AClass)) + ' : ' + AClass.ClassName: E2010 Incompatible types: 'TClass' and 'TPersistentClass'

If it failed, because multiple copies of the RTL were loaded. This is a classic problem when either:

• your project mixes packages and units (this can happen when using ODAC: their units expect packages, especially in their trials)
• loading DLLs from EXEs where one uses packages, but the other does not

What also happened when watching these were FastMM errors on memory consistency. See the log below for that. I think this has the same cause.

–jeroen