The Zen of Libraries (Part II) Inside Stuff

Copyright Notice

Copyright:Ramesh Ananthakrishnan 6th May 2003

Pilfer at your own Peril

   

But what type of alien is it? And whence did it come? And what news does it bear?
And is it chocolate flavoured?

         
---Monty Python

Introduction

    
In the Zen of Libraries (Part I) you saw why it was necessary to use libraries. This
explains the inside stuff on libraries... but beware! you need to know about assembly,
and a little about operating systems for this to make sense

Assembling the assembly

    
In order to make this article short, I'll assume that you all know what assembly is, how it's
generated from mnemonics. I'll also assume that you know that the compiler builds a parse tree
and that you know that the next stage is when the compile tree is interpreted to emit assembly
code. In fact if you had the right tools, you can actually see the assembly instructions involved
in the simplest program like the quintessential "Hello World" program.
Also I'll assume you know abt. offset & segment addresses.
So since we know that an exe is composed of straight assembly what is a library composed of.
Well... the same assembly instructions. In fact the difference between exe's and libraries is
very simple. It is this:


While libraries do not have any start instruction, all exes have a standard start instruction
and address.


What do I mean by that? Whenever you run a program. the OS actually copies your program into
memory and then, asks the processor to jump to a specific address where your program is loaded.
In fact when your program is compiled "offset" addresses are generated. The starting address
for an exe is a standard offset like say 42 bytes from the start of the program.
Once the program is loaded into a segment in memory, the OS
instructs the processor to perform a long jump to the segment (known to the OS) + offset start
address (which is common to every executable in the OS).
So if your OS loads your program right after the 16th KB. Then the processor jumps to
16KB + 48 bytes. Here there are instruction on what to do next. So the executable can be
say... executed. (Well that's not the entire story... read Stallings for a more complete
description)
But what about a library???

Libraries are dummies

    
Since some functions are used by a large number of programs, (think printf) these functions
are already compiled into assembly and kept in library files. So whenever you call say
a printf instruction the linker copies the exact assembly instructions from the library
and inserts it into your program. So a library does not have a start address, it's just a
collection of useful functions. When programming, keep in mind that you are simply gathering
all these library functions and giving them some dierection under main. So if you don't have
a main function all you have to do is compile your cpp file and you have a library all
toasty for you to use.


Think of a C library as just the same as a library of books. If you have a purpose
like a term paper, you have a sort of idea of which books you want to read. You go in
pick those books, copy some stuff from it, add some of your stuff to it, and form a term paper.
That's what programming is all about. The term paper is like your program. It has a structure
to it, the same structure which is given to an executable by the main function. Now your
profs. can read and make sense of your term paper/program. However just giving your prof.
a library full of books as a term paper doesn't make sense. He may as well write the term
paper himself. What he wants is some stuff extracted from the library, some stuff you have
written that makes a term paper he can understand.

Shared & Static libraries

    
Just imagine a term paper in which all you guys xerox around a 100 pages of the Java complete
reference API and submit to your professor. Isn't that a terrible waste of paper. Well, long time
ago when disk space was precious, it was (still is) asinine to copy the printf assembly
instructions into every tom, dick and harry's program. This lead to the concept of shared
libraries. This means that instead of everyone xeroxing the 100 pages, all of you would write
a small instruction in your term paper like say:
Look at The Java Complete Reference pg. 123
and the prof. would actually do this. This assumes that the prof. also has a copy of the
Java Complete Reference. This is what shared libraries are. In Turbo C the graphics libraries
are shared, so the instructions to draw on screen are not copied into your program.
Turbo C assumes that all machines have a copy of the Turbo C graphics library on their machines.
So when you run a graphics program the graphics library is first loaded into memory.
Then the OS notes where exactly all the graphic functions are in memory. Now when
a call to say... putpixel is made, the OS takes charge figures out where putpixel
is and then instructs the program to jump there. Like all else the above
description is a major simplification. For a detailed nuts & bolts view, look up Stallings.

But is that all...? and How do I use libraries....?

    
Well not exactly. Libraries are a large, large subject. Since their a little
high level most books that deal with programming languages don't teach you
anything about it. The books that deal with OS internals and high level stuff like
that don't deal with it because they assume that by the time you are reading OS books
you already know the zen of libraries. To compound the fact most buggers who CS nutcases
may know their algorithms, but fail to understand the basics abt. libraries. Which is why
I wrote the previous two articles. But how do I use libraries?? you ask. Fear not!
Read Part III of the Zen of Libraries on howto use libraries in your code.