WinFS has had a turbulent history. Originally announced as one of the three “pillars” of Windows Vista—the other two being the new Windows Presentation Foundation (formerly code-named “Avalon”) user interface layer and the Windows Communication Foundation (formerly code-named “Indigo”) web services layer—WinFS was to revolutionize how users and developers interacted with the files on their computers. In late 2004, Microsoft announced that Vista, then code-named Longhorn, would ship without WinFS. Later it was admitted that WinFS would be delayed even beyond Vista Server, but would be released as a free separate download for both Vista and Windows XP. Beta 1 of WinFS hit MSDN last August, and looked promising. However, Microsoft dropped a hammer on WinFS fans this weekend by revealing that WinFS Beta 2 has been canceled, and the technology behind WinFS is now scheduled to be rolled into the next release of Microsoft’s SQL Server product, rather than a standalone release:
“Since WinFS is no longer being delivered as a standalone software component, people will wonder what that means with respect to the Windows platform. Just as Vista pushed forward on many aspects of the search and organize themes of the Longhorn WinFS effort, Windows will continue to adopt work as it’s ready. We will continue working the innovations, and as things mature they will find their way into the right product experiences—Windows and otherwise.”
How did such a promising technology fall so far behind schedule, and what will the change of delivery plans for WinFS mean for Windows users and developers? To answer those questions, let’s jump in the wayback machine and look at how WinFS came to be in the first place.
In 1991, Microsoft’s Jim Allchin announced a project code-named Cairo, which was intended to be a new operating system based on Windows NT, which was already in development. Cairo was demonstrated to the public in 1993, and featured a host of advanced technologies, including an object-oriented user interface, X.400 directory and X.400 messaging services, remote procedure calls, content indexing, and an object-oriented file system.
Cairo became a bit of a monster, sucking up Microsoft employees at an insatiable rate with no clear shipping date in sight. Eventually Cairo was canceled as an overambitious project, although most of its components did eventually ship as part of various other Microsoft products. Remote procedure calls were bundled with Windows NT 3.1, a stripped-down version of the user interface appeared in Windows 95, the messaging components shipped with Active Directory in Windows 2000, and content indexing was featured in MSN Search. The only major component of Cairo that never shipped as part of any product was the file system. A database-driven, object-oriented file system was an interesting concept, but performance concerns on the hardware of the day killed the idea.
A few runs of Moore’s Law later, the idea resurfaced as WinFS. WinFS was not technically a file system by itself, but a database-driven layer that ran on top of Windows’ NTFS file system. However, the idea was to make WinFS transparent enough that developers could program to its APIs (Application Programming Interfaces) almost as if it were a native file system. This essentially meant that a system-level database existed for all the files on your computer, which could then be accessed in many creative ways by running SQL queries.
To demonstrate the power of WinFS to end-users, Microsoft integrated all kinds of new searching methods in Windows Vista. I received a demo of an early version of this user interface in 2004, and it looked promising. Fortunately for end users, the designers of this interface made it completely independent from WinFS. While the UI has changed somewhat in later builds, the searching abilities (such as being able to create live-updating folders based on previous queries) have not been lost. The difference is that they rely solely on Vista’s built-in Windows Search file indexing service (an enhanced version of the MSN Search tool available today) rather than WinFS technology.
So if end users won’t notice any difference in Vista’s abilities, what has been lost by WinFS’s repositioning? The people most impacted are developers who were hoping to create new applications that utilized WinFS technology across multiple applications. Even some developers are less than clear about how this will affect their plans. Alex James of Base4 Solutions had this to say about the announcement:
Sure we will have ADO.NET Entities and SQL server will have more features, but at the end of the day there will be no relational file system:
We won’t be able to run SQL like queries against the file system.We won’t be able to bridge other data into the file system.We won’t be able to bridge structured databases and unstructured files/emails.We won’t have a framework for promoting meta-data from proprietary file formats.We won’t have a file system with cool replication technology.
So why didn’t I care too much initially? Well I brought my frame of reference, and my frame of reference never really cared about integrating all the cool WinFS stuff with the Win32 API.
I mean with a little bit of creativity you can avoid needing this step. WebDAV anyone?
The extent of the fallout from Microsoft’s announcement will probably take a few days to be revealed. It is probably premature to proclaim that WinFS is “dead.” The technology is not going anywhere, and Microsoft has not ruled out integrating WinFS into future versions of Windows. At the moment, however, it is disappointing news for developers who expected to be able to write applications using this technology that all Windows users could run, not just developers with SQL Server.