Unix程序控制台vs其他东西

Question

我正在用unix编写一个程序。目前，它有一个控制台界面。我只是好奇，就像在Windows中的dll一样，当另一个程序想要调用你的程序时，unix中存在类似的概念。我被要求在细节方面提供一个没有其他内容的二进制文件。我有一种感觉，可能有另一个程序可能会调用它。所以，如果我继续这样做，我还需要做什么？我不能分享来源。我只能提供一个已编译的二进制文件（我也有点困惑...当我们在unix中讨论二进制文件时，这意味着有些文件是可执行文件而有些文件不可执行文件。在我的程序中，我认为它是可执行文件要求至少在我得到确认之前。我是否需要做一些特别的事情，例如提供与dll一样的api？我只是不确定这一切是如何在unix中完成的。

Answer 1

将程序打包为与其他通过管道协作的独立可执行文件是完全可行的 - 事实上，这是程序合作的经典Unix模型。

确保您的程序支持各种“命令行标志”，以确保其可以通过管道有效地用于其他需要其服务的程序。一个最重要且经常被遗忘的标志是确保程序的I / O 无缓冲的标志（因此“调用程序”不会被强制播放pty技巧）。仔细区分stdout和stderr也有帮助！此外， if 在正常操作中，您的程序以任何方式“装饰”输出以使其适合人类消费（提示，解释等），确保通过标记很容易获得“裸，只是事实“输出，这是其他程序想要的。

Answer 2

与Windows dll等效的unix是一个共享库，例如libfoobar.so。

关于如何以二进制形式将代码分发给第三方，您的选项是：

1. 静态库：libfoobar.a
2. 共享/动态库：libfoobar.so
3. 可执行文件

前两种情况实际上是相同的。人们倾向于喜欢动态库，因为库代码可以由多个可执行文件共享，使得可执行文件的大小和所需的内存量都更小。

在这两种情况下，代码的用户都必须编写代码才能使用您的API，他们需要针对您的库编译代码。

在第三种情况下，您将向第三方提供他们运行的可执行文件。他们会通过某种进程间通信机制调用你的应用程序，例如：管道或共享存储器，或通过网络，例如UDP或TCP作为低级机制，或某种RPC机制，如SunRPC，SOAP，HTTP，REST，你有什么。

Answer 3

是。在Linux中，它们被称为“共享对象”（so），在Mac OS X中，它们被称为“动态库”（dylib）和“捆绑”（bundle）。

参见例如http://www.cs.duke.edu/~ola/courses/programming/libraries.html关于如何创建* .so文件。

（如果您不想重新组织到库中，另一个程序也可以通过popen使用您的控制台界面。）

Answer 4

Unix的大多数（当前）版本上的DLL相当于共享对象文件（* .so）。

Answer 5

共享对象需要导出调用实体知道的那些符号（ - 即，SO / DLL的插件api）。 DLL有这个和SO有这个 - 这可能是你的意思API。

Windows为函数和变量提供限定符，以确保符号在DLL中可见。海湾合作委员会也必然会这样做。

以下是有关GCC and Symbol Visibility的文档的链接。