-=> Quoting Bob Shankie to Richard Town <=-
 BS> *** Quoting Richard Town to Stuart Wright dated 03-15-97 ***
 >  SW> SYSTEM.INI file:
 >  SW> COMM.DRV=COMM.DRV
 > Win3.1 and Win3.11's comm.drv is inadequate
 > Change to either WFXCOMM.DRV (free with supplied Delrina WinFax)
 > or Cybercom
 > Win3.1/3.11 and WfWG 3.11 will not adequately support 115k2
 > First two are rated at 57k6. (havn't seen any comms docs for
 > WfWG3.11)  Still need to adjust the WIN.INI
 > 
 BS> You make those statements like they are incontrovertable fact and the
 BS> TRUTH is that they AIN'T.
I'm concerned with comms in a multi-tasking environment, ensuring that
peeps that report comms problems have all variables limited to
a known working reliable state.  That done, then if probs still occur
then the tracking of the glitch is so much easier (it says here :)
 BS> Simple FACT.  Been there and DONE that with the standard COMM.DRV for
 BS> BOTH! It isn't simply communicating that is a problem but rather the
 BS> multitasking that one tends to do in Windows cause it is supposed to be
 BS> a multitasking environment.  THAT is what mucks things up and requires
 BS> BETTER 16550 support.
Yup
 BS> IF ALL one were doing is running their comm app,
 BS> there wouldn't be a problem. Even the lowly XT can do 115200bps DTE
 BS> rates.
Oh, not disputing it can do the rate.  But can it do it reliably, writing
to disk without any lost bits?  Rather you than me...
 BS> Really, it CAN.  Don't even DREAM of ANY sort of multitasking
 BS> though.  And that usually means do NOT use a write cache.
And clatter your disk heads to death.  Better tho that you write to
RAM and then copy to disk after comms is
complete with an XT.
 BS> But suffice to say that the limitations you note as regards Windows
 BS> COMM.DRV are really NONEXISTANT.
That's your opinion.  I don't intend to change mine,
nor the advice offered.  But would refer you to the previous post,
written by one of the earlier members of the Chicago project.
I 'spose that Cybercom's work was totally unnecessary and that
Delrina wasted all that time and energy too in writing their own
driver for Win3.1?  And if you don't believe either me, Delrina,
the experience of millions of Win3.1 users, then try MuSoft themselves
which initally recommended changing their own to Cherry Hill's
 BS> you contend they don't.  Even more.  The W4WG driver IS entirely
 BS> adaquate to the task.  The replacement drivers offer more control etc,
 BS> but the W4WG drivers DO WORK.
I've never said to change comm drivers in WfWG3.11 (nor Win'95, nor
NT4 for that matter :)  In fact I've gone out of my way to insist that
the only change to WfWG3.11 is to swap SERIAL.386 for a later
 BS> off to do as you suggest, BUT that is NOT to
 BS> say that one can't get by otherwise since I and others HAVE DONE
 BS> exactly that. 
Hope not on an XT 
rgdZ
Richard
--- FMail/386 1.02
---------------