从64位应用程序加载/与vb6 COM DLL进行交互

我正在研究一个应用程序，它具有多个用VB6编写的dll。 VB6代码包括COM dll和ocx控件。其余的代码是C++和C＃。我已被分配任务使应用程序代码库与64位体系结构兼容。对于C/C++代码，可以使用大量的帮助资料，因此这不是问题。但将所有这些vb6代码重写为.net或其他语言以使其与64位兼容并不容易。我也不理解所有的基础逻辑，所以只是假设重写是没有问题的。从64位应用程序加载/与vb6 COM DLL进行交互

另外，我们都知道，VB6的DLL在64位环境中无法正常工作。那么我有什么选择。

1）隐蔽每个DLL的进入，这将在32位被加载一个EXE，它可以通过COM接口与我的64位应用程序的其余部分交互。你有没有预见到这种方法的任何问题？

2）我编辑注册表并加载所有的DLL VB6出的过程中，使他们在DLLHOST加载。

3）制作一个单一的32位exe文件，引用该exe文件中的所有这些VB6 dll文件，并在32位地址空间中加载该exe文件，并且我的应用程序的64位部分与32位exe文件进行通信。

这使我想起了所有上述方法的主要问题是做什么用OCX控件????

任何想法？如果没有新的想法，而不是上面提到的哪一个将会被你所偏好，为什么？

来源

2009-05-21 Paragon

你有没有想出如何使用COM做64之间的通信，以32？看起来似乎会有某种不匹配。 – 2009-05-21 17:42:12

Nopes，我还没有开始任何实验，但会在我遇到任何成功或失败时立即更新。 – Paragon 2009-05-22 06:34:15

如果你有大量的现有VB6代码，使用在进程内运行，我想第一个问题，如果迁移到64位真的是值得的。 64位对于服务器应用程序有很多优点，但对于桌面应用程序，32位通常是完全足够的。由于WOW64预计至少可用10年，因此很少有人反对在64位Windows上运行32位应用程序。

问题是，尽管可能通过使用out-or-process服务器来调整应用程序，使其至少部分以64位模式运行，这可能会对性能产生重大影响在内存开销）。赔率是，客户因此绝对没有选择64位版本的应用程序的好处。

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

来源

2009-05-21 14:32:47

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

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

它将如何工作？

服务器32位将承载组件和64位设备将呼叫使用DCOM。

有性能损失。顺便说一句，与重写相比的努力......当然值得做。 :)

问候，马科斯利马

来源

2011-11-09 10:53:40

从64位应用程序加载/与vb6 COM DLL进行交互

回答

相关问题