Windows NT 2 Feb 1995
The second widely released test version of Windows 95 (code named "Chicago") has been shipped to 40,000 Microsoft customers. Several articles on system structure have appeared in the Microsoft Systems Journal. Microsoft has also placed public documents on the Internet. FTP to ftp.microsoft.com and examine the contents of the directory /peropsys/Win_News. There is also a book Inside Windows 95, but it's discussion of key technical items seems to be less open or honest than the more informal publications.
If you have not received a test copy of Chicago, consider the following recipe. Start with a standard desktop computer (486, IDE disks, standard network card). Install a copy of Windows for Workgroups 3.11. Enable the 32-bit drivers for the file system (FAT) and the hard disk. Now apply two optional packages from Microsoft: the 32-bit TCP/IP package (code named "Wolverine" and available from ftp.microsoft.com in /peropsys/WFW/tcpip) and WIN32S (available from ftp.ncsa.uiuc.edu in /PC/Windows). Finally, add a desktop enhancer like HP NewWave or something from Norton or Central Point.
The result is not exactly Chicago, but it is fairly close. File names are still restricted to eight characters, with a three character extension, while Chicago allows long names. WFWG lacks multithreading, but supports the rest of the WIN32 subset interface. SCSI and CDROM requests still go through DOS, but IDE file and disk I/O will operate through 32-bit drivers that run in the WFWG environment. A more accurate statement might be that WFWG 3.11 was a "very early beta of a preliminary version" of Chicago.
Microsoft would argue that this recipe trivializes a ton of improvements in the human interface, and it ignores some initiatives such as a generic E-mail interface based on MAPI and a generic telephone dialer that handles both terminal traffic and fax. Admittedly, Chicago is something more than Windows for Workgroups 3.5 with a better publicist. But most of the press coverage of Chicago will overstate the changes. Chicago completes a migration that has been going on since Windows 3.0. Each new release has moved more function into VxD's and other Windows components. Each has tried to simplify and automate the installation and configuration. Chicago completes the migration, and as with any other completed project, it uses the opportunity to finally "cleans house." This generates a number of very visible changes. However, some of the major features turn out to be more a matter of terminology than substance.
A WFWG system starts by loading a real DOS system, including its device drivers. Then WFWG starts up and loads its VxDs. I/O to supported networks and IDE disks are handled by the Windows drivers directly through to the hardware. When a request is made for a device with no native Window support, it is passed down to real DOS where it can be processed by the DOS device driver.
When Chicago boots, the Windows Virtual Machine Manager (VMM) initializes itself and loads the VxD modules that were previously Windows device drivers. VxD drivers exist for IDE and SCSI disks and for the extended VFAT file system. The network support loads support for Windows NT and Novell servers. Since this support runs as a VxD, it can be loaded into memory above the first megabyte of RAM. Although VxDs support Windows applications, they also support DOS programs running under the control of the VMM. Therefore, the command shell of Chicago will have access to extended features (such as long file names) that real DOS device drivers and file systems would not support.
However, there are still occasional odd devices that only have DOS device drives. Chicago must still support them. So at this point, the VMM creates a "DOS Virtual Machine" that is actually fairly real. It loads into the fairly real DOS virtual machine any drivers that it finds mentioned in the CONFIG.SYS dataset, and any resident routines that it finds mentioned in AUTOEXEC.BAT. Later on, when Chicago receives a request for a device with no native VxD support, it uses the Real Mode Mapper (RMM) to pass the request down to the fairly-real DOS where the old driver can process it (synchronously and using buffers in the 640K area).
A major feature of Chicago is that it "gets rid of DOS." Technically, this is a correct statement. However, the DOS programs are simply merged into the \WINDOWS directory and the DOS system function is repackaged. This new version of DOS supports long file names, and \\SERVER\SHARE\FILE.EXT syntax wherever a file or directory might appear. However, the change is still evolutionary and not radical. There has been a shift in emphasis. The glass switches from being half empty to half full. Or put in another formula:
We used to run Windows under DOS,
but Chicago runs DOS under Windows.
The Chicago installation process borrows some of the technology that Microsoft developed for NT. Through a sequence of software probes, the installation program determines automatically the type of display adapter, keyboard, mouse, disk, LAN adapter, CD-ROM, and sound card installed in the machine. It automatically configures the correct drivers. New adapters conforming to the Plug-and-Play standard will be automatically configured. Chicago installs proper support for PCMCIA. Users will find this to be substantially easier than the installation of DOS support for similar devices.
Although WFWG simplified the installation of MS networking, it greatly complicated the installation of Novell clients and TCP/IP. Chicago comes with a complete, integrated networking package. The NETBEUI support can be used for locally attached LANMAN, NT, or OS/2 file servers. The same configuration process installs a Microsoft-written Novell client, a Microsoft TCP/IP package, and support for remote dial-in LAN access using the industry standard PPP protocol.
As different functions rolled out over the years in different releases of Windows, new configuration tools were added to the user interface as needed. Before Chicago, a Windows user wanting to change the display resolution needed to run \WINDOWS\SETUP.EXE from DOS (outside Windows). Changing the network adapter is done with the Network icon in Control Panel. CD-ROM support is added in CONFIG.SYS.
Windows NT 3.1 demonstrated that it is possible to get rid of DOS and install things automatically, yet still leave a muddled mess of configuration. Users have to memorize by rote the rules that SCSI adapters and tape drives are installed with the Windows NT Setup icon, but sound cards are installed with the Drivers icon. But the user interface of Windows NT was designed to match WFWG as closely as possible.
Chicago makes a modest effort to clean things up. There is a New Device Install Wizard that helps the user to install any new card no matter what type of device it may be.
Chicago evolved. If you want a system with some design, look at OS/2. If you want a system with a detailed, elegant, advanced design look at Windows NT. Chicago is the result of compromises, like a bill reported out from the Senate Finance Committee. The most important feature of a Senate bill is that it have 51 votes (60 if you have to cut off debate). Since Chicago is designed to replace Windows 3.x and DOS 6.x, its most important requirement is to support nearly 100% of the programs that ran under the old systems. It has to fit in a four megabyte machine and deliver performance comparable to the earlier systems. Like politics, you would do well not to question how these goals were accomplished if you lack a strong stomach.
To develop the system as quickly as possible, to provide maximum compatibility, and to maintain good performance for existing Windows applications, Chicago also obeys the design principle, "if it ain't broke don't fix it." Many of the existing, tested 16-bit DLL routines in Windows 3.1 are reused. New code, such as the disk and network device drivers, are written as 32-bit libraries. Both 16-bit and 32-bit applications are supported. Requests are thunked from one addressing mode to the other as needed.
Suppose a program makes a mistake. Can it crash the system? If not, will it damage any other programs that are also running? In Plain Old Windows and Chicago, the answer is clearly Yes to both questions. In Unix, the answer is clearly No.
For thirty years, operating systems have been designed to protect themselves. The application program runs in its own memory and is unable to change system data. All services filter through a mechanism that converts from the unauthorized application mode to a privileged system mode. Native OS/2 programs work this way, as do WIN32 programs running on NT.
However, the WIN16 interface was never designed to permit isolation. This is why IBM was sure, in 1988, that Windows was a lousy system and everyone would migrate over time to OS/2. WIN16 programs run with a shared set of memory segments, shared control blocks, and shared DLLs. When a WIN16 program writes something on the screen, it doesn't call another process, address space, or subsystem. It calls a subroutine that helps the program to display the data directly on the display.
This reflects the old DOS/Windows spirit. Every program is authorized. BIOS and DOS calls are useful, but optional. DOS is a set of services that the program calls to do something it could do itself, but does not want to bother with. WIN16 is explicitly designed as a set of subroutines that cooperating programs call to coordinate their direct use of system hardware resources. But WIN16 assumes that the programs all run in a common memory and share the control blocks that determine where the window are on the screen and which window is on top.
Running all the programs together with a common set of control blocks saves memory and speeds up processing. However, if a program makes a mistake, it can crash the system.
OS/2 and Windows NT 3.5 (Daytona) can provide some isolation by running more than one virtual machine with more than one copy of the WIN16 system. Each such machines, however, uses about two megabytes of RAM to hold the USER-GDI-KRNL libraries and control blocks. Since Chicago is designed to run in typical desktop systems with four megabytes of RAM, it cannot afford isolation. Thus all the Chicago WIN16 programs have to share a common virtual machine.
Unfortunately, there is one more step in the logic. Native OS/2 PM programs can run in separate address spaces because Microsoft and IBM defined PM to avoid the limitations of the WIN16 interface. In Windows NT, WIN32 programs can run in a separate address space because NT is natively a 32-bit operating system and all the screen management is physically handled by the WIN32 subsystem (in NT, all WIN16 programs are thunked to WIN32 requests). However, Chicago reuses a large part of the old WIN16 USER-GDI-KRNL DLL support. Many WIN32 calls are thunked down to 16-bit calls to the old WIN16 library modules. Those modules assume shared memory and a common set of control blocks. Therefore, under Chicago even WIN32 programs have to share the same virtual machine with each other and with the WIN16 routines.
There is a bit of flimflam in the Chicago hype that deserves special note. Chicago is able to rearrange the page tables so that WIN16 programs cannot directly address WIN32 program storage, and WIN32 programs cannot address each other's storage. But that does not provide real program isolation. All WIN16 and WIN32 programs can address the Windows system control blocks that govern things like events and windows. Clobber one of these data areas, and the whole system fails.
IBM and Microsoft delivered OS/2 in 1988. OS/2 isolates applications and provides system integrity. If the users really cared about program integrity, they would have converted to OS/2. Windows 3.0 did not have integrity or advanced structural features. It was small and ran nice applications. Users loved it. Chicago simply continues the emphasis of size, speed, and interface over internal structure and clean program interfaces. From the view of a system designer, OS/2 is an objectively "better" system. However, most users are not system designers, and to them, a better system with no applications is not as good as a mediocre design with zillions of great programs.
Besides, Microsoft would add, if anyone cares about structure and integrity, then they should consider Windows NT.
Chicago has major advantages in installation, configuration, and ease of use. These are not, however, topics under consideration in this series of articles. Structurally, Chicago adds VxD support for most of the commonly used devices and largely disposes of DOS drivers and BIOS. There is a residual Real Mode Mapper to simulate the DOS environment for really odd devices (say Localtalk adapters) that have no native VxD support.
Chicago is a hybrid system. It preserves the old 16-bit components whenever a system service has not changed. New 32-bit components are added mostly for new kernel functions (multithreading, storage management, etc.). WIN16 and WIN32 applications are both supported. When the application program and system service use different memory models, the call is thunked.
When Chicago was to be released in 11/94, it made sense to consider it in short term planning. Now that the release has slipped to 8/95, it may be necessary to consider alternatives. If Chicago will not be available soon enough to meet your needs, then Windows NT 3.5 Workstation should be given serious consideration. It also provides a stable WIN32 platform and extensive network support. NT requires an additional 4 megabytes of memory above whatever would be needed for Chicago. On the other hand, the NT user interface is nearly identical to the Windows for Workgroups interface, so NT requires very little retraining.
Return to the Table of Contents
Copyright 1995 PCLT -- Surviving the Next Operating System -- H. Gilbert
This document generated by SpHyDir another fine product of PC Lube and Tune.