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.
| TABLE 1: Cairo Features--Now and When? | |
| What Microsoft Promised | When It's Happening |
| Active Desktop | Exchange Server used VB4 16-bit executables
Basic dialogs in Office 97, shipping now Active Desktop to ship in IE4 during 1997 |
| Distributed OLE | Basic DOLE in NT4, now shipping for Win95 |
| Object File System | Still not in beta
Exchange Server used modified JET instead |
| Extended MAPI features | Shipped in Exchange Server 4.0 |
| X500 Directory | Shipped in basic form in Exchange Server 4.0
Full OS version to be in NT 5.0 |
| Object development
environment |
OCX environment in VC++
Visual Basic 5.0 CCE brings ActiveX development to end users |
| Content indexing engine and
Microsoft Index Server |
Released in 1996 |
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.
To provide a dialog-oriented version of the AD, Microsoft is releasing an alternative forms engine, Forms 2, with Office 97. I believe this engine is closer to the original Cairo forms engine for several reasons. First, it is highly OLE automatable. Second, a senior Microsoft employee told me two years ago that the Cairo forms engine would be pan-application and the operating system would use it. Microsoft had decided at that time to ship the Cairo forms engine with a future release of Office, and not as an operating system feature.
The Forms 2 engine is extremely powerful. It can host any ActiveX control, and the instantiation time is fast once the core engine is loaded and running. Brad Silverberg also told me that the Forms 2 engine's form definition language is actually an elementary HTML format, and that future versions of the forms engine will use raw native HTML format instead. This change will bring the forms engine in line with the IE 4/AD forms definitions.
The NT 4.0 desktop, although a component of Cairo, is not the configurable desktop that Microsoft promised--it's merely a stepping-stone. Microsoft could have added the forms engine to the operating system to fulfill its promise; instead, the company has side-tracked the forms engine into Office 97. Going for the full-blown IE 4/AD solution is, without question, full and complete delivery of Microsoft's promise. You can expect to see this solution during the first half of 1997.
Distributed Objects
Cairo's implementation of objects is a mix of delivered code and undelivered
promise. OLE is here, it's now, and it's stable. Microsoft can choose among
several object implementation models for Cairo--the original OLE model, the
apartment threading model from NT 3.51, and the free thread model from NT 4.0.
Each model gives the object server more control over how it serves multiple
clients concurrently.
OLE development has become progressively easier over time. Coding OLE objects used to require C++, but now you can use VB4 for building OLE automation servers and clients with easy-to-use scripting that hides the complexity of the OLE registration registry.
ActiveX developers have taken a similar approach. ActiveX development used to require Visual C++ (VC++), but now developers can use VB5 Custom Control Edition (VB5CCE) to create full-fledged standalone ActiveX controls. This breakthrough is key to the success of the next wave of OLE development at the core of Cairo. Don't underestimate VB5CCE's importance as a tool for creating active tools within Cairo's AD framework.
Getting Objects to Talk to Each Other Across Networks
DOLE, also known as Remote OLE, lets OLE clients and servers communicate
across standard network protocols and has been available since the VB4
Enterprise Edition shipped about two years
ago. Microsoft built the DOLE core engine into NT 4.0.
DOLE lets a client know which machine is the OLE server in a point-to-point connection using routing information hardwired into the client's Registry. Unfortunately, managing and maintaining these links with any precision is difficult. However, two different methods can give administrators more control over these connections.
The first approach involves a centralized OLE server lookup table. Imagine having some black-box OLE automation servers installed on several servers on your network. Each client is wired to a particular server. If that server goes down, the server's clients have no way of locating other object servers, even if the servers are serving the same objects.
Consider the manual load balancing required to make this switchover work. If you want to load balance the object servers, each server needs to broadcast its processor utilization into a centralized lookup table. When the client requests a particular object, the OLE system on the client checks with the centralized information store to find out which OLE server can provide the object the client needs and which server has the lightest load. The OLE system can then automatically wire the connection from the client to that server.
| Microsoft hasn't delivered on the promise of Cairo, but 1997 should see it gel into a cohesive form. |
The amount of developmental effort required to make this configuration work will probably not be big because all the pieces are in place except for the centralized lookup table. This table is an ideal function for the forthcoming Cairo DS.
The second approach is to use Web pages that call out active OLE servers with new Active Server Page (ASP) technology on Internet Information Server (IIS) 3 and IIS 4 (code named K2) servers (for information about IIS 4, see T.J. Harty, "IIS K2 Alpha," February 1997). You can now build Web-based client/server solutions that have ActiveX objects running on the server side. The server-side engine can call HTML-based Web pages or ASPs that contain server-side scripting. The engine can also call a variety of server-side technologies such as a database engine (direct database connectivity using ASPs is easy to set up using Microsoft's powerful Visual InterDev toolset--for information about Visual InterDev, see T.J. Harty, "Microsoft Visual InterDev 1.0, Beta," March 1997). All the future administration console screens for NT Server will go over to ASPs.
With well-designed client-side HTML pages, server-side objects, and seamless database connectivity, you can rewrite a traditional application into a server-based ASP using ActiveX controls as necessary on both the client and server to provide the complex wrapped functionality. I'm considering rewriting some of our VB-based client/server database applications to ASP-based HTML intranet applications. This ability has to be a delivery of the mind-set and thought processes behind Cairo.
Storage Technology
Cairo has always promised several new developments in storage technologies.
The first is a full-blown content indexing engine to let users locate files
anywhere on their networks. Microsoft incorporated the Cairo indexer engine as
an ISAPI application that's available now as the indexer engine for IIS 2 and
above. This high-performance engine allows full searching of the custom document
tags I described in my article, "Exploring Cairo: Object File System,"
November 1995.
To make a searchable tree, you need a way to span multiple machines. NT's Distributed File System (DFS) has been in beta for a while (for information about DFS, see Sean Deuby and Tim Daniels, "DFS: A Logical View of Physical Resources," December 1996), but the real product will be Fault Tolerant DFS. Fault Tolerant DFS lets you create one large tree that spans clients and servers in your network. Obviously, such a tree is ideal for the indexer engine, and I expect we'll see more and more users leveraging this system in the future.
The final breakthrough in Cairo storage technology is the granddaddy of OLE storage, Structured Storage (SS) and the Object Filing System. Unfortunately, development on this front has gone quiet. However, Microsoft has notably improved SS in Office 97. For example, Word now allows multiple document versioning within one file, and many applications now allow concurrent read and write. I've heard that Microsoft's OFS, the set of server-side extensions to NTFS that lets it work with structured storage in a client/server fashion, is still under development but will see the light of day this year.
Directory Services
In addition to distributing objects and applications, you need a way to
locate everything. Although Novell released its NetWare directory services (NDS)
as part of NetWare 4.0, it failed to bring DS to the mainstream (for information
about NT and NDS, see Craig Zacker, "Windows NT and NDS," March 1997).
Like Novell, Microsoft also had the people, talent, and money to bring a
world-class DS system to NT. However, Microsoft didn't have the incentive to
move away from the traditional NT domain security model until the company could
decide how such a new DS should work.
Microsoft began developing a new DS paradigm on an X500 DS system for Cairo. The company put this technology to use in Exchange Server. But as the Internet grew in prominence, the need to support TCP/IP and Internet Domain Name System (DNS) became critical. So the Cairo DS changed shape into the Lightweight Directory Access Protocol (LDAP)-based solution. So, at least from the DS point of view, the Internet and Cairo worked hand in hand: The Internet helped push the mind-set change necessary for us to benefit from the Cairo mentality.
DS is X500 and DNS based, replaces the NT Domain Security model, and will offer far more information and storage capabilities than NT's DS. Cairo's DS will be scalable to very large systems and offer very fine granularity. Just imagine a DS aimed to take on the Novell NDS and win, and you get the right idea. The new DS surfaces a huge number of properties about users, machines, processes, and so forth that you can browse from anywhere using ASP-based Web servers. The IIS 3 platform is key to the configuration and management of the new NT 5.0 directory, which you manage with ASP pages hosted in IIS 3 or IIS 4 and that the client views with a Web browser.
Under the new DS, a user has properties such as telephone number, location, and department. Now you can build rich information stores that aren't RDBMS based, but that you can browse using whatever tool you like, such as a Web client or database viewer.
Exchange Server wrapped the Cairo Mail promise into a product complete with a grotesque forms engine and an absurd storage solution. This product has many Cairo DS and NT 5.0 DS features. It is X500 based, with a rich DS that Microsoft originally designed for NT; it understands Internet mail; it has a rich object store; it supports OLE objects; and in many ways, it is a conceptualization of Cairo's original aims. But compare the scope of Exchange Server with the scope of the current Cairo plans, and the new 1997 solution is obviously going to make the 1994/95 Exchange Server look weak at the knees.
I won't dwell on NT DS here, for a couple of reasons. First, the code we have today is still an alpha build running on NT 4.0 alongside the existing NT DS system. Second, many of you will already have the NT 5.0 DS and ASPs because Microsoft distributed them as part of the December Microsoft Developer Network (MSDN) release, at least for Universal subscribers. Finally, the best place to start thinking about the NT 5.0 DS is not with the code, but with the OLE DS white papers on Microsoft's Web page at http://www.microsoft.com/msdn/sdk/techinfo/adwp.doc. You see, all the interfaces into the new DS will exist as OLE automation interfaces. This integration will make leveraging the new DS from within any application you like or from within a server-hosted ASP client/server solution easy. You can expect to see the final NT 5.0 DS ship with the NT 5.0 product, possibly in 1997, depending on how the testing goes.
Are We There Yet?
In some respects, we have lots of Cairo here today. Some parts are in beta,
and others are in alpha release or still haven't seen the outside world.
Although we might have not yet reached the mythical Cairo and have been sidetracked with layovers in London, New York, and Paris, the destination city is now clearly within site. The journey has been very long indeed.
The best part of the trip is that the vision of Cairo is still intact. Some of the methodology has changed--we could not have envisioned the use of HTML as a page description language, for example, but you can't deny that we needed such a language, and HTML will do nicely. Nor could we have envisioned the rise in TCP/IP, but we needed a globe-spanning networking protocol for Cairo, and TCP/IP and DNS are up to the task.
When you spin in the sidetrack distractions of getting NT into shape and bringing together all the OLE technology and development tools required to support the Cairo vision, you soon see that Cairo was never going to be a mere product. It is actually the culmination of a lot of work, all pushing in roughly the same direction, lasting for many years. And Cairo isn't really a destination by itself. Once we get into serious OLE/ActiveX control development and can seamlessly distribute these controls between servers and clients, we will have achieved the final goal of moving from a file and print-share network model to an information-share model. We will have also expanded the scope of this new information model to encompass the whole world.
Yes, Cairo's late. Two years ago I thought Microsoft had lost its way and had given up any hope of turning its vision into a reality. The Internet gave Cairo a kick start, but also made the marketplace lurch out of its slumber. Will it work? It has to.
RELATED ARTICLES IN WINDOWS NT MAGAZINE
Jon Honeyball,
- "Exploring Cairo: Object File System," November 1995
- "Exploring Cairo: Forms Database Engine," January 1996
- "Exploring Cairo: Remote OLE," April 1996