OSDev.org

The details are more complicated (and vary according to OS), but I can probably clear up the idea...

Say you compile a program which calls printf from the standard C library. If you compile the program with dynamic linking, it will not actually embed the code for printf in the binary, but instead just put in a marker (say "call $printf$lc" or something conceptually similar) and leave it at that. This means that the binary itself is not "complete" in the sense that it calls functions which it doesn't actually have code for.

Later when the binary is loaded (i.e. because you executed it), it doesn't just start executing immediately, but instead loads the missing pieces first. For example, a simple implementation might just search some specific folders for the library (libc in this case) and then extract the code for printf. Then it might load that code somewhere into the binary image and then replace $printf$lc with the address where the function was loaded. This will usually be invisible to the user. I.e. whether binary is static (has no dynamic linking) or it is dynamic doesn't matter to the user: in most cases you'll just call it with something like ./prog.

That's a simplification, but that's the basic idea. There are many optimizations to this. For example, much of the code that you load might actually be readonly and so different processes can share that code. I.e. the first time a process loads printf, the loader actually loads the code. The second time a process loads printf, the loader simply uses the same code that was already loaded, though probably the process thinks it's loaded at a different address. In fact, that is one reason why you'll need help from the OS. Another thing is that you will presumably not be loading things on a function level, but something more course (i.e. you won't only load in printf, but possibly instead all functions in the c library).

As with all OS concepts the details are confusing and usually different than what I said, but that's the main idea. Hopefully this makes some sense.

Specifically, for windows DLLs, there is a table of external functions in your EXE (or DLL), which contains the name and/or index of the needed functions. After the EXE is loaded into memory, windows updates this table and records the address of each function in the table. Then the program uses this table to call those functions.

This is a simplified description, but you should get the idea.

Hi, green1.

I don't understand a bit. Do you want to know why does the OS need a dynamic memory allocator or how does it look at user's glance?

fwiw, I have a fairly trivial example of run-time linking in my OS (ndk).
I basically ported the existing rdoff2 linker to run in my kernel, such that I could load object files, and link them to symbols in the kernel.
The OS is available at www.neuraldk.org

It's not a stellar example, but it's simple. Hopefully easy to follow.

Effectively, the OS parses the obj headers, and looks for external symbols, and compares those symbols against a table which the OS exports. If it finds a match, the address in the loaded object file is patched up to reference the OS symbols location.

--Jeff