Differences and links between lib and dll files

What is the relationship between lib and dll (19:44:37)
(1) lib is required during compilation and dll is required during runtime.
If you need to complete source code compilation, it is enough to have lib.
If dynamic connection is also enabled, dll is enough.
In the development and debugging stages, it is best to have both.
(2) common dynamic library programs include lib files and dll files. The lib file must be connected to the application during the compilation period, and the dll file will be called only during the runtime. If there is a dll file, the corresponding lib file is generally some index information, the specific implementation is in the dll file. If only the lib file is available, the lib file is statically compiled and the indexes and implementations are all included. The advantage of static compiling lib files is that dynamic libraries are no longer needed during installation. However, there are also some disadvantages, that is, the application is relatively large and the flexibility of the dynamic library is lost. During version upgrade, new applications must be released at the same time.
(3) In the case of a dynamic library, there are two files, one being imported into the database. LIB) file. One is a DLL file. The imported file contains the name and location of the function exported by the DLL. The DLL contains the actual function and data, the application uses the LIB file to link to the required DLL file. The functions and data in the library are not copied to the executable file. Therefore, in the executable file of the application, stores not the called function code, but the memory address of the function to be called in the DLL, in this way, when one or more applications are running, the program code is linked to the called function code, thus saving memory resources. From the above description, we can see that the DLL and. LIB files must be released along with the application, otherwise the application will produce errors.
1. Three types of files must be noted during development and use of dll.
1. dll header file
It refers to the. h file indicating the output class or symbol prototype or data structure in dll. When other applications call the dll, the file must be included in the application's source file.
2. Import dll files
It is the file generated after the dll is compiled and linked. The main function is to introduce the file into the application when other applications call the dll. Otherwise, dll cannot be introduced.
3. dll file (. dll)
It is the real executable file when the application calls the dll runtime. After the dll application is compiled and linked, the. dll file exists. Only the. exe file and. dll file are available when the application program is running successfully. The. lib file and the dll header file are not required.
A dynamic link library (DLL) is an executable file used as a shared function library. Dynamic links provide a way for a process to call a function that does not belong to its executable code. The executable code of a function is located in a DLL, which contains one or more functions that have been compiled, linked, and stored separately from the processes that use them. DLL also helps to share data and resources. Multiple applications can simultaneously access the content of a single DLL copy in the memory.
Dynamic Links and static links are different in that dynamic links allow executable module. dll files or. exe files to only contain information required to locate the executable code of DLL functions during runtime. In a static link, the linker obtains all referenced functions from the static Link Library and puts the library together with the code into the executable file.
Using Dynamic Links instead of static links has several advantages. DLL saves memory, reduces swap operations, saves disk space, makes it easier to upgrade, provides after-sales support, and extends the MFC Library Class mechanism to support multi-language programs, and make it easy to create international versions.
The biggest difference between lib and dll files is in calling.
Dll can be static
Lib and DLL
From this chapter, my content will be specific to the windows platform. In fact, this article can also be seen as a summary of my development experience in windows, because I decided to switch to unix later.
The previous chapter describes compilation and link. It is very simple and should be put together in this chapter. Many single-speaking C ++ books are too academic. There is almost no reference to how to combine hundreds of source files in a real working environment. I guided the reader to step by step to see what is going on with lib and DLL.
The simplest C ++ program requires only one source file, which contains the following statements:
Int main () {return 0 ;}
Naturally, this program does not do anything.
When the program needs to do something, we will add more and more statements to the source file. For example, we will start to add code to the main function:
# Include <stdio. h>
Int main ()
{
Printf ("Hello World! \ N ");
Return 0;
}
Due to the limitation of human intelligence, when a function contains too many statements, it is not easy to understand. At this time, subfunctions are required:
# Include <stdio. h>
Void ShowHello ()
{
Printf ("Hello World! \ N ");
}
Int main ()
{
ShowHello ();
Return 0;
}
In the same way, a source file contains too many functions, which is also hard to understand. People start to split multiple source files.
// Main. cpp
Void ShowHello (); // [1]
Int main ()
{
ShowHello ();
Return 0;
}
// Hello. cpp
# Include <stdio. h>
Void ShowHello ()
{
Printf ("Hello World! \ N ");
}
Add these two files to a VC project. They will be compiled separately and finally linked together. In the output window of the VC compiler, you can see the following information:
------------------ Configuration: hello-Win32 Debug --------------------
Compiling...
Main. cpp
Hello. cpp
Linking...
Hello.exe-0 error (s), 0 warning (s)
This shows their compilation link process.
Next, even if you do not know, you should guess that when there are too many source files in a project, it is hard to understand, so people think of a method: compile a part of the source file into a library file, that is, a lib file. When you want to use the function, you only need to link the lib file, instead of ignoring the original source file.
Create a static library project in VC, add the hello. cpp file, compile it, and generate the lib file. Assume the file name is hello. lib.
There are two ways to use this lib for other projects:
1. Add hello. lib to the project option-> link-> Object/Library Module.
2. Add a line of command to the source code.
# Pragma comment (lib, "hello. lib ")
Note that this is not part of the C ++ language, but a pre-processing instruction of the compiler, used to notify the compiler that a link to hello. lib is required.
You can use either of the following methods based on your interests.
This lib file format can be briefly introduced. It is actually a collection of any obj files. The obj file is compiled and generated by the cpp file. In this example, the lib file only contains one obj file. If multiple cpp files exist, multiple obj files are compiled and generated, the generated lib file contains multiple obj files. Note that this is only a set and does not involve link. Therefore, you will not encounter a link error when compiling such a static library project. Even if there is a mistake, the error will only be exposed in the EXE or DLL project using this lib.
There is only so much content about static lib, which is really simple. Now we will introduce another type of lib, which is not a collection of obj files, that is, there is no actual implementation in it, it only provides the information required to dynamically link to the DLL. This lib can be generated by the compiler when compiling a DLL project. When DLL is involved, the problem becomes complicated. I don't expect to clarify the principle of DLL in this article. This is not the goal of this article. I will introduce the operation layer.
To put it simply, there are two differences between a DLL project and an EXE project:
1. the EXE entry function is main or WinMain, And the DLL entry function is DllMain.
2. The entry function of EXE indicates the start of a processing process. After the function exits, the process is completed. The entry function of DLL is just a pass for the system, when the DLL is loaded, it passes by once. When the DLL is uninstalled, it passes by [2]. You can perform process processing in the DLL entry function, but this is usually not the purpose of the DLL, DLL is used to export functions for other DLL or EXE. You can understand the relationship between DLL and EXE as the relationship between main. cpp and hello. cpp. The implementation methods are different.
First, let's look at how to write a DLL and how to export the function. First, you should try to use VC to create a new dynamic link library project. If you do not select an empty project when creating the project, in this way, you can get an example to start working on the basis of this example.
Let's take a look at the header file in the example you created with a statement similar to this:
# Ifdef DLL_EXPORTS
# Define DLL_API _ declspec (dllexport)
# Else
# Define DLL_API _ declspec (dllimport)
# Endif
This is all about function export and use of export functions. Your DLL project has defined a macro DLL_EXPORTS in the Project Settings, so your function declaration only needs to add the DLL_API to export it, And the DLL user does not define this macro, so when it contains this header file, it regards your function as imported. By imitating this example, you can write a series of functions marked as exported.
Another way to export a function is to use the DEF file and DEF file, which only limits the function name. Here, we will introduce the second [4] Method of Using DLL: Display loading. Using the LoadLibrary and GetProcAddress functions of Windows API, we can implement [5]. here, the GetProcAddress parameter requires a function name in the string format. If the DEF file is not used in the DLL project, you may need to use a very strange function name, for example :? FnDll @ YAHXZ) can be called correctly. This is because the function name is reencoded by the function overload mechanism in C ++. If the DEF file is used, you can explicitly specify the function name before encoding.

With this knowledge, you can start to write some simple DLL applications, but I am sure that you will encounter a crash, and the previous non-DLL version is no problem. If you use DLL through explicit loading, it may be caused by inconsistent call conventions, resulting in a crash. The so-called call convention is to add _ stdcall _ cdecl and so on before the function declaration, note that some macros, such as WINAPI, will be defined as one of these qualifiers. It doesn't matter if you don't understand them, but remember to be consistent, that is, the Declaration is consistent with the definition, this is not a problem when using implicit loading, but it is possible that inconsistency may occur because the header file is not used for loading.
The call convention is not what I really want to talk about, although it is a possibility. I want to talk about the issue of memory allocation and release. See the following code:
Void foo (string & str)
{
Str = "hello ";
}
Int main ()
{
String str;
Foo (str );
Printf ("% s \ n", str. c_str ());
Return 0;
}
When the function foo and main are in the same project, or foo is in a static library, there is no problem, but if foo is a DLL export function, do not write it like this, it may cause a crash [6]. The cause of the crash is that "one module is allocated and another module is released". DLL and EXE belong to two modules. In this example, the assignment operation in foo leads to memory allocation, however, after the return statement in main, the string object structure will cause memory release.
I don't want to mention all such situations. I just ask you to consider the issue of memory allocation and release when designing the DLL interface. Please follow the principle of who allocates and who releases the memory.
If you do not know how to design it, copy the Microsoft API, which is our common DLL interface, for example:
CreateDC
ReleaseDC
In pairs, one function is allocated with memory, and the other function is used to release the memory.
Back to the example where we may crash, how can we avoid it by modifying it?
This can be done as an exercise for readers. This exercise may take a long time. If you do a good job, you will be ready to work. I have seen at least two programmers with more than five years of experience make such a mistake.

Note [1]: for the purpose of illustration, I will use the direct declaration method here. In actual engineering, the header file should be used.
Note [2]: There are also threads to create and destroy will also pass the DLL entry, but this is of little significance to the novice.
Note [3]: the format of the DEF file is very simple. For the example of the DEF file, you can see it by creating an atl com project.
Note [4]: the first method is similar to using a static library, including header files and linked library files. Then, like using a common function, it is called implicit loading.
Note [5]: For details about the call method, refer to MSDN.
Note [6]: the possible reason is that if both projects are set to dynamically connect to the Runtime Library, the allocation and release are all performed in the DLL of the Runtime Library, in this case, no crash will occur.

 

 

 

Lib file. Dll file generation: Set)

Project-> property-> Configuration property-> configuration type change to static library (. lib) or other.

This article is from the "computer" blog, please be sure to keep this source http://smallstrong.blog.51cto.com/5714537/1285917