Why is .lib file necessary when load time linking DLL

[guyafe]

Hi all,
I am new in DLL programming and trying to understand how the linking is done.
I found several tutorials. All of them just tell "what" but neither explain "why" or "how".
It written there that when linking an application to a DLL on load time you have to provide the .lib file from the DLL compilation.
My question is why?
Doesn't the lib file contain only raw code?
I understand that the dll file already contains the entire code and tables necessary for the linkage?

Thanks for clarifications,
Guy

[VictorN]

Have a look at this discussion...

[Paul McKenzie]

It written there that when linking an application to a DLL on load time you have to provide the .lib file from the DLL compilation.
My question is why?

The linker has to resolve those function calls that are made, and the lib file provides the linker the entry point stubs to call those functions.

Doesn't the lib file contain only raw code?

Import libraries do not contain code.

I understand that the dll file already contains the entire code and tables necessary for the linkage?

DLL's are not involved in any of the build steps, compilation or linking. The DLL is strictly something that enters the picture at run-time.

That's why you can build any application, even if the DLL's it requires to run on do not exist on the machine or even anywhere (maybe they have been lost, never to be found). It is when you run the application is when the DLL's come into play, as the DLL's contain the actual code for the functions being called.

Regards,

Paul McKenzie

[Igor Vartanov]

Hi all,
I am new in DLL programming and trying to understand how the linking is done.
I found several tutorials. All of them just tell "what" but neither explain "why" or "how".

So, it's time for you to start asking those whys and hows here.

It written there that when linking an application to a DLL on load time you have to provide the .lib file from the DLL compilation.

You don't have to, you just may do this way. But you may do another way by loading your dll explicitly and resolving exported dll entries at runtime.

I understand that the dll file already contains the entire code and tables necessary for the linkage?

Necessary on dll side, yes. But dynamic linkage with external module is a two-side process. You need to instruct your app to start dll loading and entry resolving at app load time. And this is exactly what import library is for.

[guyafe]

Thank you all for the replies. They were much helpful.
I looked over the above links (unfortunately some of the links inside were broken) and went through your answers.
What confused me before was that .lib suffix has two meanings: The first is the just concatenated obj files and the other is an import library.
So I googled some about the lib structure and tried to hack my own lib outputs.
Let me sum things up to see if I understand correctly:


(I am talking only about load-time linking and not run-time linking)

• A dll is a file containing runnable code that is used by another application and loaded at run-time.
• A lib file (in this context) is a metadata file that contains entrypoints to the dll file (offsets) for each function exported by the dll.
• When building the executable, the linker checks the lib file so it can tell the executable where it can find the library functions inside the dll.

So it is obvious that the linker needs the header file and the lib file at linkage time.
What I don't understand is why does the linker need the dll file at linkage time?

Thanks,
Guy

[VictorN]

So it is obvious that the linker needs the header file and the lib file at linkage time.
What I don't understand is why does the linker need the dll file at linkage time?

No, linker does NOT need any header file at linkage time.
No, linker does NOT need the dll at linkage time.

[Paul McKenzie]

So it is obvious that the linker needs the header file

The linker knows nothing about the original language that was used to create the object file. Therefore, the header file has nothing to do with the linker, as the header file's only use is for C++ and C compilation issues.

That's why the linker, LINK.EXE, can work for C, C++, MS Fortran, MS Cobol, and any language that produces object code that is compatible with it. Back a long time ago, I remember using LINK.EXE for Clipper and other off-the-beaten path languages, since these "weird" languages produced object code compatible with LINK.EXE.

What I don't understand is why does the linker need the dll file at linkage time?

There is nothing to understand since the linker doesn't use the DLL at all. Didn't I mention that in my first post? You can build an entire application, and not have even one of the DLL's that the application needs to run sitting on your machine.

Don't believe me? Try it. Take any application that you build now that you know requires some third-party DLL to run. Remove that DLL from your machine. Rebuild your app. Your app will build with no issues.

Now, running your application, that is a different thing altogether.

Regards,

Paul McKenzie

[guyafe]

Thanks, Now I understand.

I think what confused me is that I compile a solution containing both the DLL and the executable. Also I used in the executable code the headers from the DLL.

Now I understand that this is not obligatory.

Guy

[kingting]

Through my limited programming knowledge, I have been using dll's and lib's and have no idea what they actually do... Like OP says, everything I read online tells you how to use them but there is never a very good explanation of why or what. Are there any good resources on this?

[S_M_A]

Try this http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx