
-----------------------------------------

	INTRODUCTION
	------------
      
     Windows NT provides a fully-integrated command prompt that 
enables you to launch both Windows-based and MS-DOS-based applications. 
Although the concept of running an MS-DOS-based application in a 
Windows-based environment may be familiar to you, Windows NT handles 
this somewhat differently than Windows (16-bit) does. 

The essential difference lies in the command prompt itself; under 
Windows NT, the command prompt is a 32-bit Windows NT-based application, 
not the virtual MS-DOS machine you would expect from Windows. Under 
Windows NT, until you start an MS-DOS-based application, no virtual 
MS-DOS machine is created. Furthermore, once you start an MS-DOS-based 
application, its virtual MS-DOS machine is used for all subsequent 
MS-DOS-based applications started from the same command prompt. 

As in Windows, each MS-DOS-based application can have a program 
information file (PIF). If there is no PIF for a particular 
application, the default PIF, _DEFAULT.PIF, is used. Because Windows 
NT only uses the PIF from the first application started in any 
given command prompt, you may need to take special care in the way 
you start your applications. For example, if you design a PIF that 
allocates some EMS memory, it is important that you start the 
associated application first; otherwise, the EMS memory may never 
be allocated. You may start a Windows NT command prompt and then 
run the MS-DOS command, MEM, to see how much memory you have free. 
Because MEM is another MS-DOS-based application, Windows NT creates 
a virtual MS-DOS machine, probably using _DEFAULT.PIF. After MEM 
finishes, you start the application you created the PIF for. 
Unfortunately, because _DEFAULT.PIF doesn't instruct Windows NT 
to allocate EMS memory, your application reports that it can find 
no EMS memory. Rechecking the PIF you created does not solve the 
problem. You need to start another command prompt and then make 
sure to start your EMS-requiring application first, before you 
start any other MS-DOS-based applications. 

There is one more difference to be aware of: each PIF contains 
a pointer to AUTOEXEC and CONFIG files. Usually these default 
to the Windows NT versions, AUTOEXEC.NT and CONFIG.NT. If you 
want to change environment variables for your MS-DOS-based 
applications, you need to point their PIFs to different files 
or modify the default ones. (To see these files and their 
locations, run PIF Editor and choose Windows NT.) 

------------------------



-----------------------

The text below describes how Windows NT supports serial communications
in 16-bit Windows-based and in MS-DOS-based applications. 


16-Bit Windows-Based Applications 

Windows NT supports serial communications in 16-bit Windows-based 
applications in the same manner that 16-bit Windows 3.1 does, through 
communications functions in the Windows application programming 
interface (API). From the application standpoint, Windows NT provides 
COMM.DRV, the communications driver in 16-bit Windows 3.1, because a 
mapping exists between the Windows 3.1 and Windows NT functions. This 
mechanism emulates the EventWord and shadow modem status register 
(MSR) to support the GetCommEventMask() function. It also sends 
WM_COMMNOTIFY messages to support the EnableCommNotification() function. 

If a 16-bit Windows-based application uses any extended functionality 
provided by a third-party communications driver, it may not communicate 
reliably because Windows NT may not support the extended functionality. 


MS-DOS-Based Applications 

Most MS-DOS-based communication applications do not use any serial port 
functions; instead, they directly access the serial port hardware. 
Windows NT supports these applications by simulating the standard 
hardware serial adapters, COM1 through COM4; the application never 
directly controls the serial port hardware. 

Windows NT simulates four 16450 UARTs at the standard serial I/O addresses 
and interrupt numbers used in IBM PC-compatible hardware. When each 
virtual MS-DOS machine (VDM) starts, the simulated UARTs are dormant. 
When an application accesses a simulated UART, Windows NT connects the 
simulated UART to the corresponding Windows NT serial port, even if it 
uses a different address, interrupt number, or a completely different 
interface. If the corresponding serial port is not present of if it is 
already in use, Windows NT displays an error dialog box to inform the 
user of the problem. 

Some applications have an "idle curiosity" about serial ports that they 
do not otherwise use. When you run one of these applications in Windows 
NT, it may cause spurious error messages and/or prevent another 
application from using the serial ports. At this time, if the software 
does not provide a method to disable this behavior, there is no method 
to work around this behavior. Contact your software supplier for a 
corrected, or Windows NT-specific, version of the application. 



   NOTE: Serial communications is not emulated perfectly because of
   fundamental differences between the preemptive and nonpreemtive
   multitasking environments. If an application uses real-time
   hardware interrupts, it may experience problems caused by
   preemptive multitasking in Windows NT. Timing serial events in
   Windows NT may be different than in 16-bit Windows 3.1. Also, the
   ability to directly access hardware is not available in Windows NT.
   If your application directly accesses hardware, contact your vendor
   for a Windows NT-specific version of the application.
-------------------------
Windows NT 4.0 keeps the same setting in the property (right click)
of the MS-DOS-based applications. 


 - If the application is in a window and the video display performance
   is slow, try full-screen mode. Windows NT 4.0  screen folder  provides
   this setting.

 - Disable the Compatible Timer Hardware feature in the _DEFAULT.PIF or
   the application's program information file (PIF) under the
   NT-specific section of PIF Editor. Since this feature causes a
   decrease in performance, it should be used only if it is required to
   make an application to run with Windows NT. Windows NT  program folder
   under  Windows NT  section provides this setting.

 - If the application is in a window and seems to pause periodically,
   try disabling Idle Detection in the Advance section of that
   application's PIF. Windows NT  misc folder  provides this setting
   in a form of a slider bar called  idle sensitivity .

 - If the MS-DOS-based application can be configured for printing,
   choose LPT1, LPT2 over parallel port. Most of the applications use
   Int17 to print when configured for LPT<x>. If you select parallel port
   mode, these applications print directly to printer ports. Parallel
   mode is significantly slower in Windows NT compared to Windows 3.1.

--------------------------------

You can increase available conventional memory (largest executable 
program size) for your MS-DOS-based applications by modifying their 
default AUTOEXEC files and removing the lines that load DOSX and RDR, 
the MS-DOS extender and network redirector drivers. However, this is 
not recommended, as it disables support for many functions, 
including: EMS memory; DPMI services; named pipes; NetBIOS; LAN 
Manager APIs; and the DLC protocol. If you have an MS-DOS-based 
application that requires none of these services, and you need extra 
memory, do the following: 


1. In the System32 subdirectory, make a copy of the AUTOEXEC.NT file.

2. In the new AUTOEXEC file, insert REM commands before the lines
   loading DOSX and RDR.

3. Start PIF Editor and create a PIF for your MS-DOS-based
   application.

4. From the main PIF Editor window, choose Windows NT.

5. In the Autoexec Filename field, enter the name of your new AUTOEXEC
   file.

6. Save the PIF and exit PIF Editor.     


-------------------------------------

The biggest problem is that some FOSSIL applications send the data to the
FOSSIL port one byte after the other and are not using the better block
transfer functions.
(The overhead is very big in a function call since it is redirected to a
DLL which is very time consuming).

Have you locked the port using the /L1 switch.

Another switch which should be used if performance is low is the /A0
switch which disables a sleep after each transfer. (but also cpu
utilization is higher)

So a good choice for calling NTFOSS is:
NTFOSS.COM /A1 /L1 COM2 BAUD=115200 if the modem supports 115200 (if not lock 
the port to a lower speed).

-------------------------------------
Some applications have an "idle curiosity" about serial ports that they 
do not otherwise use. When you run one of these applications in Windows 
NT, it may cause spurious error messages and/or prevent another 
application from using the serial ports. At this time, if the software 
does not provide a method to disable this behavior, there is no method 
to work around this behavior. Contact your software supplier for a 
corrected, or Windows NT-specific, version of the application. 

