. Dll,. Lib,. Def and. Exp files

This section briefly introduces the. dll. Lib. Def and. Exp file types that appear during the generation of static and dynamic link libraries in Microsoft development tools (VC. The executable file on Windows platform can be an. EXE file or four. DLL files. Of course, there are some special EXE or DLL files, but they have other style extensions such as screensaver programs (. SCR), ActiveX dll used. OCX also has various extensions used by various drivers. We will not discuss. com and some script files, such as. bat. cmd, although they are still executable files.

A library contains a pile of data and code, which can be used by connected programs or other executable files. The available objects (data or functions) in the library are marked with some labels. For example, some simple symbols in the. OBJ target file. Two types of link libraries, static link libraries and dynamic link libraries are discussed here.

You can think that the static Link Library is a collection of target files (. OBJ). We just package them in half of the static Link Library. The static Link Library has a. Lib extension. The static chainfo library is not used for execution, but can be used by the chain program (link.exe) to generate an executable file. By default, all the symbol tags in the static Link Library are visible to the linker and can be used. Of course, when compiling you, you need to correspond to the header file and the static Link Library. A static Link Library does not have any relationship with the. Def or. Exp file.

One disadvantage here is that when we use a static link library to link a program to generate a program, some objects in it, such as function code, will be copied to the corresponding program. This working principle and. the working principle of the OBJ file is the same. This is not a good idea for code that can be reused in different applications: When we connect, each application will have a copy of the object used in. obj.

Dynamic link library (DLL, known as the shared object. So file in the Unix world) can help us save memory space. When we link to a DLL, no code will be copied to the target executable file, but a reference will be placed in the executable file. When an executable file is loaded and executed, the system checks the DLL used by the file and loads the DLL. With DLL, we can easily upgrade our client program without updating the executable file again.

However, when linking, we must have some information to know how to link to the DLL, such as the signature of some functions in the corresponding DLL in the header file. The linked program requires more information, such as the DLL file name and the available symbols. Such information exists in the import/export file. The suffix of the import/export database is also a. Lib. When a linker generates a. dll file, it automatically generates a file named. Lib. The export warehouse is used to distribute data to developers who use the DLL during the development stage. More specifically, they use the link. There is basically no difference between the use of the import/export Library and the use of the static Link Library. Is to use the Export program during execution

Wait for the DLL to be exported.

Okay! The problem seems to have been solved, but why do we see some. Def files everywhere?

Def file (module definition file) is used to create DLL and the corresponding export and export files. In A. Def file, you can specify the symbols to be exported by the DLL for use. Linker generates DLL and Lib based on the description of the def file. Generally, DLL users are not interested in def files (I mean DLL developers and end users ). Note the differences between it and the static Link Library. By default, the internal symbols of the DLL are invisible. We have a way to make them visible-use the exports statement in the def file. However, we still have other methods, such as using _ declspec (dllexport) in the source code of zaidll or in the linker option.

Use the/export option to export a function. In fact, _ declspec (dllexport) is widely used, and Def files are rarely used. Using the def file, you can indicate other information of the linker program rather than export actions, such as the size of the stack. However, these options are often identified in the linker command line. In fact, Def files were used in the early DLL programming of Win16. Now we basically discard it in Win32. This will happen in the future.

Wait. Do we still see some. Exp files in some places? The exp file is the export file ). In the previous discussion, we discussed how to use linker to create a DLL (and its export and export in the middle). Now, let's assume that we generate two DLL (or just executables ). However, they all need to call some functions in the Peer, and the problem arises. When we generate. DLL, we need B. LIB; but B. lib in the corresponding B. DLL is not generated before it is generated, while B. DLL generation requires. lib. For this reason, Microsoft's solution is to use the exp file or export the file. Before two DLLs are generated, you can use lib.exe (library mangager tool) to create one. lib and. exp, that is,. lib and. exp, now linker uses. lib and dll B to generate B. DLL and B. lib. When you come back to link dll a, you will have B. Lib. Here, linker needs to know what needs to be exported in A. dll. The information is cached in the. Exp file. Linker does not need the def file or/export option. It only loads information in A. Exp. A.expis the same as the contact person of a.dll's two generation processes (lib.exe and linker. Similarly, linker will not generate a. Lib again. In general, this kind of loop call will not appear in our program. Therefore, we hope that you will not use exp files in your program.