Copyright (C) 1993-1994 Stefan Welch
All Rights Reserved

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

This file is copyrighted by Stefan Welch, 1:125/544, and may not be sold
or conveyed for profit in any manner.  It is "shareware", and may be
freely distributed in its unmodified form via electronic, physical, or
other media so long as the body of the text is not changed or altered in
any manner and so long as any charges for such distribution do not exceed
actual costs of media, shipping, and handling, not to exceed a maximum of
$10 per media.


Under the shareware concept:

If you find information in this file useful, I'd love to know.  Drop me a
line.  If you find errors, please forward them.  If you have further
comments from your experience in running DOS communications under Windows,
please send them along to me.  Thanks.


Disclaimer of Warranty:

THIS FILE AND INFORMATION ARE DISTRIBUTED "AS IS" AND WITHOUT WARRANTIES
AS TO PERFORMANCE OF MERCHANTABILITY OR ANY OTHER WARRANTIES WHETHER
EXPRESSED OR IMPLIED.  Because of the various hardware and software
environments used in data communications, NO WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE IS OFFERED.

Good data processing procedure dictates that any program be thoroughly
tested with non-critical data before relying on it. The user must assume
the entire risk of using the information provided.

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

Tips for running DOS communications multi-tasked under Windows:


When running DOS communications under Windows, often the first topic that
surfaces is obtaining an appropriate PIF file.  While PIF file settings
are important, the PIF file is a small part of what is needed to run DOS
communications under Windows.  I have the D'Bridge mailer (distributed by
Mosaic Press) as well as a number of other DOS communications applicatons
runnning under Windows here.  I'm running ok at 14.4 (v32b v42b) with 1650
cps, no errors, multi-tasked in the background. Also have had multiple
14.4 com sessions running concurrently ok. The Windows configuration has
mannnny details.  While DOS communications under Windows isn't technically
elegant, and it's a small miracle that Windows will accept FOSSIL drivers
as well as it does, here are some pieces to help get you started:

1) A 16550 UART on the serial port is verrrrrry helpful for high character
rates. This chip can buffer a small amount of the incoming data stream and
reduce the I/O interrupt rate the CPU needs to handle.

2) To make the 16550 work well with Windows, efficient VCD (Virtual
Communications Device) drivers help.  The VCD drivers handle DOS comm
under Windows and are configured in system.ini.  Be aware to not confuse
replacement VCD drivers with replacement COMM.DRV drivers.  Windows uses
the VCD driver(s) to manage DOS communications programs under Windows.
Windows uses COMM.DRV (or replacements *.DRV) to manage Windows
communicatons programs under Windows.  Note that replacement *.DRV drivers
will not help run DOS communications programs under Windows.

The native Windows VCD drivers are not known for efficient operation and
do not effectively support 16550 UARTs. Turbocomm drivers do a good job.
Turbocomm also comes with a manual that describes in good detail how to
set parameters in system.ini for VCD sessions.

Turbocomm drivers are available from Pacific Commware.  They may also be
available from Egghead soon.

Pacific CommWare
180 Beacon Hill Lane
Ashland, OR 97520
Ph. 1:  1-503-482-2744
Fax:    1-503-482-2627

3) PIF advanced settings need to give the DOS comm application enough 
timeslice in the foreground/background priorities to get the job done. The 
timeslice needed can usually be determined experimentally. One can also 
build a small spreadsheet to help compute desirable timeslices. The 
Windows Resource Kit has a good description of how Windows handles 
foreground/background priorities. Achieving a good balance of timeslices 
is _essential_ for proper communications operation.

4) To help smooth out the CPU time given to the DOS communications
application, it is usually recommended to set the Windows Minimum
timeslice to 10 msec (default is 20) in the 386 enhanced section of the
control panel.

5) "Detect Idle Time" setting: there are contrasting schools of thought on
this setting. Some say to select this setting, others say to de-select.
Microsoft describes that "Detect Idle Time" will tell Windows to see how
much of the timeslice a DOS session used on the last time it took CPU
cycles and then have Windows predict how much time it should give the DOS
session the next time Windows gives it CPU. Such being the case, Microsoft
has recommended having "Detect Idle Time" not selected for communications
applications.  Turbocomm documentation suggests the opposite setting.  I
have been running successfully with "Detect Idle Time" not selected.

6) If you have 32-bit disk access turned on in the Windows Control Panel
386 Enhanced Virtual Memory settings, Microsoft recommends that "Lock
application memory" be selected in the PIF for DOS communications
applications.

7) Load the FOSSIL in the DOS communications session (rather than in your
config.sys). I have also found that BNU seems to be a better fit than X00
when running under Windows.  When using BNU I have been able to set the
timeslice much lower and still get good character rates without errors.

8) FOSSIL settings:  Lock it of course.  There is some debate over other
FOSSIL settings.  A) To most smoothly utilize the CPU in multi-tasking it
is usually recommended to lock the FOSSIL at the lowest rate that will
accommodate your normal maximum character rates.  B) 16550 trigger levels
of 8 and 14 are usually suggested.  At high character rates, 14 may not
give the CPU time to respond to an interrupt before the UART overflows. 8
is less likely to lose characters, and has a slightly higher interrupt
overhead.  I've been using 8 successfully.  C) FOSSIL Tx and Rx buffer
sizes may interact with VCD buffer size set in system.ini.  I do not have
good theoretical or experimental info in this area. However, the usual 2k
buffers for high character rates have been working successfully. (Possibly
these FOSSIL buffers can be much smaller when running under Windows with
the VCD buffers doing most of the work.  On the other hand, possibly,
smaller buffers will not work well with block mode transfers implemented
by some communications software for high speed communicatons with 16550s.)

There are other refinements, however, if you get all these implemented I
expect you'll be pretty close.  I'd be happy to address any other
questions you have along the way.  If you'd like to see the PIF file I
use, you can Freq DB_PIF.ZIP from me, which includes a PIF and a few more
notes.

Regards,

Stefan Welch


