User Tools

Site Tools


module_definition_files_exp_files_.htm
Navigation:  »No topics above this level«====== Module Definition Files (.EXP Files) ====== Previous pageReturn to chapter overviewNext page

A module definition file describes the name, attributes, exports, and other characteristics of a dynamic-link library for Microsoft Windows. This file is required for Windows.

A module definition file (.EXP) is generated whenever you make a new project, or a project whose target type, operating system, or run-time library has changed.

Module Definition File Syntax

Example-Module Definition File

The NAME Statement

The LIBRARY Statement

The HEAP_COMMIT Statement

The STACK_COMMIT Statement

The HEAP_RESERVE Statement

The STACK_RESERVE Statement

The IMAGE_BASE Statement

The DEBUG Statement

The LINENUMBERS Statement

The SECTION_ALIGNMENT Statement

The FILE_ALIGNMENT Statement

The EXPORTS Statement

The MANIFEST statement

The LARGE_ADDRESS statement

Exporting a CLASS

Exporting a QUEUE

Exporting a GROUP

Module Definition File Syntax

A module definition file contains one or more statements. Each statement defines an attribute of the executable file, such as its module name, the attributes of program segments, and the numbers and names of exported symbols. The statements and the attributes they define are listed below:

Statement Attribute
NAME Names the application
LIBRARY Names the dynamic-link library
HEAP_COMMIT Amount of heap committed
HEAP_RESERVE Amount of heap reserved
STACK_COMMIT Amount of stack committed
STACK_RESERVE Amount of stack reserved
IMAGE_BASE Module base memory location address
DYNAMIC_BASE Dynamic Module Base Address - ASLR (Address space layout randomization)
DEP Data Execution Prevention
DEBUG Include debug information
LINENUMBERS Include line number information
SECTION_ALIGNMENT Multiples of 4096 only
FILE_ALIGNMENT Multiples of 512 only
EXPORTS Defines exported functions and data
IMAGE_VERSION n[.m] Values of n and m set the image major and minor version fields in PE optional header respectively. n and m must be decimal format. Default values for these fields are zero (0). n and m are WORD types and have a maximum value of 65535.

The following rules govern the use of these statements:

·If you use either a NAME or a LIBRARY statement, it must precede all other statements in the module definition file.

·You can include source-level comments in the module definition file, by beginning a line with a semicolon(;). The utilities ignore each such comment line.

·Module definition keywords (such as NAME, LIBRARY, and EXPORTS) must be entered in uppercase letters.

·The EXPORTS statement must appear last.

Example Module Definition File

The following example gives module definitions for a dynamic-link library:

LIBRARY MyDLL
; Sample export file
  EXPORTS
  Func1 @1
  Var1  @2
  Func2 @3
  Func3 @4
  Func4 @5

The NAME Statement

The NAME statement identifies the file as an executable application (rather than a DLL) and optionally defines the name and application type.

NAME [appname] [apptype]

appname If appname is given, it becomes the name of the application as it is known by the operating system. If no appname is given, the name of the executable file, with the extension removed, becomes the name of the application.

apptype Used to control the program's behavior under Windows. This information is kept in the executable-file header. The apptype field may have one of the following values:

WINDOWAPI

The application uses the API provided by Windows and must be executed in the Windows environment.

GUI

Same as WINDOWAPI.

CUI

The program uses a character based user interface, like DOS.

If the NAME statement is included in the module-definition file, then the LIBRARY statement cannot appear.

If neither a NAME statement nor a LIBRARY statement appears in a module-definition file, NAME is assumed.

The following example assigns the name wdemo to the application being defined:

NAME wdemo WINDOWAPI

The LIBRARY Statement

The LIBRARY statement identifies the file as a dynamic-link library. The name of the library, and the type of library module initialization required, may also be specified.

LIBRARY [libraryname][initialization]

libraryname If libraryname is specified, it becomes the name of the library as it is known by the operating system. This name can be any valid file name. If no libraryname is given, the name of the executable file, with the extension removed, becomes the name of the library.

initialization The initialization field is optional and can have one of the two values listed below. If neither is given, then the initialization default is INITINSTANCE.

INITGLOBAL

The library-initialization routine is called only when the library module is initially loaded into memory.

INITINSTANCE

The library-initialization routine is called each time a new process gains access to the library.

If the LIBRARY statement is included in a module definition file, then the NAME statement cannot appear.

The following example assigns the name mydll to the dynamic-link module being defined, and specifies that library initialization is performed each time a new process gains access to myDLL:

LIBRARY myDLL INITINSTANCE

The HEAP_COMMIT Statement

Specifies the amount of heap committed. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the HEAP_COMMIT statement is as follows:

HEAP_COMMIT number

The STACK_COMMIT Statement

Specifies the amount of stack committed. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the STACK_COMMIT statement is as follows:

STACK_COMMIT number

The HEAP_RESERVE Statement

Specifies the amount of heap reserved. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the HEAP_RESERVE statement is as follows:

HEAP_RESERVE number

The STACK_RESERVE Statement

Specifies the amount of stack reserved. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the STACK_RESERVE statement is as follows:

STACK_RESERVE number

The IMAGE_BASE Statement

Specifies the base memory location of the module. This statement is not generated by default from the Clarion environment, but can be implemented using the Rebase template. If no IMAGE_BASE is specified in the EXP then the module is assigned the default address (normally 00400000h) and conflicts are handled automatically by the Windows loader. (Using the Clarion IDE you can add an image_base line to the EXP file in the global embed named “Before the Export List”.) The syntax for the IMAGE_BASE statement is as follows:

IMAGE_BASE address 

where address is a 32-bit address specified in decimal or hex. If hex, then the address is followed by an “h”. The address must be divisible by 64KB (65,536 or 00010000h). It must be in the range of 00400000h to 70000000h for Windows 9x. Under Windows NT the address lower limit is 00010000h.

For more information search MSDN for “Base Address” or “Rebase”.

Example:

IMAGE_BASE 00600000h

TipBox.jpg

It's best to supply the address in hex since all documentation on the OS will show a hex address and it's easy to tell you've got a good address because it always ends with 4 zeros.

The FIXED Statement

Strips the relocation table from the binary so it must be loaded at its Image Base. FIXED had been used in EXE's to reduce size about 4%. FIXED can NOT be used with DYNAMIC_BASE because under ASLR the EXE is rebased at load time.

The DYNAMIC_BASE Statement

Added in 11.13622 on Sept 4, 2020. FEATURE: Add support for ASLR (Address space layout randomization). You can set if the linker enables dynamic base addresses or not, by default this is ON. Only matters in EXE builds. At runtime the DLLs use ASLR if the EXE has the Flag.

This modifies the header of an executable to indicate whether the application should be randomly rebased at load time by the OS. ASLR is transparent to your application. With ASLR, the only difference is the OS will rebase the executable unconditionally, instead of doing it only when a base image conflict exists. ASLR is supported only on Windows Vista and later operating systems, it is ignored on older OS versions.

DYNAMIC_BASE 

The DEP Statement

Added in 11.13622 on Sept 4, 2020. FEATURE: Add support for DEP (Data Execution Prevention). You can set if the linker enables data execution prevention or not, by default this is ON. Only matters in EXE builds. At runtime the DLLs use DEP if the EXE has the Flag. The purpose of DEP is to prevent attackers from being able to execute data as if it were code. This stops an attack that tries to execute code from the stack, heap, and other non-code memory areas. DEP prevents malware from writing code into data pages then executing it.

TipBox.jpg

For more information on DYNAMIC_BASE and DEP read the Clarion Blog entry New Application Security Features. The Project Configuration tab has new check boxes for these settings.

The DEBUG Statement

Specifies the SoftVelocity debug information is included. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the DEBUG statement is as follows:

DEBUG

The LINENUMBERS Statement

Specifies that line number information in CodeView format is included. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax for the LINENUMBERS statement is as follows:

LINENUMBERS

The SECTION_ALIGNMENT Statement

Specifies the section alignment must be in multiples of 4096. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax is as follows:

SECTION_ALIGNMENT number

The FILE _ALIGNMENT Statement

Specifies the file alignment must be in multiples of 512. This statement is not generated from the Clarion environment, but may be specified by manually editing the .EXP file and running the linker standalone. The syntax is as follows:

FILE_ALIGNMENT number

The EXPORTS Statement

The EXPORTS statement defines the names and attributes of the functions exported to other modules, and of the functions that run with I/O privilege. The term “export” refers to the process of making a function available to other run-time modules. By default, functions are hidden from other modules at run time.

EXPORTS

exportdefinitions

The EXPORTS keyword marks the beginning of the export definitions. It may be followed by up to 3072 export definitions, each on a separate line. You should give an export definition for each dynamic-link routine that you want to make available to other modules. The syntax for an export definition is as follows:

 entryname [pwords] @number | ? [NODATA] 

entryname Defines the function name as it is known to other modules.

pwords Specifies the total size of the function's parameters, as measured in words (the total number of bytes divided by two). This field is required only if the function executes with I/O privilege. When a function with I/O privilege is called, OS/2 consults the pwords field to determine how many words to copy from the caller's stack to the I/O-privileged function's stack.

@number | ? Defines the function's ordinal position within the module-definition table. The @ may be followed by the position number of the function, or it may be followed by a question mark ( ? ) if the position is unknown. The numbers must be in sequence.

NODATA Provided for use by real-mode Windows (optional).

The EXPORTS statement is meaningful for functions within dynamic link libraries, functions which execute with I/O privilege, and call back functions in Windows programs.

For example:

  EXPORTS
    Func1 @?
    Func2 @?
    CharTest @?

The MANIFEST statement

MANIFEST [file name] [VISTA] [WINDOWS7]

This directive instructs the linker to add specified manifest file name to the executable. If the manifest file name is omitted, the linker adds a default manifest. If both the project file and the EXP file contain directives to link the manifest file, the one specified in the project file will be used.

If the MANIFEST directive has a file name parameter, the optional VISTA and/or WINDOWS7 parameters are ignored and the linker uses the manifest from the file (file name) parameter. If the file name file does not exist, an error is reported.

If the MANIFEST directive has no file name parameter, the linker adds the default manifest to the executable. If neither VISTA nor WINDOWS7 parameters are present, the linker adds default manifest compatible with Windows Vista.

If either or both of VISTA and WINDOWS7 parameters are present, the linker adds the manifest with the new compatibility section introduced in Windows7. If the MANIFEST directive has just the VISTA parameter, the manifest includes the record indicating that the application supports Windows Vista. If the MANIFEST directive has the WINDOWS7 parameter, the manifest includes the record indicating that the application supports Windows7.

Examples:

MANIFEST VISTA some.manifest

The manifest is taken from the some.manifest file; the VISTA parameter is ignored

MANIFEST VISTA WINDOWS7

The linker adds to the executable the default manifest compatible with Windows7 which includes records indicating application compatibility with both Windows Vista and Windows7

MANIFEST

The linker adds the default XP/Vista-compatible manifest

The LARGE_ADDRESS statement

LARGE_ADDRESS

Alternatively, you can add the following to the LNK file:

/LARGE_ADDRESS

With either option set above, the linker adds the IMAGE_FILE_LARGE_ADDRESS_AWARE flag to the PE header. If this flag is not set, the 32-bit application receives 2 GB virtual address space.

With NT architecture, every 32 bit process runs in the 4GB virtual address space, but the amount of the virtual memory available for process data and code is dependent on Windows characteristics and settings in the process main executable's PE header.

WOW64 enables 32-bit applications to take advantage of the 64-bit kernel. Therefore, 32-bit applications can use a larger number of kernel handles and window handles. However, 32-bit applications may not be able to create as many threads under WOW64 as they can on x86. On some processors, there is less virtual address space available, and each thread contains a 64-bit stack (usually 512K). On the x64 processor, each 32-bit application receives 4 GB virtual address space in the WOW64 environment, if the application has the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header. If this flag is not set, the 32-bit application receives 2 GB virtual address space.

Exporting a CLASS

Exporting CLASS declarations requires a special form of export definition.

You must create two export definitions for the CLASS itself. The first begins with VMT$ followed by the name of the CLASS as the entryname. The second begins with TYPE$ followed by the name of the CLASS as the entryname. These are followed by an export definition for each method in the CLASS to export whose pwords must begin with the name of the CLASS as the first parameter.

For example:

EXPORTS
 VMT$MYCLASS @?
 TYPE$MYCLASS @?
 FIRSTMETHOD@F7MYCLASS @?
 SECONDMETHOD@F7MYCLASS @?

Exporting a QUEUE

Exporting QUEUE declarations requires a special form of export definition. QUEUE's with a TYPE declaratrion are NOT exported.

You must create three export definitions for the QUEUE itself. The first begins with TYPE$ followed by the name of the QUEUE as the entryname. The second begins with TCB$ followed by the name of the QUEUE as the entryname. These are followed by an export definition of the QUEUE with a dollar sign prefixing the entryname.

For example:

EXPORTS
    TYPE$MYQUE  @?
    TCB$MYQUE   @?
    $MYQUE      @?

Exporting a GROUP

Exporting GROUP declarations requires a special form of export definition. GROUP's with a TYPE declaratrion are NOT exported.

You must create two export definitions for the GROUP itself. The first begins with TYPE$ followed by the name of the GROUP as the entryname. This are followed by an export definition of the GROUP with a dollar sign prefixing the entryname.

For example:

EXPORTS
    TYPE$MYGROUP  @?
    $MYGROUP       @?
module_definition_files_exp_files_.htm.txt · Last modified: 2021/05/16 02:11 by carlbarnes