Compiling windows DLL and Def files

Question 1:

View the output of a compiled DLL. The function name is always _ XXXX @ n and so on. extern "C" has been used and the def file has been added to the project. Search for this section in "ask experts:

 

 

In VC ++, if a DLL is generated, the. Def file is not used. You only need to add
_ Declspec (dllexport) can be modified. However, using _ declspec (dllexport) is different from using a. Def file. If your
DLL is provided to VC ++ users. You only need to provide the. Lib generated during DLL compilation to users. It can easily call your DLL. However, if your DLL is for Vb,
If you use PB or Delphi, it will cause a small amount of trouble. Because VC ++ converts the name of the function declared by _ declspec (dllexport ),
Function:

_ Declspec (dllexport) int _ stdcall iswinnt ()

It will be converted to iswinnt @ 0, so that you must declare in VB as follows:

Declare function iswinnt lib "My. dll" alias "iswinnt @ 0" () as long

The number following @ may vary depending on the parameter type. This is obviously inconvenient. If you want to avoid this conversion, you must use the. Def file method.

The number after exports can be left blank, and the system will automatically allocate a number. For VB, Pb, and Delphi users, the call method by name is usually used. This number does not matter, but for VC connected by. LibProgramFor example, it is not called by name, but by this number, so it is best to give it.

 

It seems that the def file does not play a role. Finally, the def file needs to be configured to the module definition file of the "linker" in the VC project.

 

Question 2:

After several output function definitions are added to Def (these functions have been output but are not added to the def file), some previously compiled program execution errors cannot be found.FunctionBut no error is reported in other programs. It seems that the program that reported the error does not use the Lib file during connection, but does not report the error. If the Lib file is not used, use the hint locating function, so I can always find it but may find it wrong-no wonder I heard that this library has previously experienced function debugging errors.

After adding the output function, I forgot to add the definition in def.CodeThere is no human check. The most serious problem is the later version.