Logo designed by CO2 - http://www.planetquake.com/CO2
Logo designed by CO2 - http://www.planetquake.com/CO2
Logo designed by CO2 - http://www.planetquake.com/CO2
Logo designed by CO2 - http://www.planetquake.com/CO2
   
Back to HomePage

Back to Advanced menu

Credits

  • Puke
  • SumFuka
  • Mighty Moe

  •  

      What is a DLL?

    Requirements:
    A clue and your towel.

    Lesson Summary:
    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 vaguely correct).

    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 the file).

    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.

    Next Time:
    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.

    Disclaimer:
    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.

    Peace,
    Absolut

                   
    
    

     

    Logo designed by CO2 - http://www.planetquake.com/CO2

    This site, and all content and graphics displayed on it,
    are ©opyrighted to the Quake DeveLS team. All rights received.
    Got a suggestion? Comment? Question? Hate mail? Send it to us!
    Oh yeah, this site is best viewed in 16 Bit or higher, with the resolution on 800*600.
    Thanks to Planet Quake for there great help and support with hosting.
    Best viewed with Netscape 4 or IE 3