This booklet describes differences between the TNT DOS-Extender SDK
distribution disks and the printed documentation.


------------
New Features
------------

New features added in the 8.0 release of TNT DOS-Extender include the
following:

*       There are now two versions of TNT DOS-Extender.  TNT
	DOS-Extender includes all the features, compatibility and
	stability of earlier versions.  TNT Realtime DOS-Extender
	supports realtime programming through threads, signaling objects
	from interrupt service routines (ISRs), and preemptive
	multitasking.  TNT Realtime DOS-Extender is available as a
	stand-alone product or as an upgrade for existing TNT
	DOS-Extender customers.

*       TNT DOS-Extender and TNT Realtime DOS-Extender are fully
	compatible with Windows 95.

*	New versions of the following compilers are now supported:
	*	Microsoft Visual C++ version 4.0 
	*	Borland C++ version 4.5 and 5.0
	*	MetaWare High C/C++ version 3.3
	*	Watcom C/C++ version 10.5

*       A simple method for including real-mode code in NtStyle
	applications has been added.  See the sample programs in the
	\TNT\EXAMPLES\REALCOPY directory.

*       The try/throw/catch exception mechanism in Visual C++ is now
	supported.  See "Enhancements" below for details.

*       TNT DOS-Extender NtStyle programs may now allocate more than 512
	MB of memory.  See "Enhancements" below for details.

*       There are several new command line switches.  See "New Command
	Line Switches" below for details.

*	386|SRCBug can now be used to debug NtStyle programs.

*       New commands have been added to 386|SRCBug to support debugging
	of multithreaded programs.  See the 386|SRCBug Reference Manual
	for more information.

Additionally, please note the following change:

*       The -PREEMPT switch has been removed from TNT DOS-Extender.
	This switch is now available only with the TNT Realtime
	DOS-Extender.

Finally, effective with this release, the following compilers are no
longer supported:

*	Symantec C++ Professional
*	MetaWare High C/C++ for Windows NT

NOTE:  The MetaWare High C/C++ compiler for DOS (HC386) is still supported.


------------
Enhancements
------------

*       Version 2.0 of Visual C++, 32-Bit Edition added support for the
	try/throw/catch structured exception handling mechanism.
	Version 8.0 of TNT DOS-Extender now provides the run-time
	support needed for these statements.  Please note that this is
	different from the try/except/finally construct documented in
	Section 8.5, "Structured Exception Handling," of the C/C++
	User's Guide to TNT DOS-Extender.  For more information on the
	try/throw/catch mechanism, please refer to the Visual C++,
	32-Bit Edition documentation from Microsoft.  Also note that
	this construct is not supported by Version 1.0 of the Visual C++
	compiler.

*       By default,  memory allocation for NtStyle TNT DOS-Extender
	programs is limited to 512 MB.  If your program needs to
	allocate more than 512 MB, you can increase this limit by using
	the -MAXLINMEM command line switch.  Memory allocation for
	DosStyle programs is limited to 4 GB.


-------------------------
New Command Line Switches
-------------------------

Send Debug Output Directly to the Screen 			NtStyle Only
----------------------------------------

Syntax:
	-DWR[ITE]

The -DWRITE switch specifies that TNT DOS-Extender debugging output be
written directly to the screen, without calling any DOS functions.  This
switch only affects output generated when you specify the -NTDEBUG
command line switch or when you use one of the functions
NtStylePrintf(), NtStyleVPrintf(), NtStyleSPrintf(), or
NtStyleVSPrintf().

This can be particularly useful when you're tracking down a troublesome
bug.  When your program makes DOS calls to perform output, you are
changing the behavior of your program, possibly masking the problem
you're tracking.  The disadvantage of using the -DWRITE switch is that
you cannot redirect this debugging output to a file from the DOS command
line.

Note that the output produced by this switch does not scroll.  Instead,
when output goes past the bottom of the screen, it wraps back to the
first line of the display.  To help you identify the last line printed,
a line containing only a "#" is displayed following the last line of
debugging output.

By default, the screen is assumed to be at linear address B8000h, the
standard location for CGA and higher displays.  If you have a different
type of video display, use the -DBGSCR switch to specify the linear
address of your particular display adapter.


Specify Screen Linear Address for Debug Output 			NtStyle Only
----------------------------------------------

Syntax:
	-DBGS[CR] [lin_addr]

The -DBGSCR switch specifies the linear address of the screen to which
debugging output is written when you specify the -DWRITE switch.  The
default lin_addr is B8000h, the standard for CGA and higher displays.

Please see the -DWRITE switch for more information.

For example, to specify a monochrome adapter, specify linear address
B0000h:

	tnt -dbgs B0000h -dwr test


Specify Maximum Allocatable Memory 				NtStyle Only
----------------------------------

Syntax:
	-MAXL[INMEM] n

The -MAXLINMEM switch specifies the limit on the amount of memory that
may be allocated by an NtStyle program.  n is the limit in megabytes.
The default is -MAXL 512.

To specify a limit of 1 GB (1024 MB):

	-MAXL 1024


Do Not Save Original Hardware Interrupt Vectors 		NtStyle Only
-----------------------------------------------

Syntax:
	-NOINTSAVE

By default, TNT DOS-Extender saves a snapshot of all hardware interrupt
vectors on startup.

If you're not debugging your program, these saved registers are used
only to restore the original hardware interrupt vectors before TNT
DOS-Extender exits.

If you are debugging your program, TNT DOS-Extender toggles between the
original vectors and those set by your program depending on whether your
program or the debugger is in control.  As long as your program is in
control, the contents of the hardware interrupt vectors are those set by
your program.  When control is given to the debugger, TNT DOS-Extender
restores the original snapshot.  When the debugger gives control back to
your program, the debuggee's hardware interrupt vectors are restored.
This functionality can be useful when debugging hardware interrupt
service routines.

The -NOINTSAVE switch disables this functionality.  You should never
have to specify -NOINTSAVE; it is provided for compatibility with
earlier versions of TNT DOS-Extender.


Handle Unresolved Win32 Calls 					NtStyle Only
-----------------------------

Syntax:
	-A[BORT]O[N]C[ALL]
	-A[BORT]O[N]L[OAD]
	-W[ARN]O[N]L[OAD]

When the TNT DOS-Extender loads your program, it attempts to resolve all
references to other DLLs and EXEs that the program might make.  The
-ABORTONCALL, -ABORTONLOAD, and -WARNONLOAD control the behavior if your
program references a Win32 API that isn't supported by TNT DOS-Extender.

These switches only apply to functions in the following DLLs:

   *	KERNEL32
   *	W32SKRNL
   *	USERRTL
   *	USER32
   *	NTDLL
   *	GDI32
   *	ADVAPI32 

If -ABORTONCALL has been specified (default), your program is loaded,
but TNT DOS-Extender will generate a fatal error if the unsupported API
is called while your program is running:

Fatal error TNT.11450: Unimplemented function 'function' called 
                       at 'address'

If -ABORTONLOAD is specified, TNT DOS-Extender refuses to load the
executable and generates an informative message:

Fatal error TNT.11410: cannot load program : entry point not found
                       in DLL
Additional info: "dll-name.function.name from exe-name"

If -WARNONLOAD is specified, TNT DOS-Extender will issue a warning at
load time, and load your program:

Warning TNT.31060: Unimplemented API "function" used

The -WARNONLOAD switch is ignored if -ABORTONCALL is not also specified.


--------------------
Microsoft Visual C++
--------------------

Installing Linker Command Files
-------------------------------

Different 386|LINK linker command files are used for programs compiled
with each version (1.0, 2.x, 4.x) of the Microsoft Visual C++, 32-Bit
Edition compiler.  By default, the linker command files are set up for
Microsoft Visual C++ Version 4.x.

To install linker command files compatible with Microsoft Visual C++,
32-Bit Edition Version 1.0, run the USEVC10.BAT file, which takes a
single parameter identifying the TNT DOS-Extender installation
directory.  Assuming that you've done a default installation of
TNTDOS-Extender in directory C:\TNT:

	C:\>usevc10 c:\tnt

To install linker command files compatible with Microsoft Visual C++
Version 2.0, run the USEVC20.BAT file, which takes a single parameter
identifying the TNT DOS-Extender installation directory.  Assuming that
you've done a default installation of TNT DOS-Extender in directory
C:\TNT:

	C:\>usevc20 c:\tnt

To restore the linker command files for Microsoft Visual C++ Version
4.x, run USEVC20.BAT:

	C:\>usevc20 c:\tnt


Rehosting the Microsoft Visual C++  Version 4.x Compiler to MS-DOS
------------------------------------------------------------------

As shipped by Microsoft, Version 4.x of the Microsoft Visual C++
compiler runs only under Windows 95 or Windows NT.  To host this
compiler under DOS for building TNT DOS-Extender applications, you must
rebind the GOTNT stub loader (included with TNT DOS-Extender SDK) onto
the compiler tools.  This will allow the compiler (CL.EXE), linker
(LINK.EXE), librarian (LIB.EXE), and MAKE utility (NMAKE.EXE) to run
under both DOS and WindowsNT.

You must have installed the Visual C++ compiler tools on your hard disk
and the \TNT\BIN directory must be on your PATH, as described in Section
2.1 of the C/C++ User's Guide to TNT DOS-Extender.  If you have not yet
installed the compiler and tools, you can use the GETVC.BAT file to copy
the compiler and support executables from the CD-ROM to your hard disk.
You can then run the BINDVC.BAT file from the TNT DOS-Extender SDK to
rebind the GOTNT stub loader.

Assuming that you've done a default installation of the Visual C++ tools
in directory C:\MSVC40:

	C:\> bindvc c:\msvc20

If you've installed the compiler tools in a different directory,
substitute that name on the BINDVC command line.

There is, however, a limitation with the rehosted compiler:  There is no
support for incremental linking.  Therefore, you cannot use the LINK
/incremental:yes switch.


-----------
Borland C++
-----------

Problem with TD32
-----------------

There is a known problem with TD32, the 32-bit version of Borland's
Turbo Debug.  Selecting the Program Reset item from the TD32 Run menu
can cause TD32 to execute your program instead of reloading it.
Depending on the state of your program, this action can result in your
computer hanging.  If this happens, you can hit ^C to exit Turbo Debug
and return to the DOS prompt.  This is a problem in TD32 and occurs in
the Windows NT environment as well as under TNTDOS-Extender.


Dual-Monitor Debugging with TDTNT under Windows 3.x
---------------------------------------------------

Dual-monitor debugging with TDTNT is supported in Windows 3.x DOS box.
You can use the -do switch for TDTNT when you're running in a DOS box
under Windows 3.x.

The statements to the contrary on page 65 of the C/C++ User's Guide to
TNT DOS-Extender are incorrect.


Using Borland MAKE
------------------

You cannot run 386|LINK and 386|ASM under the Borland MAKE utility
because of the way it manages extended memory.  The solution is to run
the real-mode MAKE utility, named MAKER.


------------
Watcom C/C++
------------


Watcom C/C++ 10.0 Run-Time Libraries
------------------------------------

If you are using Watcom C/C++ version 10.0, you must update to the
A-level patches for compatibility with 386|LINK.  The C/C++ run-time
libraries shipped with the original 10.0 version cause errors when
linking with 386|LINK.  You are using the A-level patches if the version
number printed by WCC386.EXE is 10.0a.


Using the WinPipe API and the Watcom C/C++ Compiler
---------------------------------------------------

If you're using the Watcom C/C++ compiler and your programs calls
routines in the WinPipe API, you must use the /3s switch to force
stack-based argument passing conventions.  If you know that your program
will only be run on 80486 or Pentium machines, you may use the /4s or
/5s switch.


Using _dos_* and _bios_* Functions from NtStyle Watcom Programs
---------------------------------------------------------------

If you're using the Watcom C/C++ compiler and your NtStyle program calls
_dos_* or _bios_* routines in the DOS32.LIB library, you must use the
/3s switch to force stack-based argument passing conventions.  If you
know that your program will only be run on 80486 or Pentium machines,
you may use the /4s or /5s switch.  DosStyle programs can use
register-based argument passing conventions when calling _dos_* or
_bios_* functions.


------------------------------------
Mode Switching in a DPMI Environment
------------------------------------

If you use the TNT DOS-Extender function 253Bh (Jump to Real Mode) or if
you jump to protected mode with the function address provided at offset
114h of the information returned by the TNT DOS-Extender function 2526h
(Get Configuration Information) while running in a DPMI environment,
then you must save the state of the mode being entered exactly as if you
were using the DPMI "Raw Mode Switching Services."  Please refer to the
DPMI specification for more information about saving states under DPMI.

This is only necessary  if you're running in a DPMI environment such as
OS/2 or Windows 3.1, 95, or NT.


-----------------------
Debugging with CodeView
-----------------------

I and PO Commands Not Supported
-------------------------------
The I (Port Input) and PO (Port Output) commands listed in the CodeView
Reference Manual are not supported.


Displaying Address of Floating-Point Instructions
-------------------------------------------------

When CodeView displays the address of the current FP instruction, it
displays only the low 16 bits of the address.

--------------------------------------
Limitations of Soft-ICE/W Version 1.51
--------------------------------------

The versions of DBG2MAP and WLDR that ship with version 1.51 of
Soft-ICE/W require an NtStyle program with a PE signature.  Later
versions will be able to process NtStyle and DosStyle programs with a
Phar Lap signature.  There are two work-arounds for this problem:

*       Download new versions of DBG2MAP.EXE and WLDR.EXE from Nu-Mega's
	BBS.  This is the preferred solution.  Please contact Nu-Mega
	Technologies for more information.

*       If you're unable to download the new versions, you can use Phar
	Lap's MARKPHAR utility to temporarily change the file type and
	signature of your DosStyle .EXE file.  For example, if you're
	using the Microsoft Visual C++, 32-Bit Edition compiler to build
	a DosStyle program:

		C:\>cl /c /Zi hello.c
		C:\>386link @msvc32.dos -cvsym hello
		C:\>markphar -ntstyle -pesign hello.exe
		C:\>dbg2map hello.exe
		C:\>msym hello.map
		C:\>wldr
		C:\>markphar -dosstyle hello.exe
		C:\>tnt -softice hello

	Or, if you're using the 32-Bit Borland C++ compiler to build a
	DosStyle program:

		C:\>bcc32 -c -v hello.c
		C:\>386link @bcc32.dos -tdsym hello
		C:\>markphar -ntstyle -pesign hello.exe
		C:\>dbg2map hello.exe
		C:\>msym hello.map
		C:\>wldr
		C:\>markphar -dosstyle hello.exe
		C:\>tnt -softice hello


------------
System Calls
------------

Page-Level Caching of Memory-Mapped Devices
-------------------------------------------

The _dx_map_pgs() (INT 21h function 252Bh subfunction 2) and
_dx_map_phys() (INT 21h function 250Ah) system calls are used to map
physical devices into the application programs data segment.  These
system calls DO NOT disable page-level caching of the mapped devices on
i486 and later processors, as is incorrectly stated in the Libraries and
System Calls Reference.  Automatic page-level cache disabling was
removed for compatibility with some hardware designs.

If the system hardware knows about a memory-mapped device, it will
automatically disable page-level caching for the appropriate memory
addresses.  If you are mapping a device that is unknown to the system
hardware, you must:

1.	Map the device using _dx_map_pgs() or _dx_map_phys().

2.      Explicitly set the PCD (Page Cache Disable) bit in each page
	table entry for the mapped region.  For example:

	  ULONG DevPhysAddr;	// physical address of device
	  UCHAR *pDev;	   	// page-aligned ptr where device is mapped
	  UINT DevSize;		// page-aligned size of device memory
	  UCHAR *pDevPage;	// scan ptr thru device pages
	  ULONG pte;		// page table entry
	  ULONG pti;		// page table info

	  _dx_map_pgsn(pDev, DevSize, DevPhysAddr);
  	  for (pDevPage = pDev; pDevPage - pDev < DevSize; pDevPage += 0x1000)
   	  {
   		_dx_rd_ptinfn(pDevPage, &pte, &pti);
		pte |= PE_PCD;
   		_dx_wr_ptinfn(pDevPage, pte, pti);
   	  }


NSSIO.DLL Not Supported under Windows NT
----------------------------------------

The NSSIO.DLL NtStyle subsystem for serial communications APIs is not
supported when running in a Windows NT DOS box.



-------------------------------------------
New or Changed Functions in the NtStyle API
-------------------------------------------

There have been some changes to functions in the NtStyle API:

	NtStylePrintf	New
	NtStyleSPrintf	New
	NtStyleVPrintf	New
	NtStyleVSPrintf	New
	SetProcAddress	Changed


NtStylePrintf 						Formatted Output
------------------------------------------------------------------------

#include <tntapi.h>

VOID WINAPI NtStylePrintf(char *pMsg, ...);

	pMsg	format control string
	...	optional arguments to be printed
	

Remarks

NtStylePrintf() provides some of the functionality of the C run-time
library routine printf().  It performs formatted output to the console.
This allows you to output values from your program without having to
link the C run-time library.  NtStylePrintf() is especially useful when
used in conjunction with the -DWR switch to track particularly
troublesome bugs.  See the discussion of the -DWR switch above.

NtStylePrintf() recognizes only the following format codes:

	%s	pointer to string
	%c	ASCII character
	%x	hex unsigned int
	%d	decimal signed int
	%u	decimal unsigned int
	%hx	hex unsigned short
	%hd	decimal signed int
	%hu	decimal unsigned short
	%lx	hex unsigned long
	%ld	decimal signed long
	%lu	decimal unsigned long

NtStylePrintf() does not support field width specifiers, but will skip
over them and recognize the code following the width specifier.  You
should also note that floating point formats are not in the list of
supported specifiers.

Return Value
	None

See Also
	NtStyleSPrintf
	NtStyleVPrintf
	NtStyleVSPrintf



NtStyleSPrintf 						Formatted Output
------------------------------------------------------------------------

#include <tntapi.h>

int WINAPI NtStyleSPrintf(char *pBuff, char *pMsg, ...);

	pBuff	pointer to buffer in which formatted output will be stored
	pMsg	format control string
	...	optional arguments to be printed
	

Remarks

NtStyleSPrintf() provides some of the functionality of the C run-time
library routine sprintf().  It performs formatted output and stores the
results in the buffer pointed to by pBuff.  This allows you to output
values from your program without having to link the C run-time library.

Please refer to the discussion of the function NtStylePrintf() for a
list of the supported format specifiers.

Return Value
	Number of characters stored in pBuff, not counting the
	terminating null character.

See Also
	NtStylePrintf
	NtStyleVPrintf
	NtStyleVSPrintf



NtStyleVPrintf 						Formatted Output
------------------------------------------------------------------------

#include <tntapi.h>

VOID WINAPI NtStyleVPrintf(char *pMsg, PVOID pParam);

	pMsg	format control string
	pParam	pointer to list of arguments to be printed

Remarks

NtStyleVPrintf() provides some of the functionality of the C run-time
library routine vprintf().  It performs formatted output to the console.
This allows you to output values from your program without having to
link the C run-time library.  NtStyleVPrintf() is especially useful when
used in conjunction with the -DWR switch to track particularly
troublesome bugs.  See the discussion of the -DWR switch above.

Please refer to the discussion of the function NtStylePrintf() for a
list of the supported format specifiers.

Return Value
	None

See Also
	NtStylePrintf
	NtStyleSPrintf
	NtStyleVSPrintf


NtStyleVSPrintf 					Formatted Output
------------------------------------------------------------------------
		
#include <tntapi.h>

int WINAPI NtStyleVSPrintf(char *pBuff, char *pMsg,
                           PVOID pParam);

	pBuff	pointer to buffer in which formatted output will be stored
	pMsg	format control string
	pParam	pointer to arguments to be printed
	

Remarks

NtStyleVSPrintf() provides some of the functionality of the C run-time
library routine vsprintf().  It performs formatted output and stores the
results in the buffer pointed to by pBuff.  This allows you to output
values from your program without having to link the C run-time library.

Please refer to the discussion of the function NtStylePrintf() for a
list of the supported format specifiers.

Return Value
	Number of characters stored in pBuff, not counting the
	terminating null character.

See Also
	NtStylePrintf
	NtStyleSPrintf
	NtStyleVPrintf


SetProcAddress 							Changed
-----------------------------------------------------------------------

The implementation of SetProcAddress() has been enhanced.  You can now
use SetProcAddress() to provide implementations for any Win32 API,
including those not supported by TNT DOS-Extender.

In earlier versions, only those APIs implemented (or stubbed) by TNT
DOS-Extender could be intercepted with SetProcAddress().  Now you can
intercept (or create) any API as long as it belongs to one of the
following DLLs:

   *	KERNEL32
   *	W32SKRNL
   *	USERRTL
   *	USER32
   *	NTDLL
   *	GDI32
   *	ADVAPI32 

The sample program in C:\TNT\EXAMPLES\SYSINF illustrates the use of
SetProcAddress().


--------------------------------------------------------------------
Additional Function in the DOSX32.LIB TNT DOS-Extender Calls Library
--------------------------------------------------------------------

_dx_callReal 					Call Real Mode Procedure
------------------------------------------------------------------------

#include <pharlap.h>

int _dx_callReal(REALPTR pRealFunc, SWI_REGS *pRegs, 
                 ULONG nWords, ...);

pRealFunc	real-mode address of function to call
pRegs		pointer to structure containing real-mode register values
nWords          number of WORDs of parameters to copy from
		protected-mode stack to real-mode stack.

Remarks

The routine _dx_callReal() calls the real-mode function at address
pRealFunc, with register values specified in pRegs, and passing nWords
parameters on the stack.

_dx_callReal() is very similar to the function _dx_call_real() except
that all registers, including EFLAGS, are passed to and returned from
the real-mode function.

The parameter count is a WORD count; e.g., if you pass 2 ULONGs the
parameter count is 4.

On input, the registers struct contains the real-mode register values to
be loaded into all registers before calling the real-mode procedure.

On output, the struct contains all the register values after the
real-mode procedure returned.

The parameters to the real-mode function are passed following the last
explicit parameter in the prototype (e.g., to call the real-mode
function rfunc(ULONG val) with val = 25, you  would write:

	errv = _dx_call_real(funcp, &regs, 2, 25L);

where you have already initialized funcp and the regs structure
appropriately.

It's best to always pass ULONG parameters to real- mode functions; if
you want to pass USHORTs you have to pack them yourself, because the C
compiler always 4-byte aligns parameters pushed on the stack, regardless
of the size of the data type.

// SWI_REGS Data structure for _dx_callReal)

typedef struct {
	USHORT  u1;	/* unused, never modified */
	ULONG   u2;	/* unused, never modified */
	USHORT  u3;	/* unused, never modified */
	ULONG   eax;	/* register EAX contents */
	ULONG   ebx;	/* register EBX contents */
	ULONG   ecx;	/* register ECX contents */
	ULONG   edx;	/* register EDX contents */
	ULONG   esi;	/* register ESI contents */
	ULONG   edi;	/* register EDI contents */
	ULONG   ebp;	/* register EBP contents */
	ULONG   esp;	/* register ESP contents */
	USHORT  cs;	/* register CS contents */
	USHORT  ds;	/* register DS contents */
	USHORT  ss;	/* register SS contents */
	USHORT  es;	/* register ES contents */
	USHORT  fs;	/* register FS contents */
	USHORT  gs;	/* register GS contents */
	ULONG   eip;	/* register EIP contents */
	ULONG   flags;	/* register EFLAGS contents */
} SWI_REGS;

Return Value
	If success:	0
	If error:	1	if not enough real-mode stack space

Phar Lap System Call
	2510h

See Also
	_dx_real_int	Issue Real-Mode Interrupt
	_dx_call_real	Call Real-Mode Procedure


---------------------
386|LINK New Switches
---------------------

Generate Binary Output File
---------------------------

Syntax:
	-BIN[ARY] filename address

filename	name of binary output file
address         physical base address of first byte to be written into
		binary output file

The -BINARY switch produces a binary output file that represents the
physical memory space of the program.  A binary output file contains all
the code and data bytes for the program laid out as they would appear in
physical memory.  There is no file header or record structure in a
binary file.  Any unused areas between initialized areas are initialized
to zero.

The -BINARY switch is only supported when linking real-mode code, as
indicated by the presence of the -86 switch.


Generate Public Symbols
-----------------------

Syntax:
	-CREATESEGSYMS ALL
	-CREATESEGSYMS SEGMENT name, ...

name 	name of segment for which symbols are to be generated

The -CREATESEGSYMS command causes 386|LINK to generate public symbols
for each segment named in the command.  If ALL is specified, public
symbols are generated for all segments in the program being linked.
Three symbols are created for each segment:

	_SEG_name_BEGIN		beginning offset of segment
	_SEG_name_END		ending offset of segment
	_SEG_name_PADDR		physical load address of segment


Create Segments at Link Time
----------------------------

Syntax:
	-SEG[MENT] name option . . .

name 	name of segment to be created
option
	class		name of class to which segment belongs 
	group		name of group of which segment is member 
	limit		size of segment in bytes
	file            name of a binary file, the contents of which are
			to be placed in the segment being created
	rw		read/write data segment (protected mode only)
	ro		read only data segment (protected mode only)
	er		execute/read code segment (protected mode only)
	eo 		execute only code segment (protected mode only)
	u[p]		expand up segment
	d[own]		expand down segment
	conf[orming]	conforming code segment
	nonconf[orming]	nonconforming code segment
	tss286		286 TSS
	tss386		386 TSS

The -SEGMENT switch creates segments at link time 

The FILE option is useful for mixing real- and protected-mode code in a
PE file, as in the \TNT\EXAMPLES\REALCOPY sample program.


----------------------
Other 386|LINK Changes
----------------------

The following changes have been made to the way 386|LINK works:

*       The -STARTOBJ switch now works with a list of object files.  In
	previous releases, it supported only one object file.

*       386|LINK now works with the import and export object records in
	Borland C++ 5.0 object files.  These records are generated by
	the __declspec(dllimport) and __declspec(dllexport) attributes.

*       MAPEXE now correctly displays the exports of a PE file.  To be
	consistent, MAPEXE shows VAs for export addresses, not RVAs.
