www.digitalmars.com [Home] [Search] [CTG] [RTL] [IDDE]

Last update Dec 8, 2002


Module Definition Files

This chapter describes the effect of each module definition file irective recognized by OPTLINK. For information on:

What's in This Chapter

This chapter discusses:

Definition File

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 an MS-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 MS-DOS .exe files.

Directive overview

OPTLINK recognizes the directives summarized below. These directives and their effects are described in the paragraphs which follow.
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
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 may be 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 2001 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 you use 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. 

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; see Chapter 
		10 for information. 

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; see Chapter 
		10 for information. 

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

VERSION

Equivalent to the /VERSION switch.
Copyright © 1995-2001 Digital Mars. All Rights Reserved.