希望这个问题不会太模糊。 阅读COM规范和Don Box的Essential COM书籍，有很多关于“COM解决的问题”的讨论 – 而且这些都是重要的，相关的和最新的 。
那么COM地址在其他系统（linux，unix，OSX，android）上遇到的问题是如何处理的呢？ 我正在考虑像这样的事情：
编译器和编译器版本的二进制兼容性
二进制组件重用
编译一个应用程序，使其具有运行时依赖性而不是加载时间依赖性（即使缺less依赖项也能运行）
从库以外的语言访问库function
相当低开销的远程过程调用加载到不同进程的地址空间中的组件
等等（我确定这个名单继续）
我基本上只是想明白为什么例如在Linux上CORBA是不是像COM的东西是Windows上的东西（如果这是有道理的）。 Linux上的软件开发是否可以采用与COM提出的基于组件的模型不同的理念？
最后，COM是一个C / C ++的东西？ 有几次，我发现人们说COM是被.NET“过时”的，但没有真正解释他们的意思。
确定Linux下的二进制兼容性
关于Linux的二进制兼容性
Linux发行版之间的二进制兼容性
我应该链接哪个Linux发行版以获得最佳的二进制兼容性？
目前，我们来考虑一下Linux。
对于Linux来说，前两个点往往具有相对较低的相关性。 大多数软件是开源的，许多用户无论如何都习惯于从源头上构建。 对于这样的用户来说，二进制兼容/重用是很少或者没有结果的（实际上，相当多的用户可能会拒绝没有以源代码形式分发的所有软件）。
当组件缺失时，能够加载和运行（减少功能）也是最常见的闭源问题。 封闭的源代码软件通常有几个版本具有不同的功能来支持不同的价格 供应商可以方便地构建主应用程序的一个版本，并根据提供/省略哪些其他组件提供不同级别的功能。
这主要是为了支持不同的价格水平。 当软件是免费的，只有一个价格和一个版本： 真棒版 。
在语言之间访问库功能，往往更多地基于源代码而不是二进制接口，比如使用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，用一种中性语言定义一个接口，然后生成一组适合该接口的语言绑定（代理和存根）。 这与SWIG非常不同，在SWIG中，您可以直接从一个源到一个目标语言（例如，使用Python中的C库进行绑定）。
在开放源代码世界中，还有一些工具可以用中性接口定义语言定义接口，然后从该接口定义中为特定语言生成绑定。 CORBA是众所周知的，但通常被认为是大而复杂的，所以实际使用是相当小的。 Apache Thrift提供了一些相同的通用类型的功能，但是以更简单，更轻的方式。 特别是在CORBA试图为分布式计算提供一整套工具的情况下（完成从认证到分布式计时的所有事情），Thrift更紧密地遵循Unix原理，试图满足一个需求：从代理和存根界面定义（用中性语言编写）。 如果你想用Thrift来做那些类似于CORBA的事情，你无疑可以做到这一点，但是在建立内部基础架构的情况下，调用者和被调用者相互信任的情况下，可以避免大量的开销，手。
对于最后一个问题的回答很快，COM远远没有被淘汰。 微软世界中几乎所有的东西都是基于COM的，包括.NET引擎（CLR），还包括新的Windows 8.x的Windows Runtime 。
这里是微软有关.NET在它最新的C ++页面欢迎回到C + +（现代C + +） ：
C ++正在经历复兴，因为权力再次成为国王。 像Java和C＃这样的语言在程序员的生产力很重要的时候是很好的，但是当功耗和性能是最重要的时候，他们就表现出了局限性。 为了提高效率和功耗，特别是在硬件有限的设备上，没有什么比现代的C ++更胜一筹。
PS：这对于在.NET上投入超过10年的开发人员来说有点震惊:-)
在Linux世界中，开发静态链接的组件，或者在单独的进程中运行并通过管道文本（可能是JSON或XML）来回通信的组件是比较常见的。
其中一些是由于传统。 早在CORBA或COM存在之前，UNIX开发人员就已经这样做了。 这是“UNIX方式”。
就像Jerry Coffin在他的回答中所说的那样，当你拥有所有东西的源代码时，二进制接口就不那么重要了，实际上只是让一切变得更加困难。
当个人电脑比现在慢得多时，COM被发明了。 在那个时代，将组件加载到应用程序的进程空间并调用本地代码通常是实现合理性能所必需的。 现在，解析文本和运行解释脚本不是什么可怕的事情。
CORBA从来没有真正地被开源世界所吸引，因为最初的实现是专有的和昂贵的，到高质量的免费实现时，规范是如此复杂，以至于没有人需要使用它这样做。
Linux在很大程度上忽略了COM解决的问题。
当你有源代码可用时，二进制兼容性确实不那么重要。 但是，您仍然需要担心模块化和版本控制。 如果两个不同的程序依赖于同一个库的不同版本，则需要以某种方式支持该程序。
然后是使用相同库的不同版本的相同程序的情况。 在处理大型传统程序时，这样做通常很有用，因为在这些程序中，升级所有内容可能过于昂贵，但您仍然希望使用新的功能。 使用COM，程序的旧部分可以单独使用，因为新的库版本可以更容易地向后兼容。
另外，必须从源代码而不是二进制兼容性编译是一个巨大的麻烦。 特别是如果你实际上正在开发软件，由于二进制不兼容意味着你必须更频繁地重新编译。 如果在一个大的C ++程序中有一小部分发生变化，您可能需要等待30分钟的重新编译。 如果不同的部分是兼容的，只有被更改的部分必须重新编译。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
