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:
- Definition file directives for Win32 and Win32s applications, see Win32 Programming Guidelines.
- Definition file directives for Win16 applications, see Win16 Programming Guidelines.
- Definition file directives for DOS applications, see DOS Programming Guidelines.
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.
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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.| 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 |
| 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. |
| 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. |
| 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. |
| 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. |
| 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 |
| 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. |
| 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. |
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.| 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:| 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:
| 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.