I thought Implicit linking loads a DLL as soon as the application starts because it is also called "load-time dynamic linking". But I found some strange explanations below from the link here(https://msdn.microsoft.com/en-us/library/253b8k2c(VS.80).aspx).
Implicit Linking
Like the rest of a program's code, DLL code is mapped into the address space of the process when the process starts up and it is loaded into memory only when needed. As a result, the PRELOAD and LOADONCALL code attributes used by .def files to control loading in previous versions of Windows no longer have meaning.
Explicit Linking
An application that implicitly links to many DLLs can be slow to start because Windows loads all the DLLs when the application loads. To improve startup performance, an application can implicitly link to those DLLs needed immediately after loading and wait to explicitly link to the other DLLs when they are needed.
And another explanation for implicit linking from here(https://msdn.microsoft.com/en-us/library/151kt790.aspx).
Implicit Linking
The Visual C++ linker now supports the delayed loading of DLLs. This relieves you of the need to use the Windows SDK functions LoadLibrary and GetProcAddress to implement DLL delayed loading.
Before Visual C++ 6.0, the only way to load a DLL at run time was by using LoadLibrary and GetProcAddress; the operating system would load the DLL when the executable or DLL using it was loaded.
Beginning with Visual C++ 6.0, when statically linking with a DLL, the linker provides options to delay load the DLL until the program calls a function in that DLL.
An application can delay load a DLL using the /DELAYLOAD (Delay Load Import) linker option with a helper function (default implementation provided by Visual C++). The helper function will load the DLL at run time by calling LoadLibrary and GetProcAddress for you.
I'm really confused and don't know how to understand these.
1. Does implicit linking load a DLL on startup or only when a function in DLL is called?
2. It means both are similiar in the end because LoadLibrary() is called under the hood?
You can use load-time dynamic linking or run-time dynamic linking in your DLL in the same way as in the executable. The only restriction is not to call LoadLibrary from your DllMain function to avoid deadlocks.
The DLL can link to the same MFC static link libraries used by applications. There is no longer a separate version of the static link libraries for DLLs.
LoadLibrary can be used to load a library module into the address space of the process and return a handle that can be used in GetProcAddress to get the address of a DLL function. LoadLibrary can also be used to load other executable modules.
A dynamic link library (DLL) is a collection of small programs that larger programs can load when needed to complete specific tasks. The small program, called a DLL file, contains instructions that help the larger program handle what may not be a core function of the original program.
@remy-lebeau provided a good explanation in his comment. I'll try to elaborate here as an answer.
The difference between implicit and explicit dll loading is explained here. In short:
Implicit loading has many advantages, but it slows the application loading time because all of the dlls are loaded during this stage.
To solve this issue, Microsoft supports Delayed Loaded Dlls, which is a type of implicit loading.
By using it you can enjoy all of the benefits of implicit loading, but the dll will be loaded only when your application will call one of its functions.
To your questions:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With