使用不同的CRT将新的C++代码与旧的（二进制）组件隔离的最佳方法是什么？

提问者：小点点

我为一个用C++编写的Windows桌面应用程序编写了一个大型代码库。

许多年前，我的公司向一家大得多的公司支付了许可费，以使用我们软件中的一个组件，该组件提供了一项关键服务。该组件是带有一些头文件的二进制blob，是使用VS2008运行时编译的。

因此，目前整个应用程序都依赖于VS2008运行时。我们无法升级到现代C++，或者我们使用的库的更新版本（例如，我们被困在Qt4而不是Qt5)。由于各种原因，该公司几乎没有机会提供更新的blob，而我们正在计划编写我们自己的替换，这将需要大量的时间。

同时，我希望能够以某种方式包装这个组件并隔离它，这样我们就可以将代码的其余部分升级到以后的运行时，并使用JSON或类似工具与它通信。在将来的某个时候，我们可能会用完全不是用C++编写的自己的东西（或者开源的东西）来替换这个组件。

我可以想出很多方法来做这件事，但我不确定哪一个是最好的，哪一个能给我们最大的灵活性。读到COM，似乎这正是它被创建的目的，但是我不知道COM是否仍然被积极地开发和支持，它是否将我们永远地与Windows生态系统联系在一起。 DCOM是一个非Windows版本，但如果有的话，它似乎更被抛弃了。

我很想知道最好的方法是什么。到目前为止，我的想法是:

共1个答案

匿名用户

COM没有被积极开发，主要是因为它已经完成了。不过，它得到了积极的支持。例如，当Windows变成64位时，COM也被移植到64位。它会在必要时获得安全更新。

DCOM是COM的分布式变体。我不会费心的；您只需将所有内容设计为使用单个用户帐户在一台PC上运行即可。这已经是你的应用程序的运行方式了。

VS2008非常乐意在DCOM上使用bstr字符串，而VS2019为此提供了一个方便的_bstr_t包装器。（我不记得VS2008是否已经有_bstr_t)。

通常不需要使用COM的所有功能。 COM被设计为许多不同应用程序之间的互操作平台，但是您有由相同开发人员编写的代码库的两个部分，它们只需要相互协作。不需要动态发现COM接口等。您只需与接口定义共享一个.h文件。