OSDev.org

ah i think i understand, relocatable objects can still be used for programs calling the functions inside the file, whereas dynamically linking is used more for finding the function in seperate files.

is that right?

I would like to implement both at some point, but i have no real need for shared libraries at the moment, so i'll focus on getting my drivers in userland.

Dynamic Linking allows you load libraries at runtime. It also allows you to share libraries among many processes (using position independent code) and has some nice other features (like lazy linking). If you just want to load a program to a random memory address, it is easier to have the program stored in an object file and then to relocate the object file after loading it.

There is another binary format that is used by nextstep darwin and macosx.
Its the MACH-O format and also NetBSD can load it.It is still a bit different
from ELF.

I prefer having some way to relocate my libraries at runtime.
Easy to do with dlls.
I usually do not link my apps with static libraries.I choose (or my os chooses)where the functions in my dll reside.
Dynamic Loading is so good.

ELF uses a quite different approach to dynamic linking. In position independent elf libraries, the code does not only run from a random memory address, it can also be linked at runtime (i.e. while running the program and not before running the program). The same library can even be shared between processes without relocating it. DLLs are mostly equivalent to elf object files.

I think thats what is very interesting in elf format.
IN windows ,when a process loads more than one dll ,relocations (patches)
have to be done and its not obvious and takes a lot of time.
Sometimes its really boring.

yeah i think ELF is definatly the format to go for, at the moment i'm just getting my handler to print everything of any relevence i can find, and im gonna go from there.

For my drivers that need to be load anywhere, i assemble my code as a coff file, then i run them though a xp program called "coff2dex" this splits the obj file into two, one the driver and the other the reloc info.
This save have to place the reloc in at end of file, which would make the file much bigger (eg: no rb, rw, rd etc) or not making it backward compatable with DexOS old file type.

PS: One member of Team DexOS did some work on using Dll in DexOS (The old ver).
you can see the code here: http://www.dex4u.com/testdll.zip

NOTE: It will not run on the new ver of DexOS without mods.

im getting there, just thought i'd post an update. The string table is giving me a bit of grief at the moment, but hopefully within two weeks or so (in between exams/revision - not much time for coding atm) i'll have that working.