Exporting functions using .DEF file
A module-definition (.DEF) file is a text file containing one or more module statements that describe various attributes of a DLL. If you are not using the __declspec(dllexport) keyword to export the DLL's functions, then the DLL requires a .DEF file.
A minimal .DEF file must contain the following module-definition statements:
The first statement in the file must be the LIBRARY statement. This statement identifies the .DEF file as belonging to a DLL. The LIBRARY statement is followed by the name of the DLL. The linker places this name in the DLL's import library.
The EXPORTS statement lists the names and, optionally, the ordinal values of the functions exported by the DLL. You assign the function an ordinal value by following the function's name with an at sign (@) and a number. When you specify ordinal values, they must be in the range 1 through N, where N is the number of functions exported by the DLL.
Although not required, typically a .DEF file also contains a DESCRIPTION statement that describes the purpose of the DLL.
For example, a DLL that contains the code to implement a binary search tree might look like the following:
LIBRARY BTREE
DESCRIPTION "Implements a binary tree."
EXPORTS
Insert @1
Delete @2
Member @3
Min @4
If you are exporting functions in a C++ file, you will have to either place the decorated names in the .DEF file or define your exported functions with standard C linkage by using extern "C". If you need to place the decorated names in the .DEF file, you can obtain them by using the tool DUMPBIN or by using the linker switch /MAP. Note that the decorated names produced by the compiler are compiler specific. If you place the decorated names produced by the Visual C++ compiler into a .DEF file, applications that link to your DLL must also be built using the same version of Visual C++ so that the decorated names in the calling application match the exported names in the DLL's .DEF file.
When building the DLL, the linker uses the .DEF file to create an export (.EXP) file and an import library (.LIB) file. The linker then uses the export file to build the .DLL file. Executables that implicitly link to the DLL link to the import library when they are built.
Note : When porting DLL source code from Win16 to Win32, replace each instance of __export with __declspec(dllexport).
Pros and Cons of Using .DEF Files
Exporting functions in a .DEF file gives you control over what the export ordinals are. When you add additional exported functions to your DLL, you can assign them higher ordinal values (higher than any other exported function). When you do this, applications using implicit linking do not have to relink with the new import library that contains the new functions. This is very important, for example, if you are designing a third-party DLL for use by many applications. You can continue to enhance your DLL by adding additional functionality while at the same time ensuring that existing applications will continue to work properly with the new DLL.
Another advantage to using a .DEF file is that you can export functions using the NONAME attribute, which places only the ordinal in the exports table in the DLL. For DLLs with a large number of exported functions, using the NONAME attribute can reduce the size of the DLL file.
The major disadvantage of using .a DEF file is that if you are exporting functions in a C++ file, you will either have to place the decorated names in the .DEF file or define your exported functions with standard C linkage by using extern "C" to avoid the name decoration done by the compiler.
If you need to place the decorated names in the .DEF file, you can obtain them by using the tool DUMPBIN or by using the link switch /MAP. Note that the decorated names produced by the compiler are compiler specific.
To determine which method to use to export functions (a .DEF file or the __declspec(dllexport) keyword), answer the following questions:
1/ Will you be continuing to add additional exported functions?
2/ Who is using your DLL? For example, is it a third party DLL used by many executables that you cannot rebuild, or is the DLL used only by applications that you can easily rebuild?
