The latest version of this topic can be found at EXPORTS.
Introduces a section of one or more export definitions that specify the exported names or ordinals of functions or data. Each definition must be on a separate line.
definition can be on the same line as the
EXPORTS keyword or on a subsequent line. The .DEF file can contain one or more
The syntax for an export
entryname[=internalname] [@ordinal [NONAME]] [[PRIVATE] | [DATA]]
entryname is the function or variable name that you want to export. This is required. If the name that you export differs from the name in the DLL, specify the export's name in the DLL by using
internalname. For example, if your DLL exports a function
func1 and you want callers to use it as
func2, you would specify:
Because the Visual C++ compiler uses name decoration for C++ functions, you must either use the decorated name as the
internalname, or define the exported functions by using
extern "C" in the source code. The compiler also decorates C functions that use the __stdcall calling convention with an underscore (_) prefix and a suffix composed of the at sign (@) followed by the number of bytes (in decimal) in the argument list.
To find the decorated names produced by the compiler, use the DUMPBIN tool or the linker /MAP option. The decorated names are compiler-specific. If you export the decorated names in the .DEF file, executables that link to the DLL must also be built by using the same version of the compiler. This ensures that the decorated names in the caller match the exported names in the .DEF file.
You can use @
ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don’t recommend exporting functions by ordinal unless your DLL’s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.
By using the optional
NONAME keyword, you can export by ordinal only and reduce the size of the export table in the resulting DLL. However, if you want to use GetProcAddress on the DLL, you must know the ordinal because the name will not be valid.
The optional keyword
entryname from being included in the import library generated by LINK. It does not affect the export in the image also generated by LINK.
The optional keyword
DATA specifies that an export is data, not code. This example shows how you could export a data variable named
EXPORTS exported_global DATA
There are four ways to export a definition, listed in recommended order:
The __declspec(dllexport) keyword in the source code
EXPORTSstatement in a .DEF file
An /EXPORT specification in a LINK command
A comment directive in the source code, of the form
#pragma comment(linker, "/export:``definition``")
All four methods can be used in the same program. When LINK builds a program that contains exports, it also creates an import library, unless an .EXP file is used in the build.
Here's an example of an EXPORTS section:
EXPORTS DllCanUnloadNow @1 PRIVATE DllWindowName = WindowName DATA DllGetClassObject @4 NONAME PRIVATE DllRegisterServer @7 DllUnregisterServer
When you export a variable from a DLL by using a .DEF file, you do not have to specify
__declspec(dllexport) on the variable. However, in any file that uses the DLL, you must still use
__declspec(dllimport) on the declaration of data.