OSDev.org

One of the features of my OS is that all of the command line tools are not only able to be composed through pipelines, like in UNIX, but also into new C programs. Each tool has most of its mechanism in a library, which can be linked to. However, this makes the source (and installation) of each tool considerably more complex: the library has to be built and installed, then the tool built and installed.

Then I had an interesting idea - if all of the programs are already backed by libraries, why not somehow make the executables themselves act like static libraries? Instead of having an executable /bin/foo, and a library with the mechanism of foo in /lib/libfoo.a, there would just be a /bin/foo, and the linker path and executable path would be the same (and the lib- prefix would be unneeded). Conversely, true libraries like libc.a could be executables too - they would probably just run tests or something when invoked.

The trick here is the implementation. I'm already using the ELF executable format, so it would be easiest to just extend that somehow. My question is if that's possible, and if so, what the best way to do it is (so I don't have to modify my cross compiler very much or at all). Also, would it be possible to do this sort of thing so that an executable acts like a shared library too? I wouldn't mind if most of the code has to be position independent.

Thanks!

Windows DLL's are in fact executables. However, they behave very differently from EXE's when the entry point is called.

You could specify some startup flag that tells your binary whether it's called as a library or as an executable. This way it behaves more like a shared than a static library. (This is how I intend to implement it when my OS reaches that point.)

Switch to using ELF shared (as opposed to static) libraries and it's possible - see libc on your local Linux box