A clue and your towel.
This is the first lesson in the Got Clue? series.
Ever wandered what a DLL was, here is the simple low-ball on
it. (There are exceptions to what I say, but for the most part, it is
What is a Win32 DLL? The short answer:
It is merely a collection of
procedures and variables. You use them as if you have them written in
another source file. A header file listing all of the procedures visible
is distributed with it. You do not need to change how you code, everything
should be transparent to you.
What is a Win32 DLL? The long answer:
Dynamic Link Libraries (DLLs) provide
a way to separate the functionality of an application. An executable (EXE)
still works as usual, but, now, at startup, it needs to find the correct
DLL(s) and link to them. This makes a portion of the code replaceable
without having to recompile: the revised DLL can be put into place and when
the executable loads, it will link with the new DLL.
Link and Load, baby:
When an executable is loaded by the kernel, it checks
a special segment at the base of the executable which tells it what symbols
are currently unresolved (to some, this is called the relocation table).
Then, according to the system configuration, the correct DLL is located and
loaded into the address segment: this is called linking and loading. More
specifically, symbols are resolved, address are adjusted of various
pointers, and then a check is done to see if there are still symbols that
are left hanging, and the process is repeated until all symbols are
resolved (this allows a DLL to use functionality from another DLL).
The structure of a DLL:
The DLL is required to be position independent
(anybody with enough GCC -- the GNU C Compiler -- experience
would have probably seen the compiler flag -fPIC, which tells GCC to
produce position independent code): all address are either absolute, in
which case they are not changed on the link and load; they are relative
offsets into the DLL code, where they are flagged in a special segment of
the code that tells the linker and loader to change them to the correct
location; or they are not in the image, which sets off the link and load
process, again, with another DLL.
Changes from win3:
In Windows 3.x, when a DLL loaded, all global data in the DLL was shared
by all processes that loaded it. This has changed in Win95/NT: the
concept of memory mapping and a protected address space (so that one
ill behaved program cannot crash the rest of your good programs) was
introduced. Now, the DLL code is actually copied into the program's
address segment (actually, it called mapping, but close to the same
thing) for every program that uses it. This sounds like a step
backwards, but it adds stability to the operating system and makes
it easier to program to it (plus the DLL code is not actually copied into
memory multiple times -- memory mapping a file has all processes share
Misconceptions and other stuff:
I have seen people/books talk about "attaching to a DLL." Forget you
have ever heard this -- it is old language held over from Windows 3.x --
instead try to think of it as copying as is explained above.
DLL's no longer can be used for interprocess communication (IPC). They
used to be able to, but now that has changed. They dont change how
memory is done at all in Win95. Last week I was reading part of the
Microsoft Knowledge base information on DLL's in 95/NT, and it told
of three ways that you can use memory in a DLL: it was confusing
and useless. There is one way to use memory in a DLL, that is the usual
way you use memory in a 95/NT program: if you want data global to
the process, you make it global; if you want data thread local, then
you make calls to the thread local memory allocator.
Valerie and Donna have an affair, with each other (I wish). Oops, wrong
show. I will actually go into more on the DLL's for 95/NT: about
entry points, what things can you do with them besides all this random
stuff, how to compile them on GCC and other free compilers (and maybe
even VisualC++, if I can get my hands on it). Please email me with
suggestions as to what to do.
This comes from my pseudo knowledge of BSD shared libraries.
Most books that I have read on the topic do a poor job and explain a DLL in
terms of program attaching to it, as if it was a separate entity, but,
based on BSD shared libraries, I think they once the program loads, they
are merged into one.
I don't know what I am talking about:
For the most part, this is correct,
and these are just random ramblings of an unclued individual. I would,
however, appreciate feedback of all kinds: "what did that mean", "why didnt
you say this", "you are right/wrong", "you unclued heathen, why did you
think...", and more. For information/flames/comments please email me.