What is inside of a .lib file of Static library, Statically linked dynamic library and dynamically linked dynamic library?
How come there is no need for a .lib file in dynamically linked dynamic library and also that in static linking, the .lib file is nothing but a .obj file with all the methods. Is that correct?
For a static library, the .lib file contains all the code and data for the library. The linker then identifies the bits it needs and puts them in the final executable.
For a dynamic library, the .lib file contains a list of the exported functions and data elements from the library, and information about which DLL they came from. When the linker builds the final executable then if any of the functions or data elements from the library are used then the linker adds a reference to the DLL (causing it to be automatically loaded by Windows), and adds entries to the executable's import table so that a call to the function is redirected into that DLL.
You don't need a .lib file to use a dynamic library, but without one you cannot treat functions from the DLL as normal functions in your code. Instead you must manually call LoadLibrary to load the DLL (and FreeLibrary when you're done), and GetProcAddress to obtain the address of the function or data item in the DLL. You must then cast the returned address to an appropriate pointer-to-function in order to use it.
I found following answer from Hans also useful here.It clears the air that there could two types of lib files.
A LIB file is used to build your program, it only exists on your build machine and you don't ship it. There are two kinds. A static link library is a bag of .obj files, collected into a single file. The linker picks any chunks of code from the file when it needs to resolve an external identifier.
But more relevant to DLLs, a LIB file can also be an import library. It is then a simple small file that includes the name of the DLL and a list of all the functions exported by the DLL. You'll need to provide it to the linker when you build a program that uses the DLL so it knows that an external identifier is actually a function exported by the DLL. The linker uses the import library to add entries to the import table for the EXE. Which is then in turn used by Windows at runtime to figure out what DLLs need to be loaded to run the program.
A lib files is read by the linker and a dll file is used during execution. A lib file is essentially useless during execution and a linker is incapable of reading a dll file (except possibly in a manner irrelevant here).
The differences between the use of lib files for static and dynamic linking might be confusing but if you understand a little history then it becomes very clear.
Originally there were only static libraries. For a static library, the .lib file contains obj files. Each obj file is the output of one and only one compiler source code input file. A lib file is just a collection of related obj files, much like putting obj files in a directory. That is essentially what a lib file is, a library of obj files. For a static link, all of the obj files that an executable uses are combined into one file. Compare that to a dynamic link in which the executable is in a file separate from the other code it uses.
To implement dynamic linking, Microsoft modified the use of lib files such that they refer to a dll file instead of locations in an obj file. Other than that, all the information that is in a library for a static link is the same as for a dynamic link. They are all the same as far as the information in them except that a lib file for a dynamic link specifies the dll file.
In a static library, the lib file contains the actual object code for the functions provided by the library. In the shared version (what you referred to as statically linked dynamic library), there is just enough code to establish the dynamic linkage at runtime.
I'm not sure about "dynamically linked dynamic libraries" (loaded programmatically). Do you even link with a .lib in that case?
Edit:
A bit late in coming, but no, you don't link a .lib. Well, you link to the lib with libraryloaderex in it. But for the actual library you're using, you provide your own bindings via C function pointers and loadlibrary fills those in.
Here's a summary:
Linking ǁ Static | DLL | LoadLibrary =========ǁ===============|======================|=================== API code ǁ In your com- | In the DLL | In the DLL lives ǁ piled program | | ---------ǁ---------------|----------------------|------------------- Function ǁ Direct, may | Indirect via table | Indirect via your calls ǁ be elided | filled automatically | own function ptrs ---------ǁ---------------|----------------------|------------------- Burden ǁ Compiler | Compiler/OS | You/OS
In dll's are "things" like in an exe (there can be any kind of data, imports, exports, read/write/executable sections) but the difference is that an exe file exports only the entry point (function) but dll's export one/many functions.
