Hi, I am writing a program in unix. At the moment, it has a console interface. I am just curious like dll's in windows does a similar concept exist in unix when another program wants to call your program. I have been asked to simply provide a binary with little else in terms of details. I have a feeling that there might be another program that might be calling this. So if I go with that what would I need to do? I cannot share source. I can only provide a compiled binary (which i am a bit confused about as well...when we talk about binary in unix that means that some are executable while others are not. In the case of my program I assume its an executable they are asking for at least till I get a confirmation). would i need to do anything special like provide api's like they do with dlls? i am just not sure how that all works out in unix.
Yes. In Linux they are called "shared objects" (so), and in Mac OS X they are called "dynamic libraries" (dylib) and "bundles" (bundle).
See e.g. http://www.cs.duke.edu/~ola/courses/programming/libraries.html on how to create *.so files.
(Another program can also use your console interface via popen if you don't want to reorganize into a library.)
The equivalent of a DLL on most (current) versions of Unix is a shared object file (*.so).
It's perfectly feasible to package your program as a stand-alone executable cooperating with other through pipelines -- indeed, that's the classic Unix model of program cooperation.
Just make sure your program supports a variety of "command-line flags" that ensure it can usefully be employed by another program desiring its services through pipelines. A most important and often-forgotten one is a flag to ensure the program's I/O are unbuffered (so the "calling program" is not forced to play pty tricks). Carefully distinguishing stdout from stderr also helps! Moreover, if in normal operation your program "decorates" output in any way to make it suitable for human consumptions (prompt, explanations, etc, etc), make sure that through a flag it's easy to get "bare, just-the-facts" output, which is what other programs will want.
Shared objects need those symbols that a calling entity is aware of (--i.e., said SO/DLL's plugin api) exported. DLL's have this and SO have this -- that is probably what you mean by API.
Windows provides qualifiers for functions and variables which make sure the symbols are visable in the DLL. GCC is bound to have this as well.
Here is a link with documentation about GCC and Symbol Visibility.
The unix equivalent of a Windows dll is a shared library, e.g. libfoobar.so.
With regards to how to distribute your code to a third party in binary form your options are:
- a static library:
libfoobar.a - a shared / dynamic library:
libfoobar.so - an executable
The first two cases are effectively the same. People tend to prefer dynamic libraries these days, because the library code can be shared by multiple executables making both the size of the executables and the amount of memory required smaller.
In both cases the user of your code will have to write their code to use your API, and they need to compile their code against your library.
In the third case you would provide the third party with an executable that they run. They would call into your application via some sort of Inter process communication mechanism, e.g. pipes or shared memory, or over the network, e.g. UDP or TCP as a low level mechanism, or some sort of RPC mechanism like SunRPC, SOAP, HTTP, REST, what have you.