digitalmars.com                        
Last update Sun Mar 4 11:58:07 2018

Module Definition Files

optlink uses a module definition file (.def file) to provide additional input for its operation when generating a segmented .exe or .dll output file. The .def file usually is omitted to generate a DOS .exe file. The .def file describes the essential characteristics of an application or library for Win16 or Win32. It also assigns segment sequences, function orders for encapsulated functions, and so on, even in conventional DOS .exe files. Module definition files can also be used to create import libraries using implib.

For information on:

Directive overview

Module definition file directives are:
APPLOADER
Used with self-loading FORTRAN applications (16-bit only)
CODE
Sets default attributes for code segments
CODECLASSES
Specifies additional class names to be treated as code segments
DATA
Sets default attributes for data segments
DESCRIPTION
Specifies one-line description of module
EXETYPE
Identifies target operating system
EXPORTS
Establishes exported functions
FIXDS
Eliminates the need for EXPORTS (Win16 only)
FUNCTIONS
Orders COMDAT records
HEAPSIZE
Establishes local-heap size in bytes
IMPORTS
Establishes imported functions
INCLUDE
Specifies the point at which another file is inserted into .def file
LIBRARY
Names dynamic link library; does not create an application
LONGNAMES
Indicates that module is HPFS-aware (16-bit only)
NAME
Assigns name to an application; does not create library
NEWFILES
Indicates that module is HPFS-aware (16-bit only)
OBJECTS
Same as SEGMENTS
OLD
Preserves export information from previous library version (16-bit only)
PROTMODE
Prevents module from running in real mode (16-bit only)
RC
During linking, copies .res file into .exe during linking
REALMODE
Relaxes PROTMODE restrictions (16-bit only)
SECTIONS
Same as SEGMENTS
SEGMENTS
Sets attributes for specific segments
STACKSIZE
Establishes local stack size in bytes
STUB
Adds DOS stub to generated file, usually to terminate program
SUBSYSTEM
Sets which subsystem to use
VERSION
Equivalent to /VERSION switch

Using Definition File Directives

Only one of the directives NAME or LIBRARY can appear in a single definition file. If neither directive appears, NAME is the default, and the module is treated as an application.

Enter comments in the definition file by prefixing them with a ';'. The comment extends to the end of the line on which it appears. Use either the single-or the double-quote character, especially if the symbol matches any reserved word, regardless of case.

Except for the restriction cited above, format of the file is essentially free. Except for their actions in terminating a comment, new line characters are treated simply as white space, having no syntactic significance.

APPLOADER (16-bit only)

This optional directive tells OPTLINK the name of an external symbol that is defined in a loader module and, by prefixing it with "LOADER_," is treated as the identifying portion of the loader code segment name.
SYNTAX APPLOADER 'symbol'
EXAMPLE APPLOADER 'START'
COMMENTS The example specifies that LOADER_START is the name of the code segment in the loader module at which execution is to begin. This keyword supports self-loading FORTRAN applications.

CODE

This directive establishes the default attributes for all code segments within the application or library being linked. You must use an attribute from the following list, and only one attribute for each field may appear. Order of appearance is not significant. Fields marked with "*" have no effect on protected-mode code segments; they apply only to real-mode modules.

Code Attributes
Field Keywords
load LOADONCALL (default), PRELOAD
executeonly EXECUTEREAD (default), EXECUTEONLY
iopl NOIOPL (default), IOPL
conforming NONCONFORMING (default), CONFORMING
shared* NONSHARED (default), SHARED
movable* FIXED (default), MOVABLE
discard* NONDISCARDABLE (default), DISCARDABLE

Meanings of the keywords for each of these fields follow. The load field determines when a code segment is loaded:

Table 11-3 Field keywords
Keyword Meaning
PRELOAD Automatically loads when the program begins.
LOADONCALL Is not be loaded until it is accessed. If no attribute is specified, this is the default condition.

The executeonly field determines whether a code segment can be read as well as executed:

Table 11-4 Execution field keywords
Keyword Meaning
EXECUTEONLY Executes only; valid only in protected mode. Equivalent to EXECUTE.
EXECUTEREAD Reads and executes. If no attribute is specified, this is the default condition. Equivalent to READ.

The iopl field determines whether a code segment has I/O privilege:

Table 11-5 iopl field keywords
Keyword Meaning
IOPL Has I/O privilege and can access hardware directly; enforced only in protected mode.
NOIOPL Does not have I/O privilege; hardware access is made only through the operating system. If no attribute is specified for the field, this is the default condition.

The conforming field specifies the privilege level for the process; it is meaningful only for device drivers and system-level procedures. A conforming segment is called from either Ring 2 or Ring 3, and executes at the caller's privilege level. Keywords for this field are:

Table 11-6 Conforming field keywords
Keyword Meaning
CONFORMING Is conforming. This attribute is used only in protected mode.
NONCONFORMING Is not conforming. If no attribute is specified for the field, this is the default condition.

The shared field, ignored by protected mode but used by real-mode modules, determines whether a code segment can be shared by all instances of the program. Keywords for this field are:

Table 11-7 Shared field keywords
Keyword Meaning
SHARED Can be shared.
NONSHARED Cannot be shared. If no attribute is specified, this is the default condition.

The movable field, ignored by protected mode but used by real-mode modules, determines whether a code segment can be moved around in memory. Keywords for this field are:

Table 11-8 Movable field keywords
Keyword Meaning
MOVABLE May be moved during operation.
FIXED May not be moved during operation. If no attribute is specified, this is the default condition.

The discard field, ignored by protected mode but used by real-mode modules, determines whether a code segment may be discarded from memory when not currently in use. Keywords for this field are:

Table 11-9 Discard field keywords
Keyword Meaning
DISCARDABLE Can be discarded.
NONDISCARDABLE Cannot be discarded. If no attribute is specified, this is the default condition.

SYNTAX CODE [attribute ...]
EXAMPLE CODE PRELOAD EXECUTEONLY
COMMENTS The example sets default attributes of PRELOAD and EXECUTEONLY for all code segments. These defaults may be overridden by means of the SEGMENTS directives. Note that some attributes imply other attributes:A DISCARDABLE segment is also MOVABLE, whether so specified or not. Similarly, a FIXED segment is NONDISCARDABLE, whether or not so specified. In case of conflicts, the last specified attribute (together with all of its implications) will be used. Thus a directive such as "CODE FIXED DISCARDABLE" results in attributes of "MOVABLE DISCARDABLE". If this is not your intention, one or the other of the attributes must be removed.

The CODE directive should precede any SEGMENTS direc-tives in the definition file that refer to code segments; it will have no effect on any code segment declarations which precede it in the file.

CODECLASSES

By default OPTLINK assumes that segments with a class name ending in CODE are code segments. This directive is used to specify additional class names to be treated as "CODE".
SYNTAX CODECLASSES [classname ...]
EXAMPLE CODECLASSES TEXT
COMMENTS The example specifies that class name "TEXT" identifies a code segment, in addition to the defaults.

DATA

This directive establishes the default attributes for all data segments within the application or library being linked. Each attribute must be taken from the following list, and only one attribute for each field may appear. Order of appearance is not significant. Fields marked with "*" have no effect on protected mode code segments; they apply only to real-mode modules.
Table 11-10 Data keywords
Field Keywords
load LOADONCALL (default), PRELOAD
readonly READWRITE (default; equivalent to READ WRITE), READONLY
instance MULTIPLE (default for application), SINGLE (default for DLL), NONE
iopl NOIOPL (default), IOPL
shared NONSHARED (default), SHARED
movable* FIXED (default), MOVABLE
discard* NONDISCARDABLE (default), DISCARDABLE
Meanings of the keywords for each of these fields follow. The load field determines when a data segment will be loaded:
Table 11-11 Data keyword explanations
Keyword Meaning
PRELOAD The segment is automatically loaded when the program begins. In real-mode, data should be PRELOADed.
LOADONCALL The segment will not be loaded until it is accessed. If no attribute is specified for the field, this will be the default condition.
The readonly field determines access rights to a data segment. Keywords for this field are:
Table 11-12 readonly field keywords
Keyword Meaning
READONLY The segment can only be read from. This attribute is valid only in protected mode.
READWRITE The segment can be both read from, and written into. If no attribute is specified for the field, this will be the default condition.
The instance field determines creation of automatic data segments, and the number that will be created. Keywords for this field are:
Table 11-13 Instance field keywords
Keyword Meaning
NONE No automatic data segment will be created.
SINGLE A single automatic data segment will be created. If no attribute is specified for the field, this will be the default condition for dynamic link library modules. The shared attribute is forced to SHARED when this keyword is used.
MULTIPLE Separate automatic data segments will be created for each instance of the module. If no attribute is specified for the field, this will be the default condition for application modules. The shared attribute is forced to NONSHARED when this keyword is used.
The iopl field determines whether a data segment can be accessed by code that does not have I/O privilege. Keywords for this field are:
Table 11-14 iopl field keywords
Keyword Meaning
IOPL Access to the data segment is permitted only from code segments which have IOPL set.
NOIOPL Access to the data segment is permitted from any code segment.
The shared field, ignored by protected mode if the segment has the READONLY attribute but used by real-mode modules, determines whether a data segment can be shared by all instances of the program. Keywords for this field are:
Table 11-15 Shared field keywords
Keyword Meaning
SHARED One copy of the data segment will be loaded, and shared by all instances of the program. The instance attribute is forced to SINGLE when this keyword is used.
NONSHARED The segment cannot be shared, and a separate copy will be loaded for each instance of the program. If no attribute is specified for the field, this will be the default condition. The instance attribute is forced to MULTIPLE when this keyword is used
The movable field, ignored by protected mode but used by real-mode modules, determines whether a data segment can be moved around in memory. Keywords for this field are:
Table 11-16 Movable field keywords
Keyword Meaning
MOVABLE The segment may be moved during operation.
FIXED The segment may not be moved during operation. If no attribute is specified for the field, this will be the default condition.
The discard field, ignored by protected mode but used by real-mode modules, determines whether a data segment may be discarded from memory when not currently in use. Keywords for this field are:
Table 11-17 Discard field keywords
Keyword Meaning
DISCARDABLE The segment can be discarded as needed.
NONDISCARDABLE The segment cannot be discarded. If no attribute is specified for the field, this will be the default condition.
SYNTAX DATA [attribute ...]
EXAMPLE DATA PRELOAD
COMMENTS The example sets the default attribute for all data segments to PRELOAD. As with the CODE directive attributes, it is possible to declare contradictions and in such cases the last declared attribute takes effect, canceling earlier ones. The fields which interact with each other are the instance and shared fields.

The DATA directive should precede any SEGMENTS directives in the definition file that refer to data segments; it will have no effect on any data segment declarations which precede it in the file.

DESCRIPTION

This directive inserts its associated text into the application or library being linked.
SYNTAX DESCRIPTION 'text'
EXAMPLE DESCRIPTION 'Copyright 2011 by Digital Mars Corp.'
COMMENTS The example causes the copyright notice to be embedded into the application or library being linked. Maximum length of the text is 254 characters. This directive differs from a comment line in that comments are not added to the output module.

EXETYPE

This optional directive tells OPTLINK the operating system under which the executable file is to run. The EXETYPE keyword must be followed by one of five operating system keywords.
SYNTAX EXETYPE [OS2|WINDOWS[n.nn]|DOS4|UNKNOWN|DOS|NT]
EXAMPLE EXETYPE WINDOWS 3.00
COMMENTS The example specifies that the current executable file is to run under Windows version 3.00. If no EXETYPE directive appears in the definition file or if Windows appears without a specified minimum version, Windows version 3.10 is assumed.

This directive sets bits in the .exe header which are checked by the operating system loader to verify that the program being loaded was intended to be run under that system.

The DOS keyword selects "normal" MS-DOS EXE file format, and is required if using a definition file to create such an executable. One reason for doing so would be to take advantage of the COMDAT-record capabilities to assign functions to specific segments via the FUNCTIONS directive. Another is to specify segment order with SEGMENTS. The only definition file directives that make sense for use with "EXETYPE DOS" are INCLUDE, SEGMENTS, FUNCTIONS, STACKSIZE, and EXETYPE itself.

The DOS4 and UNKNOWN keywords are recognized but are not supported.

Use NT for Win32 executables and DLLs. This includes win32s, Windows NT, Windows 95, Windows 98, Windows 2000, Windows ME and Windows XP.

EXPORTS

By default, functions within one executable file (including Dynamic Link Libraries, DLL's, which are bound at run time) are hidden at run time from all other executable files. This directive makes specified functions available to other executable files at run time. It is also used to define names and attributes for functions that run with I/O privilege. Note that the FIXDS directive may be used to reduce the need for EXPORTS.

Each export definition begins with the extname, which is the name of the function being defined, as it is known outside its own executable file. This may be followed by the "=" symbol and the intname, the name as it appears inside the executable file. If no intname is given, it is assumed to be the same as the extname.

If the function may be referenced by name or by ordinal position within the executable file's entry table, the "@" symbol followed by numb, the ordinal position number, should appear next. If the name is to remain resident at all times even though numb is given, the keyword RESIDENTNAME should follow. If the symbol can only be referenced by ordinal number, the keyword NONAME should follow. Use of ordinals and NONAME provide the smallest executable files and fastest access.

The remaining two fields apply to functions with I/O privilege. For protected mode, parms specifies the total number of words occupied by the function's parameters. For real-mode Windows, the keyword NODATA may appear.

SYNTAX EXPORTS
extname[=intname] [@numb[RESIDENTNAME|NONAME]][parms][NODATA]
...
EXAMPLE EXPORTS
CharInput 6
GetString = StringIn
To export a symbol starting with an "@", enclose the symbol in quotes.
COMMENTS The example defines two functions within the current executable file as being available to other executable files:CharInput, defined elsewhere as having I/O privilege, uses 6 words of parameter information; GetString is defined within the executable file as StringIn. See also the discussion of the FIXDS directive for an alternative method of exporting functions under Windows, but not for OS/2.

FIXDS (Win16 only)

This directive, which is useful only for Windows applications, eliminates the need for the EXPORTS directive. It cannot be used with dynamic link libraries, or for OS/2 executable files.
SYNTAX FIXDS
EXAMPLE FIXDS
COMMENTS When this directive is used, the entire EXPORTS section becomes superfluous. So does every call to MakeProcInstance() or FreeProcInstance() in the executable file. Where the return value from MakeProcInstance() was used (such as a DialogBox() call), just use the function name instead.
FIXDS also gives one capability that isn't ordinarily available: your Windows application can export functions to be called from a dynamic link library. You can do this by listing, in the EXPORTS section, the functions to be made available to the .dll. (This is the only case requiring an EXPORTS section, and only the functions to be made available to .dll's should be listed.) Then run OPTIMP on this .def file to produce a .lib that can be linked with the .dll's.

FUNCTIONS

This directive is used to order COMDAT records and optionally assign them to specific segments.
SYNTAX FUNCTIONS [:segmentname]
functionnames
EXAMPLE FUNCTIONS
Function1
Function5
Function2
COMMENTS The example resequences three functions to appear in the order in which they are named. All functions named in this directive must be contained in COMDAT records, which may not be available from all language processors.

HEAPSIZE

This directive sets the size of the executable file's local heap, in bytes, and thus affects the size of the automatic data segment, if any.
SYNTAX HEAPSIZE n[,commit] or HEAPSIZE MAXVAL
EXAMPLE HEAPSIZE 2000
COMMENTS The example establishes size of the local heap at 2000 bytes. n is the total heap space to reserve; it must be an integer. commit is the amount of memory to allocate each time the program runs.

For compatibility with Microsoft LINK, the default commit size is 4KB. The minimum value for HEAPSIZE is 64KB.

By default, n and commit are to assumed be decimal, but the C language conventions for hexadecimal and octal values can be used if desired.

For 16-bit output only, if the keyword MAXVAL is used instead of a number, the size of the heap will be set at 65,520 bytes (64KB minus 16) minus STACKSIZE, minus the area within DGROUP that is statically allocated by the program. This provides the largest possible heap with no need for calculations. Windows requires that DGROUP's size be smaller than 65,520 bytes.

IMPORTS

This directive specifies all functions referenced in the current executable file (including Dynamic Link Libraries, DLL's, which are bound at run time) that actually appear in other executable files, by name and executable file. The IMPORTS directive appears on a line by itself, followed by any number of import definitions. For 16-bit output, the only limit on the number of definitions is that total storage required for the names cannot exceed 64KB.

Each import definition consists of an optional internal name, and a required executable file name and function identifier pair. The function identifier, func in the syntax description which follows, may be either the name listed in the EXPORTS definition of the exporting executable file, or an ordinal value. If it is an ordinal value, then the internal name is required. If the internal name is omitted and func is a name, it is used as the internal name.

SYNTAX IMPORTS
[internal=] externalfile.func
...
EXAMPLE IMPORTS
read.CharInput
NewString = read.GetString
COMMENTS The example defines two functions to be imported from an executable file or library named "read" into the current executable file. The first of these was listed by the EXPORTS directive of "read" as CharInput, and the other as GetString. Within this executable file, CharInput is known by that name, but GetString is referred to as NewString. See also the example for the EXPORTS directive.

A much simpler way to accomplish the same goal is to use the IMPLIB utility to create import libraries for each .dll and .exe that you will be importing functions from, and then link those import libraries into the using file.

INCLUDE

This optional directive tells OPTLINK the name of a file to be included in the .def file at this point.
SYNTAX INCLUDE filename
EXAMPLE INCLUDE generic.inc
COMMENTS The example specifies that file generic. inc is to replace the INCLUDE line. Processing continues with the first line of generic. inc. Include files may be nested up to 10 levels deep. At the end of each file, processing continues with the next line of the file at the next higher level.

LIBRARY

This directive indicates that the executable file produced is a dynamic link library, and optionally assigns it a name and specifies the initialization required. If no name is given, the name of the executable file (less extension) is assumed. Initialization is specified by one of the listed keywords; if none is given, INITGLOBAL is assumed.
Table 11-18 Library keywords
Keyword Meaning
BASE Equivalent to the /BASE switch.
INITGLOBAL The library's initialization routine is called only when the module is initially loaded into memory.
INITINSTANCE The library's initialization routine is called each time a new process gains access to the library.
PRIVATELIB The library is a private DLL; that is, it can be referenced by only one application at a time.
PROCESSINIT Calls the library's entry point when a process attaches.
PROCESSTERM Calls the library's entry point when a process terminates.
THREADINIT Calls the library's entry point when a thread is created.
THREADTERM Calls the library's entry point when a thread terminates.
WINDOWAPI This is a Windows (or PM) application and can execute only in the Windows or PM environment. For Windows, this eliminates the need to use RC if there are no resources.
SYNTAX LIBRARY [libname] [init] [privatelib]
EXAMPLE LIBRARY mylib INITGLOBAL
COMMENTS The example defines a dynamic link library named mylib and specified that it is to be initialized only when first loaded into memory.

LONGNAMES (16-bit only)

This directive may be used to specify a program that is HPFS-aware. It sets a bit in the file header which makes it possible for the program to access the high performance file system.
SYNTAX LONGNAMES

NAME

This directive indicates that the executable file produced is an application, and optionally assigns it a name and defines its type. If no name is specified, the name of the executable file (less its extension) becomes the name of the application. Three keywords are defined to signify type information, as follows:
Table 11-19 Name keywords
Keyword Meaning
BASE Equivalent to the /BASE switch.
WINDOWAPI This is a Windows (or PM) application and can execute only in the Windows or PM environment. For Windows, this eliminates the need to use RC if there are no resources. This is the default if no keyword is supplied.
WINDOWCOMPAT This application can run inside PM, or it can run in a separate screen group. Any application which uses the proper subset of OS/2 mouse, keyboard, and video functions that are supported in PM applications can be of this type.
NOTWINDOWCOMPAT This application must operate in a separate, screen group from PM as it is not PM-compatible.
SYNTAX NAME [appname] [apptype]
EXAMPLE NAME myapp
COMMENTS The example defines an application named myapp and specifies (via the WINDOWAPI default) that it can be run only under Windows or PM. The apptype information is kept in the executable-file header.

NEWFILES (16-bit only)

This directive may be used to specify a program that is HPFS-aware. It sets a bit in the file header which makes it possible for the program to access the high performance file system, in which file names need not follow the "normal" MS-DOS filename. ext (8.3) convention.
SYNTAX NEWFILES

OBJECTS

This directive is identical to the SEGMENTS directive. Refer to the SEGMENTS directive discussion for details.

OLD (16-bit only)

This directive tells OPTLINK to search another executable file (normally a DLL) for EXPORT ordinals. OPTLINK searches the directories listed in the path environment variable to locate the executable file, if it is not in the current working directory. If the file is not found, a warning is issued. Exported names in the current executable file which match those in the old executable file are assigned ordinal values from the old executable file.
SYNTAX OLD 'filename'
EXAMPLE OLD 'oldlib.exe'
COMMENTS The primary use of this directive is to preserve the original ordinal numbers, through successive revisions of a library executable file. Refer to the EXPORTS and IMPORTS directives for more information about ordinal numbers for function identification.

PROTMODE (16-bit only)

This directive specifies that the executable file be run only in protected mode, and not in real or dual mode. If neither this directive nor the REALMODE directive is present when EXETYPE is WINDOWS, OPTLINK assumes that the application can run only in protected mode.
SYNTAX PROTMODE
COMMENTS PROTMODE should always be used when generating protected-mode-only .exe files; less relocation information is required, thus yielding faster linking, a smaller output .exe file, and faster loading at run time. OPTLINK cannot assume PROTMODE when you specify "EXETYPE OS2", since you may "BIND" this as a family (real-mode) application, thus requiring the extra relocation information.

RC

This optional directive tells OPTLINK to copy binary resources from a .res file into the binary output file generated, and to set the appropriate flags in the header to indicate that the file is valid for Windows. By default, it also reorders segments and resources in such a manner that any preloaded, or fixed, or non-discardable segments and resources appear first, in a "fast-load" section, followed by the items that are to be "demand-loaded".
SYNTAX RC [-e -k -l -m -p -t -30 -31] filename.res
EXAMPLE RC myfile.res
COMMENTS The example specifies that the binary resources in myfile.res are to be copied to the output .exe or .dll file, eliminating the need to run the resource compiler after linking. Segments and resources are reordered as necessary to assure that preloaded items appear first.

The option switches are:

Option Switches
Switch Description
-e Create a driver which uses EMS memory.
-k Keep segments in .def file order; do not sort or create a fast-load section.
-l LIM 3.2 EMS application is to be created.
-m Set Multiple Instance flag.
-p Create a private library (PRIVATELIB).
-t Create a protected-mode-only application (PROTMODE).
-30 Tag the executable as requiring Windows 3.0 or later to run.
-31 Tag the executable as requiring Windows 3.1 or later to run.

If no filename is supplied, xxx.res (where xxx is the output filename) is assumed. The current default directory is searched first for the file. If none is found there, the path(s) listed in the OBJ environment variable are used. If none is found there, the path(s) listed in the LIB environment variable are used. If the file is not found, a valid no-resource output file is created.

REALMODE (16-bit only)

This directive specifies that the executable file can be run in real or protected mode. If neither this directive nor the PROTMODE directive is present, OPTLINK assumes that the application can run only in protected mode for "EXETYPE WINDOWS". The default is REALMODE for "EXETYPE OS2".
SYNTAX REALMODE

SECTIONS

This directive is identical to the SEGMENTS directive. Refer to the SEGMENTS directive discussion for details.

SEGMENTS

This directive establishes the attributes of one or more segments on an individual segment by segment basis, and overrides the defaults specified by the CODE and DATA directives. The SEGMENTS directive appears on a line by itself, followed by one or more definition lines. These definition lines, by their sequence, establish the order in which segments appear in the output file.

Each definition line begins with a segment name, which may be enclosed in single quotes (the quotes are required, if the name conflicts with any OPTLINK keyword). The keyword CLASS may then appear, followed by a class name in required quotes. If no CLASS is specified, CODE is assumed. The rest of the line contains attributes for the fields applicable to the segment's class, from the lists presented in describing the CODE and DATA directives.

SYNTAX SEGMENTS
['] segname['][ CLASS'classname'][
attribute [attribute ...]]
['] segname['][ CLASS'classname'][
attribute [attribute ...]]
...
EXAMPLE SEGMENTS
seg1 EXECUTEREAD CONFORMING
seg2 CLASS'special'IOPL
seg3 CLASS'data'READONLY
COMMENTS The example defines three segments, named seg1, seg2, and seg3. The class of seg1 is CODE by default, that of seg2 is "special", and that of seg3 is data.

Note that the SEGMENTS directive can implicitly change the type of a segment:calling a code segment with an attribute of READWRITE causes that segment to be treated as a data segment. The opposite is also true:calling a data segment with an attribute of EXECUTEREAD causes that segment to be treated as code.

It is also essential to preserve case significance in all references to segment or class names; wrong case or other typographical errors in segment or class names are not flagged as errors. OPTLINK ignores erroneous segments and no relevant information is generated within the .map file.

Private segments should be avoided since the SEGMENTS directive affects only the first occurrence of a private segment with a given name and class.

STACKSIZE

This directive performs the same functions as the command-line option switch /STACKSIZE, but overrides the effects of the option switch.

SYNTAX STACKSIZE n[,commit]
EXAMPLE STACKSIZE 1024
COMMENTS The example sets stack size for the generated module to 1024 bytes, no matter what is specified on the command line when OPTLINK is run. n is the total stack space to reserve; it must be an integer, and should be an even number since stack operations are normally performed in units of 2-byte words. commit is the amount of memory to allocate each time the program runs. By default, n and commit are assumed to be decimal, but the C language conventions for hexadecimal and octal values can be used if desired.

STUB

By default, OPTLINK adds a standard "stub" routine to the output executable file to terminate its operation with a warning message if a user attempts to execute the file under MS-DOS. This directive permits a substitute stub file to be defined for inclusion in the output. This can often be used to "stub" in a DOS version of the program, permitting the same .exe file to run under DOS and Windows. OPTLINK searches the directories listed in the PATH environment variable to locate the stub file, if it is not in the current working directory.

SYNTAX STUB 'filename' or STUB:NONE
EXAMPLE STUB 'newstub.exe'
COMMENTS

The example causes file newstub.exe to be inserted into the output executable file for execution under MS-DOS. If newstub.exe is not found in the current directory while linking, the list of directories specified in the PATH environment variable will be searched. If the file cannot be found, a warning is issued. If the file is found, but is not a valid MS-DOS .exe file, an error occurs.

If the keyword NONE is used, no stub at all will be included in the output file. This generates a slightly smaller .exe file, but one which will crash with no warning if an attempt is made to run it under MS-DOS.

SUBSYSTEM

SYNTAX SUBSYSTEM [ NATIVE | WINDOWS [n.nn] | CONSOLE | POSIX ]
EXAMPLE SUBSYSTEM WINDOWS 4.0
COMMENTS Use 4.0 for n.nn when developing Windows XP applications.

VERSION

Equivalent to the /VERSION switch.

Home | Runtime Library | IDDE Reference | STL | Search | Download | Forums