Clarion Community Help

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
| **Navigation:**  »No topics above this level«====== Module Definition Files (.EXP Files) ====== | [[adding an ocx control to the design environment.htm|{{btn_prev_n.gif|Previous page}}]][[coming future.htm|{{btn_home_n.gif|Return to chapter overview}}]][[glossary index.htm|{{btn_next_n.gif|Next 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 files exp files .htm#module definition file syntax|Module Definition File Syntax]]

[[module definition files exp files .htm#example-module definition file|Example-Module Definition File]]

[[module definition files exp files .htm#the name statement|The NAME Statement]]

[[module definition files exp files .htm#the library statement32|The LIBRARY Statement]]

[[module definition files exp files .htm#the heap commit statement|The HEAP_COMMIT Statement]]

[[module definition files exp files .htm#the stack commit statement|The STACK_COMMIT Statement]]

[[module definition files exp files .htm#the heap reserve statement|The HEAP_RESERVE Statement]]

[[module definition files exp files .htm#the stack reserve statement|The STACK_RESERVE Statement]]

[[module definition files exp files .htm#the image base statement32|The IMAGE_BASE Statement]]

[[module definition files exp files .htm#the debug statement32|The DEBUG Statement]]

[[module definition files exp files .htm#the linenumbers statement32|The LINENUMBERS Statement]]

[[module definition files exp files .htm#the section alignment statement32|The SECTION_ALIGNMENT Statement]]

[[module definition files exp files .htm#the file  alignment statement32|The FILE_ALIGNMENT Statement]]

[[module definition files exp files .htm#the exports statement32|The EXPORTS Statement]]

[[module definition files exp files .htm#manifeststatement|The MANIFEST statement]]

[[module definition files exp files .htm#The LARGE_ADDRESS statement|The LARGE_ADDRESS statement]]

[[module definition files exp files .htm#exporting a class|Exporting a CLASS]]

[[module definition files exp files .htm#exporting a queue|Exporting a QUEUE]]

[[module definition files exp files .htm#exporting a group|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:

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

__**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.

<code>NAME [appname] [apptype]</code>

//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:

<code>WINDOWAPI</code>

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

<code>GUI</code>

Same as WINDOWAPI.

<code>CUI</code>

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:

<code>NAME wdemo WINDOWAPI</code>

__**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.

<code>LIBRARY [libraryname][initialization]</code>

//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.

<code>INITGLOBAL</code>

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

<code>INITINSTANCE</code>

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:

<code>LIBRARY myDLL INITINSTANCE</code>

__**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:

<code>HEAP_COMMIT number</code>

__**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:

<code>STACK_COMMIT number</code>

__**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:

<code>HEAP_RESERVE number</code>

__**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:

<code>STACK_RESERVE number</code>

__**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 [[tplglobalrebaseinstructions.htm|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:

<code>IMAGE_BASE address </code>

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:

<code>IMAGE_BASE 00600000h</code>

{{tipbox.jpg|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.

<code>DYNAMIC_BASE </code>

__**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|TipBox.jpg}}

For more information on **DYNAMIC_BASE** and **DEP** read the Clarion Blog entry [[https://clarionsharp.com/blog/new-application-security-features-in-clarion/|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:

<code>DEBUG</code>

__**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:

<code>LINENUMBERS</code>

__**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:

<code>SECTION_ALIGNMENT number</code>

__**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:

<code>FILE_ALIGNMENT number</code>

__**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:

<code> entryname [pwords] @number | ? [NODATA] </code>

//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:

<code>
  EXPORTS
    Func1 @?
    Func2 @?
    CharTest @?
</code>

__**The MANIFEST statement**__

<code>MANIFEST [file name] [VISTA] [WINDOWS7]</code>

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:**

<code>MANIFEST VISTA some.manifest</code>

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

<code>MANIFEST VISTA WINDOWS7</code>

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:

<code>
EXPORTS
 VMT$MYCLASS @?
 TYPE$MYCLASS @?
 FIRSTMETHOD@F7MYCLASS @?
 SECONDMETHOD@F7MYCLASS @?
</code>

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

<code>
EXPORTS
    TYPE$MYQUE  @?
    TCB$MYQUE   @?
    $MYQUE      @?
</code>

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

<code>
EXPORTS
    TYPE$MYGROUP  @?
    $MYGROUP       @?
</code>

~~NOTOC~~