🚀 go-pugleaf

Leon B. Wood wrote:
> 
> "Albert P. Belle Isle" <belleisl@cerberus-sys.com> wrote:
> 
> >These 32-bit devices get direct "ring0" access to any part of the hardware they want,
> >and gain great speed by not having to go through the overhead functions that apps and
> >DLLs must from "ring3" of the operating system.
> 
> Are you saying that I can get faster communication speed by upgrading
> to WFWG 3.11?
> 
> BTW, if there's an award for most useful person on the Internet you
> have my nomination.
> 
> Leon Wood
> 
> ======================================
> Leon B. Wood     Kyoto  JAPAN
> E-mail: leonwood@mbox.kyoto-inet.or.jp
>         71651.2732@compuserve.com
> Tel:    +81(75)751-8067
> ======================================

Leon:

Thanks for the kind words.

The short answer is: maybe (if you can't get rid of com overruns under Windows, and you 
have a FIFO buffer in your com port).

Your serial communications speed *should* be limited by your modem.

For TCP/IP communications through a SLIP/PPP connection, you can keep yourself from 
achieving that limit with a poorly-tuned WinSock. For *any* modem communications, you 
can also prevent yourself from achieving the modem limit if your system's responses to 
"come empty the com port" interupts are too slow to allow an overrun-free com port rate 
setting that doesn't hold back the modem.

With Windows 3.1, Windows 3.11 or the original Windows for Workgroups (3.1), all 
application programs expecting Windows to tell them when something has arrived in a com 
port's UART must listen-through/talk-to a dll (comm.drv) that gets 16-bit "protected 
mode" access to system hardware resources through a lot of overhead, just like another 
Windows application program.

With Windows for Workgroups 3.11, there's a dummy comm.drv that gives application 
programs the same apparent interface, but which just points to a couple of virtual 
device drivers (vcomm.386 and serial.386) that have 32-bit "privileged mode" access to 
hardware - just like the operating system.

Win 95, also uses this serial communications architecture, as well as WFW3.11's 
separate Virtual Machine for each DOS program window (pre-emptive multi-tasking). (It 
also grants each Windows program its own VM; WFW3.11 doesn't, forcing all Windows 
programs to "cooperatively multi-task," like Windows 3.11 does.)

I've successfully tuned Windows 3.1 systems to eliminate com overruns while allowing 
com port rate settings of 115,200 bps. However, with WFW3.11 it's a much easier job, 
due to the lack of the "wet spagetti" communications architecture through which your 
UART has to push interrupts in plain old Windows. (The slightly improved "freeware" 
replacements for the Win3.11 comm.drv are also just 16-bit dlls, since they have to 
drop into the same structure.)

The overall speed of system response in WFW3.11 also benefits from 32-bit file access 
(as opposed to 32-bit block-mode disk access, which Win3.11 also has). This is also 
done through another virtual device driver (VxD) called VFAT, and similarly reduces 
overhead in reading files. Disk caching is also done through a VxD called VCACHE.386, 
with a similar performance enhancement. (The DOS TSR smartdrv.exe is relegated to 
caching floppies and CDROMs.)

As you can see, WFW3.11 is an entirely different breed of multi-tasking operating 
system than the rest of the Win3x family. It's never been properly recognized as such, 
because a lot of these features were quietly evaluated in WFW3.11 as part of "Project 
Chicago," which finally resulted in DOS7.0/Windows4.0 - marketed as Win95. (If they had 
bombed, I assume that WFW3.11 would have been quietly withdrawn as a "minor upgrade to 
WFW3.1 that had some bugs in it <g>.")

Regards,

Al

-- 
==================================================================
Albert P. Belle Isle
Cerberus Systems, Inc.

Al's Winsock Tuning FAQ -
       http://www.cerberus-sys.com/~belleisl/mtu_mss_rwin.html
==================================================================