As you undoubtedly know by now, Chicago is the not-so-secret code-name for the successor to Windows 3.1, Microsoft's mainstream version of Windows currently scheduled for release in the second half of this year. This past December, 5000 developers attended the Microsoft-hosted Win32 Professional Developer's Conference in Anaheim and received a CD-ROM containing an early beta, as well as necessary development tools.
Chicago is a difficult subject to write about, not because it's technically more challenging than other topics, but because of the legalistic minefield writers have to tiptoe through. Although nondisclosure agreements (NDAs) have long been a fact of life in this industry, Microsoft has reportedly emphasized this aspect much more strongly with regard to Chicago. It's hard to provide specifics here; you probably know that most NDAs have a clause prohibiting discussion of even the existence of a beta-test program.
Microsoft has communicated its intent to more strictly control dissemination of information about Chicago. The message is clear: This is not your mother's NT beta program, where any bozo with $69 and the ability to dial an 800 number could get the software, and 70,000 people did. Chicago is being brought to you by a different division within Microsoft from that which produced NT. The relatively new Personal Systems Group (PSG) combines the existing DOS and 16-bit Windows teams. In conversation, Brad Silverberg, who heads Personal System Group, felt that NT had been "oversold" to the public prior to its release, to its later detriment. Many people who signed up for the NT beta did so only to obtain a "trophy" copy of the CD for their machine (or their bookshelf), and Microsoft was not well-served by this kind of beta tester. Wide distribution of the NT beta perhaps contributed to the flood of prerelease coverage, which was followed by a deafening silence upon release. But the intense public curiosity that drives such press coverage is perhaps unavoidable, given the dominant position Microsoft has in the PC industry. So despite these efforts, you can brace yourself for a spring deluge of coverage on Chicago.
If you follow the trade weeklies, you have already seen screen shots of the alpha version of Chicago and read about some of its features, such as the revamped user interface and the new protected-mode version of DOS that is integrated into Chicago. Even though monthly publications are known for glacially long lead times, one of them (Windows magazine) has somehow managed to put "Windows 4.0" on its January cover, with a detailed and surprisingly thorough article.
In the developer press, DDJ has already published a number of articles touching on aspects of Chicago technology (see recent pieces in Andrew Schulman's "Undocumented Corner" column). As always, Microsoft Systems Journal has been able to provide early, officially sanctioned, coverage of Chicago for a couple of months already, including a ho-hum overview by Adrian King in its January issue and the must-read piece by Dave Edson in February.
Possibly in response to this coverage and to questions and criticism about unfairly applied rules, Microsoft seems to have backpedaled a bit from its stringent stance (although, obviously, the NDA remains in force as the only signed artifact). In early January, PSG sent a letter to people in the press. The letter was signed by Brad Chase, director of PSG product management, and was accompanied by an informative document on Chicago. Chase's letter said: "I also would like to respond to a question many of you have asked: What can I write about Chicago?'" The answer is that it's perfectly fine to write about any of the technologies in Chicago (for example, the Win32 API, networking, remote-computing support, plug-and-play hardware support, and so on)--except that certain topics are very "touchy" because they are subject to change. These touchy subjects, as you might expect, concern performance, bugs, user-interface details, and bundling.
PSG's revised approach seems eminently reasonable, and there's no good reason to violate these guidelines. What there is to write about is pretty exciting: Chicago is the next step in the evolving codebase from the Windows team that is now part of PSG. As you may recall, after Windows 3.1 came Windows for Workgroups 3.1 (WfW), which added better support for networking. WfW was recently upgraded to 3.11, which is intended not just for networks but for all mainstream desktops, effectively an upgrade to 3.1. One way in which WfW 3.11 differs from Windows 3.1 is additional 32-bit components; the API is still 16-bit, but, internally, both the file system and networking components are implemented with 32-bit code. Chicago is the next step in this incremental process, and contains both 32-bit and 16-bit components internally, although it presents a 32-bit face to applications.
As Microsoft pointed out when NT was released, Win32 is an API, and Windows NT is but one implementation of that API. Then came Win32s, an extension to 16-bit Windows that implements a subset of the Win32 API. Chicago stands between Win32s and Windows NT in the extent of its coverage of the Win32 API. In 25 words or less, Win32s adds 32-bitness to Windows programs, Chicago adds threads, and Windows NT offers enhanced security, robustness, and multiprocessor support. This is a gross simplification, but helps place these systems along a spectrum.
If Chicago replaces Win3.x, what replaces the current version of NT? In the short term, the update to NT known as "Daytona" (scheduled for the second quarter, 1994) will provide performance improvements and small increases in functionality. In the long term (second half, 1995), the project known as "Cairo" will substantially enhance NT with an object-oriented file system and database-like query facilities.
One key message from Microsoft is that its operating-system implementations will cluster around two distinct "design points," one high-end and the other low-end ("mainstream"). The two design points become parallel timelines of development. In general, user-interface innovations will first appear in the mainstream version, and crossover to the high-end stream at a later date, while functionality and technological advancements will appear first in the high-end system and trickle down to the low-end system later.
According to Microsoft, "it is not possible" to have a single operating system that sits well across the range of hardware. Chicago is for low-end machines, both desktops and notebooks; NT is for high-end systems, including servers, multiprocessor machines, and non-Intel CPUs. The stated performance goal for Chicago sounds ambitious: to "meet or exceed" the performance of Windows 3.1 running the same applications, on a mainstream desktop configuration of 386 CPU with 4 Mb RAM. As a result, Chicago will never be portable to non-Intel CPUs, because it contains a fair amount of 80x86-specific code.
Microsoft has stated that Chicago will be a "compelling upgrade" for Windows 3.1 users. Whether or not this happens depends partly on performance and partly on user interface. From the user's point of view, there will be a dramatic change. Discussing details of the UI is, of course, verboten. Also, the UI implementation is likely to change, although I surmise that most changes from this point on will have to be tweaks rather than rethinking.
But, as you may read in other publications, the UI will have more of a Macintosh look-and-feel. Possibly in response to the favorable result in last year's lawsuit with Apple, Microsoft seems to have given its UI designers free rein in borrowing look-and-feel elements from the Mac. Also, there are aspects to the Chicago UI that resemble elements in the Motif and NextStep interfaces. Finally, the UI sports some genuine innovations and long overdue fixes. The result of all this is not a hodgepodge; it holds together pretty well. Any change from the existing 3.1 UI will be an improvement, and it won't take too many such changes to "compel" existing users to upgrade.
Unlike NT, which is fresh code written from scratch, Chicago represents modifications and enhancements to an existing large body of code. These modifications are substantial, but there is much that carries over from the past, more than existing press reports may imply. Microsoft has stated two reasons for the presence of this legacy code: compatibility, and minimization of RAM requirements. Components in Chicago that are 32-bit include: the kernel, virtual memory manager, scheduler, networking, file system, I/O, and device drivers (although existing 16-bit real-mode nondisplay drivers will be supported). For compatibility reasons, the window-management code (USER.EXE) remains mostly 16-bit. GDI is supposedly mostly 32-bit, although it only accepts 16-bit coordinates (the 32-bit parameters to GDI functions are truncated internally). Similar size constraints remain in other USER-level legacy components--for example, edit controls are limited to 64K of text. All these differences are considered "minor exceptions" to the single, grand, unified Win32 API.
There is much that developers can do to get ready for Chicago. One is to become familiar with the Win32 API and its various flavors. Port your 16-bit Windows code over to Win32s, which is available from both Microsoft and third-party vendors. Borland's 4.0 compiler, for example, bundles the Win32s extensions. Another is to learn about the new UI and start thinking about how your applications can be modernized for this new look-and-feel.
Get to know the OLE 2.0 API. Microsoft emphasizes that OLE is a strategic technology that will play an increasingly important role over time. Chicago's shell uses OLE 2.0 extensively, and OLE 2.0 will permeate Cairo thoroughly.