delphi - Delphi/Win32 的虚拟库接口(interface)？

Question

我读到this article并发现虚拟库接口(interface)的概念非常适合 DLL 的运行时加载。但它们似乎不适用于 Win32。这是真的？如果是这样:为什么？我不明白这个想法与 .NET 有什么联系。

编辑:我在这里主要是改写 Rob 已经写过的内容。 :-)
我不追求插件或类似的东西 - 它是关于普通的旧 Win32 DLL。吸引我的是让编译器在运行时处理加载 DLL 的所有细节的想法 - 无需为 DLL 中的每个函数调用 GetProcAddress 等。

Answer 1

在我看来，到目前为止的三个答案完全没有捕获你的问题的要点。那个，或者我有。您在问为什么 Win32 Delphi 没有 Hallvard 的文章中提到的神奇的 Supports 功能，不是吗？也就是说，一个函数，在给定 DLL 的名称和接口(interface)的类型信息的情况下，返回一个使用从 DLL 导出的独立函数实现该接口(interface)的对象。

Hydra 似乎只是从 Win32 程序调用 .Net 代码，而不是从 DLL 导入函数。 TJvPluginManager 要求插件 DLL 导出一个特殊的自注册函数，管理器在加载 DLL 时将调用该函数，并且该函数必须返回 TJvPlugin 的实例类，因此插件DLL必须用Delphi或C++ Builder编写。另一方面，Supports 函数适用于用任何语言编写的任何 DLL。如果您愿意，您可以在 kernel32 上使用它。

我不知道为什么Win32 Delphi没有这样的东西。也许 CodeGear 没有看到对它的太多需求，因为 Delphi 和 Turbo Pascal 已经很长时间没有它了。

当然可以编写一个像这样工作的函数，而且我不认为它会比 .Net 版本更难编写，除非 Microsoft 的 .Net 库已经提供了大部分功能并且 Delphi只是将它们包装到一个方便调用的函数中，该函数看起来像 Delphi 多年来使用的 Supports 的其他几个重载版本。

在 Win32 中实现该函数需要几个步骤。 (我只提供必要内容的草图，因为我现在手头没有 Delphi 的运行副本。好好询问，也许我会找到更多详细信息。)首先，您需要确保该类型接口(interface)的信息至少包含其方法的未修饰名称。然后，Supports 需要为接口(interface)中的每个方法(除了 _AddRef、_Release 和 QueryInterface 之外)生成一个函数 stub 。假设调用约定为 stdcall， stub 将如下所示:

asm
  // Pop the return address,
  // discard the "this" pointer,
  // and restore the return address
  pop eax
  pop ecx
  push eax

  jmp AddressOfFunction
end;

当 Supports 生成每个 stub 时，它将填充实际的函数地址，该地址是通过使用相应接口(interface)方法的名称调用 GetProcAddress 获得的。 stdcall 调用约定很容易像这样包装； cdecl 有点麻烦； 注册是一件令人头疼的事。

一旦生成了所有 stub ，它就需要生成一个看起来像实现给定接口(interface)的“对象”。它不一定是一个实际的类(class)。在编译时，Supports 不知道它将被要求实现的接口(interface)的布局，因此拥有一个类不会完成太多任务。

最后一步是提供 _AddRef、_Release 和 QueryInterface 的实现。 _AddRef 不会太引人注目； _Release 是当引用计数达到零时调用 FreeLibrary 的地方； QueryInterface 根本不会做太多事情，除了声称它支持 IUnknown 以及为 Supports 提供的接口(interface)。

Delphi 曾经附带一个示例程序，该程序演示了无需任何类即可实现接口(interface)。这一切都是通过记录和函数指针完成的(毕竟，这最终只是一个接口(interface))。 Delphi 还附带了相应的代码来使用类来完成此操作，部分原因是为了展示 Delphi 可以使事情变得多么容易。我现在找不到演示程序的名称，但我确信它仍然在某个地方。