​

Definition: runtime library static library dynamic library

  • Runtime libraries: A typical example of a runtime library in Unix is libc, which contains standard C functions such as print(), exit(), etc. Users can create their own runtime libraries (DLLS in Windows), the details of which depend on the compiler and operating system.

  • Static libraries: Functions and data are compiled into a binary file (usually with a.lib extension), static libraries are actually linked to the EXE at link time, and the library itself does not need to be distributed with the executable.

  • Dynamic library: a dynamic library created in VC++ contains two files, a lib file and a DLL file. This lib file is an import library, not a static library. Import library is sometimes called import library or import library.

Note: under Windows, the dynamic library and runtime library extension is.dll, as is the COM component extension.dll, the dynamic library import library and static library extension is.lib.

Static library features and creation process

A static library is called a static library because during the linking phase, the assembler generated object file.o is linked and packaged into an executable along with the referenced library. Therefore, the corresponding link mode is called static link.

Imagine a static library linked to an executable with an object file generated by assembly. Static libraries must have a similar format to.o files. In fact, a static library can be simply viewed as a collection of object files (.o/.obj files), that is, many object files compressed and packaged into a file. Static Coulter points are summarized as follows:

  • Static library links to function libraries are done at compile time.

  • The program has no connection with the function library during operation, and it is convenient to transplant.

  • Waste of space and resources because all related object files are linked together into an executable file with the involved function library.

Here is the static library creation process:

​

Dynamic library features and creation process

Why do we need dynamic libraries?

Why do we need dynamic libraries? In fact, it is the characteristics of static libraries.

  • Waste of space is a problem with static libraries.

​

  • Another problem is that static libraries cause problems with updating, deploying, and publishing pages of applications. If the static library libxx.lib is updated, all applications that use it need to be recompiled and distributed to the user (a minor change for the player that causes the entire application to be redownloaded and fully updated).

Dynamic libraries are not connected to object code when the program is compiled, but are loaded when the program is running. If different applications call the same library, only one instance of the shared library needs to be stored in memory, avoiding space waste. Dynamic libraries are loaded while the program is running, eliminating the hassle of static libraries updating, deploying, and publishing pages. The user only needs to update the dynamic library, incrementally.

​

Summary of dynamic Kurt points:

  • Dynamic libraries defer loading links to some library functions until the program runs.

  • Resources can be shared between processes. (Hence dynamic libraries are also called shared libraries.)

  • Make it easy to upgrade some programs.

  • It can even be true that link loading is completely controlled by the programmer in the program code (display calls).

Windows and Linux execute file formats are different, and there are some differences when creating dynamic libraries.

  • In Windows, the execution file format is PE format. The dynamic library needs a **DllMain**** function to initialize the entry, usually in the declaration of the export function needs to have the _declspec(DLlexport)** keyword.

  • GCC compiler execution files in Linux are in ELF format by default, ** no initialization entry is required, and no special declaration of the function is required, ** easy to write.

Windows call down the dynamic library method:

Implicit loading: that is, include lib and. H files in your program. Implicit linking is sometimes called static loading or load-time dynamic linking. Such as:

#include “somedll.h”

#pragma comment( lib, “somedll.lib”)

You can then call functions directly from this DLL, noting that the runtime still needs someDLl.dll.

2 shows the load: use the loadlibrary and GetProcAddress call, FreeLibrary, don’t need. H file and. Lib files, but if you want to know the function prototype. Explicit linking is sometimes called dynamic loading or runtime dynamic linking.

3 Difference: If the DLL is not found when the process is started, the operating system will terminate the process using implicit links. In this same case, processes that use explicit links are not terminated and can try to recover from the error.

For detailed library structure information about Win32 DLLS, Unix shared libraries, and common libraries, see linkers and loaders.

How a link library is linked

1 Determine the link method to use:

There are two types of links: implicit and explicit.

Implicit linking

  1. Implicit linking occurs when an application’s code calls an exported DLL function. When the source code calling the executable is compiled or assembled, the DLL function call generates an external function reference in the object code. To resolve additional references, the application must link to the import library (.lib file) provided by the DLL’s creator.

  2. The import library contains only the code to load the DLL and implement the DLL function calls. When an external function is found in the import library, the linker is notified that the code for that function is in the DLL. To resolve external references to DLLS, the linker simply adds information to the executable telling the system where to look for THE DLL code when the process starts.

  3. When the system starts a program that contains dynamic link references, it uses information in the program’s executable to locate the desired DLL. If the system cannot locate the DLL, it terminates the process and displays a dialog to report the error. Otherwise, the system maps the DLL module into the address space of the process.

  4. If any DLL has an entry point function (for initializing and terminating code), the operating system will call this function. In the argument passed to the entry point function, there is a code specified to indicate that the DLL is being shipped to the process. If the entry point function does not return TRUE, the system terminates the process and reports an error. Finally, the system modifies the process’s executable code to provide the starting address of the DLL function.

  5. Like the rest of the program code, THE DLL code maps into the process’s address space at process startup and is loaded into memory only when needed. Therefore, the PRELOAD and LOADONCALL code attributes used by.def files to control loading in earlier versions of Windows no longer make any sense.

Explicit linking Most applications use implicit linking because it is the easiest method of linking to use. But sometimes explicit links are needed. Here are some common reasons to use explicit links:

  1. The application does not know the name of the DLL that needs to be loaded until runtime. For example, an application might need to get the name of the DLL and the name of the exported function from the configuration file.

  2. If the DLL is not found when the process starts, the operating system terminates the process using implicit links. In this same case, processes that use explicit links are not terminated and can try to recover from the error. For example, the process can notify the user of an error and let the user specify an alternative path to the DLL. If any of the DLLS linked to by a process using implicit links have a failed DllMain function, the process will also be terminated. In this case, processes that use explicit links are not terminated.

  3. Because Windows loads all DLLS at application load time, applications that implicitly link to many DLLS will be slow to start. To improve startup performance, applications can implicitly link to DLLS that are needed immediately after loading and explicitly link to other DLLS when needed.

  4. Explicit linking does not require linking an application to an import library. If a change in the DLL causes the export ordinal to change, applications that use explicit links do not need to re-link (assuming they call GetProcAddress with a function name rather than an ordinal value), whereas applications that use implicit links must re-link to the new import library.

Here are two disadvantages of explicit links to be aware of:

1. If a DLL has a DllMain entry point function, the operating system calls this function in the context of the thread calling LoadLibrary. This entry point function is not called if the DLL has been attached to the process because LoadLibrary was previously called but the FreeLibrary function was not called accordingly. If the DLL uses the DllMain function to perform initialization for each thread of the process, explicit linking causes problems because threads that exist when LoadLibrary (or AfxLoadLibrary) is called will not be initialized. Server load is high, the performance degradation, lead to fail to deal with the client’s request, may be a need to upgrade the server hardware itself, on the other hand is a program bug cause enough throughput, low performance, as well as architecture might be the problem, such as distributed processing, unable to dynamic expansion, basically, you need to look at memory, CPU, Disk usage, use the top, free, df and other commands to dynamically view the process that finds abnormal indicators.

2. If a DLL declares static scoped data as __declspec(thread), the DLL will cause a protection error when explicitly linking. When a DLL is loaded with LoadLibrary, the DLL causes a protection error every time the code references this data. (Static scoped data includes both global and local static items.) Therefore, DLL creation should avoid using thread-local storage, or DLL users should be told about potential defects (when they attempt dynamic loading).

​