TIP: Click on subject to list as thread! ANSI
echo: hs_modems
to: DENNIS JENKINS
from: RICHARD TOWN
date: 1997-03-23 11:01:00
subject: [2/2] Re: Hi-Speed

 -=> 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)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.