tlink.txt

tasm source document descript

  o  'NONE' means that there is no data segment created. This
     option is available only for libraries. 'SINGLE' (the
     default for .DLLs) means a single data segment is created
     and shared by all processes. 'MULTIPLE' (the default for .EXEs)
     means a data segment is created for each process.

  o  'READONLY' means the data segment can be read only. 'READWRITE'
     (the default) means the data segment can be read and written to.

  o  'PRELOAD' means the data segment is loaded when a module that
     uses it is first loaded. 'LOADONCALL' (the default) means the
     data segment is loaded when it is first accessed (this is
     ignored for 32-bit applications).

  o  'SHARED' (the default for 16-bit .DLLs) means one copy of the
     data segment is shared among all processes. 'NONSHARED' (the
     default for programs and 32-bit .DLLs) means a copy of the
     data segment is loaded for each process needing to use the
     data segment.


DESCRIPTION statement
---------------------
DESCRIPTION (optional) inserts text into the application module and is
typically used to embed author, date, or copyright information. The
syntax is:

	DESCRIPTION 'Text'

'Text' is an ASCII string delimited with single quotes.


EXETYPE statement
-----------------
EXETYPE defines the default executable file (.EXE) header type for
16-bit application. You can leave this section in for 32-bit
application for backward compatibility, but if you need to change the
EXETYPE, refer to the NAME statement. The syntax for EXETYPE is:

	EXETYPE  WINDOWS


EXPORTS statement
-----------------
EXPORTS defines the names and attributes of functions to be exported.
The EXPORTS keyword marks the beginning of the definitions. It can be
followed by any number of export definitions, each on a separate line.
The syntax is:

	EXPORTS ExportName [Ordinal] [RESIDENTNAME] [Parameter]

  o  'ExportName' specifies an ASCII string that defines the
     symbol to be exported:

	EntryName [=InternalName]

	'InternalName' is the name used within the application to
	refer to this entry. 'EntryName' is the name listed in the
	executable file's entry table and is externally visible.

  o  'Ordinal' defines the function's ordinal value as follows:

	@ordinal

	where 'ordinal' is an integer value that specifies the
	function's ordinal value.

	When an application or DLL module calls a function exported
	from a DLL, the calling module can refer to the function by
	name or by ordinal value. It's faster to refer to the function
	by ordinal because string comparisons aren't required to
	locate the function. To use less memory, export a function by
	ordinal (from the point of view of that function's DLL) and
	import/call a function by ordinal (from the point of view of
	the calling module).

	When a function is exported by ordinal, the name resides in
	the nonresident name table. When a function is exported by
	name, the name resides in the resident name table. The
	resident name table for a module is in memory whenever the
	module is loaded; the nonresident name table isn't.

  o  'RESIDENTNAME' specifies that the function's name must be
     resident at all times. This is useful only when exporting
     by ordinal (when the name wouldn't be resident by default).

  o  'Parameter' is an optional integer value that specifies the
     number of words the function expects to be passed as parameters.


IMPORTS statement
-----------------
IMPORTS defines the names and attributes of functions to be imported
from DLLs. Instead of listing imported DLL functions in the IMPORTS
statement, you can do the following:

  o  Specify an import library for the DLL in the TLINK command
     line, or

  o  Include the import library for the DLL in the project manager
     in the IDE.

If you're programming for 32-bits, you must write your own indirection
to import any function, class, or data you want imported. The following
is an example of importing data with TASM32:

	_TEXT		segment dword public 'CODE'

	extrn		_foo:dword	;This is an imported integer

	_bar		PROC

		mov	eax, -foo
		mov	eax, [eax]
		ret

	_bar		ENDP

	_TEXT		ends
	end


The IMPORTS keyword marks the beginning of the definitions; it is
followed by any number of import definitions, each on a separate line.
The syntax is:

	IMPORTS  [InternalName=]ModuleName.Entry

  o  'InternalName' is an ASCII string that specifies the unique
     name the application uses to call the function.

  o  'ModuleName' specifies one or more uppercase ASCII characters
     that define the name of the executable module containing the
     function. The module name must match the name of the
     executable file. For example, the file SAMPLE.DLL has the
     module name SAMPLE.

  o  'Entry' specifies the function to be imported--either an ASCII
     string that names the function or an integer that gives the
     function's ordinal value.


LIBRARY statement
-----------------
LIBRARY defines the name of a DLL module. A module-definition file can
contain either a LIBRARY statement to indicate a DLL or a NAME
statement to indicate a program.

A library's module name must match the name of the executable file.
For example, the library MYLIB.DLL has the module name MYLIB. The
syntax is:

	LIBRARY LibraryName [INITGLOBAL | INITINSTANCE]

  o  'LibraryName' (optional) is an ASCII string that defines
     the name of the library module. If you don't include a
     LibraryName, TLINK uses the file name with the extension
     removed. If the module-definition file includes neither a
     NAME nor a LIBRARY statement, TLINK assumes a NAME statement
     without a ModuleName parameter.

  o  'INITGLOBAL' means the library-initialization routine is called
     only when the library module is first loaded into memory.
     'INITINSTANCE' means the library-initialization routine is called
     each time a new process uses the library.


NAME statement
--------------
NAME is the name of the application's executable module. The module
name identifies the module when exporting functions. For 32-bit
applications, NAME must appear before EXETYPE. If NAME and EXETYPE
don't specify the same target type, the type listed with NAME is used.
The syntax is:

	NAME  ModuleName [WINDOWSAPI] | [WINDOWCOMPAT]

  o  'ModuleName' (optional) specifies one or more uppercase ASCII
     characters that name the executable module. The name must
     match the name of the executable file. For example, an
     application with the executable file SAMPLE.EXE has the module
     name SAMPLE.

     If ModuleName is missing, TLINK assumes the module name matches
     the file name of the executable file. For example, if you don't
     specify a module name and the executable file is named MYAPP.EXE,
     TLINK assumes the module name is MYAPP.

     If the module-definition file includes neither a NAME nor a
     LIBRARY statement, TLINK assumes a NAME statement without a
     ModuleName parameter.

  o  'WINDOWAPI' is a Windows executable, and is equivalent to the
     TLINK32 option /aa.

  o  'WINDOWCOMPAT' is a Windows-compatible character-mode executable,
     and is equivalent to the TLINK32 option /ap.


SEGMENTS statement
------------------
SEGMENTS defines the segment attributes of additional code and data
segments. The syntax is:

	SEGMENTS
		SegmentName [CLASS 'ClassName'] [MinAlloc]
		[SHARED | NONSHARED]
		[PRELOAD | LOADONCALL]

  o  'SegmentName' is a character string that names the new segment.
     It can be any name, including the standard segment names _TEXT
     and _DATA, which represent the standard code and data segments.

  o  'ClassName' (optional) is the class name of the specified
     segment. If no class name is specified, TLINK uses the
     class name CODE.

  o  'MinAlloc' (optional) is an integer that specifies the minimum
     allocation size for the segment. TLINK and TLINK32 ignore this
     value.

  o  'SHARED' (the default for 16-bit .DLLs) means one copy of the
     segment is shared among all processes. 'NONSHARED' (the default
     for programs and 32-bit .DLLs) means a copy of the segment is
     loaded for each process needing to use the data segment.

  o  'PRELOAD' means that the segment is loaded immediately;
     'LOADONCALL' means that the segment is loaded when it is
     accessed or called (this is ignored by TLINK32). The resource
     compiler might override the LOADONCALL option and preload
     segments instead.


STACKSIZE statement
-------------------
STACKSIZE defines the number of bytes needed by the application for
its local stack. An application uses the local stack whenever it makes
function calls. Don't use the STACKSIZE statement for dynamic-link
libraries. The syntax is:

	STACKSIZE bytes

bytes is an integer value that specifies the stack size in bytes.


STUB statement
--------------
STUB appends a DOS executable file specified by FileName to the
beginning of the module. The executable stub displays a warning
message and terminates if the user attempts to run the executable stub
in the wrong environment (running a Windows application under DOS, for
example).

Borland C++ adds a built-in stub to the beginning of a Windows
application unless a different stub is specified with the STUB
statement. You shouldn't use the STUB statement to include WINSTUB.EXE
because the linker does this automatically. The syntax is:

	STUB 'FileName'

'FileName' is the name of the DOS executable file to be appended to
the module. The name must have the DOS file name format.

If the file named by FileName isn't in the current directory, TLINK
searches for the file in the directories specified by the PATH
environment variable.


Module-definition file defaults
-------------------------------
The module-definition file isn't strictly necessary to produce a
Windows executable under borland C++.

If no module-definition file is specified, the following defaults are
assumed:

	CODE		PRELOAD MOVEABLE DISCARDABLE
	DATA		PRELOAD MOVEABLE MULTIPLE (for applications)
			PRELOAD MOVEABLE SINGLE (for DLLs)
			HEAPSIZE	4096
			STACKSIZE		5120 (1048576 for TLINK32)

To replace the EXETYPE statement, the Borland C++ linker can discover
what kind of executable you want to produce by checking settings in
the IDE or options on the command line.

You can include an import library to substitute for the IMPORTS
section of the module definition file.

If you're coding in C or C++, you can use the _export keyword in the
definitions of export functions to remove the need for an EXPORTS
section. Note, however, that if _export is used to export a function,
that function is exported by name rather than by ordinal (ordinal is
usually more efficient).

If you want to change various attributes from the default, you'll need
to have a module-definition file.

/**************************** END OF FILE ********************************/