From BetaArchive Wiki
WinFS Beta 1 logo

WinFS (short for Windows File System[1] or Windows Future Storage[2]) is a canceled[3] storage subsystem that allowed users to search for items based on their metadata, regardless of the item's type of file and the application in which it was created. This in turn would make searching for content independent of format easier.[4]

WinFS was billed as one of the pillars of Windows Longhorn.[5][6][7][8] However, Microsoft announced on 27 August 2004 that WinFS would be in beta testing when Longhorn becomes available, and would be delivered after the Longhorn release.[9] On 29 August 2005, Microsoft announced the release of WinFS Beta 1 for Windows XP Service Pack 2.[10] A Beta 1 Refresh was released on December 2005.[11] Regular beta and CTP releases were planned.[10]

On 23 June 2006, Microsoft (through Quentin Clark, who ran the Program Management Team for WinFS)[12] announced that there would no longer be a separate WinFS release.[13] Instead, some of its parts were included in ADO.NET and Microsoft SQL Server.[13][14][15]

WinFS was based on SQL Server 2005, ran on top of NTFS, and used metadata of files to improve organizing, searching and sharing of information.[16] It also stored structured data such as contacts and calendars. WinFS replaced the traditional file system hierarchy of files and folders[17] with items (either based on files or not, such as contacts and e-mails) and associations (relationships between items).[18]



WinFS is ultimately traceable to the Object File System (OFS) of Windows Cairo. In a Computer Chronicles episode from 1993 on Windows NT, Mark Cligget of Microsoft described OFS, although not by name:

Cairo will make it easier for people to say "Just give me the the sales data for the month of December", and the system will take care of finding the data, also enable people to build solutions where uh, where they can work with the data in exactly the way they want to. They don't have to worry about what application they're running in. They don't have to worry about the exact structure of the data. Things will just flow more smoothly in the way that people want it.

— Mark Cligget, The Computer Chronicles - Windows NT (1993), [19]

An internal March 1993 Product Planning document (later offered as a Plaintiff's exhibit and admitted in court for the antitrust case Comes v. Microsoft) described the following features related to OFS in page 5 (or page 8 of the PDF):

Distributed services and storage systems

Object File System. The Object File System (OFS) is a new high-performance file system for Cairo; it offers many features suited for native storage of objects. The OFS stores object data efficiently since it stores small objects with little overhead. It supports multiple streams that allows efficient use for OLE embedded objects. The preferred choice of Cairo's multiple installable file systems, the OFS indexes file contents and properties to support queries. It also supports long file names, quotas and a log of operations to maintain file system integrity.

Access Control. To properly control access to files in the OFS, the distributed security system provides the local operating system with the security identity and access privileges of networked users. Under the distributed security system, a user logs onto the system only once during a Windows Cairo session to establish access to enterprise resources.

Content Indexing. By indexing files according to their content and properties, the OFS provides very fast retrieval of files based on these characteristics. Coupled with the Explorer, content- and property-based retrieval greatly eases finding (organization and presentation) of unstructured information, especially on a network.

Replication. Cairo replicates files in the Object File system to increase availability, and uses the same system to replicate network domain controllers.

Distributed File System. Built on top of the OFS, the Distributed File System (DFS) maps all shared disk space in a network in the form of a single. logically arranged namespace. The DFS combines any number of networked file systems (including heterogeneous file systems) and object stores into a single global namespace. This enables users to access local or remote objects — such as files, documents, printers, and other users — using a single naming scheme.

Directory Service. Cairo leverages the DFS to provide a Directory Service (DS) data base describing the various resources on the network. The DS does away with the other naming schemes such as drive letters, E-Mail names, disk directories, file shares, printers, or network domains (C:, John Doe@Host, \WINDOWS\SYSTEM, \MTKG\PUBLIC, LPT2:, or “Building 5”), The DS enables administrators to locate, monitor, and manage all information on the entire networked system, including foreign networks.

— Greg Lobdell, I. Product Overview, [20]

A more detailed discussion of OFS appears in pages 37-39 (40-42 in the PDF) of the planning document:

The Object File System (OFS) for Cairo provides advanced persistent storage for objects. It is a robust, recoverable file system that provides direct support for object properties, in addition to content indexing, content and property based queries, link tracking, and the basis for replication and the distributed file system (DFS).

Cairo can also use other file systems such as FAT, NTFS and HPFS. However, the user and administrator should understand that these other file systems are not optimized for storing Cairo objects, and much Cairo functionality will be lost if OFS is not used.

Multiple file systems can be used with Cairo. For example, a particular Cairo installation may have two file systems, one FAT and the other OFS. They are plugged into the system using the IFS (installable file system) mechanism in NT. An OSH (object store handler) written for OFS and non-OFS file systems is responsible for interfacing the file system to Cairo.

Users can also convert their existing file systems. Cairo will provide FAT to OFS and NTFS to OFS conversion. HPFS users can convert OFS, by first converting the HPFS volume to NTFS using NT's conversion utility, and then converting the NTFS volume to OFS.

The remainder of this section discusses the Object File System, the recommended persistent store for Cairo.


OFS provides high performance persistent storage of objects and native file system support for the OLE2 storage interfaces. OFS is the file system of choice for Cairo.


OFS will provide similar if not better performance than FAT.


  • Administration. OFS will notify the administrator of interesting file system events, such as quota violation, and read/write errors. OFS will support monitoring using the meters, counters and other measurement tools provided by System Management.
  • Capacity. OFS can address volumes as large as 2 terabytes. OFS will use the same compression algorithm as DOS 6.0.
  • Context Index Notification. OFS notifies the Content Index when objects have been modified so that it can update itself.
  • Dynamic Repartitioning. An existing FAT partition can be "shrunk" without loss of user data in order to create a new partition for an OFS volume.
  • Efficiency. OFS uses an advanced allocation algorithm to provide efficient storage for small objects with as little as a few hundred bytes of overhead per object. OFS provides copy-on-write support. Copes of objects share parts of streams that are identical between them, minimizing storage requirements.
  • Filesystem Conversion. OFS provides a utility to convert FAT and NTFS volumes to OFS with no loss of user data even in the event of a power failure.
  • Junction Points. OFS catalogs can be joined together through the use of junction points. OFS volumes can serve as non-leaf nodes in the distributed filesystem whereas non-OFS volumes can only be leaf nodes.
  • Link Tracking. OFS provides support for link tracking across volumes.
  • Long Filenames. OFS allows long, Unicode filenames, and mapping between 8.3 naming and long filenames identical to NTFS.
  • Multi-spindle Volumes. OFS volumes can be composed of multiple physical disk drives. Extra drives can be easily added to increase disk space as needed. Total volume size, regardless of number and sizes of individual spindles cannot exceed two terabytes.
  • OLE2 Support. OFS implements the OLE2 IStorage and IStream interfaces directly, eliminating the need for Docfiles, and this significantly improving performance and efficiency. Multistream OLE2 objects are really composed of separate multiple streams under OFS.[21]
  • Property Support. OFS implements the property interface for efficient access to properties. Speed of property based queries is enhanced by using a property value index for frequently accessed properties.
  • Query Support. OFS resolves both content based queries, and queries on object properties. Queries can span multiple OFS volumes.
  • Quota. OFS allows the administrator to assign disk space quotas for users.
  • Recoverability. OFS maintains a log of all directory/allocation changes made to the disk to permit fast recovery in the event of a system failure. RAID, disk mirroring and striping are supported by layering device drivers provided by NT for these functions.
  • Remote Access. OFS will extend the Server Message Block (SMB) operations to allow use of new OFS features across the network.
  • Replication. OFS supports object replication by maintaining deletion logs and other data structures used by the OFS and DS.
  • Security. OFS provides ACL based security for every object.
  • Summary Catalogs. OFS provides efficient storage of summary catalogs and uses its content and property value indexing technology to enhance queries directed against summary catalogs.


OFS provides a high performance, robust file system customized to support the advanced features of Windows Cairo. It uses a new method of allocating disk space that can store many small files (which will be common under Cairo) without wasting disk space even on huge volumes. If the user is running out of disk space, he can simply add a new disk to the system and grow the amount of available disk space that OFS manages without backing up or moving any existing files. An OFS volume can be grown like this up to two terabytes. OFS groups small properties together so that a minimum number of disk accesses are required to fetch the values - often as few as a single disk hit.

OFS maintains a log of all its pending disk modifications so that it knows what actions have to be redone, and what have to be undone to recover in the unlikely event of a crash. More advanced fault tolerance features such as RAID, disk mirroring and disk striping can be used by adding the appropriate device driver to NT. OFS can work transparently with these features.

OFS implements the query interface on top of the file system so that users can ask for information about the objects that OFS maintains on its volumes. To enhance this functionality, OFS maintains a content and property index. Users won't have to periodically execute an indexing program and tie up their system while it runs. The indexing engine runs in the background, allowing the user to work on their document in the foreground, confident that its content and properties will be indexed and accessible via queries.

OFS provides the basic filesystem services used by the Directory Service and Distributed File System to create a single global namespace for the user. The user no longer needs to keep track of which objects are located on which machine - OFS and the DFS keep track of this information.

All of this is provided, without sacrificing compatibility with FAT. Existing DOS and Windows programs will be able to access all existing documents. OFS provides easy migration from FAT and NTFS using the OFS conversion utility. This utility allows the user to convert their existing filesystem to OFS in place without requiring any backup or re-arrangement of files.


OFS will support all DOS and Win32 file APIs, both locally and remote. OFS data structures are not binary compatible with FAT so utilities that expect FAT data structures on disk will not work (e.g. Norton Utilities for DOS). OFS will convert between docfiles and the more efficient multi-stream format[21] used by OFS as needed by downlevel and Cairo aware applications. OFS will provide a utility to convert FAT and NTFS volumes to OFS with no loss of user data.

Non Goals

  • OFS will not be available on DOS or Chicago.
  • OFS will not convert Netware or HPFS volumes.
  • Conversion of OFS volumes back to FAT or NTFS will not be supported.
  • There is no robustness support for multi-spindle volumes aside from standard logging.
  • OFS does not support POSIX, and thus, will not support traversal permission, case sensitive names or equal instance hard links.
  • OFS will not provide support for sparse stream storage.
  • OFS will not provide EA support.

Open Issues

  • What are Delphi's indexing requirements? Will they affect summary catalogs?
  • How will OFS work with floppy drives? The user should not have to worry about file format changes (docfile, MSF, etc.) when copying objects to floppies.
  • Do we need ACLs on embeddings or just property sets? What are Delphi's requirements?

— Nikhil Joshi, File Systems, [20]

The reference to "Delphi" refers to smart folders (page 3, or page 6 of the PDF):

Smart Folder (a.k.a. Delphi collections): Users will see certain folders with "intelligence." That is, properties on the folder define both the way information is stored in a smart-folder and the attributes of that information. The Cairo User Assistance system (Help) is an example of smart-folders in use. In addition, Cairo will ship at least an Email client, Bulletin Board System, and Document Management system as useful examples of smart-folders. Basic operations with smart folders are identical to standard shell folders - and most importantly, the user interface is through the Explorer.

— Greg Lobdell, I. Product Overview, [20]

The plan (page 58, or page 61 of the PDF) is that Cairo would ship with a mail server, the message store of which is integrated with OFS:

Message store integrated with OFS. Users' messages and message folders can be stored on the server, and are implemented as files and directories on OFS. There is no separate database code or format: OFS is the store.

— Aaron Contorer, Mail Server, [20]

A patent application from 1995 described a system for case-based organizing and querying of a database, such as a "collection of text objects supported by Cairo Milestone 4 running under the Windows NT system version 297, available from Microsoft Corporation of Redmond, Washington, and may be accessed in conjunction with the object file system 107 of that product."[22] The patent application then describes the user interface:

Figure 6


Figure 6 shows an example explorer user interface screen as viewed by an operator. While the invention is described primarily with regard to a specific user interface, it would be clear to those of ordinary skill in the art that another user interface of equal or greater flexibility would be suitable, and would be within the scope and spirit of the invention.

In a preferred embodiment, the user interface 109 may be combined with a user interface for a generalized file system exploration program, such as in the Windows NT system referred to herein. The user interface 109 may comprise a query window 601 in which the operator may enter the query 104 in free text, and a results window 602 in which the system 101 may display a set of matched objects 106 found in response to the query 104.

In a preferred embodiment, the operator 108 may enter the query 104 in the query window 601. The query 104 is input to the explorer 105, which processes it as described herein, and generates the vector query 112. The vector query 112 is input to the object file system 107, and generates the hit table 113 of matched objects 106. The hit table 113 is input to the user interface 109, which displays the matched objects 106. The operator may select a displayed matched object 106 to view its contents. In a preferred embodiment, the user interface 109, the explorer 105, and the object file system 107, may operate as asynchronously as possible. Accordingly, the object file system 107 may search the database 102 for matched objects 106 independently, once it has sufficient information from the explorer 105; the user interface 109 may display matched objects 106 from the hit table 113 as they are generated by the object file system 107.

In the example, the operator 108 has entered the query 104 "who invented the light bulb?" in a content field 603 of the query window 601, and the system 101 has responded with a set of matched objects 106 in the results window 602. The matched objects are displayed one per line, in columns labelled "rank", "query", "header", and "relevant words".

In the example, a rank field 604 displays the quality of match for each displayed matched object 106. In a preferred embodiment, the system 101 may order the matched objects 106 by rank. This may occur as the normal procedure, or at the request of the operator 108, e.g., by means of a "sort" command 605 in the query window 601. In a preferred embodiment, the rank field 604 may also be color-coded by value. In the example, a query field 606 displays the relevant words of the query which are most related to the displayed matched object 106. In the example, a header field 607 displays the header words 204 of the displayed matched object 106.

In the example, a relevant words field 608 displays the most common relevant words 211 of the displayed matched object 106.

In the example, a topics field 609 of the query window 601 displays suggested topics for refinement of the query 104 which the system 101 has identified. In a preferred embodiment, the operator 108 may select a topic in the topics field 609, and the system will display a subtopics window 610 (overlaid on the query window 601 and the results window 602) showing the subtopics which the system 101 has identified for that topic. [...]

Figure 7


Figure 7 shows a second example explorer user interface screen, as viewed by an operator, in which clusters are displayed.

The operator 108 may select a "cluster" command (figure 6) or "uncluster" (figure 7) command 701 in the query window 601, and the system 101 will display a set of clusters 402, each a set of related matched objects 106, in place of displaying matched objects 106 themselves. In the example, the operator has selected the "cluster" command 701 for the same query 104 as in the example of figure 6.

In the example, an expand field 702 displays whether the cluster 402 can be expanded (shown by a "+" symbol) to display individual matched objects 106, or can be collapsed (shown by a "-" symbol) to display a single identifier for the cluster 402.

In the example, the rank field 703 displays the best rank for all matched objects 106 in the cluster 402. In a preferred embodiment, the system 101 may order the clusters 402 by this rank field 703. This may occur as the normal procedure, or at the request of the operator 108, e.g., by means of the "sort" command 605 in the query window 601. In a preferred embodiment, this rank field 703 may also be color-coded by value.

In the example, the relevant words field 608 displays the most common relevant words 211 in the cluster 402.

Other fields and windows remain similar to the example of figure 6.

The operator 108 may also choose to cluster all objects 106 in a specific set, e.g., a specific directory in the object file system 107. In a preferred embodiment, the operator 108 may restrict the scope of the explorer 105 to a specific directory and issue the "cluster" command 701; the system 101 will display the objects 106 in that directory in clusters 402.

Figure 8


Figure 8 shows an example explorer user interface screen, as viewed by an operator, in which settings may be set by the operator. In a preferred embodiment, the operator 108 may select settings appropriate for the system 101. The operator 108 may select a "properties" command 801 in the query window 601 (figure 6) , and the system 101 will display a properties window 802 with a set of property values 803 which may be set.

A "minimum rank of returned hits" property 804 is a threshold value for including matched objects 106; matched objects 106 whose rank falls below this value are not displayed in the results window 602 and are not used in further processing. The rank of a matched object 106 is calculated by the CBR engine 110. In the example, this value is set to 80.

A "maximum clustered hits" property 805 is a maximum number of matched objects 106 which are included in a single cluster 402. Those matched objects 106 not included in clusters 402 are placed in a special cluster 402 labelled "Other". In the example, this value is set to 400.

A "clustering time" property 806 is the elapsed real time devoted to clustering. In the example, this value is set to 2500 milliseconds.

A "minimum number of clusters" property 807 is the lower bound for the number of clusters 402 generated. In the example, this value is set to 2 clusters.

A "maximum number of clusters" property 808 is the upper bound for the number of clusters 402 generated. In the example, this value is set to 8 clusters. The system 101 attempts to generate a number of clusters 402 between the minimum and maximum number selected.

A "maximum topics" property 809 is the maximum number of topics displayed in the topics field 609 in the query window 601. In the example, this value is set to 7 topics.

A "maximum subtopics" property 810 is the maximum number of subtopics displayed in the subtopics window 610. In the example, this value is set to 250 subtopics.

A "do/don't cluster" property 811 sets whether or not clustering is performed. In the example, this value is set to YES.

A "do/don't generate query topics" property 812 sets whether or not topics and subtopics are generated in response to query terms 310. In the example, this value is set to YES.

A "do/don't generate salient topics" property 813 sets whether or not topics and subtopics are generated in response to relevant words 211. In the example, this value is set to YES.

A "boolean/vector query" property 814 sets whether the object file system 107 performs a boolean query or a vector query in response to the ejφlorer 105. In the example, this value is set to vector queries. A boolean query would have boolean connectors (e.g., "AND", "OR") coupling the query terms 310, so that the query 104 would not be as flexibly matched. Search using boolean queries is well known in the art.

— Bradley P. Allen, David J. Lee, Roger D. Carasso, John R. Perry, Case-based organizing and querying of a database, [22]

In analyzing the leaked Windows NT 3.5x source code, BetaArchive user jimmsta explained:

I feel as though no one has ever really dug in to the various leaked bits of NT code and really done a deep dive into certain bits that made NT 'go'. I've spent the last couple weeks on and off, reading through bits of NT 3.51's code, which led me to a few pointers in search of Cairo. That particular leak is RC2 of NT 3.51, as far as I know. [Jimmsta may instead be referring to the Windows NT 3.5 source code leak.][23] As such, it wasn't fully stripped of Cairo bits - OFS is in there, and within the code for the Object File System, a lot of interesting tidbits can be learned. Primarily, while it appeared as a separate filesystem, it does not have any kernel-level drivers. It instead, runs entirely in User-Mode. It appears to be nearly an implementation of Bitmapped FAT - but does not store anything on disk with your typical FAT formatting. It contains an index, bitmap, and list of "onodes", which appear to be 'object nodes'. Each 'file' is stored as a data stream, encapsulated inside a virtual FAT disk, of which, there can be multiple virtual FAT data streams[21] stored as drive objects on the single OFS volume. The objects in question are OLE data streams. Instead of files, each bit of data saved to an OFS volume is composed of OLE objects, with corresponding data and metadata saved alongside the data stream.

— jimmsta, What became of Windows Cairo, [24]

Build 1175.1 required that one disk be formatted to OFS.[25][26] However, it is recommended that the system disk not be formatted to OFS, since booting from an OFS partition can lead to hanging.[27][28]

The build also implemented Content Indexing (now the Indexing Service)[29] as well as "DS", which may refer to the Directory Service,[29][30] which shipped in Windows 2000 Server as Active Directory.

In hindsight, OFS is described as an integrated store,[31] a data store, for storing document files, spreadsheets, multimedia files and other information[32], planned for Cairo.[32][33][34] The idea behind OFS "was to make sense out of all the bytes of data in the filesystem in a human readable and searchable way, organized as a collection of objects with properties all part of a strongly typed schema."[34] OFS was a relational file system, "which would help manage local and distributed objects using an active storage paradigm" and "would have removed the need to understand where data resided", both locally and remotely.[33]

Cairo fell apart in the mid-1990s.[33] According to then-Microsoft’s lead NT product marketing manager Mark Wood, at some point, OFS was stripped of its objects-only meaning and the term "OFS" actually described a feature set rather than a specific product.[35] On March[32] or April 1996,[35] Microsoft said that work on OFS for a future release of Windows NT had been abandoned in favor of a file system based on its Exchange Server,[32] or in favor of an enhanced NTFS to support OFS features such as content indexing and queries, extensible attributes, and the creation of a logical view of the network independent of its physical configuration – a big disk approach also known as a Distributed File System (DFS).[35] The file system work was abandoned because of complexity, market forces and internal bickering,[32] or due to costs to the user, as well as costs and time of development,[35] or because it was no longer necessary to beat OS/2.[36]

BetaArchive user jimmsta theorized that OFS did ship, as the Active Directory File Store in Windows 2000.[24] In his view, "the whole point of WinFS was to provide a localized version of Active Directory's file store".[37]


The more common view is that OFS never shipped. Instead, new projects would perform its intended functions. One such project is Storage+, which Paul Thurrott said Microsoft would turn its attention to after Windows 2000 shipped. Storage+ which would replace the NTFS file system and with a relational, object-oriented file system based on SQL Server 8.0. The file system would become a relational database, speeding searches and providing a higher level of granularity for those searches[38] Storage+ later became the Relational File System, which Microsoft intended to but failed to ship with SQL Server 2000.[33]


Storage+ then became "a new SQL Server .NET-based file system" slated for Blackcomb. However, by 2002, Thurrott reported that it would ship with Longhorn.[39] CNET reported:

"We're going to have to redo the Windows shell; we're going to have to redo Office, and Outlook particularly, to take advantage" of the new data store, Microsoft CEO Steve Ballmer said in a recent interview with CNET "We're working hard on it. It's tough stuff."

— Mike Ricciuti, New Windows could solve age-old format puzzle--at a price, [32]

Jim Allchin, the group vice president in charge of Windows development, said:

bringing the plan back now makes sense because new technologies such as XML (Extensible Markup Language) will make it much easier to put in place. XML is already a standard for exchanging information between programs and a cornerstone of Microsoft's Web services effort, which is still under development. Longhorn and the new data store are the "next frontier" of software design, Allchin said. In addition, Microsoft has already developed the database technology it needs for a new file system. A future release of its SQL Server database, code-named Yukon, is being designed to store and manage both standard business data, such as columns of numbers and letters, and unstructured data, such as images.

— Mike Ricciuti, New Windows could solve age-old format puzzle--at a price, [32]

By 2003, Storage+ was called WinFS, would include technology from SQL Server "Yukon" (SQL Server 2005)[40], and would not be a file system but a service on top of NTFS.[41]

During PDC 2003, Bill Gates described WinFS as a "Holy Grail":

WinFS, this is unified storage. Some of you here have heard me talk about unified storage for more than a decade. The idea of taking the XML flexibility database technology and getting it into the file system, that's been a Holy Grail for me for quite some time, and here it is thank goodness. We've got the powerful systems to be able to do this. Thank goodness, we have the evolution around XML and user interface capabilities, so that this this can all come together.

— Bill Gates, PDC 2003 Keynote with Bill Gates, [42]

Bill Gates had earlier described OFS as a "Holy Grail" in his PDC 1996 keynote.[43]

In his PDC 2003 presentation, Quentin Clark, director of program management, WinFS, explained the following points, summarized by Thurrott and Furman:

WinFS is...

  • All end-to-end data lives in Longhorn
  • New user experience in the Longhorn shell
  • A trustworthy place to store data
  • Data model built on relational database technology
  • File system capabilities built on NTFS
  • Everyday info - domain specific schemas - Longhorn will come with set of schemas Services that make data interactive

WinFS is not...

  • Abandoning legacy applications
  • Forcing the world to rewrite everything
  • Complete yet
    • PDC is good preview of model, feedback welcome
    • Fundamental model complete for Beta 1
    • Platform and UE complete in Beta 2
  • Just a database - MS has set of relational assets, WinFS is pulling techs from NTFS, SP, and CLR too

— Paul Thurrott, Keith Furman, Live from PDC 2003: Day 2, Tuesday, [44]

This WinFS schema diagram dates from PDC 2003.

On 19 April 2004, BusinessWeek reported that Microsoft would scale back WinFS to provide document indexing only on the local system and not over a network.[45][46]

On 13 May 2004, it was reported that Bob Muglia, the senior vice president in charge of Windows server development told CNET

some of the functionality of WinFS and some of the scenarios may be limited in terms of what it can do. I don't know that we will have all of the scale to the level where we would like to have it, so that you could use it for very high-volume enterprise servers,

— Mike Ricciuti and Martin LaMonica, Longhorn goes to pieces, [47]

So it could be that for example, you could use WinFS as a server for collaboration in workgroups. But if you want to support hundreds of users, that may wait for the update release."

— Mike Ricciuti and Martin LaMonica, Longhorn goes to pieces, [47]

On 27 August 2004, Microsoft announced that WinFS would be in beta testing when Longhorn becomes available, and would be delivered after the Longhorn release.[9] This meant that WinFS would be removed from Longhorn and would ship at a later date.[33] Thurott wrote:

The removal of WinFS, however, had wrecked havoc with a number of product groups. The next version of Outlook Express (now called Windows Mail) and Contacts were originally being built around WinFS and had to be rearchitected. Internet Explorer was using it for storing history and Favorites. Even Office 12 was building on WinFS. All of that work--and more---needed to be rethought.

— Paul Thurrott, Paul Thurrott's SuperSite for Windows: Road to Gold: The Long Road to Windows Vista Part 3: 2004, [46]

A report from 10 December 2004 quoted Muglia as saying that WinFS would neither be in Longhorn nor in Longhorn Server. Muglia also said:

Our mistake, frankly--and it was a mistake--was to go out and talk about it before we really had clarity as to how we would be able to deliver it and all the complexities there.

— Ina Fried, New file system has long road to Windows, [48]

He then described WinFS:

This isn't a relational database [...] This is a brand-new data model, and it satisfies a whole class of applications that frankly have been unsatisfied from a data model perspective since the beginning of history. We've been working on things like this for a long time.

— Ina Fried, New file system has long road to Windows, [48]

Beta 1

On 29 August 2005, Microsoft quietly[33] made WinFS Beta 1 available to MSDN subscribers, but announced it officially through the WinFS Team Blog.[10][12] Beta 1 required Windows XP Service Pack 2,[10][12] and .NET Framework 2.0.50215.322.[33] The WinFS API was included in the System.Storage namespace.[49]

During PDC 2005, Microsoft released a video presentation, named "IWish",[50] showing how applications would advantage of a unified type system. The concepts shown in the video ranged from applications using the relationships of items to dynamically offer filtering options to applications grouping multiple related data types and rendering them in a unified presentation. Steve De Mar, the Product Designer for the WinFS team, explained the goals of IWish:

Our goal was to peak the curiosity of you, the developers, to get you thinking about what could really be built on WinFS. We wanted you to see how WinFS enables a totally new class of user experiences. The UIs in the video are all based on some of the great prototype applications that have already been developed for the WinFS platform. Although we cast them in a more futuristic visual “theme” to fit the style of the video, the functionality we showed exists in the prototypes that either we’ve developed in house or we’ve seen others develop on WinFS. A number of these were demo’d at the PDC, and we've more on the way which you should be hearing about shortly.

We hope the video inspires you to bring to life cool new innovative applications for WinFS!

— Steve De Mar, WinFS PDC Video, [51]

In addition, during PDC 2005, Shishir Mehrota of WinFS Product Planning gave an overview of WinFS,[52][53] Program Manager Ramesh Nagarajan gave a presentation on "“WinFS” Future Directions: Building Data-Centric Applications Using Windows Presentation Foundation “Avalon” and Windows Forms",[54] (for which he built a simple Windows Presentation Foundation application that showed off how a richer document viewing experience could be built on top of WinFS)[55] and Samuel Drucker, Development Manager, gave a presentation on WinFS and ADO.NET (on how ADO.NET is evolving to incorporate some of the WinFS aspects)[56] and WinFS Programming with LINQ.[57]

Four WinFS sessions were planned for Tech Ed 2006.[58] Roger Lueder gave a talk on "Building on WinFS: Developing a Great WinFS App from Scratch".[59]

"FIG. 7 is a block diagram illustrating as an example the alignment of Microsoft Windows® File System (WinFS®) content in a Microsoft Windows® Desktop Search (WDS)" (Source: US7590654B2 patent)[60]

Beta 2 was planned for some time later in 2006,[58] and would have been integrated with Windows Desktop Search, so that the latter could display both WinFS and non-WinFS files.[61]


On 23 June 2006, Quentin Clark announced through the WinFS Team Blog, "With most of our effort now working towards productizing mature aspects of the WinFS project into SQL and ADO.NET, we do not need to deliver a separate WinFS offering."[13]

Many of the principal features Microsoft intended to provide with WinFS included a pane for metadata property editing, breadcrumb-based property navigation, filtering or stacking items over properties, incremental search, and saved searches;[1] these features were incorporated in Windows Vista.[62] Query composition, a WinFS feature that allowed users to perform additional searches that reuse the results of a previous query,[63] was later incorporated in Windows Vista.[64]

Examples of uses of the technology are the object-relational mapping components into ADO.NET Entity Framework; support for unstructured data, adminless mode of operation, support for file system objects via the FILESTREAM data type[65], and hierarchical data in SQL Server 2008, then codenamed Katmai, as well as integration with Win32 APIs and Windows Shell and support for traversal of hierarchies by traversing relationships into later releases of Microsoft SQL Server[15] and the synchronization components into Microsoft Sync Framework.[15]

In 2013, Bill Gates cited WinFS as his greatest disappointment at Microsoft:

We had a rich database as the client/cloud store that was part of a Windows release that was before its time. This is an idea that will [re-emerge] since your cloud store will be rich with schema rather than just a bunch of files and the client will be a partial replica of it with rich schema understanding.

— Gavin Clarke, Billionaire baron Bill Gates still mourns Vista's stillborn WinFS, [66]

Limitations of traditional file systems

Traditional file systems, including NTFS which is used in modern versions of Microsoft Windows, store data only as a stream of bytes packed in a file. The Microsoft WinFS SDK Beta 1 Documentation explained the limitations of this approach:

In a file system, data is stored as one or more byte streams packed in a file. This flat data structure does not make the information easily identifiable. The only viable way to identify it is to use the file name and its directory path, that is, a folder hierarchy. Although a file may contain many kinds of information, it is the smallest unit of data that can be moved around and operated on. For example, to read a paragraph of a document, you need to retrieve the entire file and open it in a document viewer.

— Microsoft, Overview > WinFS: Unified Storage System for Windows, Microsoft WinFS SDK Beta 1 Documentation, [67]

As Richard Grimes explained:

The perennial problem with data is that you always have too much of it and it is always too difficult to find what you want. This problem will get far worse in the near future when typical machines will have hard disks measured in terabytes. The bigger the hard disk, the more data you will want to store, and the more difficult it will be to find a particular item. Finding a piece of data depends on identifying the specific item, which means that the item has to be categorized.

For example, imagine that you have several thousand digital photographs. Typically, your camera and desktop software will catalog this data by naming the photos in sequence and maybe place these in a folder according to the date that the photos were taken. Searching for a particular photo in this scheme involves remembering the date and photo number. If you do not know either of these things, you will have to resort to looking through thumbnails of the photos. Of course, if you have the patience, you could name each photograph as you download it to your desktop. A coarse-grained system, like the file and folder system in Win32®, is not flexible enough to allow you to store all the data you need.

Desktop software may fill this gap, allowing you to build a catalog that stores other descriptive properties like camera settings, light condition, and a general description of each picture. Such software, of course, is an implementation of a database, but the important point is that it acts as a supplement to the file system. You could argue that these descriptions of your photos—metadata—are actually part of the photograph's object. Digital photographs hold other information within the image file's EXIF (Exchangeable Image File Format) header. This header contains information obtained when the photo was taken. To include this metadata in a search would require a query engine to extract this information from each candidate photo and compare it with the query condition. A sophisticated photograph organizer could extract the EXIF information when the photograph is transferred to the desktop and include it as additional metadata in the database.

— Richard Grimes, WinFS Lets Users Search and Manage Files Based on Content, [4]

Desktop search allowed a user to see different types of data from different sources. However, these data still resided on different sources, different places.[61]

Traditional file systems also did not allow for storing files in multiple places without making duplicates. Hal Berenson, former General Manager of Integrated Storage (which would become WinFS after he left Microsoft), gave an example:

For example, you might want an album with pictures of Aunt Jean. But you also want the pictures of Aunt Jean at the wedding to be in the wedding album. You also want to share about 50 of the 500 photos you took (and make sure you don’t share any of the hot tub pictures). How do you do that without copying the pictures to a separate share location? Maybe you want to organize photos from all visits to Disney World together, but also keep them together by broader trip.

— Hal Berenson, WinFS, Integrated/Unified Storage, and Microsoft – Part 1, [68]

A solution is to put an external metadata later on top of the file system, and to use an application or library to interact with the photos instead of interacting directly with the file system. Berenson noted that this causes problems as applications typically won’t understand the layer and operate just on the file system underneath it. This can make functionality that the layer purports to provide unreliable (e.g., when the application changes something about the photo which is not accurately propagated back into the external metadata store). And with photos now stored in a data type-specific layer, it is ever more difficult to implement scenarios or applications in which photos are but one data type.[68]

Berenson then illustrated the limitations of traditional file systems and the benefits of integrated storage by using the processing of claims against an insurance company as a scenario:

Let me cross over into the enterprise app space and talk about an Insurance Claims Processing scenario. Claims processing is interesting for a number of reasons, they key one being that it was one of the first enterprise applications to really embrace the notion of multiple data types. When you file a claim, for a car accident for example, it goes into a traditional transactional database system. But each claim has an associated set of artifacts such as photos of the accident scene, the police report, photos taken by the insurance adjuster, photos taken at the repair shop, witness statements, etc. that don’t neatly fit into the classic transactional database. Yes you can store these artifacts in a database BLOB, but then they lose all semantics. Not only that, you have to copy them out of the database into the file system so that applications that only know how to deal with the filesystem (e.g., Photoshop) can work against them. And copy them back. That creates enormous workflow difficulties, introduces data integrity problems, and prevents use of functionality that was embedded in the photos storage application.

The claims processing scenario is one that demonstrates where the name integrated storage came from. What you really want is for the same store that holds your transactional structured data about a claim to hold the non-transactional semi-structured artifacts, and not just as blobs. You want the semi-structured artifacts to expose their metadata and semantics to the application, or applications, built on that store. As soon as you do that the ability to create richer apps, and/or use the data in complex information worker scenarios, climbs dramatically.

Rather than just using the photos as part of processing a specific claim they now become usable artifacts for risk analysis, fraud analysis, highway planning, or any number of other applications. Data mining applications could run against them seeking patterns that weren’t captured in the transactional data. Indeed all kinds of linkages could be made amongst the photos, police reports, etc. that just aren’t possible from the transactional data alone.

— Hal Berenson, WinFS, Integrated/Unified Storage, and Microsoft – Part 1, [68]

Lastly, Berenson noted that there is no way to back up and restore related structured (i.e., typical database data), semi-structured/unstructured data (e.g., a photo or document), and unstructured data, without a storage system that can be the primary store.[68]

Grimes pointed out that one of the monumental problems organizations face is aggregating information that is stored in disparate formats. Knowledge workers have long wanted to be able to search for content independent of format.[4] Sean Grimaldi of the WinFS team called the existence of many formats with different expectations and behaviors a "divide-and-conquer approach" in dealing with data. Grimaldi extensively discussed the negative effects of this approach and summarizes:

The data is divided into file, database, and other data. The negatives are that programmers have to recreate data types, bridge between data types, and rewrite behaviors repeatedly. If this seems normal to you, it may be because you have operated in this fractured data environment for years and have come to expect nothing more.

— Sean Grimaldi, The WinFS Files: Divide et Impera, [69]

The Microsoft WinFS SDK Beta 1 Documentation described the existence of proprietary file formats as "separate islands":

Proprietary file formats tend to aggregate data into separate islands, creating barriers for data sharing between applications. For example, an address book created by an e-mail system, such as Microsoft Outlook, is not directly usable by an appointment-setting application unless the latter adopts the same file format or knows how to translate the format from one to another.

— Microsoft, Overview > WinFS: Unified Storage System for Windows, Microsoft WinFS SDK Beta 1 Documentation, [67]

Shawn Wildermuth pointed out what this system means for developers:

Data integration solutions must first try to make sense of all the different places applications can store information. Let's look at a typical example:

I am writing an application, I need access to the user's Contact List, Documents folder, and Music Folder. To access each of these data stores, I have to deal with three different APIs to get that data (MAPI to access Contacts, System.IO for the Documents folder, and the Windows Media Player SDK to find all the music for a user). It would be better if we had a consistent API for users' data.

But that is not the worst part of the problem. If my application wants to tie its data and these external pieces together, it will need code that not only establishes the relationship between the objects, but deals with changes to that data and handles data synchronization problems such as orphaned data.

— Shawn Wildermuth, A Developer's Perspective on WinFS: Part 1, [70]

Using common file formats is a workaround to this problem but not a universal solution; there is no guarantee that all applications will use the format. Other solutions used by corporations are database systems and XML and XML web services, as Thomas Rizzo, director in the Microsoft SQL Server group, explained:

In the beginning, computers could not handle the complexities of modeling and automating many business processes. However, with faster computers, better programming languages, and better data technologies, automation of business processes became a way for corporations to streamline their operations, especially with the advent of enterprise resource planning (ERP), customer relationship management (CRM), sales force automation (SFA), and other types of enterprise applications. With these new types of applications, data suddenly became more complex—but at the same time, data had better structure that was more useful for businesses. Rather than storing opaque binary data or simplistic data models, database systems could relate different types of complex data together. For example, ERP systems understand and can model the complexities of general ledgers, human resources, and sales systems. Since standardized schemas described the data in the system, corporations could ask interesting questions about their business and query their systems for that information.

However, working across systems is still a problem in the industry. Not only is it hard to integrate systems within a corporation, but integrating systems across corporations is even harder. This has sparked the growth of enterprise application integration (EAI) vendors who help customers navigate the sea of schematized data across heterogeneous systems. Recognizing this integration problem, the industry has looked to XML and XML Web services as a way to help companies work across multiple systems and multiple organizations. These newer standards help solve data integration problems and are helping to democratize data throughout and across organizations.

— Thomas Rizzo, WinFS 101: Introducing the New Windows File System, [71]

Traditional file systems also provide only a single way of organizing the files, namely via directories and file names. Vijay Bangaru of the WinFS team illustrated the problems with this:

If you’re like me, you probably have tons of digital pictures on your computer. My photos are currently organized in a simple hierarchy. In “My Pictures”, I have a bunch of folders that are named something like, “2004-11 Thanksgiving”. Within this folder are all my photos from that holiday. I’m sure you can already see the limitations in this structure.

My latest challenge in actually using my pictures came the other day. My grandparents wanted me to send them some pictures of my fiancée and me. Wouldn’t it be really cool if I could just tell my computer, “Show me all the pictures that have Crissy and me in them”. Instead, I had to scan through my folders to see what events we were both at and copy all the pictures with both of us in them to a temp folder. Then I needed to go through the temp folder to pick which ones to send. Of course, I didn’t remember to delete the temp folder; so it’s eating up drive space. Good thing hard drives are so cheap nowadays.

— Vijay Bangaru, Unify, Organize, Explore, and Innovate. Oh my! (Part 2), [72]

A traditional file system can retrieve and search data based only on the directory path:

If the user knows the directory path to the file, searching is simple. But if she does not know where the file is, she must walk down from the root directory of a file system—for example, by selecting Search from the Start menu—to traverse the available directory paths until she finds the file. When there are many files on a computer, the search can take a long time. In the NTFS file system and other traditional file systems, the directory path is more or less the only way to identify a file. But users tend to think of data more naturally in terms of its types and attributes—that is, the structure or shape of the data: a document or an e-mail message, its title or subject, the author or sender. How the data is stored is generally of little or no interest. Therefore, reliance on paths is an inherent limitation of the tree-based structure of traditional file systems.

— Microsoft, Overview > WinFS: Unified Storage System for Windows, Microsoft WinFS SDK Beta 1 Documentation, [67]

A user may put a file into multiple directories, but this wastes disk space. Also, when a copy is changed, the other copies no longer represent the same data as the changed copy. Hard links that can be created to represent a file by multiple paths are also difficult to manage: links will break when a file is renamed.[67]

Bill Gates summarized all these issues in his keynote during PDC 2003:

Users want to manage information. We've had the information in silos. Mail is separate than, the files is separate from the web pages, and the information has not been structured. All the operating system knows about files is that they're binary streams. That's it. You know, something like the address book is at the application level, not at the platform level. And so if you want to share address book across applications, you can't even do that. The idea of rich searching, the search command is different in every application. So learning how to search mail, navigate mail, is different than learning that for files. When you get attachment sent to you, storing those, understanding the different versions you might be getting, It's very complex, and so just dealing with information has not been very rich. We don't have standard schemas for the concepts. We had the clipboard, but we haven't gone beyond the clipboard to structure the information, to make replication, and searching just a very straightforward thing that you expect out of the system. So in the next wave, we've got to have those rich views, got to have content indexing, got to unify the store. We've got to have the schemas, allow you to classify things, so that things even appear to organize without you getting involved. We see a little bit of this in the Outlook client where you have search folders, so that if you want to see all your mail from one person, you just click on that folder. You don't have to drop something in there because it's, it's essentially a standing query, and so information can be in many locations. It's just a matter of defining the criteria, not having to move it around. The ability to intermix files and mail and notes into one hierarchy that's organized the way that you want it to be.

— Bill Gates, PDC 2003 Keynote with Bill Gates, [42]

Gates also stated in an interview from a month after PDC 2003:

Your next big product is the new Windows operating system code-named Longhorn. Why are you saying that it's a bigger step than anything in the last 10 years?

Well, the system today is in some ways quite fragmented. The way that you deal with your files is different than the way you deal with your e-mail, which is different than the way you deal with your address book, and you have to be pretty smart to understand how you navigate each of those, how you move them around between different machines or devices. And so [we're] getting rid of a lot of the specialized systems that have grown up on the PC that make it just a lot harder to work with. And then we're saying, hey, the photos will be there, so the way that you navigate photos and the way you navigate music will all be very rich and very common. That is the new storage system code-named Win FS, Windows File System. And that is probably the most ambitious, the most shocking advance that we've got in the system. You can find your stuff, search your stuff, share your stuff, and once people have gotten used to that they won't want to go back to the fragmented, fairly simple world that they have right now. We [also] have a lot of things about real-time collaboration, peer to peer, the graphics richness of the system, the fundamentals of knowing when you install a piece of software it won't mess anything else up. But I'd say Win FS is probably the biggest advance.

— Steven Levy, He's Still Having Fun, [73]

WinFS as solution

The core concept of WinFS was that by storing data in a cohesive data store, not just a file system, it would have allowed systems and users to store rich metadata about a myriad of objects and to relate these objects.[70] Compared to a file in a traditional file system, a "WinFS" item would be the smallest unit of data that could be moved around and operated on by different users or applications.[67]

The Microsoft WinFS SDK Beta 1 Documentation explained that WinFS would have provided comprehensive object-relational mappings to let users view and work with their data as an item on a Windows computer. With items, a user or an application would have found it more logical or natural to view and use data. This should have made organizing and querying data, especially complex data, less burdensome. The documentation provided as an example:

For example, consider an e-mail message containing two photos as attachments. In the tabular form, this is most likely modeled as three rows in two tables. One table stores all the e-mail messages and the other stores all the photos. To get the message, a user or application must query two tables and perform the so-called UNION operations on the tables. In the itemized form, the attachment is part of the item. Querying the e-mail message item will return the attached photos as well.

— Microsoft, Overview > WinFS: Unified Storage System for Windows, Microsoft WinFS SDK Beta 1 Documentation, [67]

WinFS would have served all kinds of data, whether structured (as in tables/rows or items), semi-structured (as in an XML file), or unstructured (as in a flat byte stream).[67]

The Microsoft WinFS SDK Beta 1 Documentation and the IWish video summarized the benefits of WinFS integration into four points: Unify, Organize, Explore, and Innovate.[74][50][51]


WinFS would have allowed data sharing between applications, as Grimaldi explained:

Because applications can build on WinFS-defined data types, applications can share data—assuming the correct permissions. This is good for you as a programmer, as well as for the end user of your application.

As a programmer, you can reuse data the end user already has in the WinFS store. For example, assume your application presents advertisements to a user of events they could attend, like a bike race or a rodeo.

Before presenting an event to the user, your application can check the user's calendar and display the event differently if the user already has a meeting scheduled that would conflict with the event, such as making the border of the invitation red.

You can also populate data into the WinFS store to be used by other programs. For example, if the end user accepts the invitation to the bicycle race, their personal information manager (PIM) application, such as their e-mail client, could show that date as reserved in their calendar. This also gives the end user a rich user experience in both applications.

— Sean Grimaldi, The WinFS Files: Divide et Impera, [69]

WinFS would have placed data from multiple applications into one central store. Bangaru showed the advantages of this:

With WinFS, I can move all my contact information into one central store. My applications can interact with this information and I can synchronize it wherever I want to. The obvious benefit is that I can go to one place reliably for the most up to date information. Now, I could easily add whoever I wanted to an Evite for a Halloween party. No more need for typing in email addresses or importing all my contacts (into yet another silo). When I order flowers for mom on her birthday, it’s just one click for me to fill out the information for the recipient.

In addition to being a central data store, WinFS can be your synchronization hub. I can sync between WinFS Stores and I can sync changes back and forth with legacy stores (like Outlook, PDAs, and cell phones). Now, I can have my latest contact info on my phone, make changes on the road, and sync that information back to WinFS. This, of course, enables some great offline experiences. When I’m doing work on vacation, I don’t need to worry about manually synchronizing my data with my desktop machine once I’m home. Now all my applications will behave like Outlook 11’s awesome offline mode.

Of course, this applies to all data; not just contacts. Now, all my calendar apps will show my Evite invites. My photos are now associated with contacts and events, so I can easily say, “Mail these photos to everyone that was at the event”. When you start adding email, RSS feeds, documents, music and everything else to this, it can get pretty exciting.

— Vijay Bangaru, Unify, Organize, Explore, and Innovate. Oh my! (Part 1), [75]


Bangaru illustrated how data could be related, and how related data could be shown:

With WinFS, I can relate my contacts to my photos, so I can easily query for all the pictures that are related to a set a contacts. A photo app built on WinFS could display all the pictures with Crissy and me in them. Then, I could select the good ones to email or print. If you’ve been playing with the Beta 1 bits, you know how easy it is to write an app with this behavior.

Plus, I can now easily check to see what photos I’ve already sent, so I don’t send the same ones again. How? Tell the computer to “show me the photos with both of us that I’ve sent to my grandparents.” All these containment relationships and associations would already be in my store.

Again, this applies to much more than pictures. I can associate a document with a meeting, or music and contacts to a party invite. And these aren’t keywords added to a file, these are associations between real items. All of these organization constructs are just waiting to be exploited by a WinFS app.

Also, all these types are extensible. So for my wedding guest list, I can extend the Contact type to have properties for “Sent ‘Save the Date’ card”, “Sent invitation”, “RSVP Received”, “# of Guests”, “Vegetarian meal?” and so on. That could make things significantly easier. Good thing I can do this with the Beta bits. If we had to wait for WinFS RTM to plan the wedding, I think Crissy would make sure that I wouldn’t be able to blog anymore. :-)

— Vijay Bangaru, Unify, Organize, Explore, and Innovate. Oh my! (Part 2), [72]


WinFS natively recognized different types of data by defining common item types, such as audio record, meeting, contact, person, document, photo, message, video clip. This would have solved the problem of querying the following data:

You could write code that shows a picture of a person, his role, and his contact information for everyone attending a given meeting and every document that they contributed to that you have not already read, and on a personal note, if they have already given you some money for the charity bicycle race you are participating in next month. Today, I have all this data available to my computer, but no feasible way to query it without WinFS. I plainly can't get at a lot of my data.

— Sean Grimaldi, The WinFS Files: Divide et Impera, [69]

WinFS would have allowed queries such as "Show me all email from people I am meeting with this week," that NTFS could not.[76]

Bangaru explained how one of the mockup applications showed in the IWish video[50] would use WinFS:

WinFS gives you the ability to use relationships to find and display your data. In the PDC video, we showed an app that takes a range of dates and displays the location for your meetings on the map. As it draws the best route to drive between all your meetings, it adds icons that represent your contacts and important customers at their location on the map. Now, as you visualize your schedule, you can see who is close by and set up lunch.

Let’s walk through how WinFS made this possible. The app is able to query for all your appointments in a certain date range. It displays each appointment in the proper place on the map by using location of the meeting. Today it would be tough for a map application to do this, because your appointments are in a different application or maybe even more than one application. Assuming you can access the meetings programmatically, accessing the location may be hard. Your calendar app probably just has a field called “Location” that can contain an arbitrary string and would be tough to parse correctly. With WinFS, all your appointment information is in a single store with an API that let’s any application access the data uniformly.

Next, the application finds contacts and customers with high priority issues that are located close to where you will be and displays them on the map, by using the address of the contact. If you select a contact, the app can display some information for the person (a photo and contact info for example). From there, you can send them a mail to setup a lunch while you’re in town. Again this would be tough to do today; your contact information is probably in a silo that your map application can’t get to. Plus, chances are, your customers with high priority issues are tracked in a completely different application silo.

— Vijay Bangaru, Unify, Organize, Explore, and Innovate. Oh my! (Part 3), [77]


Bangaru explained how WinFS would have done away with proprietary file formats:

WinFS is built on a true relational store that all applications can leverage. Today, tons of popular apps lock their data into proprietary stores. This includes photo apps like Photoshop album, music apps like WMP and iTunes, financial apps like Quicken and Money, email apps like Outlook, and so on. By using WinFS, developers can concentrate on building rich applications without worrying about creating a storage silo. After all, WinFS can give applications a place for all their structured, semi-structured, and unstructured data.

In addition, WinFS will provide services like synchronization, notifications, rules, and backup/restore. The services provided by WinFS lead to a zero-admin and extremely reliable experience.

— Vijay Bangaru, Unify, Organize, Explore, and Innovate. Oh my! (Part 4), [78]

Drucker explained how WinFS addressed lock-in:

Interviewer: "So, is Microsoft getting rid of lock-in? I mean, is this the uh, are we, are we docking in a new pool here?" (laughs)

Drucker: "Well, those sound very buzzy." (laughs)

Interviewer: "Probably"

Drucker: But I will say this. WinFS is a persistence platform because of the schematization, because the programming model enables applications to share data on behalf of the user in a way that just isn't even feasible to do now. Even if, even if applications wanted to, you really couldn't do it. I mean you can't write outlook express today as like a file folder of MSGs. It's just not fast. It's not practical. Users will hate it."

Interviewer: "Now that for, for an application developer who is used to lock-in and used to "I control my world", that sounds scary, doesn't it?"

Drucker: "I think it is very scary and I think we get that feedback, we've gotten some of that feedback from ISVs. But I think the the upside, right, the world where you can share information with other applications is so powerful that even people who enjoy a tremendous amount of lock-in in their applications today think about 'Oh what would it mean if I could really share data with the other applications the user uses?' And that promise, that potential of greater interoperability far outweighs the benefits they're getting from lock-in today."

— Samuel Drucker, Samuel Druker - How does Outlook Express in Longhorn use WinFS?, [79]

Synchronization is explained under Data sharing. Rules is explained under Rules.

Bangaru explained two levels of backup that WinFS would have included. Item level backup would have allowed a user to revert a change to an item. Store level backup would have covered the situation of a broken hard drive and a user needing all his files back.[80]

As part of Longhorn


Hillel Cooperman explained in PDC 2003 in his demo of a build 4050 how WinFS would work in Longhorn:

But the best part about this is not that we have this functionality built in Windows. The best part, like everything I want to show you today, is that this is part of the platform. This is essentially the evolution of My Documents, but a couple of things are different. First of all, we're showing almost 1100 items in this view, which frankly, given today's uh experience, it would be a little uhh not useful. Um and in fact, these items are not sitting in one folder. They're located across the system, and this view is actually a dynamic view that's generated for you, uh right in the system, and of course available as part of the platform. So let's do a simple thing uh, that you think would be simple today, but, but WinFS is going to provide built-in search facilities. So I have 1,100 items, I want to fall, find all the items that have somebody do with Longhorn. So as I type, I want you to watch the the number right here, 1095, go down to 30. See how fast that happens. By the time I'm done typing, we're down from 1100 to 30 items right there in the system. Now built-in search capabilities, this is something you're gonna expect.

But let's talk about the kind of self-organization that Bill talked about in WinFS. For example, let's say we want to take these 1,100 items and organize them by a property, a property that's built into the schema. Um, so right here, we have "Author". We click on "Author" and we could actually filter down the 1100 based on who the author is. Or we can do this new thing called "Stack" and when I click on Stack, it's actually drawing a new view that shows all these items uh in these stacks by who wrote them. And in fact, if you look carefully at the stacks, they have different heights depending on how many items are represented in them. And because they're not physical locations, one item can show up in more than one stack. And these are not folders I went, created. This is dynamic view being built for me on the fly based on the rich structured metadata that's sitting in WinFS on these items. So let's double click on "Bill". Now, the properties that are built in to the schema are well and good, but of course you're gonna want to add your own. And it's not just users and IT professionals but of course developers. They're gonna go extend these schema uh, in any way they want. So let's actually add a property right now, let's add project to our view. I click right here on "Project" and I can stack by project. And in fact, I can go down here and see here's all the stacks. And these five items down here aren't attached to any project.

—, Hillel Demoes Longhorn build 4050 (Extended cut), [81]

WinFS was intended to have the following user interface (UI) features in Longhorn:

As shown in Figure 1, the storage model has a number of components:

  • A breadcrumb bar for navigation
  • A preview area
  • Commands (based on FolderType and folder sniffing)
  • Filters and filter controls
  • A list view area (for thumbnails and grouping)
  • A user's list of storage favorites

— Microsoft User Experience Group, The Windows File System, [1]

The storage model would have also come with the following elements:

  • A scope (for example, c:\foo</code> + d:\bar)
  • A specific query and filters (for example, select * from Media.Music where Artist = Madonna & year = 1984)
  • An associated "drag target" (a physical folder, which is optional)

— Microsoft User Experience Group, The Windows File System, [1]

Microsoft also intended that Longhorn would support sets. A static set was intended to be a list of items stored within WinFS and that did not share common properties. For example, a music playlist is a list of pointers to actual music files stored on some physical media. The files could be stored in different locations, but the lists could be used across different computers, and users can control the hierarchy of the lists. Static sets would have been best used to organize items that had no properties in common. For example, a user might maintain a list of documents he's working on. The documents have no properties in common.

In contrast, dynamic sets would have been the results of queries based on the properties of items (for example, image files or all files created in February) in WinFS that were run against certain locations (called the scope). The sets could be used across different computers. For example, scope could include the computer used by the user, a shared server, or a company's network domain. In WinFS, dynamic sets would have been the preferred way that users can organize their files—not by location, but by the properties most relevant to them.[1]

Dynamic sets were intended to work as follows:

With "Longhorn," users perform familiar file management tasks such as finding, organizing, and performing actions on data. However, dynamic sets replace the need for physical folders and become the primary way users access their data.

In "Longhorn," the list view control shows the items that have been dynamically selected based on the user's criteria. Each item in a list view is not necessarily implemented as a file in the file system. A list view can contain contacts, e-mail messages, and other non-file objects. Depending on the selected view property, users can see previews and details about the files in the list. However, in icon views, for example, this amount of detail may be minimal.

Dynamic sets can be grouped visually into "stacks" according to a specific property such as author. If a user chooses to stack the items by author, a stack for each author is displayed, and items with no author value appear in a flat list. Dragging one of these items into the stack for a particular author assigns that author as a property of the item, which allows for easy property editing.

With filter menus, storage favorites, and the wordwheel, users can change the dynamic set they are viewing until they have narrowed the set to exactly the items they want to view.

Users can select a particular property value from a filter menu to narrow a dynamic set to items with that value. For example, a user could select Raquel Mello from the "Author" filter menu, and the dynamic list would narrow to only items created by Raquel Mello.

A user could further narrow the dynamic set to only documents created in a particular month.

The breadcrumb bar in the storage page helps users keep track of where they are and what filters they have used.

Users can save links to their favorite dynamic sets, called "storage favorites," which are readily available in the UI.

Clicking a storage favorite runs a query of all items within a specific scope, and returns only the items with specific properties. For example, a user might create a set of important documents in the month of October, and he might want to see this set of documents frequently. While viewing the set of documents, he could save a storage favorite and name it "Important Documents from October." This storage favorite would be immediately available to him in the future.

Users can also filter the items in a dynamic set using the wordwheel.

As a user types in the wordwheel, the dynamic set narrows to items with properties that match or contain the string that the user typed.

— Microsoft User Experience Group, The Windows File System, [1]

Longhorn would have allowed a user to add a property to an item through the preview pane, by dragging an item into a stack, or through the property page.[1]

Users could form search queries using words that mean something to them, such as, "What is a firewall?" or "Pictures from Maui." Users could perform more complex searches, such as "Look for information about Jim from 1987 to 1999," because non-file-based data like contacts and e-mail messages were cross-referenced with files.[1]

The preview pane would have showed commands associated to a WinFS type or file type.[1]

A rules engine would have made possible for users to create simple or complex rules to define how their system handles particular messages.[1]

Microsoft also intended that applications could easily reuse any contacts already present in the WinFS Contact store. Contacts would appear on the Contacts explorer, and for frequently communicated contacts, on the Sidebar.[85] Contacts would also have their own property pages, with the following parts:

  • The preview pane displays the commands with which users can perform various contact or communication tasks. You can add commands from your application to the command list in the preview pane.
  • The explorer pane gives users a view of the data from a given application and provides links to related files, the communication history, and other applications that create property page extensions. If an application has synchronized data about a given contact into the contacts explorer, that data is listed in the explorer pane.
  • The content area contains a composite view of contact data from multiple sources. Windows provides UI to alert users to and manage any conflicts between applications.
  • Property page extensions allow your application to embed a preview of your content inside the property page. If you want your application to add its own propriety contact data, you can extend the contact schema and create a property page UI extension to render application-specific data inside the property page.

— Microsoft User Experience Group, User Experience (Aero): Contacts (Microsoft Access 2002 Technical Articles), [85]

Messages in the WinFS Store would be displayed in Communication History. Users may access the history of multi-application communication messages related to a given contact.[85]


A Milestone 4 build that leaked in or around March 2003 contained "Windows Future Storage Services" and "Windows Storage Full-Text Index". A user opening Search would simply be asked: "What are you looking for?", with a list of example searches provided for reference such as "Pictures from John" or "What is a firewall?". The build came with libraries, stacks, and filter features.[2]

Build 4051, which was distributed during PDC 2003, contained WinFS. Part of the "Self-Guided Longhorn Tour" that Microsoft released for this build described how WinFS (erroneously called WinFX) worked, which operationalized the UI features Microsoft intended for Longhorn:

1. From the Start menu, click Computer. This is a place from which you can get to all of your storage locations, such as the WinFXTM default store.

2. Open the "DefaultStore," which is a view of WinFX through the Win32® APIs. Drag in copies of a variety of photos, music, and documents. (Use only copies of your data to prevent data loss.)

  • Because WinFX is still in development:
    • It might take several minutes to copy the files and promote the metadata.
    • You cannot rename items that you've added to WinFX.
    • Saving files might be an issue because of application compatibility.

3. Open the Start menu and click Music. The music you added to the WinFX default store appears in the music collection.

4. Click the column heading Artist and select Stack by artist. The items appear in stacks according to their artist metadata. Double-click a stack to see music by a specific artist.

5. Click the column heading Track Number. Pick one, and the list narrows to only items with that track number.

6. Notice how your navigations are tracked in the Address bar. You can click on any item in the address bar to navigate, or click the drop-down control to the right of each item to navigate to one of the item's peers.

7. Find the text box labeled Filter by on the left. This is called the wordwheel, and it allows you to quickly filter the items you see based on what you type. Type an artist's name and notice that, as you type, the items are filtered and only items related to what you typed remain.

8. In the Address bar, click the drop-down control next to Music and select Photos and Videos to navigate to the photos and videos collection. The photos you previously added to WinFX appear.

9. Use the Address bar to navigate to "Documents". Select a document, and a thumbnail of the document appears in the preview pane, along with relevant tasks and metadata for the item.

10. From the preview pane, click Add a category. Type categories related to the document (separated by semicolons) and press Enter. Because it's in development, this might take a few minutes.

11. Click the column heading Category and then select one of the categories that you added. The items will filter to only the item for which you attached this category.

12. Sign on to Windows Messenger. After a few minutes, your buddies will be added to WinFX so that they will appear in your collection of contacts, and in the Contact Picker.

13. Use the Address bar to navigate to Contacts. All your WinFX contacts, including your Messenger buddies, appear. Double-click a contact to view and edit details for the contact.

14. To add contacts from Active Directory to your contact collection, open the File menu and click Add contacts. This launches the Contact Picker. To find the contact you want to add, type a name in the Search For text box, and then click Search. Select the contact and click Add.

— The Windows Team, Take a Self-Guided Longhorn Tour, [86]

WinFS in build 4051 suffered from huge performance issues.[33]

Build 4074, the WinHEC 2004 preview build, also included WinFS. It slowed down the system because it catalogued every single file, including system data, so that WinFS would be able to search them.[87]

WinFS Beta 1

On 29 August 2005, Vijau Bangaru, a Program Manager on the WinFS product team, announced the release of WinFS Beta 1 for Windows XP Service Pack 2.[10]

The installer can be modified to allow WinFS to install on Windows Vista and Windows Server 2003:[88]

1. Get a HEX Editor application.

2. Start en_WinFS_Beta1.exe and it will extract the necessary contents to C:\\winfsbeta1 (by default). When the extraction process is done, you may get an error message on non-WXP SP2 systems - just disregard and close it.

3. Drag C:\\winfsbeta1\\winfs.msi to your HEX editor and go to offset 0×1FE9E.

Now you can choose one of the following:

#1 4. Look at the ASCII pane and replace = 501 with > 500.

#2 4. Look at the ASCII pane and replace 501 with [NTVersion_Major][NTVersion_Minor]. E.g. “501″ for Windows XP, “502″ for Windows Server 2003, “600″ for Windows Vista (fka. “Longhorn”).

5. At offset 0×1FEBC replace byte 0×32 with 0×30.

— Stanimir Stoyanov, WinFS Beta 1 on Non-Windows XP with SP2 Systems, [88]

Beta 1 Refresh was released to MSDN subscribers on 1 December 2005 to be compatible with the final release of .NET Framework 2.0.[11]

Data storage

From this section, the discussion is on how WinFS worked under Beta 1, the latest release of WinFS to the public, not under any Longhorn pre-reset build. All documentation therefore should refer to the WinFS Beta 1 time frame, PDC 2005 included.


What is WinFS?[52]

WinFS used a subset of SQL Server 2005 technology, modified for file storage.[17] It consisted of the following components:

  • "WinFS" Core - the core services expected from a file system, and included the relational storage engine;
  • Data model - the technical innovations of WinFS, including basic item structure, relationships, and the ability to extend both items and relationships;
  • Schemas - built-in schemas allowed WinFS to understand a user's data in richer ways than traditional file systems and provide a more structured way to handle metadata. Included were first, schemas for everyday information such as documents, e-mail, appointments, tasks, media, audio and video, and second, system schemas that define configuration, programs, and other system-related data;
  • Services - included syncronization and rules (discussed below);
  • APIs - which developers might have used to program the different building blocks of the "WinFS" system, including data operations, rules, synchronization, and the data model[89]

WinFS required three services, which ran in three processes:[90]

  1. WinFS.exe, the WinFS data store, that ran a Yukon (SQL Server 2005)-derived database engine
  2. WinFSSearch.exe, which ran the WinFS search engine
  3. WinFPM.exe, which ran the WinFS File Promotion Manager. File promotion referred to the process of extracting data from a file and populating the data to an item. The reverse process of persisting itemized data to streams of the underlying file was called demotion.[67][91] WinFS served all kinds of data: structured, semi-structured, or unstructured, through a new file system driver (RsFxDrv.sys).[67] This driver allowed a user to access a WinFS item both as a file stream (as a file) through the Win32 API or as an item via the WinFS API. The process of file promotion and demotion kept the file-based and item-based representations of a WinFS item synced. This made WinFS backwards-compatible with NTFS.[91]

WinFS depended on the .NET Framework,[90] and used the same APIs as other data types thanks to ADO.NET.[18] The WinFS API was included in the System.Storage namespace.[91][69]

Data store

WinFS data hierarchy[91]

WinFS kept data in Stores, which in turn are kept in a relational backend.[91] A WinFS store was a common repository where any application can store items and associations. Items could either be backed by files (for example, images and documents) or not (for example, contacts and e-mail).[18] Associations established relationships between different types of data (items), which then allowed users to organize information based on how they used them.[18] Bagnaru explained how items and associations were stored:

Q: Mikael writes, “How and where are all the relations, keywords, etc. saved?”

A: The item properties are stored in the WinFS store as part of the item itself. WinFS has a concept of “links” which are an entity type with a source item and a target item that relate items. There is also the concept of “common value” relationships which are based on item properties. Navigation of common value relationships is a value based join.

— Vijay Bangaru, WinFS Mailbox, [92]>

All data in the store were accessible as CLR objects, allowing a developer to leverage all their Visual Studio and .NET knowledge while building apps..[78]

WinFS, by default, came with two stores, DefaultStore and Catalog. DefaultStore was the default location for user and application "WinFS" data. Catalog stored metadata about "WinFS" stores and shares, as well as other system data. The Catalog store was read-only and should not be used for user data.[93] Users could create additional stores,[33] but a store could not span multiple volumes and could only be hosted on NTFS volumes. The reason for these limitations was that every WinFS store had a root share with the same name as the store.[93]

WinFS stores were made up of database files stored in a directory under the "System Volume Information" folder.[93] Filestreams were saved as ordinary NTFS files with a GUID as file name.[90] Tony Voellm of the WinFS Team explained, "The term NTFS Streams was used but the File Data is actually stored in NTFS files."[76][21] Meanwhile, metadata is stored in a SQL Server database.[90]

Data model

The WinFS data model is the architecture of the type system.[94] WinFS introduced a type definition language, an XML vocabulary but not the XML Type Definition Language, to describe types.[95]

WinFS provided a set of schemas that defined types[95] and attributes for implementation by the WinFS API.[94] A developer could also create custom schemas.[95][96]

A schema was a collection of type declarations, such as the declaration of a postal address, a full name, or a person. Each schema defined a set of types that mapped to some information. All these types derived from a set of base types defined by "WinFS". The base types grouped related types together, creating type families.[94]

The root types in the WinFS system were Item, Link, InlineType, and ItemFragment. The other WinFS types derived from the root types.[95] Descendants of one of these types were entity types. For example, Person was derived from the Contact type, which derived from the Item type. AttachmentLink was derived from the Link type. Therefore, Person, Contact, and AttachmentLink were all entity types. An EntityType had its own unique identity, and so could exist on their own. In contrast, an InlineType did not have a unique identity and could exist on its own. FullName of a Person is an InlineType, a Person is an EntityType.[97]

ItemFragments were also entity types, which enabled the declaration of large collections in the item types, such as multivalued properties. Each collection member had a key, which enabled applications to access individual members of the collection independently of the owning item. An example would be a message, which might have a large number of participants.[98] The ItemFragment would be participants under the Item message.[91]

Meanwhile, an EntityExtension allowed a user to extend built-in items by adding further properties as necessary.[91] WinFS schemas defined several extension types. For example, the System.Storage schema namespace defined two ItemExtension types: Reminder (such as a birth date Reminder to a Person) and ItemKeywords (which allowed a user to assign keywords, such as "legal document" or "personal document" to a Document).[98]

Links and associations

Links referred to data that defined links between two or more distinct existing item types; for example, an Item type, Message, might have attachments that were documents, another Item type.[99][91] WinFS also provided the concept of Associations to relate items. Associations were not physically stored in the store. An example of an Association would be that declared by a user between the Document and Contact types when identifying the publisher of a document.[99]

WinFS depended on applications and users to provide the information to create links. According to Bagnaru,

Q: Mikael also asks, “Do I have to set all relations manually? How does WinFS know which document is created by which user?”

A: The relationship “setting” will depend on how it is modeled. A link will need to be set by something (i.e. metadata handler, sync adapter, application, etc.) A common value relationship, however, is just based on a join. WinFS depends on the application and user to provide the information to create links. In many cases, an application already has this data; for example, Office applications already have an “Author” property. In other cases, the user already knows this information and can set it. It would be fairly easy to get my primary contacts’ information moved into WinFS and then relate pictures to the contacts. In the future there could be many processes that could be used to relate your data: natural language processing of documents, concept extraction, face recognition for images, etc.

— Vijay Bangaru, WinFS Mailbox, [92]


The Item was the fundamental concept in "WinFS". An item was the smallest data element defined by WinFS, and was the equivalent of an object in object-oriented programming. Each item had a unique identifier, its GUID.[98]

Items grouped together in DefaultStore

WinFS defined common item types, which resided in the following WinFS namespaces:

  • System.Storage.Audio
  • System.Storage.Calendar
  • System.Storage.Contacts
  • System.Storage.Documents
  • System.Storage.Image
  • System.Storage.Media
  • System.Storage.Messages
  • System.Storage.Video[69]

An item that would fall under System.Storage.Documents would lead to, as Malik explained:

For instance, if you author a Microsoft Word document, it is automatically promoted to an instance of System.Storage.Documents.Document, which then automatically populates its various relevant properties such as title, subtitle, author, etc.

— SahiL Malik, WinFS Basics: Working with a Data Store, [91]

If a file did not fall under any of the common item types, WinFS stored them as a GenericFile item. This happened when no file metadata handler was registered for a file name extension. A file metadata handler promoted and demoted properties between structured file formats and "WinFS" items.[100] (See #Architecture for discussion of file promotion and demotion.)

A definition for item types then reduced the amount of code to bridge between types. Grimaldi showed the benefit of this:

For example, if your application and my application both use the WinFS person type, no transformation is necessary. Even if I extend the WinFS person type, we may be able to share the data without transforming it. For example, if I write an extension to the person type that adds a property for their medical insurance member ID, and your application is a greeting card application, I can pass a person between our applications with just a cast to person.

— Sean Grimaldi, The WinFS Files: Divide et Impera, [69]

Another benefit was common behaviors. Only one code would be necessary to save an item, regardless of type.[69]

Defining common item types also allowed WinFS to look inside files in a similar manner to desktop search engines. Bagnaru pointed out:

Q: Lars asks, “Does WinFS look inside files (word, excel, pdf, etc.) like desktop search engines do?”

A: Yes. When a file is stored in WinFS, its metadata will be extracted by type specific property handlers. Part of our Beta 2 work is to integrate this with the Windows Desktop Search handlers. The end result is that a Windows Desktop Search query will return WinFS and non-WinFS files.

— Vijay Bangaru, WinFS Mailbox, [92]


WinFS Rules provided an object-oriented API useful in definition of data sets, logical properties of data, and associations between data items.[101]. The WinFS SDK Beta 1 Documentation defined a rule as conditional logic used to define queries, filters, computed properties, or computed associations that can be composed, persisted, and reused.[102]

WinFS Beta 1 supported the following rules:

  • FilterRule - A rule that contained filtering logic that could be applied to item(s) of the given type. FilterRules obtained derived item sets based on the conditions of the rule;[103]
  • PropertyRule - A rule used to calculate custom properties from existing properties of data objects. For example, a PropertyRule could define a new property of the Contact class, named locale, based on the zip code of the contact's primary address.[103] Property rules allowed a developer to define new properties on item types without modifying or extending the schema for that type. To illustrate, an email application could expose capabilities for creating a “Color” property for messages and allow each user to define the value of “Color” using their own logic;[63]
  • AssociationRule: A rule to calculate relationships between data objects. For example, a Document could be associated with a Contact defined as its author or copyright owner;[103]
  • ActionRule: A rule to identify actions available on various data types. Rules of this type identified actions to be performed on data items. For example, the Photo class could define resize or rotate actions;[103]
  • Query: A rule that defined a derived set. It was used to implement execution of a query as distinguished from the definition of a rule.[103]

Kati Dimitrova, a developer on the WinFS API team, explained how a query worked as a rule through a scenario involving Mary, a recruiter trying to manage and track candidates throughout her day across multiple applications:

First and foremost, WinFS rules are persistable units of logic. In this scenario, Mary creates the query “candidates that are interviewing today” through her WinFS-enabled recruiting application and persists it. But how is the query persisted? As a WinFS item. In fact, all WinFS rules, including queries, are items. This has many advantages. To start with, rules can be created, manipulated, stored and secured in the same manner as all other items.

Further, WinFS rules are about discovery and sharing of persisted logic among applications. Because rules are WinFS items, they can also be queried for, discovered and shared among applications just like all other WinFS items. In this scenario, Mary can easily find and use the query “candidates that are interviewing today” from her email application even though she created it through her recruiting application.

Finally, WinFS rules are about re-usability and composition. Not only can Mary find the query she created in her recruiting application, she can re-use it in her email application to create a new query “mail related to candidates that are interviewing today” that refers to the original query. Note that composition of rules is true composition; if Mary changes the logic that defines the query “candidates that are interviewing today,” those changes will affect the results of the query “mail related to candidates that are interviewing today.”

— Kati Dimitrova, About WinFS Rules , [63]

Access control

Bagnaru explained how WinFS secured data:

Q: Chris asks, “While it's good to have a common silo that all apps can easily use, it's seems a bit risky. Wouldn't some rogue app/spyware have an easier time getting to financial Quicken/Money data?”

A: Even though all your data is in a single silo, all the data isn’t equally accessible. WinFS provides two data protection mechanisms. First, there is share-level security that controls access to your WinFS share. Second, there is item level security that supports NT compatible security descriptors. In order to access an item, the caller must be provisioned at the both share and the item. To manage this, WinFS will provide a rich API for security administration. Also in Vista there is the concept of “integrity level” for an application (Mandatory Integrity Control). Data can be configured to prevent lower integrity apps from accessing it. Simon (our security PM) will post more detailed description about this soon.

— Vijay Bangaru, WinFS Mailbox II, [61]

Data retrieval

Searches and queries

WinFS used OPath, a string-based query language used for filtering, sorting, and projecting information stored in the WinFS store.[104] OPath was used in multiple places on StorageSearcher to specify queries, and in other places in the API, such as when creating StorageViews.[105]

OPath allowed a user to perform the following types of queries:

  • Extent - Identified the source of the data queried in an OPath query expression;
  • Filter - Created a collection of objects that contained a filtered set of objects from the input collection;
  • FilterByType - Created a collection of objects that contained only the objects from the input collection that were of the specified type, or a sub-type of that type;
  • Group - Created a collection of objects that contained groupings of the data in a collection of objects;
  • Join - Created a collection of objects that contained parings of data from two or more input collections of objects.
  • Project - Created a collection of StorageRecord objects that contained only the selected properties of the objects in the input collection;
  • Sort - Created a collection of objects with the data sorted by one or more property values of the input collection;
  • Top - Created a collection of objects that contained the first number of objects in the collection specified;
  • TreatAsType - Created a collection of objects that contained objects that were converted to a base type
  • Union and UnionAll - Created a collection of objects that contained the data from two or more collections of objects;
  • Yield - Created a collection of values computed by applying the OPath expression specified to each object in the input collection[106]


A notification was simply defined as "TBD" in the WinFS SDK Beta 1 Documentation.[102]

Data sharing and synchronization

WinFS Beta 1 included a Windows Shell namespace extension, which showed WinFS stores as top level objects in "My Computer". The stores also appeared as a share in "My Network Places".[61][33][90] Files could be copied into and out of the stores.[33] Applications could be directly used to save there through the share \\COMPUTERNAME\DefaultStore in "My Network Places".[33][90][33] Even folders such as My Documents could be redirected to a WinFS store.[61]

WinFS Sync allowed synchronization of data between WinFS stores and non-WinFS, or external, data stores (for example, synchronizing contacts between a "WinFS" store and a PDA or synchronizing e-mail between "WinFS" and an e-mail server) and synchronization of data between "WinFS" stores (for instance, making "WinFS" data available on all computers in a home network or sharing a set of documents, peer-to-peer, at work).[107]

WinFS Sync provided change enumeration services that used change tracking to determine all entities that had changed since a previous synchronization. It also provided change application services that made changes to the data in WinFS.[108]

WinFS allowed for both one-way importers, moving data from an application to WinFS, and two-way importers, which allowed for both. WinFS could resolve conflicts among data. Neil Padgett, program manager working on the WinFS Synchronization APIs, explained:

Let’s assume that we did some initial sync to ensure we had our contact in both stores. (We can talk about what this exactly means later, but for now we can think of it to be like running our importer.)

And let’s imagine that, after we sync we make some updates:

In the application store, we’ll update: -Home address -Telephone

And, in WinFS we’ll update: -Home address -Cell

So, now imagine we want to bring our two stores back into sync. So, how do we do that? We know we were in sync before, so we need to figure out what changed on each store, and then apply those changes to the other store. We can call these processes change enumeration and change application, respectively, and we want to do them in both directions. (In fact, WinFS does the hard work of figuring out what changed for us and of making sure that remote changes brought to WinFS are not echoed back to us later.)

Considering our example, we have some changes that are straightforward – the telephone numbers were each changed on the one store, but not on the other. We call these non-conflicting changes. For these non-conflicting changes, we can simply apply them each to the other store. The difficulty comes with the home address – we made changes on both stores – so-called conflicting changes. We’ve detected a conflict and we’ll need to resolve it, either by prompting the user or, more likely, according to some policy (for example, keeping the latest change.) Then, we can bring our two stores back into sync.

— Neil Padgett, Getting Data Into WinFS with WinFS Synchronization, [109]


WinFS Beta 1 shipped with unsupported applications: File System Sync Adapter, Microsoft Rave, StoreSpy, Type Browser, and OPather.

File System Sync Adapter

The File System Sync Adapter synchronized file-backed items and directories between a WinFS replica and a file system directory.[110]

Microsoft Rave

Microsoft Rave attempting to join synchronized folders "A" and "B". Note the "File System: WinFS" that appears in the Explorer window of DefaultStore mapped as a network drive

Microsoft Rave allowed synchronization of two or more WinFS stores. A user could synchronize between WinFS folders in the same machine[111] or in multiple computers, and also with other users[112] in a Windows domain.[111]

Microsoft Rave used peer-to-peer technology to communicate and transfer data.[112]


StoreSpy included in WinFS Beta 1

StoreSpy allowed a user to search for files in stores by executing queries.[113] It supported type-specific grid views, reminiscent of Outlook 2003, for Documents, Messages, Events, Contacts, and Photos, with a typed preview pane for messages, meetings, contacts, and photos, and a debug preview pane for other types.[114]

StoreSpy supported property, query, full-text, and folder based filtering. It also allowed saving and retrieving queries.[114] It also included a one-way Outlook sync adapter to bring items from Outlook 2003. However, it could only read from a Global Access List.[92]

StoreSpy did not allow editing of items[114] or their properties, though it was slated for inclusion in a future release.[115] WinFS was cancelled before it could materialize.

Shishir Mehrotra demoed StoreSpy on a video uploaded on the Microsoft Developer Network's Channel 9.[116]

An earlier version, v0.8, was released for the WinHEC 2004 Longhorn build, 4074. It was an Explorer-like tool to browse WinFS, and allowed a user to inspect Item, Relationship (all 3 types), Extension, Nested Element, and MultiSet properties.[117]. However, BetaArchive user ATeamInc found that the download link has not been archived.[118]

WinFS Type Browser

WinFS Type Browser could be used to visualize WinFS schema types (not WinFS data which StoreSpy showed), their type hierarchy, methods, properties, other types it was related to, among others.[119]

Shishir Mehrotra also demoed the WinFS Type Browser on a Channel 9 video.[116]


WinFS Beta 1 also included OPather. Luiz Miranda of the WinFS Team explained:

When I created the tool I wanted a GUI interface where I could quickly set my target object and start writing my query and know right away of any mistakes in my query string. To do this with OPather is a snap. Open the tool, select the target object type you want to start querying against, then start writing your OPath query. There is even an Intellisense-like feature to help guide you through simple queries. Combined with other features that grew from feedback such as binding results to a DataGrid, constructing StorageViews, and ability to Dump all Code for written query, this tool can certainly help beginners and advanced users who intend to write an App that queries against the WinFS Store.

— Luiz Miranda, Using OPather To Help Write Queries, [105]

Project "Orange"

Microsoft launched a team, codenamed Project Orange to build an application built on the Windows Presentation Foundation ("Avalon"), that would demonstrate some of the ideas showed in the IWish video from PDC 2005. (discussed above at Development). Shishir Mehrotra of the WinFS Team shared some links to job postings and quoted some job descriptions covering positions at Project Orange.[120]

However, since WinFS development went dark, the status of Project "Orange" is unknown.


  1. 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 Microsoft User Experience Group (October 2003). The Windows File System. Aero User Experience Guidelines. Microsoft Developer Network (MSDN). Archived from the original on 21 December 2003. Retrieved on 17 March 2021.
  2. 2.0 2.1 Wilcox, Joe (4 March 2003). Leaked Windows hints at changes to come. ZDNet. CBS Interactive. Archived from the original on 30 September 2007. Retrieved on 17 March 2021.
  3. Schofield, Jack (29 June 2006). Why WinFS had to vanish. The Guardian. Guardian News and Media. Retrieved on 17 March 2021.
  4. 4.0 4.1 4.2 Grimes, Richard (January 2004). WinFS Lets Users Search and Manage Files Based on Content. MSDN Magazine. Microsoft. Retrieved on 17 March 2021.
  5. Microsoft User Experience Group (October 2003). The Windows File System. MSDN. Microsoft. Archived from the original on 5 December 2003. Retrieved on 19 March 2021.
  6. Everett, Cath (18 March 2005). Will Longhorn be worth the pain?. ZDNet. Archived from the original on 30 September 2007. Retrieved on 17 March 2021.
  7. Knorr, Eric (15 January 2004). Microsoft's Longhorn, Three New Technology Pillars. CIO. Retrieved on 17 March 2021.
  8. Udell, Jon (16 July 2004). The long view on Longhorn. InfoWorld. Retrieved on 17 March 2021.
  9. 9.0 9.1 Microsoft Announces 2006 Target Date for Broad Availability of Windows “Longhorn” Client Operating System. Microsoft (27 August 2004). Retrieved on 17 March 2021.
  10. 10.0 10.1 10.2 10.3 10.4 Bangaru, Vijay (29 August 2005). Welcome. WinFS Team Blog. Archived from the original on 23 August 2006. Retrieved on 17 March 2021.
  11. 11.0 11.1 Bangaru, Vijay (1 December 2005). WinFS Beta 1 Refresh now available. WinFS Team Blog. Archived from the original on 20 May 2007. Retrieved on 17 March 2021.
  12. 12.0 12.1 12.2 Clark, Quentin (29 August 2005). Shipping WinFS Beta 1. WinFS Team Blog. Archived from the original on 20 August 2008. Retrieved on 17 March 2021.
  13. 13.0 13.1 13.2 Clark, Quentin (23 June 2006). WinFS Update. WinFS Team Blog. Archived from the original on 20 August 2006. Retrieved on 17 March 2021.
  14. Clark, Quentin (26 June 2006). Update to the Update. WinFS Team Blog. Archived from the original on 20 July 2006. Retrieved on 17 March 2021.
  15. 15.0 15.1 15.2 JonUdell (15 May 2008). Where is WinFS now?. Channel 9 MSDN. Retrieved on 17 March 2021.
  16. Mook, Nate (29 August 2005). WinFS Resurrected for Windows Vista?. betanews. Retrieved on 19 March 2021.
  17. 17.0 17.1 Mook, Nate (29 August 2005). MS Explains WinFS, Releases Beta 1. betanews. Retrieved on 19 March 2021.
  18. 18.0 18.1 18.2 18.3 Mook, Nate (14 September 2005). WinFS Examples in Action at PDC. betanews. Retrieved on 19 March 2021.
  19. The Computer Chronicles (1993). The Computer Chronicles - Windows NT (1993). YouTube. Retrieved on 22 October 2023.
  20. 20.0 20.1 20.2 20.3 Microsoft Corporation (8 March 1993). Microsoft® Windows™ Cairo Product Planning Product Requirements. Archived from the original on 25 September 2012. Retrieved on 16 October 2023.
  21. 21.0 21.1 21.2 21.3 For explanation of streams, see 5.1 NTFS Streams. Microsoft Learn (15 December 2021). Retrieved on 22 October 2023.
  22. 22.0 22.1 Bradley P. Allen, David J. Lee, Roger D. Carasso, John R. Perry (19 January 1995 [publication date]). Case-based organizing and querying of a database. Retrieved on 23 October 2023., cited in ReflectiaX (16 August 2018). Pieces of Cairo's History. Retrieved on 23 October 2023.
  23. jimmsta (24 May 2020). Re: Windows NT 3.5 Source Code Leak. BetaArchive. Retrieved on 20 November 2022.
  24. 24.0 24.1 jimmsta (11 July 2022). What became of Windows Cairo. BetaArchive. Retrieved on 20 November 2022.
  25. The Distractor (17 March 2017). [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1175]. Retrieved on 23 October 2023.
  26. ovctvct (18 March 2017). Re: [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1]. Retrieved on 23 October 2023.
  27. Battler (18 March 2017). Re: [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1]. Retrieved on 23 October 2023.
  28. The Distractor (18 March 2017). Re: [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1]. Retrieved on 23 October 2023.
  29. 29.0 29.1 jimmsta (19 March 2017). Re: [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1].
  30. rthdribl (20 March 2017). Re: [OFFER Windows NT Server "Cairo" (the real one!) 4.00.1].
  31. Anand, Sanjay. My tryst with Destiny, err… Integrated Storage. WinFS Team Blog. Archived from the original on 31 October 2007. Retrieved on 17 March 2021.
  32. 32.0 32.1 32.2 32.3 32.4 32.5 32.6 Ricciuti, Mike (13 March 2002). New Windows could solve age-old format puzzle--at a price. CNET Archived from the original on 10 June 2004. Retrieved on 31 March 2021.
  33. 33.00 33.01 33.02 33.03 33.04 33.05 33.06 33.07 33.08 33.09 33.10 33.11 33.12 Thurrott, Paul (30 August 2005). Windows Storage Foundation (WinFS) Preview. Archived from the original on 2 July 2007. Retrieved on 17 March 2021.
  34. 34.0 34.1 Flynn, Brendan (12 March 2020). The Evolution of Windows Search. Microsoft Windows Search Platform DevBlogs. Retrieved on 17 March 2021.
  35. 35.0 35.1 35.2 35.3 Sweat, Jeff (22 April 1996). MICROSOFT DUMPS CAIRO’S OBJECT FILE SYSTEM. CBR Online / Tech Monitor. Retrieved on 16 October 2023.
  36. Petreley, Nicholas (8 April 2022). The Road to Cairo. Computerworld. Retrieved on 16 October 2023.
  37. jimmsta (23 September 2022). Re: What became of Windows Cairo. BetaArchive. Retrieved on 20 November 2022.
  38. Thurrott, Paul (6 March 2000). COM+, A Windows 2000 technology showcase. Archived from the original on 15 August 2007. Retrieved on 17 March 2021.
  39. Thurrott, Paul (13 November 2002). The Road to Windows "Longhorn". Archived from the original on 12 July 2007. Retrieved on 17 March 2021.
  40. Vaas, Lisa (10 March 2004). Yukon, Whidbey Releases Slip Yet Again. Retrieved on 31 March 2021.
  41. Thurrott, Paul (6 March 2000). The Road to Windows Longhorn 2003. Archived from the original on 29 June 2007. Retrieved on 17 March 2021.
  42. 42.0 42.1 Gates, Bill (20 May 2011). PDC 2003 Keynote with Bill Gates. Retrieved on 7 April 2021.
  43. Gates, Bill (20 May 2011). PDC 1996 Keynote with Bill Gates. Retrieved on 9 April 2021.
  44. Paul Thurrott, Keith Furman (28 October 2003). Live from PDC 2003: Day 2, Tuesday. Windows Network & .NET Magazine. Archived from the original on 27 November 2003. Retrieved on 17 March 2021.
  45. Greene, Jay (19 April 2004). How Microsoft Is Clipping Longhorn. BusinessWeek. Archived from the original on 18 April 2004. Retrieved on 31 March 2021.
  46. 46.0 46.1 Thurrott, Paul (26 October 2006). Paul Thurrott's SuperSite for Windows: Road to Gold: The Long Road to Windows Vista Part 3: 2004. Paul Thurrott's SuperSite for Windows. Archived from the original on 20 January 2007. Retrieved on 31 March 2021.
  47. 47.0 47.1 Mike Ricciuti and Martin LaMonica (13 May 2004). Longhorn goes to pieces. CNET Archived from the original on 4 June 2004. Retrieved on 31 March 2021.
  48. 48.0 48.1 Fried, Ina (10 December 2004). New file system has long road to Windows. CNET Archived from the original on 6 March 2005. Retrieved on 8 April 2021.
  49. LSoft Technologies Inc.. WinFS for Developers. Retrieved on 17 March 2021.
  50. 50.0 50.1 50.2 IWish Concept Video. Microsoft. Archived from the original on 2 June 2006. Retrieved on 17 March 2021.
  51. 51.0 51.1 De Mar, Steve (5 October 2005). WinFS PDC Video. WinFS Team Blog. Archived from the original on 8 July 2007. Retrieved on 17 March 2021.
  52. 52.0 52.1 Shishir Mehrotra (14 September 2005). "WinFS" Future Directions: An Overview. PDC 2005. Microsoft. Retrieved on 19 March 2021.
  53. Session Details. Archived from the original on 10 December 2005. Retrieved on 28 March 2021.
  54. Ramesh Nagarajan (September 2005). “WinFS” Future Directions: Building Data-Centric Applications Using Windows Presentation Foundation “Avalon” and Windows Forms. PDC 2005. Microsoft. Retrieved on 19 March 2021.
  55. Nagarajan, Ramesh (21 September 2005). Postcard from the PDC. WinFS Team Blog. Archived from the original on 13 August 2007. Retrieved on 28 March 2021.
  56. Eric (10 March 2006). re: My tryst with Destiny, err… Integrated Storage. Archived from the original on 31 October 2007. Retrieved on 17 March 2021.
  57. Drucker, Samuel. “WinFS” and ADO.NET: Future Directions for Data Access Scenarios (PPT). Archived from the original on 20 December 2005. Retrieved on 17 March 2021.
  58. 58.0 58.1 Sinha, Shan. Showing off the next release of WinFS at Tech Ed 2006, in Boston! Join us!. WinFS Team Blog. Archived from the original on 8 March 2007. Retrieved on 17 March 2021.
  59. 59.0 59.1 Mooney, Paul (14 June 2006). WinFS is Sweet. Archived from the original on 23 June 2006. Retrieved on 6 April 2021.
  60. 60.0 60.1 60.2 Anurag Gupta and Sameet H. Agarwal (inventors) (15 September 2009 (publication date)). US7590654B2 - Type definition language for defining content-index from a rich structured WinFS data type - Google Patents. Retrieved on 14 April 2021.
  61. 61.0 61.1 61.2 61.3 61.4 Bangaru, Vijay (16 December 2005). WinFS Mailbox II. WinFS Team Blog. Archived from the original on 4 February 2007. Retrieved on 20 March 2021.
  62. Windows Vista Product Guide (DOCX) 44–51. Microsoft (2006). Archived from the original on 1 July 2011. Retrieved on 17 March 2021.
  63. 63.0 63.1 63.2 Dimitrova, Kati. About WinFS Rules. WinFS Team Blog. Archived from the original on 11 August 2007. Retrieved on 17 March 2021.
  64. Bentz, Ben (31 October 2006). Query Composition: Building a search upon another search. Shell: Revealed Blog. Microsoft. Archived from the original on 15 December 2006. Retrieved on 17 March 2021.
  65. FILESTREAM (SQL Server). Microsoft (11 January 2018). Retrieved on 6 April 2021.
  66. Clarke, Gavin (12 February 2013). Billionaire baron Bill Gates still mourns Vista's stillborn WinFS. The Register. Retrieved on 17 March 2021.
  67. 67.0 67.1 67.2 67.3 67.4 67.5 67.6 67.7 67.8 WinFS: Overview > WinFS: Unified Storage System for Windows, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  68. 68.0 68.1 68.2 68.3 Berenson, Hal (14 February 2013). WinFS, Integrated/Unified Storage, and Microsoft – Part 1. Retrieved on 29 March 2021.
  69. 69.0 69.1 69.2 69.3 69.4 69.5 69.6 Grimaldi, Sean (December 2005). The WinFS Files: Divide et Impera. MSDN. Retrieved on 17 March 2021.
  70. 70.0 70.1 Wildermuth, Shawn. A Developer's Perspective on WinFS: Part 1. MSDN. Retrieved on 17 March 2021.
  71. Rizzo, Thomas (17 March 2004). WinFS 101: Introducing the New Windows File System. MSDN. Retrieved on 17 March 2021.
  72. 72.0 72.1 Vijay Bangaru. Unify, Organize, Explore, and Innovate. Oh my! (Part 2). WinFS Team Blog. Archived from the original on 2007-06-09. Retrieved on 2007-06-30.
  73. Levy, Steven (23 November 2003). He's Still Having Fun. Newsweek. Retrieved on 12 Apri 2021.
  74. WinFS Overview, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  75. Bangaru, Vijay (24 October 2005). Unify, Organize, Explore, and Innovate. Oh my! (Part 1). WinFS Team Blog. Archived from the original on 8 July 2007. Retrieved on 17 March 2021.
  76. 76.0 76.1 Voellm, Tony (14 September 2005). Performance, Performance, Performance. WinFS Team Blog. Archived from the original on 7 August 2007. Retrieved on 28 March 2021.
  77. Vijay Bangaru (4 November 2005). Unify, Organize, Explore, and Innovate. Oh my! (Part 3). WinFS Team Blog. Archived from the original on 16 August 2007. Retrieved on 17 March 2021.
  78. 78.0 78.1 Bangaru, Vijay (18 November 2005). Unify, Organize, Explore, and Innovate. Oh my! (Part 4). WinFS Team Blog. Archived from the original on 18 August 2007. Retrieved on 17 March 2021.
  79. The Channel 9 Team (24 May 2004). Samuel Druker - How does Outlook Express in Longhorn use WinFS?. Retrieved on 9 April 2021.
  80. Bangaru, Vijay (26 September 2005). WinFS Backup/Restore at VSS Plugfest. WinFS Team Blog. Archived from the original on 17 August 2007. Retrieved on 17 March 2021.
  81. (17 February 2016). Hillel Demoes Longhorn build 4050 (Extended cut). Retrieved on 8 April 2021.
  82. Koo, Heesung. Copy CD. Storage Design Team Website. Retrieved on 9 April 2021.
  83. 83.0 83.1 Koo, Heesung. Music library. Storage Design Team Website. Retrieved on 9 April 2021.
  84. 84.0 84.1 84.2 84.3 84.4 Koo, Heesung. Virtual folders. Storage Design Team Website. Retrieved on 9 April 2021.
  85. 85.0 85.1 85.2 85.3 85.4 85.5 85.6 85.7 85.8 85.9 Microsoft User Experience Group (October 2003). User Experience (Aero): Contacts (Microsoft Access 2002 Technical Articles). Aero User Experience Guidelines. MSDN. Archived from the original on 4 April 2004. Retrieved on 10 April 2021.
  86. The Windows Team. Take a Self-Guided Longhorn Tour. MSDN. Archived from the original on 30 October 2003. Retrieved on 29 March 2021.
  87. JabbaPapa (12 August 2004). Using WinFS in Codename Longhorn 4074. Retrieved on 29 March 2021.
  88. 88.0 88.1 Stoyanov, Stanimir (30 August 2005). WinFS Beta 1 on Non-Windows XP with SP2 Systems. Stanimir Stoyanov's Blog. Archived from the original on 16 June 2006. Retrieved on 9 April 2022.
  89. WinFS: Overview > WinFS System Architecture, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  90. 90.0 90.1 90.2 90.3 90.4 90.5 van der Meer, Erwyn. First Look on WinFS Beta 1. Archived from the original on 9 June 2007. Retrieved on 20 March 2021.
  91. 91.0 91.1 91.2 91.3 91.4 91.5 91.6 91.7 91.8 Malik, Sahil (25 January 2006). WinFS Basics: Working with a Data Store. Retrieved on 20 March 2021.
  92. 92.0 92.1 92.2 92.3 Bangaru, Vijay (13 September 2005). WinFS Mailbox. WinFS Team Blog. Archived from the original on 22 May 2007. Retrieved on 20 March 2021.
  93. 93.0 93.1 93.2 WinFS as a File System > WinFS Stores and Shares > WinFS Stores, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  94. 94.0 94.1 94.2 WinFS Type System, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  95. 95.0 95.1 95.2 95.3 WinFS Type System > WinFS Type System Basics, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  96. How Do I... > How Do I Use Other Important WinFS Features > Create and Use Custom Schemas > Create a Custom Schema, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  97. WinFS Type System > Scalar and Entity Types (WinFS Type System), Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  98. 98.0 98.1 98.2 WinFS Type System > WinFS Type System Basics > WinFS Items, Item Fragments, and Item Extensions, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  99. 99.0 99.1 WinFS Type System > WinFS Type System Basics > Associating WinFS Items (WinFS Type System), Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  100. WinFS as a File System > File Metadata Promotion and Demotion in WinFS > System of WinFS File Promotion and Demotion > WinFS File Metadata Handlers, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  101. WinFS Rules > Introduction to WinFS Rules, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  102. 102.0 102.1 WinFS Glossary, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  103. 103.0 103.1 103.2 103.3 103.4 WinFS Rules > Introduction to WinFS Rules > WinFS Rules Model, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  104. WinFS Programmability > WinFS Programming Techniques > Querying and Retrieving Objects Stored in WinFS > Overview of WinFS API Query Capabilities, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  105. 105.0 105.1 Miranda, Luiz. Using OPather To Help Write Queries. WinFS Team Blog. Archived from the original on 19 November 2007. Retrieved on 29 March 2021.
  106. WinFS Programming Techniques > Querying and Retrieving Objects Stored in WinFS > WinFS OPath Query Language Reference, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  107. WinFS Sync, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  108. WinFS Sync > WinFS Sync Overview, Microsoft WinFS SDK Beta 1 Documentation, 27 July 2005
  109. Padgett, Neil (17 November 2005). Getting Data Into WinFS with WinFS Synchronization. WinFS Team Blog. Archived from the original on 17 February 2007. Retrieved on 28 March 2021.
  110. File System Sync Adapter, File System Adapter Read Me.wri, stored at the Unsupported\FileSystemAdapter\ folder of the WinFS Beta 1 install CD
  111. 111.0 111.1 Microsoft Rave, User Manual.wri, stored at the Unsupported\Rave\ folder of the WinFS Beta 1 install CD
  112. 112.0 112.1 Jhaveri, Vivek (8 September 2005). Synchronize your WinFS data with Microsoft Rave. WinFS Team Blog. Archived from the original on 4 February 2007. Retrieved on 28 March 2021.
  113. Lee, Wei-Meng (2005-09-07). WinFS -StoreSpy. Retrieved on 2007-06-30.
  114. 114.0 114.1 114.2 Release and Install Notes for StoreSpy, Readme.rtf, stored at the Unsupported\StoreSpy\ folder of the WinFS Beta 1 install CD
  115. StoreSpy should become StoreEditor (9 April 2021). Archived from the original on 29 September 2007. Retrieved on 30 June 2006.
  116. 116.0 116.1 scobleizer (29 August 2005). Shishir Mehrotra - WinFS beta 1 team meeting. Retrieved on 29 March 2021.
  117. Demiliani, Stefano. WinFS StoreSpy v0.8 for the WinHEC 2004 Longhorn Build. Archived from the original on 21 June 2004. Retrieved on 28 March 2021.
  118. ATeamInc (30 March 2021). Re: [Req] WinFS StoreSpy v0.8 for the WinHEC 2004 Longhorn Build. BetaArchive. Retrieved on 16 April 2022.
  119. Nagamangalam, Sanjay. Visualizing WinFS Types. WinFS Team Blog. Archived from the original on 16 August 2007. Retrieved on 28 March 2021.
  120. Mehrotra, Shishir. The killer app for getting users organized. WinFS Team Blog. Archived from the original on 9 March 2007. Retrieved on 28 March 2021.

See also

BetaArchive forum



External links


Longhorn-era WinFS



Reactions to WinFS delays

WinFS Beta 1 era




Hal Berenson: WinFS, Integrated/Unified Storage, and Microsoft

General links

Other forums