Edit

Share via

EXPORTS

  • Article

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.

EXPORTS
   definition

Remarks

The first definition can be on the same line as the EXPORTS keyword or on a subsequent line. The .DEF file can contain one or more EXPORTS statements.

The syntax for an export definition is:

entryname[=internal_name|other_module.exported_name] [@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 internal_name. For example, if your DLL exports a function func1 and you want callers to use it as func2, you would specify:

EXPORTS
   func2=func1

If the name that you export is from some other module, specify the export's name in the DLL by using other_module.exported_name. For example, if your DLL exports a function other_module.func1 and you want callers to use it as func2, you would specify:

EXPORTS
   func2=other_module.func1

If the name that you export is from another module that exports by ordinal, specify the export's ordinal in the DLL by using other_module.#ordinal. For example, if your DLL exports a function from the other module where it is ordinal 42, and you want callers to use it as func2, you would specify:

EXPORTS
   func2=other_module.#42

Because the MSVC compiler uses name decoration for C++ functions, you must either use the decorated name internal_name 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, goes 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 PRIVATE prevents 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 exported_global:

EXPORTS
   exported_global DATA

There are four ways to export a definition, listed in recommended order:

  1. The __declspec(dllexport) keyword in the source code

  2. An EXPORTS statement in a .DEF file

  3. An /EXPORT specification in a LINK command

  4. A comment directive in the source code, of the form #pragma comment(linker, "/export: definition "). The following example shows a #pragma comment directive before a function declaration, where PlainFuncName is the undecorated name, and _PlainFuncName@4 is the decorated name of the function:

    #pragma comment(linker, "/export:PlainFuncName=_PlainFuncName@4")
BOOL CALLBACK PlainFuncName( Things * lpParams)

The #pragma directive is useful if you need to export an undecorated function name, and have different exports depending on the build configuration (for example, in 32-bit or 64-bit builds).

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.

See also

Rules for Module-Definition Statements