Thread: DLL Fundamentals :: MFC

Originally posted by MrWizard
Fordy:

I noticed in your example you link to the lib file and then include the header as "imported" If you took out the DLL stuff wouldn't it be exactly the same? I mean, if you are using DLL's shouldn't you be able to leave out the lib? I thought the old lib's were statically linked and DLL's could fully replace them if needed. A little confused why you used both there.

That library is only an import library (cot a library full of code like old style static libs)...it only contains a stub to allow the linker to find the dll and its member functions.....this info is added to the exe's import table, and the loader then uses it do map the dll into the process and resolve the jumps or calls to the functions..

Originally posted by Fordy


That library is only an import library (cot a library full of code like old style static libs)...it only contains a stub to allow the linker to find the dll and its member functions.....this info is added to the exe's import table, and the loader then uses it do map the dll into the process and resolve the jumps or calls to the functions..

Okay, that makes since. One more question. I see applications all the time with just DLL's and no corresponding lib's though. This is what confuses me, how do they do it then ?

Originally posted by MrWizard


Okay, that makes since. One more question. I see applications all the time with just DLL's and no corresponding lib's though. This is what confuses me, how do they do it then ?

Most likely they link at run time (explicit linking).....see novacain's code above....

First you create a typedef of the function you want to import....this defines a function pointer...

Then call LoadLibrary()......If the dll is already mapped into your process, it returns a handle, otherwise it maps it, relocates it, calls its entrypoint and then returns a handle...

Then call GetProcAddress() with the module handle and you will get a pointer to the start of that imported function.....cast this back to your typedef'ed function pointer and you can use the function at will!!!

Dont forget FreeLibrary() after youve finished...this decreases the dll's usage count and unmaps it after its not needed

Originally posted by Fordy


Most likely they link at run time (explicit linking).....see novacain's code above....

First you create a typedef of the function you want to import....this defines a function pointer...

Then call LoadLibrary()......If the dll is already mapped into your process, it returns a handle, otherwise it maps it, relocates it, calls its entrypoint and then returns a handle...

Then call GetProcAddress() with the module handle and you will get a pointer to the start of that imported function.....cast this back to your typedef'ed function pointer and you can use the function at will!!!

Dont forget FreeLibrary() after youve finished...this decreases the dll's usage count and unmaps it after its not needed

So, when you implicity link the DLL, this is similiar to the old static lib's? You only use explicit linking when you don't need the DLL that much just in certain situations? I'm having a hard time seeing from a practical standpoint the differences between dll's and lib's.

When you use a standard code library (lib) you add that code to your code and its all housed in the .exe you are producing......

With a dll the code you are using is housed in a seperate file (the dll itself)...this dll can be used by any program that is willing to load it...therefore that's why code in dlls such as kernel32.dll does not have to exist in every .exe

Now you can use that dll in 1 of 2 ways.....

1. An Import Lib (implicit linking)

This is produced with the dll and so you add it to another project as you wish....this lib doesnt contain any code....its just information to allow the linker to create an exe that imports the relevent dlls at execution...it also gives the info needed for the exe to resolve to the dll's exported functions....if you use __declspec(dllimport) with an import library, then this is the most efficient way to use a dll...the downside is that if you change the dll, you might need to change the lib...therefore you need to relink the exe that uses it.

2. Run Time Loading (explicit linking)

Here you use no lib....you just call LoadLibrary to load the dll, and then GetProcAddress to get the function.....This slightly more cumbersome and less efficient than using an import lib, but it allows you to use any dll as long as you know its exported funcs.....

Crystal clear, thank you for your time, patience and help.