EXPORTS

  • Artigo

 

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.

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[=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:

EXPORTS  
   func2=func1

Because the Visual C++ compiler uses name decoration for C++ functions, you must either use the decorated name as the entryname or 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 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``")

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