Cairo--Are We There Yet?

What is the product that is Cairo? Or is it a collection of technologies or ideas that Microsoft was working on? In 1992, Cairo was definitely a product. Then, as the release date disappeared into the distance, Cairo became a collection of ideas that the Windows NT team was working on. Then Cairo was back to being a product with a new name--Windows NT 5.0 (for information about NT 5.0, see Mark Minasi, "The Evolution of NT 5.0," February 1997). Now, the answer to Cairo's fate varies with each person you ask.

Cairo has been all these things, and its release date has always been vague. Without a doubt, the reason for the confusion lies at Microsoft's feet, but you can easily understand why Microsoft didn't tell the world what it was up to.

Whether you classify Cairo as a product or a cluster of ideas, it still isn't here. Viewed from the bouncy predictions that Jim Allchin made in July 1992, this reality is a considerable disappointment. However, when you look at how the market has changed and how the PC computing world has grown since 1992, the reality isn't such a disappointment.

The truth is that large components of Cairo are available now, but several other pieces haven't appeared in a coherent form (see Table 1 for a historical summary of several Cairo technologies). The biggest disappointment is that Microsoft hasn't delivered on the underlying vision and promise of Cairo, but 1997 should see it gel into a cohesive form.

About 18 months ago, I presented my vision of Cairo in a series of articles (for details, see the list of related Windows NT Magazine articles). The series focused on several key areas such as distributed objects, active storage, a new user interface (UI), and a directory service (DS). These key areas are relevant today and still apply to my updated vision of Cairo.

Barriers to Cairo's Emergence
Since I wrote the articles on Cairo, the computing world has experienced big changes. Namely, the Internet arrived with a vengeance, and with it came the whole mind-set of the intranet. Companies are rethinking their IT strategies, and some are brave enough to go back to first principles (i.e., instead of thinking of Office and Windows platforms, they're thinking content, HTML, and a new era of server site technologies). Meanwhile, Microsoft has achieved the almost impossible by completely restructuring from top to bottom.

Many commentators claim that the Internet's arrival means Microsoft has sidelined or devalued Cairo. This claim demonstrates a fundamental misunderstanding of the nature of the problems that Microsoft faced and a misreading of how Cairo was and is going to help solve those problems.

To understand Microsoft's approach to Cairo, you have to travel to 1990 or thereabouts. Microsoft was doing major internal research and development that largely involved NT. At the same time, the company was starting to develop Cairo components such as Object Linking and Embedding (OLE) objects, distributed objects, document storage engines, indexing and retrieval solutions, DSs, and new UI designs.

But Microsoft faced a fundamental problem: how to convince users to stop thinking about applications and start thinking about documents? For starters, Microsoft introduced OLE, which lets you work on one type of program file from within another program. So, for example, OLE lets you work on an Excel worksheet from within Word. This new approach required a lot of coding design to establish a complete object API set that defines a way for applications to talk to each other. OLE allows window negotiation (so the contained application can work in the container application) and lots of small but vital details such as automatic menu bar negotiation.

In addition to OLE, Microsoft introduced Visual Basic custom controls (VBX) and the OLE custom control (OCX) component model. The company also presented the OLE automation system that lets one application control another, development tools such as Visual Basic (VB) 4 to make custom control creation easy, and early beta versions of distributed OLE (DOLE). All these products screamed "objects," but the world didn't notice. Everyone still thought applications and servers were for file and print sharing.

The reason Microsoft had trouble grabbing our attention is simple: No matter what the company tried, it hadn't found a compelling reason to make us sit up and take note. The sweet spot that makes users and IT managers ooooh and ahhh was missing. Microsoft hadn't focused on the content. Instead, it pushed the sale of applications to make the content better and overlooked the fact that we fundamentally cared only about content.

Only with the advent of the World Wide Web did the world begin to understand that content matters above all else and that you need a range of tools to look at your content. HTML is universal (at least in theory), so instead of thinking Word document, users began thinking about HTML content that was quite separate from a viewer frame.

This new approach frees us from the cage of the traditional application. Better still, the Web provides a fast-moving marketplace. Now users can have new browsers every few months instead of the two-year time scales for the big application developments. Suddenly the Web and Web browsers are hot, and companies are thinking content, not container.

As the Web gained momentum, we began seeing a much more subtle change. All at once, objects and downloadable pieces and server-side automation became the flavor of the day, and the requisite mind-set began focusing on making a deliverable object framework work.

Microsoft encountered other, less subtle barriers that prevented the company from making Cairo a reality. For starters, NT 3.1 was too big and too slow, and adding Cairo's features would have produced an unusable system even on the highest-powered platforms. Although NT is a high-end system, Microsoft wants the operating system to reach down onto the desktops of mere mortals and not be sidelined as an esoteric nicety.

The economics of hardware in 1994, the anticipated delivery date for Cairo, were also quite different from those of today. Back then, we were running fast 486 processors with early Pentiums coming available, and we believed that 32MB of RAM was a lot because it cost so much.

Microsoft's top priority was to get NT 3.1 up to speed. As NT 3.1 was the base platform for Cairo, Microsoft needed to make the operating system faster and smaller, so the company released NT 3.5. The subsequent NT 3.51 release probably represented the high-water mark in terms of NT Server stability (many of us are still not convinced that NT Server 4.0 has the towering stability that NT 3.51 exhibited).

So if Cairo hasn't appeared, what's happened to it? Let's look at Cairo's underlying technology for the desktop, distributed objects, and storage technology and see where it maps to the reality of today and tomorrow.

The Desktop
Microsoft has always said that the Win95 UI came from the Cairo team, so it inevitably became part of NT 4.0. If you look at Jim Allchin's slides from the 1992 NT Developers Conference, you recognize a lot of Cairo UI components such as right-click pop-up menus, browsing windows, and hierarchical trees that translated directly into the Win95 shell.

Cairo also promised an object-based desktop that you would be able to rebuild at will. I overestimated Microsoft's desire to let us users decide how we want our workspace to work. Just look at the limited amount of customization you can achieve within the Win95 shell and you soon realize it's little better than the previous Win3.x desktop. For example, Microsoft gave us icons on the desktop and a rebuildable Start button, but they forgot to include OLE objects in the tray and truly customizable frames on the desktop. Microsoft has saddled us with a filing system approach to My Computer etc., and hasn't provided common dialog boxes that users can repaint and rebuild.

Microsoft planned to use the OCX object model to let the shell host raw object servers (so you could mount running applets within the taskbar, for example). Unfortunately, this step hasn't happened. Worse still, you can't apply OLE automation to the desktop (you can apply API calls to the shell to make it perform specific tasks, but building these calls in VB as part of a corporate desktop solution is difficult).

Microsoft made big promises when it added the Win95 shell to NT, but it hasn't delivered. NT 4.0 is in sync with Win95, but I think the baby's been thrown out with the bath water. The shell that Microsoft added to NT 4.0 is clunky and not very clever. For example, under NT 3.51, you can click on any application window and know that it will get immediate attention--responsiveness is not an issue. With NT 4.0, the desktop shell is a much larger active process. If the shell becomes busy, NT 4.0 can tie up your system for several seconds.

Microsoft's port of the Win95 code onto the NT platform also makes a poor showing. For example, try dragging two unrelated NT 4.0 directories to the Recycle Bin at the same time or copying some files in one place and deleting them elsewhere. The shell won't let you delete files while you create new ones on the desktop. Microsoft has sacrificed NT 3.51's instant responsiveness on NT 4.0's low-rent solution. NT 4.0 is not multithreaded enough and can't spawn multiple shell tasks simultaneously.

As a piece of code, NT 4.0 needs work, especially when you consider the next step in its evolution. Microsoft's Active Desktop (AD), the new name for the Internet Explorer (IE) 4, is a desktop shell and will run as a new layer on the desktop. It will feed Web information straight to your desktop. AD is late. Only last summer, Brad Silverberg, senior vice president of Microsoft's applications and Internet client group, told me that AD would be out during the fourth quarter of 1996. Just before Christmas, Microsoft promised AD would be in beta by the end of the year. Both deadlines have been blown away.

Consider the ramifications of Microsoft's promise for a user-definable desktop. To implement this new UI, you need a form painter and a desktop that can host OLE objects (NT 4.0 provides neither). In one leap, the AD gives a clear solution to the problem. Because AD will be based on HTML that you download from the Web, maintaining the desktop will be simple. You will be able to place ActiveX controls in the HTML stream and build very complex and interactive desktops that provide real information feeds to the user. The AD will also feed data back on networked servers.

The use of HTML-based forms and ActiveX controls for the AD is a masterstroke. At once, this combination integrates both public (Internet) and private (intranet) feeds into one seamless environment. So taking intranet feeds from corporate data servers and integrating them with public news feeds, for example, provides the possibility of the definitively rich UI experience.

   Previous  [1]  2  Next