I have a question with .lib ,which might be stupid. Why would we need to link a lib file if a header file has been included? When would we need to link a lib file?
Printable View
I have a question with .lib ,which might be stupid. Why would we need to link a lib file if a header file has been included? When would we need to link a lib file?
Linking with the lib basically links with the .dll. If its a static library, linking with the lib adds the lib code to your executables code. With simply the .h file, the linker doesn't know where the function is implemented.
you link to the lib if you are directly linking (static linking) to the dll, as opposed to loading the dll on run time. So yes, use your .lib file even if the .h is included
The header file (.h) generally just includes the function/method prototypes. The library (.lib, .dll) is where the actual code is and thus needs to be included for the appilcation to work. Header files are used by the compiler for code generation, will the linker uses the libraries to satisfy references in the genaerated code. This is a rather simplistic view of the complie and link process...
Thanks for you guys' excellent comments. Now it will go to my true concern. According to your opinions, link a .lib is just a option. Am I right? However, sometimes if I failed to link a .lib, there would be linker errors. That really makes me confused. Since I have included header file, therefore at least I might link the library dynamically. Why is still there linker errors?
No, no opions here. Also no, libs are required. When you compile the code you've written is translated into machine code and stored in .obj (object files). The compiler handles one file at a time and has no knowledge of where any of the externals (functions, varialble) are or will be located, so when the compiler encounters a function, it looks in the included headers to verify the parameters, and other information. If the function is not present in the current module (file) it adds the function to a table of externals and in place of the address it would normally call it puts a place holder. The linker then takes all the obj's and libs and looks through them to satisfy all the unresolved externals and changes the placeholders to the actual address... if the lib is for a dll, the placeholder is exchanged for one that indicates that the address will be resolved at runtime.
This is still a simple explaination, and glosses over many of the points relavite to compiler design and workings. But to stress again you need both the header and the lib; if the lib is implemented in a dll, you need the dll at runtime.
Nice explaination. However, I still couldn't understand your points one hundred percent. Let me think about it this way. If I want to STATICALLY link the libraries, what should I do?Quote:
Originally posted by bytz
No, no opions here. Also no, libs are required. When you compile the code you've written is translated into machine code and stored in .obj (object files). The compiler handles one file at a time and has no knowledge of where any of the externals (functions, varialble) are or will be located, so when the compiler encounters a function, it looks in the included headers to verify the parameters, and other information. If the function is not present in the current module (file) it adds the function to a table of externals and in place of the address it would normally call it puts a place holder. The linker then takes all the obj's and libs and looks through them to satisfy all the unresolved externals and changes the placeholders to the actual address... if the lib is for a dll, the placeholder is exchanged for one that indicates that the address will be resolved at runtime.
This is still a simple explaination, and glosses over many of the points relavite to compiler design and workings. But to stress again you need both the header and the lib; if the lib is implemented in a dll, you need the dll at runtime.
A normal lib is always statically linked. DLL's (Dynamic Link Library) are either dynamically linked or can be loaded by the consumer at runtime. MFC exists in two forms: LIB and DLL, hence it can be either statically or dynamically linked. For MFC, I prefer static linking, as it seems to avoid problems at the cost of some space. For other libraries, it depends on how they're created, as a .lib or .dll. To add to the "confusion" .dll's always/often/mostly have a lib file which the linker uses.
As for how to statically link the MFC libraries, use the project settings and set the MFC setting (on the general tab) to Use MFC in a static library... for other libraries, include the lib in your project or on the linker tab of the project setting, or in the off case that you're using a make file - place it in the appropiate spot.
Then what is the point to use dll, since no matter whether the library be statically or dynamically linked, the normal lib is always statically linked.Quote:
Originally posted by bytz
A normal lib is always statically linked. DLL's (Dynamic Link Library) are either dynamically linked or can be loaded by the consumer at runtime. MFC exists in two forms: LIB and DLL, hence it can be either statically or dynamically linked. For MFC, I prefer static linking, as it seems to avoid problems at the cost of some space. For other libraries, it depends on how they're created, as a .lib or .dll. To add to the "confusion" .dll's always/often/mostly have a lib file which the linker uses.
As for how to statically link the MFC libraries, use the project settings and set the MFC setting (on the general tab) to Use MFC in a static library... for other libraries, include the lib in your project or on the linker tab of the project setting, or in the off case that you're using a make file - place it in the appropiate spot.
One more thing unclear about that the library is statically linked. In that case, do I have to include the header files(I guess no)?
If statically linked, a .lib saves you the trouble of having to LoadLibrary, and GetProcAddress for all your functions and going through that frustration. You won't notice much of a difference, but take out the .lib file from your linker and watch the external errors come pouring in!
So why use the other method? The other method isn't statically linked, you can choose to try, on the fly, to load the .dll, and if found add an extra feature, for example. The benefits of linking statically, then, are found in 3rd party development of dlls that you want to use, etc.
There are pros/cons to both ways, but you have to decide which better fits your project. If your code won't update a lot, then no need for a .dll! If you want code to be executed from a .dll, which means it is REQUIRED to exist to run, then statically link, and as you optimize your code release newer versions of a .dll (aka sending someone a few kb instead of a whole application when you do a small update).
Ok, I said a lot, but I'm not sure if I said anything at all :D
Hope this helps though
Yes, you always need the headers included. The lib contains different information than the headers. If you are statically linking then all of the code is contained in the lib file. If you are dynamically linking, the lib contains code which calls the code in the dll (this isn't exactly how it works, but an easy way to look at it). So there will always be some code in the lib file, so you always need the file.
I think you are being confused with two totally different issues.Quote:
Originally posted by dullboy
Then what is the point to use dll, since no matter whether the library be statically or dynamically linked, the normal lib is always statically linked.
One more thing unclear about that the library is statically linked. In that case, do I have to include the header files(I guess no)?
The first issue is that is to be resolved is to make the compiler happy. To do this, the header files are needed so that the compiler doesn't give you errors that you are calling a function without a proper prototype. The linker knows nothing about header files.
The next, totally seperate issue is linking. Once the compiler has compiled your files to OBJ files, it's job is done. The linker now steps in and creates the executable file, based on what the compiler has compiled. The linker looks at all of your function calls, and determines if these functions actually exist. The linker uses a variety of ways to do this
a) looks to see if the actual code for the function you're calling was compiled by you.
b) If it can't find it in the files you compiled, it then looks to see if the code exists in other libraries. If the code doesn't exist in the other specified libraries, the linker gives up and emits an error. The other libraries can be "static" or "dynamic", the former being actual object code, and the latter being just a stub to other functions located in other executable modules.
Note that the linker that comes with VC++ can be used with any language that supports the Microsoft object format. This is why (from what I remember), the same LINK.EXE is used for VC++, MS-Fortran, and MS-COBOL programs, as well as other non-Microsoft languages.
But in general, this is basically how compilers and linkers, regardless of the language or OS, have worked for decades.
Regards,
Paul McKenzie
Thanks for your guys' instructions. Sadly, I am not sharp. So if I missed your points, don't get mad but just get used to it. :D
I guess when the linker tries to get the actual code to implement the functions, it actually gets the addresses of functions. However for the dll, the addresses contained in it could be shared by a number of applications. However the addresses contained in the lib couldn't be shared. So here my question is what makes the addresses in the dll be shared among a number of applications? Correct me if I am wrong.
Take the .dll you want to view and open it up in Depends (start menu --> programs --> MS VS --> Tools --> Depends).
Opening the dll in depends will explain a lot to you, I hope anyway! You'll see that public functions are assigned ordinals (@1, @2, etc). When you load a dll at run time, it uses the name specified before the ordinal number to look up the ordinal number and essentially find the function in the .dll.
IIRC...
The .lib file is pretty much doing the same. It's mapping where it's at in the dll so that when you link it can find the functions and, when statically linked, insert the function into your project.
Take a look at it and read up on it on the internet; there are tons of articles that explain, in detail, how this stuff works and why it works.
Go my son. We have taken you as far as we can, it is now time for you to step out into the real world.... alone. ;)
Usually, I do search on the internet. But I just prefer the interactive way in the forum. There is one good thing about the discussion in the forum that we could look at the things from the different angles. That is just my humble two cents.Quote:
Originally posted by Eli Gassert
Take the .dll you want to view and open it up in Depends (start menu --> programs --> MS VS --> Tools --> Depends).
Opening the dll in depends will explain a lot to you, I hope anyway! You'll see that public functions are assigned ordinals (@1, @2, etc). When you load a dll at run time, it uses the name specified before the ordinal number to look up the ordinal number and essentially find the function in the .dll.
IIRC...
The .lib file is pretty much doing the same. It's mapping where it's at in the dll so that when you link it can find the functions and, when statically linked, insert the function into your project.
Take a look at it and read up on it on the internet; there are tons of articles that explain, in detail, how this stuff works and why it works.
Go my son. We have taken you as far as we can, it is now time for you to step out into the real world.... alone. ;)
Anyway, really thank you for the information. I will go get them soon.
I wish I could be young for ever. On the other hand, am I going to be benefited a lot in my professional career if I look more senior. :)
Grow a beard and get bald, that does wonders to make you look older ;)Quote:
Originally posted by dullboy
...I going to be benefited a lot in my professional career if I look more senior. :)
Sorry, I was out at a meeting for a while... (*^*&^*& work interfering with fun again!!)
I think that we've established that:
1 Headers are for the compiler, you need them to use the function, and to avoid compile errors.
2. Libraries are for the linker and are the functions that the header referred to.
3. Libraries have two flavors: normal and DLL.
4. When you link to a normal library it's static linking; when you link to a DLL it's dynamic.
5. DLL's don't need to be linked; they can be loaded at runtime.
Why would you use a normal lib or a DLL? I'd try to answer, but perhaps it's best to start another thread as I think that would almost start a "holy war".
:D :D
Thanks... but I will pass because my girl friend doesn't like that. :DQuote:
Originally posted by Yves M
Grow a beard and get bald, that does wonders to make you look older ;)
Are you sure you want to start another thread? Okey, I will start a new thread soon per your request. But I will keep the five points you have made above as a first post in the new thread because I don't want to go back to the old-stone age.:)Quote:
Originally posted by bytz
Sorry, I was out at a meeting for a while... (*^*&^*& work interfering with fun again!!)
I think that we've established that:
1 Headers are for the compiler, you need them to use the function, and to avoid compile errors.
2. Libraries are for the linker and are the functions that the header referred to.
3. Libraries have two flavors: normal and DLL.
4. When you link to a normal library it's static linking; when you link to a DLL it's dynamic.
5. DLL's don't need to be linked; they can be loaded at runtime.
Why would you use a normal lib or a DLL? I'd try to answer, but perhaps it's best to start another thread as I think that would almost start a "holy war".
:D :D
Well, I had intended to separate the thread into Why use a dll instead of static (normal) linking as there are good technical reasons for both, and alot of fluff, as the old saying goes if you have 4 programmers, you have 0x0101 opinions.:D ;)
I don't object to continue discussing what libraries are for in this thread, but the aforementioned issue is a way more specialized case.
It may help you to search/read intro stuff about compiling and linking, maybe figure out what an assembler is & why it's different from a compiler -- this knowledge may not really be of use in solving day to day programming problems, but sometimes it helps to know what's going on under the covers. I was mulling over this during my hour long commute, and realized that VS tends to isolate/insulate programmers from the nity-grity process of building code... Why when I was a young, snotty nosed Comp Sci student < ;) :rolleyes: :rolleyes: > we had to roll our own make files, and what a pain that was! But at least you understood what was going on through out the entire buld process.
Enough digression, remember that a compiler uses .h and .cpp (or .c) files to produce object code (.obj)? Essentially these .obj files are the machine language equivelent of the code written in the .cpp files (also remember that the compiler only looks at one file at a time). The linker acts just like it's name implies, it links one or more object files together into a .exe, lib or other sort of file. This linking process is concerned, among many other things, with finding out what function calls are being made from one module (the .obj produced by one .cpp file/module) to another. So, the linker essentially builds a big dictionary of what's where and then starts checking if every function call can be resolved somewhere in that list... if not it emits an "Unresolved External" error, which means that it can't find a function or variable in any of the modules in the project. The compiler, OTOH, emits Syntax errors (mostly, there are other types) which generally mean "you typed the statement wrong, Bozo". Why say this - 'cuz if you get a compile error, you generally fix it by correcting the mistake in your code and link errors are generally fixed by making sure that your project includes everything that it needs to. WARNING the previous was a very simplistic explination of a complex set of error conditions... It's late, so I'll try to wind it up...
As you start to write a great deal of code, you'll notice that there is a great deal of common funtionality, i.e. you often need to copy a string from one place to another, find out the string length, get the absolute value of a number, etc, etc... So you could re-write these functions for every application that needed it or you could write it once and reuse it when ever needed. Enter the "Library", these file are collections of commonly used routines that can be used by simply including a header file (for the compiler) and adding the .lib to the project (for the linker). All this was to say that a library file is nothing more than a collection of linked .obj files... linked in the sense that the library has no unresovled externals etc...
Enough for now. Good luck and keep thinking & questioning.
Thanks for your explaination. However, my question is NOT about which one is better, dynamically linking or statically linking. My question is what in the world is the difference in USING dynamically linked library and statically linked library.Quote:
Originally posted by bytz
Well, I had intended to separate the thread into Why use a dll instead of static (normal) linking as there are good technical reasons for both, and alot of fluff, as the old saying goes if you have 4 programmers, you have 0x0101 opinions.:D ;)
I don't object to continue discussing what libraries are for in this thread, but the aforementioned issue is a way more specialized case.
It may help you to search/read intro stuff about compiling and linking, maybe figure out what an assembler is & why it's different from a compiler -- this knowledge may not really be of use in solving day to day programming problems, but sometimes it helps to know what's going on under the covers. I was mulling over this during my hour long commute, and realized that VS tends to isolate/insulate programmers from the nity-grity process of building code... Why when I was a young, snotty nosed Comp Sci student < ;) :rolleyes: :rolleyes: > we had to roll our own make files, and what a pain that was! But at least you understood what was going on through out the entire buld process.
Enough digression, remember that a compiler uses .h and .cpp (or .c) files to produce object code (.obj)? Essentially these .obj files are the machine language equivelent of the code written in the .cpp files (also remember that the compiler only looks at one file at a time). The linker acts just like it's name implies, it links one or more object files together into a .exe, lib or other sort of file. This linking process is concerned, among many other things, with finding out what function calls are being made from one module (the .obj produced by one .cpp file/module) to another. So, the linker essentially builds a big dictionary of what's where and then starts checking if every function call can be resolved somewhere in that list... if not it emits an "Unresolved External" error, which means that it can't find a function or variable in any of the modules in the project. The compiler, OTOH, emits Syntax errors (mostly, there are other types) which generally mean "you typed the statement wrong, Bozo". Why say this - 'cuz if you get a compile error, you generally fix it by correcting the mistake in your code and link errors are generally fixed by making sure that your project includes everything that it needs to. WARNING the previous was a very simplistic explination of a complex set of error conditions... It's late, so I'll try to wind it up...
As you start to write a great deal of code, you'll notice that there is a great deal of common funtionality, i.e. you often need to copy a string from one place to another, find out the string length, get the absolute value of a number, etc, etc... So you could re-write these functions for every application that needed it or you could write it once and reuse it when ever needed. Enter the "Library", these file are collections of commonly used routines that can be used by simply including a header file (for the compiler) and adding the .lib to the project (for the linker). All this was to say that a library file is nothing more than a collection of linked .obj files... linked in the sense that the library has no unresovled externals etc...
Enough for now. Good luck and keep thinking & questioning.
For me, it seems the same thing.
For example, by dynamically linking, you have to include header files( to make the compiler happy), link the .lib files(to make the linker happy). However, if you take a look at statically linking, you would do the SAME thing as dynamically linking, wouldn't you?Correct me if I am wrong.
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 still have a question. How does the linker know a developer/programmer's choice in either dynamically linking or statically linking? Or in the other words, what special things a developer/programmer has to do to choose between dynamically linking and statically linking?( I remember you used to point out it but I got the impression that basically a developer/programmer does the same thing for both. Now I am looking for the difference.)Quote:
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...
Maybe this has been said already....but static vs dynamic???
Find a bug, patch it (ohh you where gonna download that?), call me later...
When you use a standard LIB file during you link, the code is
added to your EXE file.
When you link with a DLL LIB file, the only thing added to your
EXE file is a reference to the DLL. The code is not added to your
EXE. However, you will need to include the DLL file when you
distribute you program to others. If you don't include the DLL, your program won't run - you will get an error like "Can't find
xxx.dll."
When you use a DLL, then your EXE is smaller. But you have
additional files to distribute.
You are absolutely right, but you didn't answer my question. Let me express my question this way.Quote:
Originally posted by cvogt61457
When you use a standard LIB file during you link, the code is
added to your EXE file.
When you link with a DLL LIB file, the only thing added to your
EXE file is a reference to the DLL. The code is not added to your
EXE. However, you will need to include the DLL file when you
distribute you program to others. If you don't include the DLL, your program won't run - you will get an error like "Can't find
xxx.dll."
When you use a DLL, then your EXE is smaller. But you have
additional files to distribute.
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
Yes and I think as paul stated it, there are two questions here...I'll deal with yours...you don't static link if you ever have worked on any code that deals with millions of lines...and have to provide quick updates...thus...dlls....Quote:
Originally posted by dullboy
You are absolutely right, but you didn't answer my question. Let me express my question this way.
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
PS: static linking is for people who haven't thought ahead :) or maybe they have??? I can see for miles and miles...
This is a really complex answer so follow along closely;) :rolleyes:Quote:
Originally posted by dullboy
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically. Generally you, the programmer, only creates one or the other or the vendor only sells one kind (not always the case, and generally it's a dll vs ActiveX), so this desicion is made for you. The only time it comes into play is when you create a project and you make the decision for MFC, or when you create a library of code that you want to include in other projects....
If you are using MFC library, there is somewhere in Visual studio for you to specify whether linking dynamically or linking statically. It is very clear, period. However, for the library I , as a programmer, create, it seems there is no place to specify whether linking dynamically or linking statically. That is exactly my question---how could I, as a programmer, use the library I create through statically linking in my application?:confused:Quote:
Originally posted by bytz
This is a really complex answer so follow along closely;) :rolleyes:
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically. Generally you, the programmer, only creates one or the other or the vendor only sells one kind (not always the case, and generally it's a dll vs ActiveX), so this desicion is made for you. The only time it comes into play is when you create a project and you make the decision for MFC, or when you create a library of code that you want to include in other projects....
Re-read the following sentence:Quote:
Originally posted by dullboy
how could I, as a programmer, use the library I create through statically linking in my application?:confused:
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.Quote:
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 .
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!
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.
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?:confused:Quote:
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...
The .lib generated with the dll is an import library. it merely assists the linker in finding where to find the functions.Quote:
Originally posted by harisankar_r
I've a question here bytz. What is in the library generated along with dll?
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.
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.Code:
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
{
}
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.Quote:
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?:confused:
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
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 :).
Yeah. That was stupid of me, my bad. The stack would be screwed by big time !!
Hi kiran,Quote:
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.
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.Code:
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
{
}
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
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