从 64 位应用程序加载/与 vb6 COM dll 交互答案

【问题标题】：Loading/interacting with a vb6 COM dll from a 64bit Application从 64 位应用程序加载/与 vb6 COM dll 交互
【发布时间】：2010-10-27 22:07:34
【问题描述】：

我正在开发一个包含多个用 VB6 编写的 dll 的应用程序。 VB6 代码包括 COM dll 和 ocx 控件。其余代码使用 C++ 和 C#。我被分配了使应用程序代码库与 64 位架构兼容的任务。大量的帮助材料可用于 C/C++ 代码，因此手头没有问题。但是要将所有这些 vb6 代码重写为 .net 或其他语言以使其与 64 位兼容并不容易。我也不了解所有底层逻辑，所以假设重写是不可能的。

另一方面，我们都知道 VB6 dll 不能在 64 位环境中工作。那么我的选择是什么。

1) 将每个 dll 转换为一个 EXE，该 EXE 将以 32 位加载，它可以通过 COM 接口与我的其余 64 位应用程序交互。您预见到这种方法有什么问题吗？

2) 我编辑注册表并将所有 VB6 dll 加载到进程外，让它们加载到 dllhost 中。

3) 制作一个 32 位 exe，在该 exe 中引用所有这些 VB6 dll 并将该 exe 加载到 32 位地址空间中，我的应用程序的 64 位部分与 32 位 exe 通信。

对于上述所有方法，我想到的主要问题是如何处理 OCX 控件？？？？

有什么想法吗？如果没有比上述哪一个更受您青睐的新想法，为什么？

【问题讨论】：

你知道如何使用 COM 在 64 到 32 之间进行通信吗？似乎仍然存在某种不匹配。
不，我还没有开始任何实验，但一旦我遇到任何成功或失败，就会更新。
这种通信通常应该可以顺利进行——尤其是当所有接口都是 oleautomation-compatibe 时，就像你的情况一样。

标签： com dll vb6 64-bit

【解决方案1】：

如果您有大量用于在进程中运行的现有 VB6 代码，我首先会质疑迁移到 64 位是否真的值得付出努力。 64 位对于服务器应用程序有很多优势，但对于桌面应用程序，32 位通常完全足够了。由于 WOW64 预计至少可用十年，因此几乎没有人反对在 64 位 Windows 上运行 32 位应用程序。

重点是，尽管通过使用进程外服务器可以调整应用程序，使其至少部分在 64 位模式下运行，但这可能会对性能产生重大影响（以及内存开销）。因此，很可能客户不会从选择 64 位版本的应用程序中获得任何好处。

也就是说，我会说 2) 或 3) 将是自然选择。 2) 当然更容易实现，但 3) 让您可以更好地控制应该创建多少进程外服务器以及如何管理它们的生命周期。

【讨论】：

我理解您的所有顾虑 :( 但问题是我的应用程序在 AutoCAD 中作为插件运行。如果您想在 64 位 Windows 上运行 AutoCAD，AutoDesk 要求您购买 64 位版本的 AutoCAD .AutoCAD 安装程序不允许您在 64 位 Windows 上以 WoW 模式安装 AutoCAD。所以我的应用程序必须以 64 位模式运行。这不是我的选择问题。我别无选择，只能提供 64 位版本的我的适用于已安装 64 位 windows 的客户。
我明白了。我认为在做出决定之前要考虑的一个重要方面是评估 AutoCad 进程和（32 位）OOP 服务器之间必须进行多少通信。对于经常使用的对象，我会认真考虑用 C++ 或任何语言重新实现它们。它们可以托管在 64 位进程中。对于不经常使用的对象，进程外解决方案可能就足够了。我认为没有这样的考虑，很难判断进程外策略是否真的可行。

【解决方案2】：

我正在从 SQL 2000 x86 迁移到 SQL 2008 x64。

在这里，我们面临着类似的问题。我决定使用 DCOM。

它是如何工作的？

32 位服务器将托管程序集，64 位计算机将使用 DCOM 调用。

存在性能损失。顺便说一句，与重写相比的努力……当然值得做。

【讨论】：