c++ - 在非Windows世界中的COM？

Question

希望这个问题不会太含糊。通读COM规范和Don Box的Essential COM书籍，有很多关于“COM解决的问题”的讨论-它们都听起来很重要，相关并且是current。

那么，COM地址在其他系统(Linux，Unix，OSX，Android)上如何解决？我在想这样的事情:

跨编译器和编译器版本的二进制兼容性

二进制组件重用

编译应用程序，使其具有运行时依赖性而不是加载时依赖性(以便即使缺少依赖性也可以运行)

从库自身的

以外的语言访问库功能

对开销不同的进程

的地址空间中加载的组件的合理低开销的远程过程调用

等(我确定列表会继续下去)

我基本上只是想了解为什么在Linux上，例如CORBA不会像COM在Windows上那样(如果有任何意义)。也许Linux上的软件开发与COM提出的基于组件的模型是否遵循不同的哲学？

最后，COM是C/C++吗？几次我都听到有人说COM被.NET“过时”，但没有真正解释它们的含义。

Answer 1

在本文的其余部分中，我将使用Linux作为开放源代码软件的示例。在我提到“Linux”的地方，它通常是一种简短/简单的方式来一般地指代开源软件，而不是针对Linux的任何东西。
COM与.NET
COM实际上并不限于C和C++ ，. NET实际上也不能替代COM。但是，.NET在某些情况下确实提供了COM的替代方法。 COM的一种常见用法是提供控件(ActiveX控件)。 .NET为控件提供/支持自己的协议(protocol)，该协议(protocol)允许某人用一种.NET语言编写控件，并使用其他任何.NET语言的控件-或多或少与COM在.NET外部提供的同类控件世界。
同样，.NET提供Windows Communication Foundation(WCF)。 WCF实现了SOAP(简单对象访问协议(protocol))-可能一开始很简单，但是充其量只是变得简单得多。无论如何，WCF提供了许多与COM相同的功能。尽管WCF本身特定于.NET，但它实现了SOAP，并且使用WCF构建的SOAP服务器可以与没有WCF的实现进行通信(反之亦然)。由于您提到了开销，所以可能值得一提的是WCF/SOAP往往会增加COM的开销(根据情况，我看到的开销几乎等于COM的两倍)。
需求差异
对于Linux，前两点往往具有较低的相关性。大多数软件都是开源的，无论如何，许多用户习惯于从源代码构建。对于此类用户，二进制兼容性/重用几乎没有影响，甚至没有影响(实际上，相当多的用户可能会拒绝所有未以源代码形式分发的软件)。尽管二进制文件通常是分布式的(例如，使用apt-get，yum等)，但它们基本上只是缓存为特定系统构建的二进制文件。也就是说，在Windows上，您可能只有一个二进制文件可用于从Windows XP到Windows 10的任何版本，但是如果使用apt-get，例如Ubuntu 18.02，则安装的是专门为Ubuntu 18.02构建的二进制文件，而不是一种试图与Ubuntu 10或更高版本兼容的工具。
缺少组件时能够加载和运行(功能降低)也是最常见的闭源问题。闭源软件通常具有多个版本，它们具有不同的功能来支持不同的价格。供应商可以方便地构建主应用程序的一个版本，并根据提供/省略的其他组件来提供不同级别的功能。
这主要是为了支持不同的价格水平。当该软件免费时，只有一种价格和一种版本:awesome edition。
再次访问语言之间的库功能通常倾向于基于源代码而不是二进制接口(interface)，例如使用SWIG允许使用来自Python和Ruby等语言的C或C++源代码。同样，COM基本上可以解决主要由于缺乏源代码而引起的问题。当使用开源软件时，根本就不会出现问题。
在其他过程中再次进行编码的低开销RPC似乎主要源于封闭源代码软件。当/如果您希望Microsoft Excel能够在Adobe Photoshop中使用某些内部“填充”，则可以使用COM进行通信。这增加了运行时的开销和额外的复杂性，但是当其中一部分代码由Microsoft拥有，而另一部分代码由Adobe拥有时，这几乎就是您所需要的。
源代码级别共享
但是，在开源软件中，如果项目A具有某些在项目B中有用的功能，那么您最多可能会看到(最多)项目A的分支将其转换为库，然后将该库链接到两个库中。项目A的其余部分并进入项目B，甚至还有项目C，D和E-都没有施加COM，跨过程RPC等开销。
现在，请不要误会我的意思:我不是在尝试充当开源软件的代言人，也不是说封闭源代码很糟糕，而开放源代码始终总是优越的。我的意思是说COM主要是在二进制级别定义的，但是对于开源软件，人们倾向于更多地使用源代码。
当然，SWIG只是在源代码级别支持跨语言开发的多种工具中的一个示例。尽管SWIG被广泛使用，但COM在一个相当关键的方面不同于它:使用COM，您可以使用一种单一的中性语言定义一个接口(interface)，然后生成适合该接口(interface)的一组语言绑定(bind)(代理和 stub )。这与SWIG完全不同，在SWIG中，您直接从一种来源匹配一种目标语言(例如，绑定(bind)以使用Python中的C库)。
二进制通讯
在某些情况下，至少具有一些类似于COM提供的功能很有用。这些导致了在很大程度上类似于COM的开源系统。例如，许多开源桌面环境使用/实现D-bus。在COM主要是RPC之类的地方，D-bus主要是在组件之间发送消息的公认方式。
但是，D-bus确实指定了它称为对象的事物。其对象可以具有可以向其发送信号的方法。尽管D-bus本身主要是根据消息传递协议(protocol)来定义的，但是编写代理对象相当简单，以使在远程对象上调用方法看起来很像在本地对象上调用方法。最大的区别是COM有一个“编译器”，它可以采用协议(protocol)的规范，并自动为您生成这些代理(以及远端的相应 stub 以接收消息，并根据消息调用适当的功能)。已收到)。这不是D-bus本身的一部分，但是人们已经编写了一些工具来获取(例如)接口(interface)规范，并根据该规范自动生成代理/ stub 。
这样，尽管两者并不完全相同，但是有足够的相似性，D总线可以(并且经常)用于与COM相同的许多事物。
与DCOM相似的系统
COM还允许您使用DCOM(分布式COM)构建分布式系统。也就是说，在一个系统上，您在一台机器上调用一个方法，但是(至少有可能)在另一台机器上执行该调用的方法。这增加了更多的开销，但是由于(如上所述，关于D总线)RPC基本上是与连接到末端的代理/ stub 进行通信，因此以分布式方式完成相同的事情很容易。但是，开销上的差异往往会导致需要设计系统才能正常工作的方式有所不同，因此，将与本地系统完全相同的系统用于分布式系统的实际优势往往很小。
因此，开源世界提供了用于执行分布式RPC的工具，但通常不会努力使它们看起来与非分布式系统相同。 CORBA是众所周知的，但是通常被认为是庞大而复杂的，因此(至少以我的经验)，当前的使用是很少的。 Apache Thrift提供了一些相同的常规类型的功能，但是以一种更简单，更轻量的方式。尤其是在CORBA尝试提供一套完整的分布式计算工具(从身份验证到分布式计时的所有功能)的情况下，Thrift更加严格地遵循Unix哲学，试图满足一个需求:从一个代理生成代理和 stub 。界面定义(以中性语言编写)。如果您想使用Thrift来做类似CORBA的事情，那么您无疑可以，但是在构建调用者和被调用者彼此信任的内部基础结构的更典型情况下，您可以避免大量的开销并直接从事业务。手。同样，google RPC提供的功能与Thrift大致相同。
特定于OS X
cocoa 提供的distributed objects与COM非常相似。不过，这是基于Objective-C的，我认为它已被弃用。
苹果还提供XPC。 XPC比RPC更注重进程间通信，因此我认为它与D-bus相比，与COM更直接。但是，就像D-bus一样，它具有与COM相同的许多基本功能，但是形式不同，它更加注重通信，而不再像本地函数调用那样使事物看起来(现在无论如何，许多人还是更喜欢使用消息传递而不是RPC) )。
概括
开源软件在设计中具有足够多的不同因素，因此对提供与Microsoft COM在Windows上提供的功能组合相同的功能的需求较少。 COM在很大程度上只是一个试图满足所有需求的工具。在开放源代码世界中，提供单一，全面的解决方案的动力越来越小，而倾向于将一套工具做得很好的工具集，每种工具都能做得很好，可以组合成一个针对特定需求的解决方案。
Apple OS X更具商业导向性，它可能(至少可以说)比大多数更纯粹的开源世界更接近COM。