Table of contents
Visual studio generates a dll file and modifies the name of the dll file
Visual Studio under Windows can create dlls through .def files.
1. Prepare the test code
1. Determine the function that needs to be exported. The test.cpp file is defined as follows
void fun1()
{
return;
}
void fun2()
{
return;
}
int main()
{
return 0;
}
2. Add the .def file, usually under the source file. *
There is a "module definition file" under the code bar, which is our .def file
3. Write the test.def file
LIBRARY "test"
EXPORTS
fun1
fun2
After the file is added, the next step is to set some export rules.
Second, set the export dll properties
4. Right-click on our project and select "Properties". Modify the configuration
Whether the platform is 64-bit or 32-bit should be consistent with our code version. Check the code version as follows:
Set the "target file name" on the property page, and the target file name needs to be consistent with the LIBRARY "test" in our .def. At the same time, modify the following "target file extension" to .dll
If the target file name is inconsistent, the following problems may be reported. The dll file name of the output file is not set by itself.
Three, generate the dll file
5. After setting, right-click the project, generate or regenerate, and our dll file can be generated.
A brief introduction to .lib .dll .pdb
The .lib and .dll files are all files that can be directly referenced by the program. The former is a so-called library file, and the latter is a dynamic link library (Dynamic Link Library) is also a library file. The .pdb can be understood as a symbol table file (for debugging).
How to use dll files
Our dll file can be used directly, call the api LoadLibrary of windows to load the dll, call GetProcAddress to load the functions in the dll according to the header file, and finally use FreeLibrary to release.
How to use the lib file
There are generally two ways for programs to reference .lib files:
1. Dynamic link (principle)
The basic principle of this method is that the entry or address of a certain program (function) is included in the lib file, and its real machine code is in the dll file.
When the IDE is linked, the .lib file (program address) is linked to the source code. When the program is running, it searches for the dll file at the corresponding location (environment variable path, current directory, etc.) and executes the machine code in it.
Therefore, there are generally three files required for this reference method: .h, .lib, .dll, and the generated source program will be relatively small, because it only saves the function address, but this method will always fail to find xxx.dll this kind of problem.
If we still have the source code of the dll at this time, and hope that IED can debug the source code, then we need a .pdb file. The pdb file stores the symbol table of the dll. The so-called symbol table can be understood as machine code (here is the ) and the mapping between the key and the source code file, so as long as you specify the path where the source code is stored, the IDE will automatically find the source code.
It should be noted that the pdb file and the dll file are matched, that is to say, once the dll file is changed (for example, regenerated) the pdb file must be changed accordingly.
The pdb file is also relatively large, and the program will run slower because of the need to complete the mapping. This is also the difference between the release version and the debug version.
2. Static link:
This method only needs the lib file, of course the header file is also needed. In this way, there are two parts in the lib file, you can change the file suffix to rar and decompress it to see it. The first part is the key in the first method, and the second part is that the .obj file is stored in the obj folder. It is equivalent to the machine code in the dll, but this machine code is put into the program when linking. Instead of taking it in when the program is running. If we also have the source code at this time and hope that IED can debug the source code, it is easy because if the lib file is generated in NDEBUG mode (it seems not to be possible), there is a xx.pdb in the pdb file in the obj folder Things will be put into the pdb of the program by IED, so you can directly specify the location of the source code and use it.