Delphi 个类，共享 memory，不同的 DLL 加载地址

Question

I'm working with an old and complex system that shares memory between dozens (sometimes hundreds) of Win32 processes. The code is mostly very old Pascal that has been ported to Delphi a few years ago.

(Almost) all of the code is in a single DLL, which all of the processes load. At the moment, we have forced a fixed loading address of that DLL. Image base is defined and ASLR is disabled in linker settings. Each process checks the DLL loading addresses at startup and the entire system refuses to work if the DLL cannot be loaded at the exact same address in all of the processes. This is of course a problematic solution. Sometimes customers have all sorts of 3rd party gadgets which affect the address space and prevents our product from having the address it wants for the DLL.

The reason for the fixed DLL loading address is below. I'm wondering if there is a way to work around this problem.

I've been trying to introduce object-oriented programming. The problem is, if I instantiate a Delphi class in the shared memory, that instance now seems to be dependent on the DLL loading address. For example, if another process tries to destroy that object, it will crash, unless the two processes happen to have the same DLL address. Delphi runtime seems to save function addresses in the object instance, assuming they will stay fixed for the lifetime of the object.

One possible solution might be to copy the DLL contents to the shared memory, then do some sort of magic trickery on DLL_PROCESS_ATTACH to make the process run that copy of the code instead of the loaded DLL address. The shared memory we have is always mapped at the same addresses. (Yes, this is also a problem sometimes but very rarely since the shared memory can be mapped at high (above 2 GB) addresses which are easily available.)

Or is there a way to tell Delphi compiler "please do not assume that the addresses of the functions related to this class are fixed"? I'm using Delphi 11.1.

Answer 1

I was able to figure out aa solution that seems to work well, so let me answer my own question.

The issue is that in order for dynamic dispatch to work, the object instance must be 'tagged' with type information. In the case of Delphi in Win32, this tag is in the first 32 bits of the object instance, and it is a memory address into the DLL where the the code of the class in question is.

If you shift this address to match the variable (process-specific) address of the DLL, the dynamically dispatched methods work fine. In order to do this, you need to compare this address to the loading address of the DLL (or any other reference address inside the DLL) and save the offset, when creating the object.

Then, before calling the object's methods in another process, "localize" the object by taking the actual address of the DLL, adding the offset, and writing this sum to the first 32 bits of the object.

Now you can use the object in any process, as long as you localize it first:

Obj.Localize;
Obj.Do_Something;

This can be neatly wrapped in a class. Offset is simply a private 32-bit UInt32.

constructor Global_Object.Create;

begin
   Self.Offset := PUInt32(Self)^ - Self.Reference_Address;
end;


procedure Global_Object.Localize;

begin
   PUInt32(Self)^ := Self.Reference_Address + Self.Offset;
end;


destructor Global_Object.Destroy;

begin
   inherited Destroy;
end;


function Global_Object.Reference_Address
                           : Cardinal;

begin
   // Anything in the DLL can be used as a reference,
   // such as the address of this function.

   Result := Cardinal(@Global_Object.Reference_Address);
end;