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.
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
{
}
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