Programming Windows: Cairo, a Road Not Taken (Premium)

Windows NT was released in 1993 and was described by First Boston as “the most aggressive piece of software ever written by mankind.” That sounds hyperbolic. But it was, in some ways, an understatement: While many saw NT as some future successor to MS-DOS, Bill Gates and Microsoft viewed NT as nothing less than the future, a “universal interface” between all computers. Microsoft’s goal for NT was simple, and it amounted to the chant I later heard at the firm’s Redmond campus: “NT EVERYWHERE.”

Before NT could be a ubiquitous engine for Microsoft’s future, however, it needed to be improved, as early versions were slow and incompatible with most hardware peripherals. And so Microsoft improved NT alongside the DOS-based versions of Windows in the mid-1990s, releasing the second major release, Windows NT 3.5 (“Daytona”), in September 1994. And then a minor update focused on PowerPC and called Windows NT 3.51 shipped in May 1995.

Those releases were created by the core NT team headed by Dave Cutler. But a second NT team, led by Jim Allchin, was separately working on a coming major update to the product that was codenamed “Cairo.” Cairo was in many ways as ambitious as the original NT, and it would deliver what computer scientists of the early 1990s considered to be state of the art: An object-oriented desktop built on top of COM technologies, an object-oriented file system built on SQL database technologies, an object-oriented software development environment built on Visual C++, and an object-oriented directory services networking infrastructure.

Cairo was an explicit acknowledgment from Microsoft that it was collectively tired of being viewed as second-rate within the industry. NT had been developed by a core team with origins outside of Microsoft, and so, too, would be Cairo: Mr. Allchin came to Microsoft from networking pioneer Banyan, where he had created the VINES distributed operating system. He would go on to create Microsoft’s Server business and lead NT and then overall Windows development for over a decade.

The timing was good for Microsoft to take a step up in quality. Windows was already ubiquitous on the PC desktop, but it was a shaky foundation at best. And the market was expanding into network-connected PCs, workstations, and servers as well as into devices-based consumer electronics. Companies like NeXT were pioneering OOP-based OSes and application development platforms. And companies like Novell were making advanced in networking, and in directory services.

The goals for Cairo were impressive.

The Cairo user interface was to be based on a desktop model similar to that used by the Mac. The special purpose manager applications from Windows 3.x–File Manager, Program Manager, and Print Manager–were gone, replaced by direct manipulation techniques like drag and drop in a new interface called Explorer. Objects in the UI exposed their behaviors via right-click context menus, and those on the Desktop could be physically present in the Desktop or *references*–e.g. shortcuts–representing the actual object that was elsewhere in the file system.

Those ideas will likely be familiar to anyone using Windows today, but Cairo was also going to offer smart folders that looked like standard shell folders in Explorer but offered intelligent features. Cairo’s Help, Email, Bulletin Board, and Document Management applications would all be implemented as smart folders.

Cairo would begin the push beyond drive letters by offering a single namespace that encompassed both the local machine and the network to which it was connected. Users would no longer need to connect to explicit network shares to find information.

A feature called Task assistants would help users automate routine tasks like filtering and filing email messages and though it was based on scripting, it would feature an intuitive and easy GUI.

Cairo’s file system, the Object File System (OFS), was a “new, high-performance file system” that would “offer many features suited for native storage of objects. It would include access control, content indexing, and replication capabilities. And a Distributed File System (DFS) built on top of OFS would map all shared disk space in a network into a single namespace.

Existing applications that were designed for MS-DOS, Windows 3.x, Windows NT, or Chicago–Windows 4.0, or Windows 95–would run normally under Cairo. But new apps could take advantage of Cairo services like content indexing, smart folders, and replication.

For developers, Cairo would be “an evolutionary path based on Object Linking and Embedding (OLE) 2.0 [a Microsoft componentization technology] and Win32.” It would include a Component Object Runtime (COR) that enabled software connectors, “a standard way for objects to describe their structure, binding characteristics, and persistent binding information.”

Developers would also gain access to new Cairo Design Environments (codenamed Delphi) that would let them add behavior and properties to smart folders and customize them for presentation in Explorer. And they could build and compose “pluggable” object components to create a new kind of app.

A basic Cairo application would utilize Win32, OLE 2a, and other previous Microsoft technologies. But a “true Cairo application” would be built from components with extensible interfaces. And they could optionally be distributed objects with remote invocation functionality that would enable them to be discovered and run over a network. True Cairo applications would also support new Cairo interfaces like content filters, smart containers, shell integration, event notification, query interfaces, and the new Cairo help system.

The problem with Cairo was that delivering these technologies on top of NT–which was so slow at that time that critics claimed its name stood for “Not There” instead of “New Technology”–was simply untenable. Worse, Cairo sought to change too much of the system at once. And so the project slowly collapsed under its own weight.

Microsoft’s original schedule for Cairo–a very early pre-release version in Q4 1993, followed by a Beta in Q1 1994, new betas every quarter after that, and a final release on the curiously specific date of October 18, 1994—was hopelessly optimistic given the issues Microsoft faced shipping Windows NT 3.1.

Microsoft eventually did deliver on many of the promises of Cairo, albeit in less elegant than the promised ways. Indeed, the firm officially claimed afterward, disingenuously, that Cairo was never meant to be a new version of NT. (Not knowing any better at the time, I even parroted this official company line early in my career after discussing the project with Microsoft.)

The COM-based desktop shell was first adapted to work with Windows 4.0, which was later renamed Windows 95, giving Microsoft’s most popular operating environment a new look and feel. But the Windows 95 shell wasn’t object-oriented. And it wasn’t even really COM: Because Windows 95 was supposed to work well on PCs with as little as 4 MB of RAM, it wasn’t possible to start up the entire COM subsystem at boot-time, as doing so would bring most PCs to their knees. So, the Windows 95 shell team took out the parts of COM they needed and made a COM-Light, of sorts, that would work within the system’s constrained resources.

As originally envisioned, the Windows 95 shell was supposed to offer a preview of the coming power of the Cairo shell. But when Windows NT 4.0 shipped in August 1996, it arrived with the same scaled-down Windows 95 shell instead. Windows NT 4.0 wasn’t Cairo as some still claim; instead, it was codenamed the Shell Update Release (SUR) because that was the only major difference between it and its predecessor, Windows NT 3.51.

That OOP file system never materialized either, but the central goal of that project—the ability to search content within files, and not just by file name, did of course come to Windows after Windows 95 (which supported only filename searching). The issues here were many, but the new file system required Microsoft to essentially rewrite the SQL Server database engine from scratch—previous versions had been based on Sybase—and then adapt it for use in other scenarios, which took several years. And even then, SQL Server proved too big and heavy for use elsewhere. Even an effort to bring the SQL Server database engine to the Exchange email server failed.

Despite its less-than-impressive technical underpinnings, Windows 95 did ship with some of the Cairo philosophy intact. Viewed at the time as a light and implementable first step towards Cairo, Windows 95 shipped with a document-centric user interface that was itself a light version of the task-based user experience that Microsoft envisioned for Cairo but never fully realized.

The idea reads like science fiction, even today, which makes sense since Cairo was viewed as almost fantastically futuristic in its day as well. In this task-based system, users would stop thinking about applications but instead focus on tasks, and the user interface would adapt to meet the needs of whatever project the user was working on. As implemented in Windows 95, what we got was the ability to mix and match Office document types within each other thanks to the COM-based object linking and embedding capabilities. But even this basic first step towards a task-based system was confusing to both users and third-party developers, and it was quickly abandoned by Microsoft.

One interesting change did come out of these efforts: Under a task-based system, the need to work on multiple documents of the same kind in a single application window—the so-called Multiple Document Interface (MDI)—was abandoned and replaced by the system we still use today, where each document (compound or not) gets its own window. (Yes, it’s called SDI, for Single Document Interface.) Microsoft claims to have known “for some time” than MDI would become obsolete in the future, but it pushed the technology pretty heavily in Visual C++ throughout the late 1990s.

Eventually, Cairo ended with a whimper and the history rewriting began. As always history is written by the victor: Mr. Allchin was given control of the consumer versions of Windows in 1999 in addition to the NT-based versions he was already in charge of, so he was able to control the narrative. And he went on to ship Windows XP, successfully, in 2001, and then Windows Vista, much less successfully, in 2005.

Vista, of course, had its origins in another Allchin-led “road not taken” called Longhorn, a subject we’ll examine in some depth later. But it is interesting to me that one person was responsible for Microsoft’s two biggest Windows defeats, and that he says today that “creating and growing the firm’s Server business from scratch” was his biggest accomplishment. Had Cairo or Longhorn succeeded, that would most certainly not be the case.