DEF file format

Module definition (. def) file
The module definition (. def) file provides the linker with information about the exported, attributes, and other aspects of the linked program.
Information. The. def file is most useful when building a DLL. Because there is a linker option that can be used instead of a module definition statement, a. def file is usually not required. You can also use __declspec (dllexport) as a means to specify an export function.
You can use the/def (Specify module definition file) linker option in the linker stage to invoke a. DEF file.
If the generated. exe file is not exported, using a. def file will make the output file larger and slower to load.
Rules for module definition statements
The following syntax rules apply to all statements in a. def file. Other rules that apply to specific statements are described along with each statement.
Statements, property keywords, and user-specified identifiers are case-sensitive.
Contains spaces or semicolons (;) The long file name must be quoted (").
Use one or more spaces, tabs, or line breaks to separate statement keywords from their arguments and separate statements.   Specifies the colon of the parameter (:) or an equal sign (=) with 0 or more spaces, tabs, or line breaks on both sides.
If you use the NAME or LIBRARY statement, the statements must precede all other statements.
In. def files, SECTIONS and exports statements can occur more than once. Each statement can take multiple specifications, and each specification must be separated by one or more spaces, tabs, or line breaks. The statement keyword must appear one time before the first specification and can be repeated before each additional specification.
Many statements have equivalent LINK command-line options. For additional details, see the appropriate LINK option description.
The comments in the. def file are separated by a semicolon at the beginning of each comment line (;) Specified. Comments cannot share a row with a statement, but can occur between the specifications of a multiline statement. (SECTIONS and exports are multi-line statements.) ）
Specifies a numeric parameter on a decimal or hexadecimal basis.
If the string argument matches a reserved word, you must enclose the string argument in double quotation marks (").
DESCRIPTION "Text"
The statement writes a string to the. Rdata section. Causes the specified text to be enclosed in single or double quotation marks (' or '). To use quotation marks (single or double quotation marks) in a string, enclose the string with another type of tag.
In a module definition file, DESCRIPTION is only valid when generating a virtual device driver (VxD).
exetype:dynamic | Dev386
In a module definition file, Exetype is only valid when generating a virtual device driver (VxD). If Exetype is not specified in the module definition file when the virtual device driver is generated, static load (dev386) takes effect if the/EXETYPE linker option is not specified.
Exports
Definitions
The exports statement introduces a section that consists of one or more definitions (exported functions or data). Each definition must be on a separate line. The EXPORTS keyword can be on the same line as the first definition or on the previous line. The. def file can contain one or more exports statements.
The syntax for exporting definitions is:
Entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]
EntryName is the name of the function or variable to be exported. This is a required option. If the exported name differs from the name in the DLL, the exported name in the DLL is specified by InternalName. For example, if the DLL export function func1 (), to use it as FUNC2 (), you should specify:
Exports
Func2=func1
@ordinal allows you to specify an export table that is an ordinal rather than a function name to enter the DLL. This helps to minimize the size of the 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 a project that uses a DLL.
The optional NONAME keyword allows you to export only by ordinal and reduce the size of the exported table in the resulting DLL. However, if you want to use GetProcAddress on a DLL, you must know the ordinal because the name will not be valid.
The optional PRIVATE keyword prevents EntryName from being placed in the import library generated by LINK. It is not valid for an export in an image that is also generated by LINK.
The optional data keyword specifies that the export is in the database, not the code. For example, you can export a data variable as follows:
Exports
I DATA
When you use private and data for the same export, private must be in front of data.
There are three ways to export definitions, followed by the recommended order of use:
__declspec (dllexport) keyword in source code
Exports statements in. def files
The/EXPORT specification in the LINK command
All three of these methods can be used in the same program. LINK also creates an import library when the program that contains the export is generated, unless the. exp file is used in the build.
The following is an example of the 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 using a. def file, you do not need to specify __declspec (dllexport) on the variable. However, in any file that uses a DLL, you must still use __declspec (dllimport) on the data declaration.
LIBRARY [Library][base=address]
This statement notifies LINK to create a DLL. LINK also creates an import library, unless the. exp file is used in the build.
The library parameter specifies the name of the DLL. You can also use the/OUT linker option to specify the DLL output name.
The base=address parameter sets the base address that the operating system uses to load DLLs. This parameter overrides the default DLL location for 0x10000000. For more information about base addresses, see the/base option description.
Keep in mind that you use the/DLL linker option when building a DLL.
/heap:reserve[,commit]
HeapSize shows the same functionality as the/HEAP linker option.
NAME [Application][base=address]
This statement specifies the name of the primary output file. Another way to specify the output file name is to use the/OUT linker option, and the other way to set the base address is to use the/BASE linker option. If both methods are specified, the/out overrides the NAME.
If the build dll,name will only affect the DLL name.
SECTIONS
Definitions
The SECTIONS statement introduces a section consisting of one or more definitions (access specifiers for each section of the project output file). Each definition must be on a separate line. The SECTIONS keyword can be on the same or previous line as the first definition. The. def file can contain one or more SECTIONS statements.
The SECTIONS statement sets properties for one or more sections in an image file and can be used to override the default properties for each section type.
The format of the definitions is:
. Section_name specifier
Here,. Section_name is the section name in the program image, and specifier is one or more of the following access modifiers:
EXECUTE
READ
SHARED
WRITE
Separate the modifier names with spaces. For example:
SECTIONS
. rdata READ WRITE
SECTIONS marks the beginning of the Definitions section list. Each definition must be on a separate line. The SECTIONS keyword can be on the same or previous line as the first definition. The. def file can contain one or more SECTIONS statements. Supports the Segments keyword as a synonym for SECTIONS.
Earlier versions of Visual C + + supported:
Section [CLASS ' classname '] specifier
For compatibility reasons, the CLASS keyword is supported, but it is ignored.
Another way to specify section properties is to use the/section option.
STACKSIZE Reserve[,commit]
The statement sets the size of the stack, in bytes. Another way to set up the stack is to use the stack allocation (/stack) option. For more information about the reserve and commit parameters, see the documentation for this option.
This option is not valid for DLLs.
Stub:filename
When used to generate a module definition file for a virtual device driver (VxD), the STUB allows you to specify the Image_dos_header structure that will be used in the VxD (in WINNT. H) instead of the default header's file name.
Another way to specify filename is to use the/STUB linker option.
In a module definition file, stubs are only valid when generating a virtual device driver (VxD).
VERSION Major[.minor]
This statement notifies LINK to place a number in the header of the. exe file or DLL. The major and minor parameters are decimal numbers in the range from 0 to 65,535. The default value is version 0.0.
Another way to specify a version number is to use the version information (/version) option.
VXD filename
Allows you to specify the name of the virtual device driver (VxD). By default, the VxD gets the same name as the first object file.
Another way to specify the version of the virtual device driver is to use the/VXD linker option, and another way to name the output file is to use the/out option.
In a module definition file, a VxD is only valid when generating a virtual device driver (VXD).
Two. Explanation of the terms in MSDN
A module definition (. def) file provides the linker with information about the exported, attributes, and other aspects of the linked program. The. def file is most useful when building a DLL. Because there is a linker option that can be used instead of a module definition statement, a. def file is usually not required. You can also use __declspec (dllexport) as a means to specify an export function. You can use the/def (Specify module definition file) linker option in the linker stage to invoke a. DEF file.
If the generated. exe file is not exported, using a. def file will make the output file larger and slower to load.
Popular explanations:
In VC + +, the build DLL can not use a. def file. Only need to add __declspec (dllexport) modifier before the function definition of VC + + can be. However, there is a difference between using __declspec (dllexport) and using. def files. If the DLL is available to VC + + users, you only need to compile the DLL when it is generated. Lib is provided to the user, and it can be very easy to call your DLL. But if your DLL is for other programs such as VB, Delphi, and. NET
Users use, then there will be a little trouble. Because VC + + for __declspec (dllexport) Declaration of the function will be a name conversion, such as the following function:
__declspec (dllexport) int __stdcall iswinnt ()
will be converted to [email protected], so you must declare it in VB:
Declare Function iswinnt Lib "My.dll" Alias "[email protected]" () as Long
The number after the @ may differ depending on the parameter type. This is obviously not very convenient. So if you want to avoid this conversion, you need to use the. def file method.
Exports after the number can not be given, the system will automatically assign a number. For VB, PB, Delphi users, usually use by name to call the way, this number is not a small relationship, but for the VC program using. lib link, not by the name of the call, but according to the number of calls, so it is best to give.
Example: We use VC6.0 to make a DLL, do not use a. def file, write this in the header file
#ifndef Lib_h
#define Lib_h
extern "C" int _declspec (dllexport) Add (int x,int y);
#endif
If this is a. def file, you can
LIBRARY "Xxx_dll"
Exports
Add privat

DEF file format