Windows for Workgroups 3.11

Previews of two new technologies--Chicago and At Work--make this the most advanced version of DOS-based Windows now available

Jon Udell

I've long thought Windows for Workgroups a vastly underrated product. The original version (3.1), dubbed Windows for Warehouses, languished in part because the MIS crowd saw its peer-networking capabilities as a security risk. That view seemed shortsighted to me. Peer file sharing was always an optional feature of WFW. Subtract that, and WFW would still be an extremely useful complement to a server-based LAN. Mail, group scheduling, Clipboard sharing, and network DDE are powerful enhancements to the basic NetWare file and print services. Thanks to WFW's dual-shell capability, a Windows workgroup enjoying these extra services can coexist comfortably with a preexisting NetWare LAN.

WFW 3.11 improves on the original version in ways that preview two new technologies that are strategic for Microsoft. Its new 32-bit file and network I/O move toward the protected-mode device-driver model we'll see in Windows 4.0 (aka Chicago). And version 3.11's fax software plays into the smart-office initiative known as At Work.

What about those MIS security concerns? Version 3.11 enables an administrator to control file, print, and Clipboard sharing. An encrypted file stored locally on each WFW 3.11 machine selectively enables or disables these features. An administrator can force the security settings stored in that file to synchronize, at start-up, with canonical settings stored on the network. With version 3.11, an administrator can also choose to reform version 3.1's troubling habit of caching passwords, arguably its worst security flaw.

On the Road to Chicago

The big story isn't security, however. New 32-bit file and network I/O technologies put WFW 3. 11 a half-generation ahead of any current DOS-based version of Windows--and within shouting distance of Chicago. Like many newfangled Windows features nowadays, these are implemented as VxDs (virtual device drivers) that run in a true 32-bit environment unavailable to normal Windows applications.

Most Windows users got their first taste of 32-bit device support in the form of FastDisk, the protected-mode BIOS interceptor that debuted in Windows 3.1. On machines with WD1003-compatible (or older ST506) drive controllers--this covers most Windows machines, including the majority now sold with IDE controllers--Windows 3.1 can hook INT 13h and talk directly to the hard drive, bypassing the system BIOS.

The full implications of this technique weren't always apparent to users, though, because of a quirk of user-interface design. You enable FastDisk in the Virtual Memory dialog box that's accessible from the 386 Enhanced section of the Control Panel, a dialog box primarily used to configure the swap fil e. Knowing that Windows bypasses DOS and uses low-level BIOS calls to communicate with a permanent swap file, many users assume (not unreasonably) that FastDisk applies only to this special case. In fact, it works for all files.

FastDisk can help performance in several ways. WDCTRL, the VxD that talks to the drive controller, will in many cases be faster than the system BIOS. Use of WDCTRL eliminates one costly switch between protected mode and real mode. And WDCTRL can sometimes handle I/O asynchronously, letting Windows do other work while a request completes.

Sending DOS to the Sidelines

With FastDisk intercepting the BIOS, the bottleneck is DOS itself. Under Windows 3.1, it's still necessary to switch from protected mode to real mode so that DOS can look up the location of a requested piece of a file in the FAT (file allocation table) and then back to protected mode, where WDCTRL can field the resulting INT 13h call.

Why not take DOS out of the loop as well? That's what WFW 3.11's 32-bit file access feature does, using a pair of new VxDs. VFAT.386 delivers protected-mode INT 21h services, and VCACHE.386 is a protected-mode replacement for the SmartDrive disk cache. As with FastDisk, and still a bit confusingly, you enable this 32-bit feature (per drive) by way of the Virtual Memory dialog box.

The results can be impressive. An Advanced Logic Research Flyer 32LCT 4DX2/66 with an IDE controller more than doubled its sequential file I/O throughput using the VFAT/VCACHE combo, while bettering its random file I/O throughput by about a third. But on an Everex Step 486DX2/50 with an Adaptec AHA-1742 controller, and an IBM PS/2 Model 90 XP 486 with an IBM SCSI-2 controller, the story was quite different. Here, random file I/O throughput improved by 73 percent and 83 percent, respectively. These marks were close to (for the Everex) or better than (for the PS/2) those posted by Windows NT on the same two machines. But in both cases, 32-bit file access hurt sequential file I/O performance. The PS/2 lost a fifth of its 16-bit throughput; the Everex lost a fourth. This degradation made application load times noticeably slower on the two SCSI machines.

As you've probably now realized, VFAT and VCACHE don't require FastDisk--although they do prefer it. That's fortunate, because controller manufacturers didn't support FastDisk as unanimously as Microsoft hoped they would. Some companies, including Ultrastor and Future Domain, offer FastDisk drivers for their SCSI controllers; others, notably Adaptec, do not.

You should note, therefore, that VFAT and VCACHE seem to perform rather differently on FastDisk and non-FastDisk systems. If you can use FastDisk, 32-bit file access seems like a clear winner. But if you can't, don't assume it will boost throughput in all cases. You should probably test your bread-and-butter applications with and without VFAT/VCACHE to determine whether they help or hinder.

You should also know that while VCACHE unifies caching for local hard drives (VFAT) and remote ones (VREDIR), it won't cache floppy or CD-ROM drives. To cache these, you'll still want to use the provided SmartDrive 5.0 (which also comes with MS-DOS 6.2).

32-bit Networking

The 32-bit networking components of version 3.1 included the NetBEUI transport, the NetBIOS interface, the server, and the redirector. Version 3.11 adds 32-bit (NDIS 3.0) adapter drivers and a 32-bit SPX/IPX protocol stack with a Novell-compatible NetBIOS. A 32-bit TCP/IP stack is in the works, too, but unfortunately it didn't ship with version 3.11.

Using NetDDE to ship a 50-KB chunk of data between two stations, I found the 32-bit network-card NE2000 and SMC drivers to be 25 percent faster than their 16-bit counterparts. As with the 32-bit disk and file technology, the dominant effect is almost certainly the reduction in protected-to-real-mode switching.

Configuring for the test, however, proved more challenging than I'd have thought. For a given protocol, WFW 3.11 offers four driver options: Novel l's ODI (Open Data-Link Interface), real-mode NDIS, real- and protected-mode NDIS, and protected-mode NDIS. You use the ODI option for NetWare connectivity or if your adapter lacks bundled NDIS support. With ODI, you can access network hardware in real mode only. The NetWare shell, of course, runs in real mode, too, but you can still layer on that foundation either or both of the 32-bit transports (i.e., NetBEUI and SPX/IPX) for use by the Windows networking components.

Real-mode NDIS, like ODI, puts 16-bit adapter support underneath 32-bit transports. The real-and-protected option, confusingly, installs 16- and 32-bit adapter support; Windows uses the 32-bit code, but the 16-bit code is available for use in DOS. Finally, protected-mode NDIS installs and uses only the 32-bit NDIS 3.0 driver.

To make things even more interesting, WFW 3.11 installs both NetBEUI and SPX/IPX transports on top of whichever flavor of driver you choose and makes SPX/IPX the "default" protocol. The availability of a rou table protocol, namely SPX/IPX, is a great thing. As I discussed last month, you can dispense entirely with NetBEUI in this version of Windows for Workgroups and run file, printer, and Clipboard sharing solely on SPX/IPX.

If you happen to operate a NetWare WAN (wide-area network), this arrangement WAN-enables Windows networking in a way that was never before possible. But I ran into problems using the SPX/IPX stack (and its companion NetBIOS) with WFW's NetDDE. When SPX/IPX was the default protocol, Clipboard sharing and other light-duty NetDDE operations worked, but the 50-KB transfer I used to measure over-the-wire performance failed.

The same transfer worked flawlessly when I used NetBEUI as the default transport. So while my NetDDE test didn't satisfy my curiosity as to whether NetBEUI or SPX/IPX is the faster 32-bit transport, it did raise concerns about the suitability of SPX/IPX as the preferred transport for Windows networking.

The Fax Connection

The Chicago technology in WFW 3 .11 is tantalizing, if a bit rough around the edges. Microsoft's At Work technology that debuts in version 3.11 is equally tantalizing and, while limited in scope, quite successful. At Work is an umbrella standard that Microsoft hopes will enable PCs, telephones, printers, copiers, and fax machines to cooperate intelligently on a network. A compliant fax machine, for example, will run the At Work operating system (a 16-bit real-time preemptive multitasker) and will present a touchscreen user interface based on a subset Windows API. (Prototypes of these smart fax machines were shown at last fall's Comdex.) A pair of fax devices will be able to exchange not only conventional faxes, but also compact binary attachments that survive as editable documents.

How does this differ from E-mail? It doesn't, really. For PC Fax, the At Work-compliant fax-server software in WFW 3.11, fax is E-mail. A sender need actually render an image of a document only when the receiver indicates it cannot receive a more compact and infinitely more useful binary transfer.

The current limitation is that there aren't any At Work devices other than WFW 3.11 PCs. Thus, for most users in the near future, PC Fax will operate as a conventional fax server. In that capacity, however, it excels. Outbound and inbound faxing on one WFW machine with an attached SupraFaxModem was trivial, as was sharing that modem from another WFW machine. Because PC Fax is implemented as a form of E-mail, you can broadcast to a mixture of E-mail and fax destinations using a single distribution list. Equally important for integrators, you can send faxes programmatically using simple MAPI (Messaging API).

Announced last June, At Work has now begun to emerge from shrouds of vapor. It's a grab bag of rendering, communications, and real-time operating-system technologies, none of which is by itself earthshaking. But if vendors buy into this vision of smart networked office equipment, At Work could do more for millions of workers than any version of Wind ows.

---

Jon Udell is a BYTE technical editor at large. You can reach him on the Internet or BIX at judell@bix.com .