2 Feb 1995

DOS was written in 1980 for the Intel 8086 family of CPU chips. In 1985 IBM and Microsoft agreed to develop a new operating system for the 286 CPU chip. OS/2 Version 1 was not delivered until 1988, and by then the 386 was becoming popular. It became clear that hardware was changing much too fast for software development to keep pace. So in 1988 when they decided to do it again, IBM and Microsoft decided to being work simultaneously on two products.

OS/2 Version 2 would be an evolutionary refinement of the previous systems updated for the new hardware features of the 386. It would continue to support applications and device drivers developed for the previous system. This became the current IBM OS/2 product.

OS/2 Version 3 would be based on New Technology. It would start over from scratch and develop a system based on the best current software engineering principles. It would not be biased to the Intel CPU, but would be portable to any modern computer chip. This eventually became Windows NT.

Both systems took longer to develop than expected. Both designs had to be modified in 1990 when Windows 3.0 became such an astonishing success. However, the most important factor in the eventual development of both systems was the breakup of IBM and Microsoft as they discovered their conflict of interests.

IBM developed OS/2 to be the ultimate client in a corporate network where the "big machine" was a mainframe, parallel Power system, or large AS/400. OS/2 was shaped first by SAA and then by a search for something like VisualAge. The objective is to sell lots of power to run inefficient applications that simplify the development of corporate information systems based on centralized authoritative databases.

Microsoft wanted to offer smaller companies the opportunity to expand their information system without requiring an MIS department, a million dollar machine, or a Unix hacker to keep it running. Microsoft wanted the "big machine" to be a multiprocessing RISC system running some version of Windows and SQL Server. By offering a uniform Microsoft family of products across the entire information system, users could benefit from "Information at your Fingertips" without massive retraining or hiring.

Microsoft has a clear vision of Chicago as the client desktop system and Windows NT as the departmental or corporate server. Because there are two systems, Microsoft can let each specialize. Chicago can concentrate on compatibility and size. NT, therefore, does not have to worry as much if Doom or Flight Simulator can't run on it. Instead, NT concentrates on integrity (a program can't crash the system), security (a program can't access protected datasets), reliability (UPS, disk mirroring), and throughput (maximum transactions per second).

Unix and Protestantism both represent enormously successful movements that quickly fragmented into unmanageable, truculent sects. Programs written for BSD don't run on SVR4 Unix. Then there is SunOS, AIX, Ultrix, OSF, Linux, NextStep, USL, and dozens more. All Unix systems share a common set of services, but each has personality quirks that can produce program dependencies.

The Microkernel was an idea developed to reunite the Unix community. A rich set of operating system services (free of all idiosyncratic quirks) is contained in a small, pure system kernel. Application programs do not access the kernel services directly. Instead, they make requests through subsystems programmed to duplicate the personality of a particular Unix system.

The Microkernel idea has now expanded to include non-Unix personalities. IBM is working on a microkernel operating system for the PowerPC. In some diagrams, it will support personalities for OS/2 2.x, AIX, Macintosh, and even AS/400 programs. Windows NT supports OS/2 1.x, WIN32, and Posix (stripped down Unix) capabilities.

Unfortunately, it is difficult to justify the Windows NT design in practical terms. The OS/2 support is too limited to be useful (and is unavailable on RISC systems). The Posix support is similarly meaningless. All the programs that run on NT (16-bit Windows programs, 32-bit Windows programs, and DOS applications) all run under the control of the WIN32 personality. A microkernel with only one meaningful personality isn't a particularly wise design.

WIN32 is the new Microsoft 32-bit programming interface. Where it is possible, WIN32 is compatible with the original 16-bit Windows services. However, the original Windows interface made bad assumptions about shared control blocks. WIN32 has been redesigned to allow the physical separation of applications from each other and from the operating system.

Although the term "Windows" normally refers to the user interface through the screen, mouse, and keyboard, WIN32 includes all of the services found in any large operating system. Routines are defined to allocate storage, load programs, start tasks, handle errors, post events, and perform file I/O. On each system, WIN32 is implemented as a collection of DLL routines that can be called by the application program.

WIN32 is an evolving standard. New routines are added as they become necessary. Windows NT supports most of the WIN32 interface. Chicago supports a subset that excludes security and UNICODE. It is possible to install a more limited subset into Windows 3.x using the "WIN32S" package available from Microsoft through a variety of sources.

The most visible feature of Windows is the user interface. Several application programs can each display information or ask questions through overlapping windows on the screen. One application program is active (has "the focus") and its window is on top. To manage this interface, the Windows system must maintain control blocks in one place so that it is easy to determine the order in which the application windows are drawn on the screen and the program that will receive a message when the mouse is clicked on any particular screen location. If these control blocks were scattered all over the system, the cost of this interface would be prohibitive.

• Windows 3.x and Chicago put all of the system control blocks in the same virtual machine with the application program. When the program makes a request, it calls a subroutine. The subroutine locates the control blocks and uses them to perform the operation correctly.
• OS/2 Presentation Manager puts the control blocks in shared memory. Each application program runs in a different address space, but the screen interface blocks are available to subroutines on demand. They are protected against casual programming errors, but a malicious program could damage them and crash the system.
• Windows NT has a separate address space called the WIN32 Subsystem. It contains all of the control blocks needed to enforce the WIN32 personality and to coordinate output to the screen. Although the Application Program may initially make a request by calling a subroutine in a DLL, that subroutine passes the request on to the separate WIN32 Subsystem for execution.

The Microkernel has to support DOS, Windows, and POSIX programs. Thus the Microkernel can support file names that are case sensitive (POSIX), all uppercase (DOS), or even double-byte UNICODE (WIN32). A POSIX program will create path names separated by a forward slash ("/"). A DOS-Windows program separates path names with a backslash ("\") and it may begin with a disk letter ("C:") that POSIX doesn't use. The WIN32 Subsystem enforces the common set of DOS conventions on the DOS, old 16-bit Windows, and new 32-bit Windows programs.

In order to understand Windows NT, it is important to realize that "WIN32" refers to two separate but interdependent components. First, WIN32 the Application Program Interface is a set of DLL modules mapped into the same address space as the application program. When the program writes to the screen, opens files, or allocates storage, it initially calls the WIN32 DLLs. However, in Windows NT the DLLs don't actually do the work. Instead, they repackage the request and ship it to the WIN32 the Subsystem. The subsystem is a separate component of Windows NT running as a separate process with its own threads in its own address space. It holds the control blocks that allow the system to coordinate requests from the application programs, and it enforces the Windows personality. WIN32 applications are not allowed to call the microkernel directly. Instead, they pass all requests to the WIN32 Subsystem, and it calls the microkernel as needed.

A Windows NT machine can run DOS programs, old 16-bit Windows programs, and new WIN32 programs. All run under the control of the WIN32 Subsystem. But the WIN32 subsystem isn't a part of the operating system kernel. Instead, it is a separate program running in its own address space, just like the application programs. To make this work, NT must supply an efficient mechanism that allows the DOS, old Windows, and new Windows programs to request WIN32 services.

The solution is a Local Procedure Call (LPC). Programmers may recognize this name as a play on words. For many years, Sun's Unix systems have used a technique called Remote Procedure Call (RPC) to transfer file I/O and other requests between a Unix client and a Unix server. Windows NT uses a version of RPC on the LAN to perform remote administration (of accounts, data security, printers, and logs) on server machines. However, the LPC is a much simpler and more efficient service to hand off requests between two programs running in the same machine.

Under Windows NT, each DOS program runs in a Virtual Machine. NT loads into that virtual machine its own dummy version of the DOS operating system. While a real MSDOS system consists of two files named IO.SYS and MSDOS.SYS, NT loads into the virtual machine an alternate version of the same routines named NTIO.SYS and NTDOS.SYS. The DOS application then proceeds as if it were running under a real copy of DOS.

Under Windows NT, each old 16-bit Windows program also runs in a Virtual Machine. Normally, all the WIN16 programs share a single virtual machine called the "WOW". When the WOW starts up, NT loads into it a dummy version of Windows 3.x. As with real Windows, the dummy includes copies of the USER.EXE, GDI.EXE, and KRNLx86.EXE modules. The old applications make 16-bit Windows calls just as if they were running in a real Windows 3.x machine.

Native 32-bit Windows programs each run in their own address space. An address space is essentially the same thing as a virtual machine, but WIN32 programs are well behaved and do not try to do things at the hardware level. Since NT does not have to simulate any hardware devices for these programs, it is enough to give them their own isolated memory area without the rest of the Virtual Machine mechanisms. NT maps 32-bit DLL modules into the application address space to provide the system services of the WIN32 programming interface.

However, all three types of programs (DOS, old 16-bit Windows, and new WIN32 programs) all actually filter their requests through the WIN32 Subsystem. The Local Procedure Call provides the mechanism.

• A WIN32 application program calls routines in the WIN32 DLL library modules that are part of the application program address space. These DLL routines convert the caller's request into an LPC to the WIN32 subsystem.
• A WIN16 application program calls dummy versions of the USER-GDI-KRNL libraries installed in the WOW virtual machine. It can also call real 16-bit DLL modules that application programs have installed somewhere along the path. WOW will not have dummy DRV files, because physical devices are all handled by the WIN32 subsystem. Each user call is eventually thunked to a 32-bit form and is shipped as an LPC to the WIN32 subsystem. Since WIN32 contains every service originally defined in WIN16, all the real work can be done there.
• A DOS program issues an INT 21 call to what it thinks is the DOS operating system, or it issues another INT call to what it thinks is the system BIOS. These calls are trapped by code that resides in the DOS Virtual Machine. That resident code converts the DOS or BIOS operation into the corresponding WIN32 request which is issued by an LPC to the WIN32 subsystem.

As was previously noted, Chicago is forced to run all the WIN32 and WIN16 programs in a single virtual machine. Because NT has a complete, native set of WIN32 services, it is able to run WIN32 applications each in the own isolated address space. A WIN16 program can crash the WOW virtual machine and terminate all the other WIN16 programs. However, WIN16 programs do not effect running WIN32 applications, and WIN32 applications fail individually without effecting any other program.

Well behaved DOS programs run in Windows NT. However, Microsoft has not put much effort into full DOS capability. DOS programs access the hardware directly. To fully support them, it is necessary to either give the DOS programs full authority to do anything they want (as Chicago does), or to build an elaborate hardware simulation similar to the Virtual Device Driver (VDD) interface of OS/2. People do not play games on servers, and anyone who wants to run such programs can get Chicago instead.

How is the system configured? If the question is asked of Windows for Workgroups, the answer is that different information is stored in CONFIG.SYS, AUTOEXEC.BAT, PROTOCOL.INI, WIN.INI, and SYSTEM.INI. OS/2 is even worse. Microsoft has been trying to simplify things through the creation of The Registry.

In Windows NT, the Registry is largely a database constructed from the content of files in the \WINDOWS\SYSTEM32\CONFIG directory. During its installation, NT automatically identifies the type of display adapter, keyboard, mouse, SCSI card, network card, and CD-ROM that is installed on the machine (though the user can correct any errors that it makes guessing their identities). The information about adapters, I/O addresses, interrupt levels, DMA, and adapter memory ranges is stored in the Registry files.

When NT begins to boot up, it loads the Registry files into memory. The information about adapters tells NT which device drivers to load and the order in which they must be initialized. For example, to initialize a SCSI CD-ROM it is necessary to start the driver for the SCSI adapter card first, then load the driver for the CD-ROM device. It will also be necessary to load the driver for the CD file system. In previous systems, this information would have come from CONFIG.SYS. A common problem installing new drivers into DOS or OS/2 occurs when CONFIG statements get put in the wrong order. NT avoids this problem by loading the Registry as a whole, analyzing dependencies, and calculating the required order for driver initialization.

The Registry also contains information previously used to configure the Program Manager (groups and program items), the File Manager (file associations), and the Desktop (background, colors, screen savers). Some of this information is global to all users of a machine. Some is personal to an individual Userid. This is where the Registry gets fuzzy.

By design, the Registry is supposed to offer enough function so that WIN32 programs will not require their own INI file. WIN16 programs (such as Word or Excel) still use INI files. There aren't a lot of WIN32 programs, and the few examples that do exist (such as Mosaic) still have old style INI files. However, at least the applications that Microsoft ships with the system (Solitaire) store their configuration in the Registry.

If an NT Workstation is connected to a Domain managed by an NT Server, then the user at the workstation has the option to logon using an ID name and password define in the local Workstation security database (logging on to the local machine) or in the Domain Controller database (logging on to the domain). Information about the user and his preferred parameters are extracted from the local machine or from the central server and are incorporated into the Registry as information about the Current User.

There is a problem with this design that will have to be resolved as real applications are developed specifically for the NT environment. When an application package is installed on a machine, which of the program parameters applies to all users of the machine, and which parameters are subject to personal customization? Is the default template for Word a global or a private decision? What about the Custom spelling dictionary?

The Registry is a good idea, but it has not yet been clearly defined. Microsoft has gotten away with vagueness because, although Windows NT has been out for a year, there are still no NT applications, even from Microsoft itself. Chicago also includes something called a Registry, so the uncertainties will have to be worked out soon.

Unix has a "console" to which simple character output can be directed. OS/2 has character mode applications that can write to windows or to the full screen. Both Unix and OS/2 allow programs to be launched as the system starts up, and those programs can run and write output to the console without anyone logging on to the machine. In Unix, such programs are called "daemons" and they provide all the network server functions on the machine.

However, the Windows NT design is strongly biased to presenting a GUI interface to every user. An ordinary character mode display appears only at the beginning of the boot sequence as the device drivers and file systems start up.

Windows NT can supply a large number of network services. It is a file server, print server, database server (with SQL Server), and communications servers. Through the Internet, it can act as an FTP server, LPR server (on Daytona), Gopher server, WWW (Mosaic) server, and WAIS server. It can also act as a gateway so that Microsoft clients can access files and printers on Novell networks and (with NTAS) printers on Appletalk.

Network services cannot be provided by a program written like any normal application. Instead, a program that is loaded when the system starts up and runs in the background before any user logs on is called a service. A service is a fairly normal EXE file, except that it is not allowed to communicate directly with the screen and keyboard. It is not just a program without Windows GUI calls. It also cannot display "Hello World" on the screen. A service runs quietly in the background. To display any information about the service, it is necessary to write an ordinary Windows GUI program that the end user can launch after logging on. This foreground program can then contact the service (through a pipe or an LPC), extract status information, and display it in an ordinary window.

Services also have to configure themselves in the Registry. The Control Panel has a "Services" icon that will display the modules configured as services on the machine and allow the administrator to manually start and stop them. Services can also be configured to run in the background under a particular Userid and Password.

For twenty years, most software vendors have searched for a single system that could handle all requirements. DEC ran VMS on big machines and MicroVAX workstations. Unix runs on the desktop and on Power servers. OS/2 is designed as both a Client and a Server.

Microsoft is now the world's largest software company. It doesn't make any hardware. It can afford to design two coordinated but structurally distinct operating systems.

Chicago is the system for the average end user desktop. It runs on a 486 with four megabytes of memory and an 200-300 megabyte IDE hard drive. That matches 98% of the systems offered for sale in Computer Shopper or the New York Times. It is evolutionary, compatible, and efficient.

Windows NT is a complete departure from previous designs. Throw everything out. Start from scratch. Do it right. Use the best technology. Make no compromises. Don't worry about cost.

After studying computer systems for a quarter century, it is clear that there are two ways to design a system. If the system is designed to work well on the vast majority of machines currently available, then it will sell well and generate lots of revenue initially. However, operating systems seem to take around 5 years to develop and mature. Hardware doubles in power every 18 months. Therefore, a system which is ideally sized for its initial availability becomes quickly obsolete. It's the same buying clothes for kids, you get everything a size too large to leave room for growth.

The other approach is to build a system with no architectural limits. It will run on the fastest CPU (RISC chips today). It will run with multiple processors. It can use an unlimited amount of RAM effectively. It can handle large amounts of disk. It can build large files. This provides room for growth on the average machine and avoids embarrassment when other servers "max out" and are unable to handle additional transactions no matter how much hardware you throw at the problem.

Such a system must have additional management and control features. It must not allow an application program to damage the system or effect other programs. It must provide data security for sensitive information. There must be fault tolerance for power problems and disk failures.

It was important to Microsoft that the system initially look like ordinary Windows. This made it familiar to use and reduced the learning curve. It was not important that it run Star Wars Rebel Assault.

Some features of NT appear to have overshot the mark. The microkernel structure is hard to explain when there is only one meaningful personality. DOS, WIN16, and WIN32 programs all run under the control of the WIN32 subsystem.

Strategically, an NT Domain Controller provides the central control point for security, configuration, files, database, software distribution, messaging, and communication for a department. Chicago will run standalone, but it doesn't really achieve its full potential unless it is connected by network or by occasional dial-up to an NT Server.

If Chicago were going to be available in a few months, then it would be difficult to make a good case for NT as a desktop system. However, with Chicago delayed, Windows NT 3.5 Workstation is a reasonable choice for the software developer or power user that needs a reliable 32-bit Windows platform today.

Summary

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.