By the time you read this, the first beta of Microsoft's successor to Windows, code-named Chicago, should be back from the CD-ROM replication plant. This beta, also known as "M6" replaces the M5 prebeta handed out last December. Although obtaining the beta requires signing a nondisclosure agreement (NDA), Microsoft recently gave a detailed demonstration of Beta1, free of NDA restrictions, to members of the press. We'll leave it to the trade weeklies to provide the overview. Here, we'll focus on subjects of interest to developers. In doing so, we'll try to dispel a couple of myths Microsoft is promulgating about Chicago.
Given that M6 was due in early March, there appears to be at least a three-month slippage in schedule. Microsoft now says that Beta2 will appear in the summer, with initial customer shipments in the second half of this year. According to Microsoft vice president Brad Silverberg, Chicago is now "95 percent code complete," meaning fewer changes and more testing from here on in.
"Plus-or-Minus" Performance
At the top of the news is performance. Microsoft claims that Chicago now runs 10 percent faster than Windows 3.1 on a system with 8 Mbytes of RAM. With 4 Mbytes of RAM, the relative speeds of the two systems are roughly equivalent, "plus-or-minus a few percent." After December's M5 release, Chicago programmers worked over the holidays to crank up its performance. In tight memory configurations (4 Mbytes), Chicago runs neck-and-neck with Windows 3.1, depending on the task at hand. For example, in displaying Video for Windows files, accessing data from hard-disk storage or from the network, Chicago runs faster than 3.1. In other areas, most notably launching an application, Chicago falls behind. In conversation, Silverberg said that, although you could expect additional increments in performance (especially with regard to application launching), the performance issue had been satisfactorily addressed and no dramatic changes would occur prior to shipment. Nevertheless, Microsoft continues to enjoin the press from publishing any specific benchmarks on Beta1.
The performance increases are the result of various factors. Architecturally, great efforts were made to rid Chicago of real-mode code (and the consequent costly transitions to/from protected mode). Also, performance-critical system-level services--file system, communications, networking, and the like--have been converted from 16-bit to 32-bit code. The idea is to ensure a 32-bit, protected-mode code path "from API to media." Unlike NT, many of the higher levels of the Win32 subsystem--that is, User and GDI--remain 16-bit code for compatibility and working-set size minimization (not to mention running out of time for conversion). There is now a single, system-wide, integrated cache which manages data from IDE drives, SCSI drives, CDs, and networks in one place. Because of the 32-bit code paths and client-side caching, Microsoft claims that a Chicago client on a NetWare network has two-to-four times the throughput over the Windows 3.1 equivalent. Reducing working-set size is another way to improve performance. To this end, device drivers and other VxDs are dynamically loaded and unloaded. Dynamic driver loading is also necessary to support Plug-and-Play, a specification that facilitates hardware autoconfiguration.
Plug-and-Play is one of the major advantages Microsoft is touting with respect to Chicago. Configuring hardware is a job that has been the bane of many PC users, especially those without the support of a corporate MIS department. As mentioned here last month, up to 40 percent of multimedia upgrade kits for PCs are returned by customers who are unable to install them. However, Plug-and-Play is not exclusive to Chicago, or any other operating system. The spec is designed to be OS, CPU, and bus independent. Nevertheless, it looks like Microsoft will try to link, in the public's mind, the benefits of Plug-and-Play--which are undeniably attractive--with Chicago.
Of course, Macintosh users for years have enjoyed the benefits of autoconfiguration. Microsoft has sought to steadily erode this and other advantages of the Macintosh platform. One long-standing advantage, of course, is the Mac UI--which anyone who's used it extensively knows is significantly easier to use than Windows, despite their cosmetic similarities.
A Usable UI, at Last
Those who have followed the prerelease version of Chicago know that it sports the Chicago Shell, which is a redesigned, cleaned-up UI that replaces the notoriously cumbersome and inconsistent Windows Program Manager and File Manager. The Chicago UI has not changed much since M5, but it has been fleshed out. Among the nice visual touches are a pie chart showing the amount of free disk space, and a thumbnail preview of your monitor screen when you change resolution (which can be done on the fly, even while playing a Video for Windows file on screen). There is still work to do, however; at occasional but regular intervals I noticed spots where dialogs were incomplete or not plugged in. These gaps, however, are narrow and local in scope.
Chicago provides the Explorer, a Finder-like window that sports, on the left side, a hierarchical view of the user's computer (as well as resources such as other machines on the network), and on the right, a window pane that provides a multipurpose view, depending on what is selected. The right pane can show directories and files in a manner similar to that of File Manager. However, it can also be used to show and manipulate Control Panel objects, Windows Setup elements, Print Manager items, and Mail messages. Combined with long filenames and the unified namespace (which makes files and directories on a remote machine transparently accessible), the result is seamless ease of use.
Microsoft UI designers have added many elements familiar to Mac users: "shortcuts" (roughly equivalent to Mac aliases or UNIX symlinks), toolbar help (similar to Mac balloon help), property sheets (similar to GetInfo boxes), a "unified namespace" (similar to Macintosh naming), long filenames (longer than on the Mac), and so on. Other elements, such as proportional scrollbars and a greater 3-D look, will feel familiar to Motif users.
Instead of relying on raw intuition, as did the original designers of the Macintosh UI, Microsoft has poured tremendous resources into usability testing and metrics--presenting hundreds of novice users with typical tasks (such as "find and launch Notepad"), then videotaping and analyzing their reactions. Part of this methodology emphasizes measuring how long it takes a novice user to accomplish a given task, then reducing this time (Microsoft claims up to a 400 percent improvement over Windows 3.1 timings).
Steve Capp, Bruce Horn, and others on the original Mac Finder team must be gratified that these elaborate measures have validated their original concepts. However, if Apple wants to remain in the game, it needs to freshen up its code, because Microsoft has done its homework on this one. Chicago's UI holds together very well and offers some innovations that had some members of the press, normally savvy wiseacres, gushing at Brad Silverberg's feet. Microsoft UI designers have eliminated or provided alternatives to many actions that novice users find troublesome: double-clicking, window management, traversing hierarchies, and so on. In addition to wanting to Do the Right Thing, part of the motivation may be the attractiveness of the home-computing market, which is growing rapidly even as the corporate arena faces downsizing and stagnation. In conversation, Silverberg mentioned a talk with Intel's Andrew Grove, in which the opinion was floated that the Pentium may find more rapid penetration in the home market rather than in the office, because of the inordinate conservativism of corporate MIS managers.
Perhaps in harmony with this observation, Microsoft has set its sights on the games market, which is still dominated by DOS-based products (in 1993, over 75 percents of game sales were for the MS-DOS platform). The portion of the Windows GDI that puts device-independent bitmaps (DIBs) on the screen has been tuned and encapsulated into a game developer's library known as WinG, which will be available in beta form later this month. WinG's DIB engine is a generation ahead of the graphics primitives of Video for Windows 1.1. In addition to performance increases for game-oriented graphics primitives, WinG also provides "thread-friendly sound," MIDI, and support for various types of connectivity (WinSockets and UniModem). Reportedly, the popular DOS game DOOM was ported to Windows in two days using WinG. (The Windows version of this game will be available this Christmas from Id Software.)
Still, Microsoft realizes the importance many corporate MIS departments place on compatibility, and is hedging its bets by saying that the old-style UI (Program Manager plus File Manager) will be supported. This compatibility message was not heard in December, when only new features were highlighted.
DOS is Always with Us
Users who read early reports on Chicago may have sighed with relief that DOS is finally dead, a message Microsoft started to promulgate late last year. David Cole, group manager for Chicago, says: "Chicago has no dependency on MS-DOS_. When you're running Chicago, there is no DOS there." Old friends such as config.sys and autoexec.bat have been replaced by the Registry database. Like Freddy Kruger or Leatherface, however, DOS seems to live on endlessly. Although in theory, the last vestige of real-mode code has been exorcised from the system, there are many situations where compatibility dictates its return.
Compatibility with existing DOS and Windows apps is the sine qua non of any successful software for the PC market. For compatibility reasons, Chicago supports config.sys and autoexec.bat, as well as real-mode device drivers. Not only does it support the familiar "DOS boxes" in older versions of Windows, but also something called "single-application mode" in which the system is taken over by a single, real-mode DOS session to provide "the ultimate compatibility mode." Microsoft proudly demonstrated some ill-behaved DOS programs, such as DOOM, that cause Windows 3.1 to hang, but now run under Chicago.
The OLE Illusion
The myth that DOS is going away is a rather benign one. However, one myth promulgated by Microsoft that should be dispelled is Chicago's relationship with OLE. For the past few months, Microsoft's marketing staff and evangelists have vastly overstated the relationship, in some cases to the point where these statements are now located in the remote suburbs of truth.
For example, in the March 1994 issue of Microsoft Developer Network News, David Cole talks about "key things that developers should incorporate in their Windows-based applications to exploit Chicago." According to Cole, "the first two are Win32 and OLE 2.0. They are the fundamental building blocks for writing great Windows applications." In that same issue, Tammy Steele (Microsoft technical evangelist) writes: "To integrate well with the Chicago environment, applications should incorporate OLE 2.0 technologies such as compound files, drag-and-drop, visual editing, and automation." She lists the "top ten things to do to create a great Chicago app," and three out of the four topmost items have to do with OLE. In a separate article, Kraig Brockschmidt answers the question, "Do I have to use OLE 2.0?" with: "OLE 2.0 is your head start into a Windows environment where the entire system is built on these technologies. By incorporating any OLE 2.0 features today, you can put yourself in a great position for tomorrow_. An OLE 2.0 application will simply run better and integrate better with Chicago and with other applications." In yet another article, Dave Seres, OLE product manager, writes: "OLE 2.0 technology is a major foundation piece in Microsoft's strategic operating system direction. The next major releases of Microsoft Windows NT (Cairo) and Windows (Chicago) will build on OLE and be compatible with it." For example, in Microsoft Systems Journal (February, 1994), Dave Edson writes: "OLE 2.0 is the backbone of Chicago."
Yet strictly speaking, OLE has little to do with the Beta1 version of Chicago, which is supposed to be "95 percent code complete." Fundamentally, Chicago consists of two large components: the UI (known as the Shell) and the Win32 subsystem (composed of subcomponents such as GDI, Kernel, User, and Virtual Machine Manager, that together implement the Win32 API subset that Chicago supports). According to informal comments by Microsoft programmers, these components were built largely without OLE.
The Win32 subsystem, which represents the ongoing evolution of the code base in Windows 3.1 and Windows for Workgroups, also represents enhancements and modifications to a long-standing body of code and makes no use of OLE 2.0 technologies--neither system-level services such as the Component-Object Model or Structured Storage, nor application-level technologies such as linking, embedding or in-place activation. Unlike the Win32 subsystem, the Chicago Shell is an entirely new body of code and can therefore be expected to make greater use of OLE 2.0 technologies. But here also, the interfaces between its subsystems are apparently not compatible with OLE. The Shell does have an extensible architecture that allows you, for example, to create a windowpane for the Explorer tool to implement behaviors such as a control panel or configuration setup. But such extensions are Shell specific, rather than generally accessible in the way that real OLE objects are. One Microsoft programmer described these interfaces as being "OLE-like, but not OLE-compatible."
When I asked Seres about this, he explained that 32-bit OLE was not available when the Shell was being written, so the implementors had to roll their own OLE-like interfaces. The Shell does use the OLE compound-file interface to access the Registry database. Seres added that 32-bit OLE will be present in Chicago when it ships and can thus be accessed by all applications. In a follow-up interview, he added that "Chicago's UI model is patterned after OLE_in a manner specified in the OLE UI style guide." Microsoft intends, he said, to more fully utilize OLE in future releases of Windows. Moreover, the mini-applications that ship with Chicago (successors to NotePad and Paintbrush) are fully OLE compatible.
None of this sounds much different than adding the OLE 2.0 DLLs to the present version of Windows or to NT, plus running a few OLE-enabled apps. It is hard to see how adding this configuration means that "the entire system is built on these technologies." Rather than being "the backbone of Chicago," OLE sounds more like a strapped-on appendage.
Those of a conspiratorial bent have suggested that Microsoft has used OLE 2.0 as a huge red herring to throw off and confuse would-be competitors by forcing them to learn an unwieldy and complex API which Microsoft controls and which Microsoft itself did not utilize in Chicago. In addition, would-be competitors are compelled to buy Visual C++, the only programming environment that facilitates writing OLE 2.0 applications (although you can certainly create an OLE 2.0 app using any compiler or language, assuming you are able and willing to write about 18,000 lines of code). Borland's recently released 4.0 compiler has been strongly criticized for lacking OLE support.
On the other hand, a more trusting (or naive) soul might conclude that Microsoft's mendacious myth-making is merely a result of a marketing department that has lost touch with the development arm of the company. You can draw your own conclusions.
Reverse-Engineering NetWare
One of the most interesting parts of Chicago is its connectivity support. The artificial distinction between Windows 3.1 and Windows for Workgroups is gone. Learning from the unhappy experience of Windows NT, Microsoft has decided to "get into the NetWare client business." Out of the box, Chicago will support a NetWare redirector plus IPX/SPX protocols, allowing multiple driver models (NDIS3, NDIS2, and ODI). In addition, TCP/IP and NetBEUI protocols are supported, as are Windows Sockets and DCE/RPC. This means that a Chicago machine can have multiple connections using multiple protocols open concurrently. Multiple NetWare sessions can each run in their own VM, unlike 3.1, where all throughput is serialized through a single DOS driver. Due to client-side caching, UNIX-like sequential read-ahead, and 32-bit code paths, NetWare throughput is significantly increased, up to four times more.
But that's not all that's interesting about Chicago networking. Through what seems like rather clever reverse-engineering, Microsoft engineers have allowed Chicago-based clients to seamlessly integrate with NetWare servers. For example, files on a server can have long filenames. NetWare utilities (like SYSCON and NLIST) invoked from a Chicago client can display data from other Chicago machines. Users don't need to type in a password to log on or use MAP or ATTACH; instead, these connections are made transparently, using the password entered by the user at machine startup time (a feature called "pass-thru security"). Password data is stored only once, on the server (which can be either an NT machine or NetWare system).
I asked John Ludwig, group manager of Chicago networking, whether this tight integration was a result of cooperation with Novell, or whether it was a result of reverse-engineering NetWare core protocols (NCP). His carefully worded response was that it was accomplished without Novell's assistance, using "industry-standard techniques." These techniques, he added, have been reviewed by the legal department and have "extensive lawyer approval." (Or is it expensive lawyer approval?)
In another era, this clever piece of work would only merit a few oohs and aahs. But given Microsoft's complaints about reverse engineering in the recent Stac vs. Microsoft case, there'll likely be some raised eyebrows around the industry--and, on the part of Novell, perhaps some quick calls to its legal department. In any case, users end up with a smooth, seamless, and consistent integration of network connectivity into all aspects of the user interface.
Development Tools
If you want to write apps for Chicago, there are various choices. First, of course, you use any compiler that will produce executables for Windows NT, and keep in mind the limits imposed by Chicago (such as 16-bit coordinates). This won't allow you to develop Shell extensions, which are specific to Chicago and require, among other things, a new thunk compiler. Secondly, if your app is not architected for threads, you can work in 16-bit Windows, adding as much of the Chicago "look-and-feel" as you can via DLLs and custom controls such as CTL3D, HIER, SPIN, and so on (available on the MSDN C). This can be risky, and depends on how well-modularized your code is. If you are part of the Chicago beta program, things are pretty painless. Chicago beta participants will receive both a prerelease version of Visual C++ 2.0, as well as the preliminary Chicago SDK, which includes the new thunk compiler, a Register editor, and a new 32-bit help compiler that supports the Chicago Help extensions.
Conclusion
Although cynics might say Chicago is basically Win32s plus threads with an ersatz Macintosh interface, Chicago does look like a winner. There's nothing radically new here, but the innumerable incremental improvements combined with a few clever innovations will likely add up to a compelling upgrade for most Windows 3.1 users--modulo any bugs, that is. Silverberg's group, however, seems committed to releasing the software when it's ready, instead of obeying artificial deadlines, so we should expect a robust release--the OLE smokescreen notwithstanding.
