我正在开发一个具有多个用VB6编写的dll的应用程序。 VB6代码包括COM dll和ocx控件。其余的代码是C ++和C＃。我被分配了使应用程序代码库与64位体系结构兼容的任务。大量的帮助材料可用于C / C ++代码，因此这不是问题。但要将所有这些vb6代码重写为.net或其他语言以使其与64位兼容并不容易。我也不了解所有底层逻辑，所以只是假设重写是不可能的。
另一方面我们都知道VB6 dll在64位环境下不会工作。那么我的选择是什么。
1）将每个dll转换为一个EXE，它将以32位加载，并且可以通过COM接口与我的其余64位应用程序进行交互。你预见到这种方法有什么问题吗？
2）我编辑注册表并将所有VB6 dll加载到进程中，使它们在dllhost中加载。
3）制作一个32位exe文件，在该exe文件中引用所有这些VB6 dll并将该exe文件加载到32位地址空间，并将我的应用程序的64位部分与32位exe进行通信。
使用上述所有方法出现的主要问题是如何处理OCX控件????
有什么想法吗？ 如果你不喜欢上面提到的新想法，为什么？
答案 0 :(得分：0)
如果您有许多用于在进程中运行的现有VB6代码，我首先要问的是，迁移到64位是否真的值得付出努力。 64位服务器应用程序有许多优点，但对于桌面应用程序，32位通常是完全足够的。由于预计WOW64至少可以使用十年，因此几乎没有人反对在64位Windows上运行32位应用程序。
关键是，虽然有可能通过使用out-or-process服务器来调整你的应用程序，使其至少部分以64位模式运行，这可能会对性能产生重大影响（以及内存开销）。可能的是，客户因此选择64位版本的应用程序绝对没有任何好处。
那就是说，我会说2）或3）将是自然的选择。 2）当然更容易实现，但3）使您可以更好地控制应该创建多少个进程外服务器以及如何管理它们的生命周期。
答案 1 :(得分：0)
我从SQL 2000 x86迁移到SQL 2008 x64。
我们面临着类似的问题。我决定使用DCOM。
它将如何运作？
服务器32位将托管程序集，64位计算机将使用DCOM进行调用。
存在性能损失。顺便说一下，与重写相比的努力......当然值得做。 ：）
此致 马科斯利马