25 Jun 1995
Windows 3.1 uses the services of DOS, the DOS device drivers, and the BIOS to access disk files and some hardware devices. Because DOS and BIOS only operate on buffers below a megabyte, this typically involves moving data between Windows memory above a megabyte and the DOS 640K area. Windows then has to return to the ordinary DOS mode of execution in order to make the DOS or BIOS call using the INT instruction. Results have to be reflected back to the application program running in Windows memory.
Windows does not use DOS services for the display, mouse, or keyboard. Its use of these devices is much more sophisticated than DOS drivers can support. Windows for Workgroups 3.11 takes the next major step, by moving IDE disk I/O and most networking support away from the DOS environment and under the control of Windows. Windows 95 (Chicago) will complete the process by moving most of the remaining I/O (mostly SCSI disk and CDROM support) into Windows, eliminating the dependency on DOS device drivers.
An application program needs to read a file on disk. Under Windows 3.1, the request would be passed on to DOS through the INT 21 interface. If the file was on a local hard disk, DOS would interpret the FAT directory, locate the file, and read the sectors off disk using BIOS calls. If the file was on the network, the request would be passed on to DOS device drivers and resident routines that represent the Microsoft or Novell network Redirector. They would in turn be passed on to the LAN adapter card and, through the LAN, to the file server.
When a file request is issued by a Windows program under WFWG 3.11, the system checks to see if 32-bit file access and disk support are enabled. Such support is available for the most popular desktop configurations with IDE hard disks. When this is the case, Windows contains a driver that can manipulate the disk hardware directly without using DOS or BIOS. In particular, Windows must be able to interpret the FAT directory structure, manage the disk cache area, and translate the request into hardware values such as cylinder, track, and sector.
WFWG 3.11 disk support replaces any support provided by DOS or the BIOS. In particular, any storage allocated by SMARTDRV for disk caching is ignored. Windows supplies its own VCACHE buffers. Therefore, SMARTDRV should not be used on systems that run WFWG 32-bit file support.
WFWG 3.11 disk support includes the ability to perform asynchronous disk I/O. In theory, an application can start a disk request, then go perform other work until it completes. However, no applications use this interface, and it is unlikely that any will be developed until Chicago upgrades the support with multithreading.
WFWG 3.11 also supports internal 32-bit LAN drivers for popular LAN adapter cards and for specific network protocols. If the workstation user connects to other Workgroup and NT servers using NETBIOS, or uses the Internet with TCP/IP, then all the network activity will bypass DOS. If a Novell server is used, however, the LAN support will be installed in DOS as a resident routine and WFWG will go through the same path as plain Windows 3.1.
The presence of some 32-bit internal VxD components does not change the external program interface. The same WIN32S package that installs in Windows 3.1 can also be installed in WFWG 3.11. As before, all 32-bit requests are simply translated to 16-bit requests before execution.
WFWG 3.11 offers many of the structural changes that most people associate with Chicago. Since it maintains the standard Windows user interface, the changes are less obvious. It may be argued that the difference between the two is more in their advertising budgets than in their code.
A user first loads DOS. DOS loads drivers and resident routines for odd devices (SCSI cards, CD-ROMS, and the Novell network). Then WFWG starts up. The 16-bit Windows support handles all the usual GUI issues. For IDE disks, common network adapters, and requests to Microsoft network servers, all of the file system management, disk support, and network functions can be handled by Windows drivers in the Windows environment. Requests are only passed to DOS for the odd devices (SCSI, CD-ROM) and for the odd networks (Novell).
Although the publicity may suggest that Chicago is a major step forward, it is simply an incremental refinement of previously provided support. At some point however, a boundary is crossed and the glass becomes half-full instead of half-empty. That is a milestone that certainly deserves recognition.
Continue Back PCLT
Copyright 1995 PCLT -- Surviving the Next Operating System -- H. Gilbert
This document generated by SpHyDir, another fine product of PC Lube and Tune.