linux中共享代码有哪些二进制标准（类似于COM）？

所以我在这里读完了一篇文章：

关于为什么我们有COM，以及它如何让我们共享代码，而不必担心编译器的名称混乱、unicode/ascii问题或以独立于语言的方式进行内存管理

---

我在其他地方读到过，LINUX不支持COM，因为COM基本上使用操作系统作为获取这些标准化对象的调节器。Linux中不应该有类似的东西吗？如果是这样，那是什么呢？

在Linux上，您可以运行任何在标准输入上接受其输入的程序，并通过管道将其连接到在标准输出上生成结果的任何其他程序

POSIX中基于文件和管道的简单输入/输出比MS Windows早几十年。而且，只要管道双方在交换数据的格式上达成一致，那么创建每个程序所使用的编译器就无关紧要（尽管在Linux上，有相当一个de-factor编译器，所以这是一个没有实际意义的问题）

通过使用套接字对，管道变成双向的，因此两个进程可以相互交换数据

这通常是进程在Linux上的互操作方式：

1） 将两个进程连接在一起的管道或网络套接字

2） 为两个过程之间交换的数据格式制定的商定标准

重要的是要理解，没有一个实用的标准要求所有进程使用相同的确切格式来交换消息。我想，最接近这种标准的是远程过程调用（remote procedure call）或RPC，这是在一些低级协议（如NFS）中使用的标准，但大多数情况下，单个应用程序定义并使用为其定制的特定格式

---

例如，X窗口系统协议：--这是用于在X服务器和X客户端之间通信的协议的格式定义。为使用此协议而编写的应用程序（实际上，它们通常使用中间库或工具包）可以建立连接，并通过网络连接或本地管道使用任何使用相同协议的X服务器。

在假设COM是某种已建立的技术之前，请检查该文件上的日期。它已经过时了。MS Windows的较新版本使用完全不同的API和技术。那么CLR是COM的替代品吗？当你指的是更新技术时，这就是你所指的吗？微软通过销售开发工具和文档来赚钱。开发任何技术，并将其作为长期标准，都不符合微软的商业利益。为了保持收入的流动性，微软会定期更新一些过时的技术，比如COM，并将它们“更新”成其他的东西。CLR是MS当前的技术之一。但是，就像它们中的每一个一样，它都有一个有效期，不会永远保持当前的MS技术，并且在某个时候，会再次“更新”为其他首字母缩略词。真是胡说八道。是的，看看这篇文章的日期。是1995年的。COM在当时存在，COM现在存在。我想说，20年的存在使COM成为一种成熟的技术。人们每天都使用COM编写程序、库和组件。脑海中浮现出GNU Bonobo、KParts和D-Bus。虽然有点老，但CORBA.COM不仅仅是通信，例如对象激活、接口、对象标识、引用计数、UI线程关联（或缺少它），COM+带来了更多的功能。