Printable View
When I specify a .lib file to link to in my application, why does it work for my friend, who doesn't have these .lib files? Do they somehow link to the .dlls?
Also, why use static link libaries as opposed to dynamic link libraries, while we're here. :p I'll search anyway, but if anyone can be bothered answering, go ahead.
i dunno if it's just me, but i'm alittle confused. U mean, u compile the app and ur friend runs it or u both compile it?
u would use static libraries over dynamic libraries if the program depends on a particular version of functions in the library. Since dynamic library versions can change versions without recompilation of programs.
I compile it, then send the executable to my friend, and it works fine for him.
I sort of have the idea that a static library puts it's functions INTO an executable. That would seem logical, because, as you said, DLLs change over time, so functions could become outdated or different.
Thank you, I understand now.
EDIT: Does this mean, barring the risk of program crashing, that dynamic linking would create a smaller executable?
well then yes it would mean that he has dynamic libraries. Its like Dx, i have the Dx SDK with all the .lib files, but on the bottom of most game boxes now it says "requires directx". that doesn't mean the dx SDK with all the .lib files. downloading dx has all the .dll files along probably with some other types. But not .lib files.
When a program is compiled and the program uses dynamic libraries what actually happens is that, when a function is first called (this function resides in a dynamic library) it doesn't get called it (yet), it askes the OS where this function actually risides in memory. After that, only is it called, but this only happens once. Once the location of the function is found, the memory location is placed in the executable and then the function would be called using that memory location. This happens everytime the program is re-run. Every time the program is opened again it would ask the os for the function.
i don't really understand ur last question. crashing doesn't really have anything to do with the size of the executable. Unless u put the fact that increase in program size, increases the risk of a programmer to make mistakes.
>>I sort of have the idea that a static library puts it's functions INTO an executable
Effectively yes.
>>Does this mean, barring the risk of program crashing, that dynamic linking would create a smaller executable?
Yes as all the exe needs is the import details needed for that dll...not the actual code itself. The downside is that everyone needs that the right dll to run your prog
Thank you, problem (:p ) solved.
You are talking about a .lib that is associated with a .DLL (an import library?)Quote:
Originally posted by bennyandthejets
When I specify a .lib file to link to in my application, why does it work for my friend, who doesn't have these .lib files? Do they somehow link to the .dlls?
Also, why use static link libaries as opposed to dynamic link libraries, while we're here. :p I'll search anyway, but if anyone can be bothered answering, go ahead.
The .lib only has the code that is needed to load the .DLL.
You don't NEED to link the .lib at all. You could manually, using LoadLibrary and other functions, work with the DLL only. However, it can be a pain in the ass to reinvent the wheel everytime you need to execute a function in a DLL, so when you build a DLL, the compiler is nice enough to auto-generate this code, and put it in a static library. Your program calls functions in the static library, and the functions in the static library handle loading the DLL and then they call the DLL versions.