On 29/05/2016 06:37 AM, Warp wrote:

> Executable files contain references to dynamically loadable libraries,
> and when you execute such a file, the OS will insert function calls
> into said executable to point to whichever dynamically loadable library
> it needs (which the OS also loads or, most usually, is already loaded
> into memory because most of everything else needs it too.)

I don't have any direct experience with that.

I was *about* to say that I've only done it with AmigaOS - but that's 
not quite right. What I was *actually* looking it is calling *the OS*, 
which is a bit different.

The way AmigaOS does it, memory address 0x00000004 holds a pointer to 
the function table for exec.library. Every function in the library has a 
known index in that table, so by adding your index to the address 
pointed to, you get a function pointer to the actual library function 
that you want. Now since exec.library is the one that contains the 
functions to load *other* libraries, from here you can open any other 
library you want. This similarly returns a function table base pointer, 
which you can use in the same way.

Of course, exec.library is in ROM, as are most of the low-level system 
libraries [including the entire GUI]. But you don't need to care about 
that. Just call OpenLibrary(), and it'll load from disk if required, and 
ultimately give you back a base pointer.

Presumably any self-respecting protected-mode OS does it differently. In 
particular, calling the kernel presumably implies a transition to 
ring-0, and I don't remember how x86 does that exactly. (From what I 
dimly recall, you purposely trigger a kind of software interrupt, but 
I'm not sure how you designate what function you're trying to call.)

 From what I can tell, C code does not call the Linux kernel. C code 
calls glibc, which then calls the kernel on your behalf. (As evidenced 
by several manpages that describe a glibc function and a kernel function 
of identical name but subtly different behaviour...)

> The idea with dynamically loadable libraries is, of course, to save
> memory and increase efficiency. Since 99.9% of all executables use
> the same system functions, it's more efficient to have them all share
> the one and same library in memory than to statically link all those
> megabytes of system library code into every single executable.

This gets entertaining when you have one program that uses a dozen 
libraries that nobody else is using. Or when every single program on the 
system uses a different version of the same library, so they all supply 
their own version of it. Then again, if old code doesn't work with a 
newer version of some dynamic library, who's fault is that?

Post a reply to this message