Power PDC

I’m sure some applications will soldier on with their proprietary workflow engines anyway. For a few, that will be because there’s something in the Microsoft OS-level engine that simply isn’t good enough for them, but for the remainder it will be because they’re stuck in the mud. Naturally, the 90:10 rule will apply with a vengeance here, and spotting those who are dragging their heels won’t be hard.

Power PDC

WinFS storage

I found time at the PDC to catch up with Quentin Clark, head of the WinFS group. Back in March, when I was last at Redmond, Quentin had taken me through the big vision plans for WinFS over the next five to six years, and thanks to that meeting I was happy to write that I was convinced Microsoft really did have a storage story. The first fruits of this are the WinFS Beta 1 components I wrote about last month.

One point of useful clarification emerged from our LA meeting – as I surmised last month, when you take a file like a Word document or a photograph, it gets examined for any existing property tags, and these are copied off and placed into the WinFS store. The file itself is then renamed with a long GUID (Globally Unique Identifier) as a filename and is stored into a hidden partition within the NTFS file system. So when some application comes along that uses the standard Win32 API calls to read that file, WinFS just hands over the file handle to the raw file held in the NTFS hidden store and the application can read, write and manipulate it at full speed just like any other file on a traditional NTFS partition. Compatibility is guaranteed because it’s a normal file, treated in the normal way.

The obvious question to ask, though, is ‘what will happen in future?’ Will that file ever get dropped into the WinFS store itself, as some sort of binary stream? This is the way a raw object file system would work and was the method promised by the Cairo OFS. A similar scheme is used when you drop a file into the Exchange Server store; for example, the binary file itself gets gobbled up into the new store, away from the native NTFS file system. The thing is, there’s a big problem with this ‘chuck it all into one bit-bucket’ approach, as you need to rewire the entire set of Win32 APIs to make them work that way, and that’s not going to be pleasant. Or else you take the approach used with the Exchange Server store and its drive M trick; that is, write an installable file system (IFS) driver that sits on top of the object store and plugs itself into the bottom of the Windows driver stack, appearing as another drive letter so thatyou can use standard Win32 APIs to manipulate files held in the store. The API doesn’t know that it isn’t talking to NTFS, because the IFS driver does all the arm-waving for you in the background.

The problem comes in making the store look sufficiently like NTFS through this IFS driver – and Exchange Server experience shows that it’s terribly easy for a rogue Win32-API application to run riot through the store – because the driver has to catch every possible use of the Win32 API. For example, I know that numerous Exchange Server Drive M stores have been trashed because someone ran a backup application across drive M itself, thinking it must be another NTFS volume. They got trashed in a rather subtle way, breaking Exchange Server in a quite infuriating, non-obvious and hard-to-debug way.

So the route the WinFS team is taking looks like a sensible balance between 100 per cent bombproof backwards compatibility with the Win32 API and future handling of all the metadata. It’s this sensible compromise that distinguishes WinFS from the ‘leap in with both feet’ approach taken by OFS, Exchange Server store and some other DB-centric solutions. But it still begs the obvious question: at what point in the future will it become possible to store all of a file’s binary stream into the WinFS store natively, rather than relying on this shadow-boxing arrangement of keeping the binary part out on the NTFS partition? To be honest, I’m still not sure, and the more I think about it the more obvious it becomes that this current arrangement will be with us for a very long time (at least another decade, if API compatibility continues to be held important). After all, it was only with the arrival of the 64-bit version of Windows that API support for 16-bit Windows applications was finally dropped.

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.

Todays Highlights
How to See Google Search History
how to download photos from google photos