Delphi类跨进程共享内存问题：DLL固定加载地址替代方案咨询

一、针对「通过Delphi编译器设置让类不依赖固定地址」的可行方案 #

Delphi类（尤其是带虚方法/析构函数的）默认会在实例中存储虚方法表（VMT）的绝对地址，这导致共享内存中的对象依赖DLL加载地址。无需特殊编译器开关，只需调整类的实现方式即可解决：

1. 用「纯数据结构+导出函数」替代类 #

完全放弃面向对象语法，改用C风格的结构体存储共享数据，所有操作逻辑通过DLL导出的全局函数实现：

// 共享内存中的纯数据结构
type
  TSharedData = record
    ID: Integer;
    Value: Double;
    // 仅存数据，无任何函数指针
  end;

// DLL导出函数，供各进程调用
procedure CreateSharedData(var Data: TSharedData); stdcall;
procedure DestroySharedData(var Data: TSharedData); stdcall;
procedure UpdateSharedData(var Data: TSharedData; NewValue: Double); stdcall;

每个进程调用自己加载的DLL中的这些函数操作共享内存，完全不依赖固定地址。

2. 禁用类的虚方法/析构函数 #

如果必须使用类，确保类中无虚方法、动态方法、虚析构函数：

// 仅含静态方法的类，实例中无VMT指针
type
  TSharedObject = class
  public
    ID: Integer;
    Value: Double;
    constructor Create; // 静态构造函数，直接初始化数据
    class procedure DestroyObj(var Obj: TSharedObject); static; stdcall;
    procedure UpdateValue(NewValue: Double); // 非虚实例方法
  end;

销毁对象时不要直接调用Free，而是调用导出的DestroyObj静态方法，避免触发虚析构函数的地址依赖。

3. 使用接口并规避VMT地址问题 #

若要保留面向对象特性，可使用接口，但需确保接口的实现不依赖固定VMT地址：

• 接口定义放在公共单元，所有进程共享
• 接口的实现类方法全部用stdcall，且通过导出函数创建实例：

type
  ISharedInterface = interface
    ['{GUID-HERE}']
    procedure UpdateValue(NewValue: Double);
  end;

// DLL导出函数，创建实例并返回接口
function CreateSharedInterface: ISharedInterface; stdcall;

接口的引用计数由Delphi运行时管理，且每个进程仅调用自身DLL中的接口方法，不会跨进程使用无效地址。

二、针对「将DLL复制到共享内存运行」的评估 #

这个思路理论可行，但实现复杂度极高，不推荐：

• 需手动处理DLL重定位：即使映射到固定地址，DLL中的绝对地址引用仍需重新计算修改，工作量巨大
• 安全与权限问题：共享内存需设置可执行权限，易触发Windows DEP保护，且存在代码注入风险
• 进程同步风险：多进程执行同一块共享代码，全局变量、静态变量的修改会引发竞态条件，需额外加锁
• 调试难度极大：共享内存中的代码无法被常规调试器高效追踪

三、长期最优方案：放弃固定DLL加载地址 #

彻底解决地址冲突问题，建议：

1. 重新编译DLL时启用{$DYNAMICBASE ON}（启用ASLR）和{$FIXED OFF}（禁用固定基址），生成重定位表
2. 移除所有进程对DLL加载地址的校验逻辑
3. 改造共享内存通信：仅传递纯数据结构，所有业务逻辑通过各进程自身加载的DLL导出函数处理，完全避免跨进程的函数指针依赖

内容的提问来源于stack exchange，提问作者Hannu