EXPORTS
Introduces a section of one or more definitions that are exported functions or data. Each definition must be on a separate line.
EXPORTS definitions
The EXPORTS keyword can be on the same line as the first definition or on a preceding line. The .def file can contain one or more EXPORTS statements.
The syntax for export definitions is:
entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]
entryname is the function or variable name that you want to export. This is required. If the name you export is different from the name in the DLL, specify the export's name in the DLL with internalname. For example, if your DLL exports a function, func1() and you want it to be used as func2(), you would specify:
EXPORTS func2=func1
@ordinal lets you specify that a number, and not the function name, will go into the DLL's export table. This can help you minimize the size of your DLL. The .LIB file will contain the mapping between the ordinal and the function, which allows you to use the function name as you normally would in projects that use the DLL.
The optional NONAME keyword allows you to 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 PRIVATE prevents entryname from being placed in the import library generated by LINK. It has no effect on the export in the image also generated by LINK.
The optional keyword DATA specifies that an export is data, not code. For example, you could export a data variable as follows:
EXPORTS i DATA
When you use PRIVATE and DATA for the same export, PRIVATE must precede DATA.
There are three methods for exporting a definition, listed in recommended order of use:
-
The __declspec(dllexport) keyword in the source code
-
An EXPORTS statement in a .def file
-
An /EXPORT specification in a LINK command
All three 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.
The following is an example EXPORTS section:
EXPORTS DllCanUnloadNow @1 PRIVATE DATA DllWindowName = Name DATA DllGetClassObject @4 NONAME PRIVATE DllRegisterServer @7 DllUnregisterServer
Note that when you export a variable from a DLL with a .def file, you do not need 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.
It is possible to use the .def file to create an entry point in one DLL that serves as an alias for a function in another DLL. This can be used to "forward" or "redirect" the call to that DLL function elsewhere to where it is really implemented. As noted above, entryname[=internalname] is available to provide a public alias for a differently named internal function. This aliasing can be used to cause forwarding or redirection by introducing a prefix on internalname:
EXPORTS
FunctionAlias=OtherDLLName.RealFunction
In the above, FunctionAlias is the name exported by your DLL, which may be "decorated" for calling convention or C++ name mangling as suits your need. OtherDLLName is the implementing DLL's filename. RealFunction is the function name exported by OtherDLLName.dll. This function name may or may not be decorated depending on how the other DLL exported that symbol, but it must match the DLL's export table.
This can also be done from the command line using the /export linker option.
/export:FunctionAlias=OtherDLLName.RealFunction
References:
Jeffrey Richter. "Win32 Q & A", Microsoft Systems Journal, Sept 96, Vol. 9
- 8/14/2007
- JoelS
