-=> Quoting DENNIS JENKINS to RICHARD TOWN <=-
RT>Win3.1 and Win3.11's comm.drv is inadequate
RT>Change to either WFXCOMM.DRV (free with supplied Delrina WinFax)
RT>or Cybercom
DJ> The stock driver is the only thing that really works right with
DJ> Promcomm Plus.
Procom Plus for Windows, yes. But running the DOS version (2.01?)
in a DOS box will need a better driver for Windows 3.1 or 3.11. But
_not_ Windows for Workgroups 3.11. Only the SERIAL.386 should be
updated there, leaving COMM.DRV alone.
QIC HINT FROM PACKLINK/ZOOM MODEM SUPPORT
WINDOWS COMM DRIVERS: Should You Change?
==================== =================
There's been some conflicting thoughts on the use of
cybercom.drv, and other drivers, with Windows for Workgroups 3.11.
Some imply that cybercom will be an improvement, while others state
emphatically that cybercom should *never* be used with WfWG (Windows for
Workgroups). If not cybercom, is there perhaps another third-party comm
driver that does improve WFWG?
Windows 3.1 and Windows 3.11, a cosmetic upgrade with the same com port
capabilities, both include a comm.drv that has limited flexibility in
utilizing a FIFO. It has a fixed setting of 14 for RxTrigger, allowing
only 20 bit-times for responding to the IRQ before overruns occur. Among
the replacements for the Win3.x comm.drv that allow tuning RxTrigger
points under Windows 3.x is a "freeware" driver from CyberCom.
Windows for Workgroups uses a completely different kind of serial
communications structure as compared to Windows 3.x
WFW3.11 has all of the DOS-Window pre-emptive multi-tasking functions
from the "Chicago" project (Win4.0/DOS7.0) which became Win95. It's a
significantly more sophisticated OS than Win 3.1, the cosmetic upgrade
Win3.11, or WfW3.1 - the initial version of WFW. Some speculate that the
introduction of so many "Chicago" features under the guise of a minor
upgrade of WFW (from 3.1 to 3.11) was to be able to bury excessive bug
complaints while saving any major surgery needed to fix the bugs for the
highly visible introduction that became Win95. But only MSFT knows ;-)
Windows for Workgroups 3.11 was actually the test-bed for many of the
features of Microsoft's Chicago project, which produced Windows95.
Consequently, it has many high performance internal structures not found
in Win3.1 or Win3.11. It uses a 32-bit virtual device driver (VxD) called
VCOMM.386 to virtualize the com ports. (A VxD is like a .dll for the
operating system. It can talk directly to hardware in ring-0 "privileged"
mode, unlike .dlls and application programs, which must operate in ring-3
16-bit "protected" mode.) This VxD talks to another, called serial.386,
which actually talks to the FIFO.
The WFW comm.drv has the same Application Program Interface (API) as the
Windows 3.1 comm.drv, in order to maintain compatibility with
communication application programs. However, API-compatibility
notwithstanding, they are very different on the other end - the part that
talks to the com port.
Application programs still issue their serial communications API function
calls to a 16-bit ring-3 dll called comm.drv. However, this small
comm.drv is only there to forward their requests to VCOMM. The whole
serial communications architecture of WFW3.11 (and Win95) is quite
different from the "everything-in-a-ring3-dll" (comm.drv) serial
communications architecture of Win3.x, and it yields much faster
interrupt response performance.
A Windows' comm.drv substitute (like cybercom.drv) is no more compatible
with the WFW serial communications structure than the Win comm.drv itself.
In both cases, the comm.drv is an installable driver type of
Dynamically-Linked Library (dll), which has 16-bit, Ring3- (applications-)
level access to hardware resources through a lot of Windows-style
cooperative multi-tasking overhead.
However, the WFW comm.drv is merely a front-end for a Ring0 Virtual Device
Driver (VxD), called vcomm.386 which does all of the actual interfacing
with the comport hardware (actually through another VxD called serial.386)
and is extremely fast. Win 3.1 comm.drvs are unaware of vcomm.386 and
unable to utilize its high-speed access to system resources.
While early versions of serial.386 introduced extra escape characters on
shutting down a com port, and had to be replaced with a new version to
cure the need to re-boot in order to access the port a second time, the
WFWg comm.drv (simple as it is) is not a limiting factor in WFW's serial
communications architecture.
That bug consisted of serial.386 sending gratuitous extra null
characters to the com port on exit. The effect was to lock-up the port
for subsequent programs that tried to open it, an effect clearable only
with a hard system reset.
The lock-up only occurred if the port's UART was implemented in an
integrated chip-set that used a common 16550A-equivalent cell (as
opposed to having a discrete 16550A UART chip). The old National chip
would just laugh-off the extra characters, while the integrated
(Standard Microsystems, among others) chip-set would gag.
MSFT claimed that nobody should care about null characters , but
fixed the bug with a new serial.386 (10620 bytes, and dated 2/17/94).
Neither the Windows comm.drv nor any of its replacements (like
cybercom.drv) are designed to properly talk to VCOMM in Windows for
Workgroups (unlike the WFW comm.drv). Since it's only designed to talk to
VCOMM, rather than to a com port, you can't use the WFW3.11 comm.drv in
Win3.x.
If you have overruns, you'll probably find that their cure is associated
with the configuration of the rest of your system (FIFO-equipped com port,
windows system.ini settings, video card driver, hard disk driver, BIOS,
etc.), especially those subsystems whose IRQs have a higher priority than
com port IRQs, and can keep the CPU too busy to empty the com port in time.
Comport drivers available at PackLink 2:254/235 01812972486 are:
For Win3, 3.1, 3.11
-------------------
CHCOMB.386 [02] Cherry Hill Windows 3.x comms driver (the Microsoft docs
mentioned one)
CYBERCOM.ZIP [06] Hi-speed windows comms driver
WFXCOM.ZIP [09] Windows communications driver to replace COMM.DRV Now
in public domain. From Delrina. In use at PackLink
For WfWG
--------
WG1001.EXE [02] WG1001: UPDATED SERIAL.386 DRIVER FOR WINDOWS(TM) FOR
WORKGROUPS
For Win'95
----------
Stay with the supplied COMM.DRV Or switch to FaxWorks' FX-COMM.DRV
Ver3.00e or g by Global Village.
rgdZ
Richard
--- FMail/386 1.02
---------------
* Origin: Another message via PackLink +44(0)1812972486 (2:254/235)
|