Question with .lib

[dullboy]

Originally posted by bytz
Re-read the following sentence:
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically.

Further explaination:
It depends on the type of library you create!!!!! If you create a normal lib; from then you will link it statically, no choice, no decision, it just the way it works. If on the other hand you created a DLL, when you used it in a application it would linked using dynamic linking, once again no choice, no decision. Once a library has been created there is no choice how to link it -- well, almost none; you can choose not to link a dll, but to load it programmatically at runtime.

The only choice you could have with one of you libraries is too create both a static version and a dynamic version. Then you could choose one or the other and the linking would occur as determined by the lib type .

Excellent! Now it is going back to my initial question if you still remember, which is why I have to link a .lib file when I use DLL.
My concern #1:
Why after I specify DLL, both DLL and LIB files are generated?
I think if I specify DLL, then ONLY DLL will be generated eventually and if I specify LIB, then only LIB will be generated.

My concern #2:
Why I have to link the .lib files when I specify DLL.

In order to confirm what I thought, I wrote a dummy application in the following(please note, they all are verified)

// Client.cpp

#include "testLib.cpp"

int main(int argc, char* argv[])
{
Speak("Hello, library\n");
return 0;
}

// testLib.cpp
#include <iostream>
#include <windows.h>

using namespace std;

int Speak(LPTSTR szText)
{
cout<<szText<<endl;
return 1;
}

//testDLL.cpp
#include <iostream>
#include <windows.h>

using namespace std;

int Speak(LPTSTR szText)
{
cout<<szText<<endl;
return 1;
}

testDLL is a dynamic link library and testLib is a static link library.

Under folder testDLL, ONLY testDLL.dll were generated!
Under folder testLib, ONLY testLib.lib were generated!

[bytz]

Actually your original question was why do you need a .lib when you had already included the .h.
When you link a library (either static or dll) the linker need information i.e. where the functions are, names, etc, when the completed application is run, it needs just the address (where to jump/call). So in creating the concept of a dynamic DLL, the designers decided to leave everything that the linker needed in the .lib file, along with any additional info requred for dynamic linking and move all of the executable code into a new file the DLL. So, if you recall, the lib is still the thing that makes the linker happy, reguardless of whether it's static or dynamic.

[harisankar_r]

Originally posted by bytz
You're basically right, there are a few differences in how the linker handles references between Static and Dynamic linking, and there are a few differences at runtime. When you link to a static library, the linker opens the lib and copies it's contents to the exe, when you link dynamically, the linker inserts a reference to the DLL (name, location of the fucntion, etc). This leads to situations; One, the static linking can cause a (much) larger exe size but is able to run without any additional files. The second is that the DLL version exe is smaller, although total code size is about the same (exe + dll), but the dll must be present in order for the application to startup. It's this difference that leads to the question "Why/when would I use either one". This has been alluded to, and semi-explained earlier in the thread...

I've a question here bytz. What is in the library generated along with dll? Is it that If I don't refer the functions from the dll in my exe, instead I used LoadLibray, GetPRocAddr..., I need not link this library with the exe? What code is linked to my exe when I include this library?

[kirants]

Originally posted by harisankar_r
I've a question here bytz. What is in the library generated along with dll?

The .lib generated with the dll is an import library. it merely assists the linker in finding where to find the functions.

To explain in very simple terms...
1. When you link to a dll's lib( say in your exe), the linker , when it encounters a function not present in any .obj files will try to look for one in one of the linked libraries. If it doesn't find any, it spits out an error "unresolved external symbol.. function name".
So, you keep the linker happy by supplying it an import library for the dll you wish to dynamically link to at load time. The import library will have information as to what functions are exported by the module and what the dll is. Say there is a function Func() exported by Func.dll and is called in FuncCaller.exe. Now, when you link FuncCaller.exe, linker will look for all libs. If it finds Func.lib listed, it will try to look for if Func() is listed in the Func.lib . If it finds, it puts an entry in the FuncCaller.exe's import table saying something like,
module Func.dll -> Func.

When you execute FuncCaller.exe, during the loading process, the loader checks thru all the entries in the import table. It finds that there is a module called Func.dll required. It tries to find this module in it's standard loading paths and if it finds it, it will map this dll to the process space. Now, the loader has to make some things. It needs to find the address of the function Func in the Func.dll and make the caller jump to this section of code in dll.
It is done in a round-about way.

The linker will actually put a jmp instruction to a single location wherever Func is called. Now, in this location there is one more jmp instruction to the actual location in the dll.

For e.g.

location a: 
jump to location b:
main()
{
   Func() --- jump to location a 

   Func() --- jump to location a
}

--- func.dll id loaded in this address
.
.

location of Func() starts at this address
{

}

So, you see that the loader now has to just replace the b in one place and all calls to Func will go to the dll.

Is it that If I don't refer the functions from the dll in my exe, instead I used LoadLibray, GetPRocAddr..., I need not link this library with the exe? What code is linked to my exe when I include this library?

When you call LoadLibrary and GetProcAddress, you don't need to link with the lib file. This delays the loading of the dll till LoadLibrary is called.

Note that linking with a .lib for LoadLi & GetProcAddr doesn't make sense simply because, the parameters to LoadLib and GetProcAddr can be runtime and how the **** would the linker know what it is in advance ????

Hope this clears somethings... although it is just a superficial explanation

- Kiran

[bytz]

Good explaination, kirants, 'cept it think that the linker proabably uses a 'call' and a 'ret' for location a rather than a jmp -- not that it matters for the casual reader .

[kirants]

Yeah. That was stupid of me, my bad. The stack would be screwed by big time !!

[harisankar_r]

Originally posted by kirants
The .lib generated with the dll is an import library. it merely assists the linker in finding where to find the functions.

To explain in very simple terms...
1. When you link to a dll's lib( say in your exe), the linker , when it encounters a function not present in any .obj files will try to look for one in one of the linked libraries. If it doesn't find any, it spits out an error "unresolved external symbol.. function name".
So, you keep the linker happy by supplying it an import library for the dll you wish to dynamically link to at load time. The import library will have information as to what functions are exported by the module and what the dll is. Say there is a function Func() exported by Func.dll and is called in FuncCaller.exe. Now, when you link FuncCaller.exe, linker will look for all libs. If it finds Func.lib listed, it will try to look for if Func() is listed in the Func.lib . If it finds, it puts an entry in the FuncCaller.exe's import table saying something like,
module Func.dll -> Func.

When you execute FuncCaller.exe, during the loading process, the loader checks thru all the entries in the import table. It finds that there is a module called Func.dll required. It tries to find this module in it's standard loading paths and if it finds it, it will map this dll to the process space. Now, the loader has to make some things. It needs to find the address of the function Func in the Func.dll and make the caller jump to this section of code in dll.
It is done in a round-about way.

The linker will actually put a jmp instruction to a single location wherever Func is called. Now, in this location there is one more jmp instruction to the actual location in the dll.

For e.g.

location a: 
jump to location b:
main()
{
   Func() --- jump to location a 

   Func() --- jump to location a
}

--- func.dll id loaded in this address
.
.

location of Func() starts at this address
{

}

So, you see that the loader now has to just replace the b in one place and all calls to Func will go to the dll.



When you call LoadLibrary and GetProcAddress, you don't need to link with the lib file. This delays the loading of the dll till LoadLibrary is called.

Note that linking with a .lib for LoadLi & GetProcAddr doesn't make sense simply because, the parameters to LoadLib and GetProcAddr can be runtime and how the **** would the linker know what it is in advance ????

Hope this clears somethings... although it is just a superficial explanation

- Kiran

Hi kiran,
This is really very useful. My doubts got cleared. I know that I should not link to the lib when we use dll using LoadLib & GetProcAddr() but still I'd the doubt because I didn't know exactly what is there in the Lib? Now its clear. Thank u very much