OSDev.org

Hi,

I'm developing my own OS from scratch.

Instead of writing my own implementation of stdlib, I've decided to write my own classes for everything the way I'd like (ie, my own String class, my own Console class instead of OStream, etc.).

Anyways, my question should be pretty simple. Right now, I only have one executable, kernel.bin. Now, pretty soon, I'll want to implement some sort of loader so my OS can launch other executables.

How will my library come into play? Would the library be linked with every single executable? This could seriously bloat them... Would I want to build the library as a .o file, or some custom format that I make so that I could load it up similarly to a DLL in windows? Then, all of the executables would call across process?

I think I might be just scratching the surface of this issue, and I haven't the faintest idea how to go about this. I have a ways to go before I approach this design issue, but I thought I'd ask how others do it.

Thanks much!

Bryce

Windows DLLs are a poor man's way to link object code at run time. I'd take a look at unix shared libraries. They're quite a fair bit more extensible in my opinion (at the very least, a shared library and be linked to a shared library... which is impossible with DLLs).

Essentially, you'll need some form of object loader that'll load shared libraries on demand and keep them in memory as they're needed. This loader will maintain a list of all libraries and what functions they provide. Applications will list which shared libraries they require, and if they aren't loaded, the loader will load them, and link them at runtime.

The Linux elf format embodies all of these things (executables supporting shared libraries, and the shared libraries themselves).

For a hint at how to runtime link you can take a look at rZero.c in my kernel at http://www.neuraldk.org (software -> ndk). This has already all been revamped and with better APIs, but I'm not ready to release that version just yet Soon...

--Jeff