definition
- Runtime library: A typical example of runtime library in Unix is libc, which contains standard C functions, such as print(), exit(), etc. Users can create their own runtime library (DLL in Windows) , And the specific details depend on the compiler and operating system.
- Static library: The functions and data are compiled into a binary file (usually with the extension .lib). The static library is actually linked to the EXE during linking. The library itself does not need to be distributed with the executable file.
- Dynamic library: The dynamic library created with VC++ contains two files, a lib file and a dll file. This lib file is an imported library, not a static library. An imported library is sometimes called an import library or an import library.
Note: The extensions of dynamic libraries and runtime libraries under windows operating system are both .dll, the extensions of COM components are also .dll, and the extensions of dynamic libraries and static libraries are both .lib.
Method of calling dynamic library under windows
(1) Implicit loading: the lib file and .h file are included in the program. Implicit linking is sometimes called static loading or dynamic linking during loading. E.g:
#include "somedll.h"
#pragma comment( lib, "somedll.lib")
Then you can directly call the functions in this dll, and note that somedll.dll is still needed at runtime.
(2) Display Load: Use loadlibrary, GetProcAddress, FreeLibrary, and other functions. No .h file and .lib file are needed, but you need to know the prototype of the function. Explicit linking is sometimes called dynamic loading or runtime dynamic linking.
The difference between the two
If the DLL is not found when the process starts, the operating system will terminate the process that uses implicit linking. Also in this case, the process using the explicit link will not be terminated, and you can try to recover from the error.
Decide which link method to use
1. Implicit link
- The implicit link occurs when the application code calls the exported DLL function. When the source code of the calling executable file is compiled or assembled, the DLL
function call generates an external function reference in the object code. To resolve this external reference, the application must be linked with the import library (.LIB file) provided by the creator of the DLL. - The import library only contains the code to load the DLL and the code to implement DLL function calls. After the external function is found in the import library, the linker will be notified that the code of this function is in the DLL. To resolve external references to the DLL, the linker only needs to add information to the executable file, telling the system where to look for the DLL code when the process starts.
- When the system starts a program that contains a dynamic link reference, it uses the information in the program's executable file to locate the required DLL. If the system cannot locate the DLL, it will terminate the process and display a dialog box to report the error. Otherwise, the system maps the DLL module to the address space of the process.
- If any DLL has an entry point function (for initialization code and termination code), the operating system will call this function. Among the parameters passed to the entry point function, there is a code specifying that the DLL is being attached to the process. If the entry point function does not return TRUE, the system will terminate the process and report an error. Finally, the system modifies the executable code of the process to provide the starting address of the DLL function.
- Like the rest of the program code, the DLL code is mapped into the process's address space when the process starts, and is only loaded into memory when needed. Therefore, the PRELOAD and LOADONCALL code attributes used by .def files to control loading in earlier versions of Windows no longer have any meaning.
2. Explicit linking
Most applications use implicit linking because this is the easiest linking method to use. But sometimes you also need to explicitly link. Here are some common reasons for using explicit links: - Until runtime, the application does not know the name of the DLL that needs to be loaded. For example, the application may need to obtain the name of the DLL and the name of the exported function from the configuration file.
- If the DLL is not found when the process starts, the operating system will terminate the process using implicit linking. Also in this case, the process using the explicit link will not be terminated, and you can try to recover from the error. For example, the process can notify the user of an error and let the user specify another path to the DLL. If any of the DLLs linked to by the implicit linking process has a failed DllMain function, the process will also be terminated. Also in this case, the process using explicit link will not be terminated.
- Because Windows loads all DLLs when the application loads, applications that are implicitly linked to many DLLs will start up slowly. To improve startup performance, applications can implicitly link to DLLs that are needed immediately after loading, and wait until they are explicitly linked to other DLLs when needed.
- There is no need to link the application with the import library under explicit linking. If the change in the DLL causes the export sequence number to change, applications that use explicit linking do not need to be relinked (assuming they call GetProcAddress with function names instead of sequence number values), and applications that use implicit linking must be relinked to the new Import the library.
Here are two disadvantages of explicit linking that need to be noted: - If the DLL has a DllMain entry point function, the operating system calls this function in the context of the thread that called LoadLibrary. If the DLL has been attached to the process because LoadLibrary was previously called but the FreeLibrary function was not called accordingly, this entry point function will not be called. If the DLL uses the DllMain function to perform initialization for each thread of the process, explicit linking will cause problems, because the thread that exists when LoadLibrary (or AfxLoadLibrary) is called will not be initialized.
- If the DLL declares static scope data as __declspec(thread), the DLL will cause a protection fault when explicitly linking. After loading the DLL with LoadLibrary, the DLL will cause a protection error whenever the code references this data. (Static scope data includes both global static items and local static items.) Therefore, you should avoid using thread local storage when creating a DLL, or you should (when the user is trying to load dynamically) inform the DLL user of potential defects.
Link conditions
Implicit link
In order to implicitly link to the DLL, the executable file must obtain the following items from the DLL's provider:
- A header file (.h file) containing declarations of exported functions and/or C++ classes. Classes, functions, and data should all have __declspec(dllimport). For more information, see dllexport, dllimport.
- Import libraries (.LIB files) to be linked. (The linker creates the import library when generating the DLL.)
- The actual DLL (.dll file).
The executable file that uses the DLL must include a header file, which contains the exported functions (or C++ classes) in each source file, and these source files contain calls to the exported functions. From a coding perspective, the function call of the exported function is the same as any other function call.
To generate the calling executable file, it must be linked with the import library. If you are using an externally generated file, please specify the file name of the import library, which lists other object (.obj) files or libraries to be linked to.
The operating system must be able to locate the DLL file when loading and calling the executable file.
Explicit link
Under explicit linking, the application must make function calls to explicitly load the DLL at runtime. To explicitly link to the DLL, the application must:
- Call LoadLibrary (or similar function) to load the DLL and get the module handle.
- Call GetProcAddress to obtain function pointers to each exported function to be called by the application. Since the application calls
the functions of the DLL through pointers , the compiler does not generate external references, so there is no need to link with the import library. - Call FreeLibrary after using the DLL.
If there is any infringement, please private message me to delete, thank you
Reprint link
https://os.51cto.com/art/201911/606673.htm