Why does Implicit DLL Linking need a corresponding lib file, but explicit linking does not?

Question

In Windows environment

When I tried to link the DLL with my program Explicitly (using LoadLibrary),

• First I need to define function pointers for each in the DLL.
• Then get the addresses of the functions using "GetProcAddress" and assign them to these pointers.

When I tried to link the DLL with my program Implicitly (using the header file)

• First, to obtain function signatures, you need the appropriate header file.

• Then he needs the appropriate Lib file that was generated using the DLL.

  My questions

  • Why do I need a Lib file for implicit binding?
  • What information needs to be extracted from the "Lib" file, which it cannot receive from the DLL or Header file ?
  • If there is something for question 2, how do I get the information when loading explicitly?

I have already turned to this question. But I cannot understand any worthy cause. Please can anyone explain this in plain language. Thanks.

Answer 1

Why implicitly link the lib file as well.

.Libs have information about importing DLLs, you can check the information using the dumpbin command, which is included in the Windows / Visual Studio SDK.

This is the recv link information inside ws2_32.lib, for example:

 Version : 0 Machine : 14C (x86) TimeDateStamp: 4907F6ED Wed Oct 29 01:38:53 2008 SizeOfData : 00000014 DLL name : WS2_32.dll Symbol name : _recv@16 Type : code Name type : ordinal Ordinal : 16 

You can check if there is a serial number and name inside ws2_32.dll (check what it says now to import the DLL).

What information needs to be extracted from the "Lib" file, which cannot be obtained from the DLL or the header file

There is no information in the header file about where to get the import, so when compiled they are marked as import (__imp__name), and when it is associated with .lib, it resolves the name:

• If it is inside .lib, it just refers to it.
• But if there is information about an external link (DLL), it will build the import inside the import table so that it loads dynamically.

If there is something for question 2, how is this information retrieved when explicitly loaded.

If you mean LoadLibrary for explicit loading, you talk about it at runtime, not at link time. Thus, the PE loader will look for the DLL inside the PATH and will load it dynamically. Then you have other functions to get the addresses of the exported functions.

If you don’t understand something, just ask me, try playing with dumpbin and read about PE if you want to understand it better.

Answer 2

When implicitly bound, a function declaration indicates the name that will be used in the program, and the prototype and call protocol. But more information is needed. In particular:

• The fact that the function is implemented externally in the DLL.
• The name of this dll.
• The exported function name. This is the name used to export the function from the DLL, which may not be the same as the one used to import it.

Some language developers have decided to provide this information using language extensions. For example, Delphi chose this route. Implicit binding is fully indicated in the code without .lib files. On the other hand, the convention for C and C ++ is to use .lib files to indicate missing information.