A 4-MB RAM budget and a strict compatibility mandate forced hard choices with Chicago
Jon Udell
Microsoft hopes that Windows 4.0 (also known as Chicago) will upgrade many of the world's 40 million existing Windows 3.x PCs and will ship on most new PCs in 1995. For users, Chicago's mission is threefold. It must match or exceed the performance of Windows 3.x when running on a 4-MB 386. It has to work more intuitively than Windows 3.x. It must cram as much of Windows NT's robustness and multitasking muscle as will fit into 4 MB. For developers, it must also propel the Win32 API that Chicago shares with NT to the forefront of Windows programming, while introducing new messaging, telephony, and Plug and Play APIs.
Chicago's ease of use will be judged initially on the streng
th of a completely new (but still unfinished) shell that unifies the functions performed in Windows 3.x by Program Manager, File Manager, and Task Manager. What isn't completely new, especially if you've used Windows for Workgroups 3.11, are many of the technologies under Chicago's hood, such as virtual device driver-based disk, file, and network support.
If you've used NT, you'll find Chicago's threaded preemptive multitasking, layered device-driver model, desynchronized input queue, event-driven scheduling, and long filenames also familiar. In the latter cases, Chicago mimics NT features without sharing NT's code; there's no NTFS (NT File System) in Chicago, for example. The new long filenames are shoehorned into multiple directory entries.
Does Chicago do away with DOS? Yes and no. Chicago's boot process begins with a modified version of real-mode MS-DOS that processes AUTOEXEC.BAT and CONFIG.SYS if present (they're optional) and loads real-mode TSR programs and device drivers. But when prote
cted-mode components like the VFAT (Virtual FAT) and CD-ROM file systems, network redirector, and 32-bit DoubleSpace driver load, they can, in many cases, unload their corresponding real-mode components from memory. DOS will then be history, unless you depend on a real-mode device driver or TSR for which you have no protected-mode replacement.
Novell's Btrieve requester and Eicon's NABIOS redirector are examples of the kinds of services that, until rewritten as DLLs or VxDs (virtual device drivers), will perpetuate DOS dependencies in Chicago. You also incur DOS dependencies when you launch a DOS box to run a character-mode application. But if you run only 16- and 32-bit Windows-based drivers and applications, you'll never invoke any of Chicago's MS-DOS components.
Chicago's virtual machine manager, like that of Windows 3.x, can create multiple virtual 8086-mode sessions. These share a common MS-DOS context in low memory, and their separate mapped address spaces are also visible to ring 0 compon
ents, notably VxDs (see Beyond DOS, September 1993 BYTE). Like OS/2 2.x and unlike NT, Chicago's DOS-box architecture favors compatibility (performance) over system robustness (protection from crashes), because Chicago will have to run DOS-based games without excuses.
Microsoft's design retains a large amount of 16-bit code, also for compatibility. When Win32-based applications call a 32-bit API that's implemented by a 16-bit component of the system, the function call is "thunked," or translated to its 16-bit equivalent, a process that incurs overhead. Chicago's three main modules--KERNEL, GDI, and USER--are divided into 16- and 32-bit parts. Win32 programs on Chicago will thunk down to 16 bits to access many GDI and USER services, much as Win32s programs do today. Win32 programs will image into the same 16-bit coordinate space that Win16 and Win32s programs do today, not the vastly larger 32-bit grid available to NT programs.
Chicago's Win16 support is a potential Achilles heel. Chicago's 16-bi
t system components are not reentrant, which means they can't be safely accessed by Win32 application or system threads. Every multithreaded operating system, including NT, uses some form of API serialization. The problem with Chicago's scheme is that a Win16 application that dawdles when processing messages can lock out other Win16 and Win32 applications. In this context, a single 16-bit Windows application is the weak link in the chain. In an environment with only Win32 programs running, programs won't be nearly as vulnerable.
If you use Chicago to run Win32 applications only, it will more closely approximate an "NT lite," which lacks NT's security, portability, scalability, asynchronous I/O, Unicode, and event logging. Chicago applications run in private address spaces, just as they do in NT. However, Chicago's memory management, scheduling, and I/O services are modeled on--but not ported from--NT.
Chicago, when running a mixture of DOS and Win16 applications, will behave much like Windows 3.
x with a few improvements. As in Windows 3.1, DOS applications still multitask preemptively, while Win16 applications multitask cooperatively. To better track resource ownership and simplify cleanup when applications fail, Chicago runs each DOS and Win16 application on a separate thread. As a result, Chicago should handle DOS or Win16 crashes more cleanly than Windows 3.x.
Even at its best, though, Chicago is not the pure 32-bit operating system that NT is. Instead, it is a 16- to 32-bit hybrid. At the December conference in which Microsoft distributed its second preliminary developer kits, programmers who hadn't worked yet with NT were, in general, more impressed with Chicago than those already familiar with NT.
Microsoft still lacks an operating system for the midrange RISC (i.e., $3000 8-MB PowerPC-based) systems that will hit the streets this year. But Chicago represents an ambitious Windows upgrade for the huge installed base of 4-MB PCs. If the result of Chicago's compromises is an operati
ng system that is easier to use, more powerful, but not fatter than Windows 3.1, the payoff will be huge.
Illustration: While Chicago's I/O subsystem mirrors that of Windows NT, a number of device drivers will be written as 80x86-specific VxDs.
Chicago: An Ambitious Compromise
