There are two kinds of libraries:
One is that Lib contains the information (ingress) of the DLL file in which the function resides and the location of the function in the file, which is provided by the DLL that is loaded in the process space by the runtime, called the dynamic link library.
One is that Lib contains the function code itself, which is added directly to the program at compile time, called static link library.
There are two ways to link:
Dynamic linking uses a dynamic-link library that allows executable modules (. dll files or. exe files) to contain only the information required to locate the executable code of a DLL function at run time.
Static linking uses the static link library, which obtains all referenced functions from the static link library lib and places the library with the code in the executable file.
The differences between Lib and DLL are as follows:
(1) Lib is used at compile time, DLL is used at runtime. If you want to complete the compilation of the source code, you only need lib, if you want to make a dynamically linked program run, you only need the DLL.
(2) If there is a DLL file, then Lib is generally some index information, log the function of the DLL's entry and location, DLL is the specific content of the function, if only the Lib file, then the Lib file is statically compiled, the index and implementation are in it. Using a statically compiled Lib file, you do not need to hang the dynamic library when you run the program, the disadvantage is that the application is larger, and the flexibility of the dynamic library is lost, and the new version is released when the new application is published.
(3) In case of dynamic link, there are two files: one is lib file and one is DLL file. Lib contains the name and location of the function exported by the DLL, the DLL contains the actual functions and data, and the application uses the Lib file to link to the DLL file. In the application's executable file, it is not the called function code, but the address of the corresponding function code in the DLL, thus saving memory resources. DLL and LIB files must be released with the application or the application will produce an error. If you do not want to use the Lib file or no Lib file, you can use the WIN32 API function LoadLibrary, GetProcAddress load.
There are two files to be aware of using Lib:
(1). h header file containing class or symbol prototypes or data structures that describe the output in Lib. When the application calls Lib, it needs to include the file in the application's source file.
(2). LIB file, slightly.
There are three files to be aware of using DLLs:
(1). h header file containing the. h file that describes the output class or symbol prototype or data structure in the DLL. When an application calls a DLL, it needs to include the file in the application's source file.
(2). LIB file is a file generated by a DLL after it is compiled and successfully linked, and it is necessary to introduce the file into the application when other applications call the DLL, otherwise an error is generated. If you do not want to use the Lib file or no Lib file, you can use the WIN32 API function LoadLibrary, GetProcAddress load.
(3). dll file, the real executable, after the successful development of the application at the time of publishing, only the. exe file and the. dll file are required, and the. lib file and. h header files are not required.
Ways to use Lib:
In static Lib, a Lib file is actually a collection of any obj files, and the obj file is generated by the CPP file compilation. When compiling this static library project, there is no link error at all, and even if it is wrong, it will only be exposed in the Ext file or DLL project using this lib.
Create a new Static library type project Lib in the VC, add the Test.cpp file and the Test.h file (including the function declaration in the header file), and then compile, generate the Lib.lib file.
There are two ways to use this lib for other projects:
(1) Add the Lib.lib file in the Project->link->object/library module (query the project directory first, then query the system Lib directory), or add the command #pragma comment (lib, ") in the source code. Lib.lib ").
(2) Copy the Lib.lib into the directory where the project is located, or execute the file-generated directory, or the system Lib directory.
(3) Add the corresponding header file test.h.
Ways to use DLLs:
Using LIB in a dynamic link is not a collection of obj files, that is, there is no actual implementation, it simply provides the information needed to dynamically link to the DLL, which can be generated by the compiler when compiling a DLL project.
How to create a DLL project (slightly).
(1) Implicit link
The first method is to add the. lib file through the Project->link->object/library module (or add the directive #pragma comment (lib, "Lib.lib") to the source code), and place the. dll file in the directory where the project resides, and then add the corresponding. h header file.
#include "stdafx.h"
#include "DLLSample.h"
#pragma comment (lib, "DLLSample.lib")//You can also set a link to the library in the project properties
int main ()
{
Testdll (123); A function in the DLL, declared in DllSample.h
return (1);
}
(2) Explicit links
Requires a function pointer and WIN32 API function LoadLibrary, GetProcAddress mount, using this loading method, does not require the. lib file and the. h header file, only the. dll file is required (the. dll file is placed in the project directory).
#include
#include//using functions and some special variables
typedef void (*DLLFUNC) (int);
int main ()
{
DllFunc DllFunc;
HInstance hinstlibrary = LoadLibrary ("DLLSample.dll");
if (hinstlibrary = = NULL)
{
FreeLibrary (hinstlibrary);
}
DllFunc = (dllfunc) GetProcAddress (hinstlibrary, "Testdll");
if (DllFunc = = NULL)
{
FreeLibrary (hinstlibrary);
}
DllFunc (123);
Std::cin.get ();
FreeLibrary (hinstlibrary);
return (1);
}
The LoadLibrary function takes a name as an argument, obtains an instance of the DLL (the HINSTANCE type is the handle to the instance), and usually calls the function to see if the function return succeeds, or null if unsuccessful (the handle is not valid). This calls the function FreeLibrary frees the memory that the DLL obtains.
The GetProcAddress function uses the DLL's handle and the name of the function as a parameter, returns the corresponding function pointer, must use a strong turn, determines if the function pointer is null, and if so, invokes the function FreeLibrary releases the memory obtained by the DLL. After that, you can use a function pointer to invoke the actual function.
Finally, remember to use the FreeLibrary function to free up memory.
Note: How does the application find the DLL file?
With LoadLibrary explicit linking, you can specify the full path to the DLL file in the parameters of the function, and if you do not specify a path or implicitly link, Windows will follow the following search order to locate the DLL:
(1) directory containing EXE files
(2) Project catalogue
(3) Windows system directory
(4) Windows directory
(5) A list of directories listed in the PATH environment variable
The. h header file is required at compile time, and Lib is required at the time of the link, and the DLL is required at runtime.
Additional dependencies are. Lib is not a. dll, and if a DLL is generated, a Lib file must also be generated. If you want to complete the source code compile and link, there is a header file and Lib is enough. If you also make a dynamically connected program run, there is enough DLL. In the development and commissioning phase, of course, it is best to have.
The relationship of the. h. lib. dll is:
H file function is: Declare Function interface
DLL file function is: function executable code
When we refer to a function in an H file in our own program, how does the linker know which DLL file to call? This is what Lib files do: Tell the linker which DLL the function is calling in, and where the function executes the code in the DLL, which is why additional dependencies are required. LIB file, it acts as a bridge. If you generate a static library file, there is no DLL, only Lib, and then the function executable code part is also in the Lib file
There are two kinds of libraries with Lib suffix, one is static link library (static libary, hereinafter referred to as "still Library"), and the other is the import library (import libary, hereinafter referred to as "import library") of Dynamic Connection library (DLL, hereinafter referred to as "Dynamic Library"). A static library is a package of one or more obj files, so some people simply refer to the process of generating lib from the obj file as archive, which is merged together. For example, if you link a static library, if there is a mistake, it will find out exactly which obj is wrong, that is, static Lib is just a shell. The dynamic library usually has the corresponding import library, the convenience program statically loads the dynamic link library, otherwise you may need oneself loadlibary the DLL file, then GetProcAddress obtains the corresponding function manually. With the import library, you only need to link to the import library and follow the declaration of the header file function interface to call the function. The difference between an import library and a static library is that they are essentially different things. The static library itself contains the actual execution code, symbol table and so on, and for the import library, its actual execution code is located in the dynamic library, the import library contains only the address symbol table, etc., to ensure that the program to find some basic address information of the corresponding function.
The General Dynamic Library program has lib files and DLL files. Lib files must be connected to the application at compile time, and DLL files are not called until the run time. If there are DLL files, then the corresponding LIB file is generally some index information, specifically implemented in the DLL file. If only the Lib file, then the Lib file is statically compiled, the index and implementation are in it. A statically compiled LIB file has the advantage of not having to hang up the dynamic library when installing to the user. But there are drawbacks, that is, the application is larger, and the flexibility of the dynamic library is lost, and when the version is upgraded, a new application will be published at the same time. In the case of a dynamic library, there are two files, and one is the introduction library (. LIB) file, a DLL file that contains the name and location of the function exported by the DLL, the DLL contains the actual functions and data, the application uses the Lib file to link to the DLL file that is needed, the functions and data in the library are not copied to the executable file, Therefore, in the application's executable file, it is not the called function code, but the memory address of the function to be called in the DLL, so that when one or more applications run, the program code and the called function code are linked together, thus saving memory resources. As you can see from the instructions above, DLLs and. lib files must be released with the application or the application will produce an error.
Both the static and shared libraries are a collection of obj files, but after a static link, there is a copy of the obj that is required to execute the program, and after dynamic linking, the executor simply contains a reference to the shared library. The shared library is equivalent to an obj file that is composed of multiple obj files, and all of its code is loaded after the link, whether needed or not.
It seems that a conclusion can be drawn:
The statically linked program is larger than the storage space used by the dynamic link, because the code copy in the library is included in the execution program;
A dynamically linked program uses more space than a static link because it loads unwanted code into the run space.
For the above Knowledge 2 questions:
1) DLLs and. Lib files must be released with the application or the application will produce an error.
My answer: Lib should not need it.
2) If a dynamic library is called in a program (called by the header file, Lib+dll), the content of a function of the dynamic library is modified, but the interface is not changed, will the program calling this dynamic library recompile the connection? Do I need to recompile the connection if it is dynamically loaded via loadlibary?
My answer: You need to recompile the connection if you call through Header+lib+dll, but you don't need to recompile the connection if you use LoadLibrary.
The 2nd answer is wrong. You should not need to recompile the interface unchanged. Lib does not have to be updated
1) Save memory. The same software module, if reused in the form of source code, is compiled into different executable programs, and the binaries of these modules are repeatedly loaded into memory when the EXE is run. If you use a DLL, it is loaded only once in memory, and all processes that use the DLL share this block of memory (of course, a global variable in a DLL is copied by each process).
2) do not need to compile software system upgrade, if a software system uses a DLL, then the DLL is changed (the function name is unchanged), the system upgrade only need to replace this DLL, do not need to recompile the entire system. In fact, many of the software is upgraded in this way. For example, we often play the Star, Warcraft and other games such as the version upgrade.
3) DLL libraries can be used in a variety of programming languages, such as DLL written in C can be called in VB. This point on the DLL is not enough, so on the basis of DLL invented COM technology, better solve a series of problems
The difference and use of c++:lib and DLL