Submitted by “There are obviously a lot of questions on people’s minds. So I post again today trying to answer some of them. To those who think I am not a real person but rather a name in front of PR machinery – that’s just not true. I am flesh and blood – with a job, a team, and a passion for what we have been pursuing in WinFS. And even a life outside of Microsoft Building 35 with a wife, kids and other interests. Certainly seems like I might have been too careful in wording last week – was not my intention to offend bloggers everywhere, really.”
I certainly wasn’t questioning, or trying to shoot the messenger. Microsoft refusing to give WinFS as a free update to all those people who’d forked out for Vista and rolling it into SQL Server to try and make more money was always on the cards.
I certainly wasn’t questioning, or trying to shoot the messenger. Microsoft refusing to give WinFS as a free update to all those people who’d forked out for Vista and rolling it into SQL Server to try and make more money was always on the cards.
Just because the technology is being used in SQL Server doesn’t mean it will only be available in SQL Server nor only for a price. There are 2 free versions of SQL Server (SQL Express and SQL Everywhere), and they’ve mentioned that the technology could make it into a number of products. They just aren’t shipping the whole thing as one big package and staggering updates to client, then server, then SQL, as they were originally.
Let the boy have his way. He wants to believe it was a plan all along to just extort money out of people for it, so let him believe it.
Let the boy have his way. He wants to believe it was a plan all along to just extort money out of people for it, so let him believe it.
Oh poor you. Somebody points out the truth, you don’t like it and you stamp your feet – as usual. WinFS was a complete total and utter failure to deliver in Vista (and it was meant to be a definite new feature in Vista and then a definite add-on for people), and as a result it then became a feature to throw on top of the new SQL Server pile as Microsoft had to find a use for it.
That’s the way it’s happened, and no amount of spin or outright denial is going to alter what’s actually happened.
<blockquote> Somebody points out the truth, you don’t like it and you stamp your feet – as usual.</blockquote>
You know, having been on a deathmarch or two in my life, I think we’re all being a bit harsh. Yes, there probably some systemic issues at MS and a number of PR issues, but at this point, I see no point in kicking a man while he’s down.
It’s not as if he’s saying, “ha ha, we’re not finishing WinFS, nyah!” It has to be a great disappointment, but then, kicking a man while he’s down does seem to be a well developed skill among developers (…and don’t try to tell me it isn’t).
This is a list of skills necessary for a modern developer to be successful in any major software shop.
1. Kicking a beaten adversary.
2. Undermining competing a project’s progress.
3. Under-estimating your time frame.
4. Mad golf skills
5. Good hair.
WinFS was based on SQL Server technology in the first place. It’s a natural progression to go back to SQL and use it as a base for the new technologies spawned from it. WinFS as a single product is dead. The technology is not, and is being applied in a more general fashion across MS’ data products so they have a common base to build from. They all will speak the same language (Entities — an evolution of WinFS’ Items), and use the same API (ADO.NET 3.0 — an evolution of ADO.NET, the WinFS API, and Object Spaces — documentation and a CTP available on MSDN).
It will take more time to get the platform, but it will be a more unified solution across multiple data stores up front than the original WinFS story.
The problem is that if I am reading it right if your program is not an ADO.NET 3.0 based program then any file it creates will not be handled as a WinFS file. All extensions can be lost or never created when a older program handles a file. A new file will not be indexed by it’s additional attributes as old program (a) don’t have these attributes to write out, (b) do not have the interface to do the writting.
Edited 2006-06-28 15:48
The problem is that if I am reading it right if your program is not an ADO.NET 3.0 based program then any file it creates will not be handled as a WinFS file. All extensions can be lost or never created when a older program handles a file. A new file will not be indexed by it’s additional attributes as old program (a) don’t have these attributes to write out, (b) do not have the interface to do the writting.
That’s not how things work. WinFS in it’s original form was a seperate store from NTFS, using NTFS for storage of regular files (then referred to as file-backed items — presumably as file-backed entities now), while the WinFS store stored extended metadata and schematized objects. WinFS support on any big level was always developer and application dependent.
For legacy apps, or if the developer only desired basic file I/O, the normal file I/O APIs from Win32 or .NET were used. Normal apps used the file as usual. Apps wanting to participate on a non-trivial scale with WinFS needed to use the WinFS API (which has now evolved and is being rolled into ADO.NET 3.0).
WinFS had a synchronization layer that handled mirroring file updates to NTFS into the WinFS store and vice-versa. This is likely how it would work going forward unless MS decides to create a more integrated file system that is also based on entities at its core and intrinsicly supports file streams as well, which could be the case since they plan to support unstructured data more directly within SQL Server. WinFS as a file system could end up being a DB with integrated stream support. The dependence on NTFS was mostly one of convenience anyway (existing optimized and compatible implementation) that could always be replaced with something else.
For legacy apps, or if the developer only desired basic file I/O, the normal file I/O APIs from Win32 or .NET were used. Normal apps used the file as usual. Apps wanting to participate on a non-trivial scale with WinFS needed to use the WinFS API (which has now evolved and is being rolled into ADO.NET 3.0).
——————————————————–
That is my point. All program do not use the WinFS API so file handling by older programs will interfer with the metadata of files written by newer programs.
I see this whenever I have to do something with the old Posix commands on my BeOS. File attributes are lost because the old code did not support them. However, 95%+ of my time is using either BeOS programs or interface program (BeIDE) that wrap around older code so I still have my BeFS atrributes unharmed.
Windows on the other hand has tons of useful programs that are not WinFS aware and without the FileSystem automaticly hang onto the metadata a lot of it will be lost while using older programs.
The way it worked was that the WinFS server process created a virtual file system, an applications could use Win32 file IO API against that file system, not against the underlying NTFS.
Not
.NetAPP<->WinFS API<->WinFS Server<->NTFS
and
Win32APP<->NTFS
But Win32APP<->VirtualFileSystem<->WinFS Server<->NTFS
WinFS would take those API calls, and reroute them to the approptiate Item stream on the disk. So if a non-winfs aware application updated a file WinFS would be aware and keep the existing database metadata attached to the same file.
Normal applications would have been prevented from modifying the underlying file streams without going through WinFS by traditional NTFS ACLs.
There were also some metadata sync services, so if a non-winfs aware application updated an image file and changed the Exif data, WinFS would be notified of the change, and re-read the exif tags from the file to update its internal metadata.
The new ADO.Net Entities are nothing to do with files or metadata, its just a way of expressing logical units of data in a database that may be spread over several underlying tables, to make it easier to program against complex database schemas.
Its using some of the ideas behind the .Net WinFS API, not the virtual file system datastore.
It must feel good to be able to throw logic out the door and be able to so blatantly state speculation as fact. Not even trying to hide it here. That takes balls man.
It’s almost cute. Almost.
this is a clear failure to deliver
they have told so often that this would be included in longhorn (vista), then is would be included as an optional download after the vista release, and now it’s dead (a mssql feature instead of a filesystem)
mere money can’t buy real innovation
I fully agree that it is a failure to deliver and nothing more. There’s nothing in this “update” that I couldn’t infer directly from the previous post. However, there is one interesting comment where he refuses to apologize for the failure to deliver WinFS on time–even with the multi-year delay. He suggests that the bar was set too high, and that’s why WinFS didn’t make it in.
This, and not a sense of obligation to let people know as soon as possible, was why they reported this news in a blog instead of “firing up the MS PR machine,” as he puts it. He tries to play this down by reminding us that WinFS was pulled from Vista long ago, but it was always suggested that WinFS would be offered as an add-on when it was ready.
The overall impact is that structured data will never be a first-class citizen on Vista, and therefore it will be more-or-less closed-off to 3rd-party developers. Instead, structured data functionality (beyond the simple case of desktop search) will be implemented on flat files using NTFS attributes, which will be so complicated that only Microsoft would dare try it.
There is no way any OS can replace my BeOS if the file system does not support live queries.
If the functional code of WinFS is instead rolled over into the .Net code then I don’t see how live queries can be made to work without a major hit in the filesystem preformance.
This also raises the question to me if only .Net is maintaining the indexs to files then any change made by a non-.Net program will be invisible to the indexs. Does this mean some sort of cron job is rebuilding the index every X minutes to keep it up to date?
Since it is rather obvious that relational models and oo like structures of filesystems do not match, so trying to shove oo like structures into relational models always is a speed hit.
Did Microsoft upfront research into why BeInc basically stopped this approach and rowed back?
There were others as well, some CMS systems basically also tried this VFS approach and did not fail but were forced to make bypasses etc.. to gain desired speeds.
(Opencms comes to my mind instantly)
As someone else said, this is clearly a failure to deliver. However, let me say first that I understand that the whole Vista project had really high goals, among which there was a full re-engineering of the Windows platform.
Under a technical point of view, we should understand how difficult it could be to re-engine the whole platform to mitigate defects (or features which ended up being defects). To me, the simple fact that you have greater control over software and you need to approve system-wide changes is worth the Vista upgrade. That was needed because Microsoft needed a new foundation onto which they could develop coming innovations. The mid-90s foundation was simply too acient to keep innovating and too keen to security risks. That was something we all understood during early 2000s so I don’t blame Microsoft for that.
However, only Microsoft could deliver such a great changes WHILE still promising to keep compatibility with old technologies. Please, understand this is just great. Others simply say: things changed, update your software or wait until a new version will be released. Instead, while developing such great changes, Microsoft is still promising compatibility even with DOS era software. Just great.
However, I’d tell MS not to go around showcasing technologies they’re not sure to deliver. I’m sure this is a big hit to all those developers who wasted months in learning WinFS technology and companies planning to deliver on that, not to mention PR investments.
For example, as for me, right now I see under a different light even the WinFX-.NET 3.0 thing. Yeah, there should be no problem about releasing that BUT, as I said, *should*. I think this failure will affect how the developers community will react to Microsoft new technologies in future, expecially in early stages. As I wrote in other posts: be sure to deliver or keep them closed until you are.
Well maybe Microsoft is tired of releasing vapor ware? Gates is now going and truths are comming out?
Even half baked attempts at a real filesystem is responded to well. ZFS is an example (ZIP File system is still vaporware). You still cant boot off ZFS on sparc and have to hack ZFS for x86.
“Was WinFS “killed” because of its design?”
Since when has this been a priority? Slap in access she will be right.
SQL inclusions I expect are progression into the actual. It is harder to incremental update a filesystem but no problems with servers.
Microsoft failing to deliver an actual improvement to their OS? Say it ain’t so! Did anyone actually believe that WinFS was going to happen? If you did, you’re either a) a big optimist or b) a Microsoft lemming.
Microsoft doesn’t innovate, they integrate. There’s a big difference. And you can’t integrate a technology you don’t have. Most of the “improvements” in Vista consist entirely of Microsoft integrating technologies other OS have had for years into Windows. Still, for anyone who has to use Windows they’re probably worth it (if you’re willing to take the performance hit).
Instead of trying something so ambitious like a whole filesystem that is a DB, they could have just easily delivered a DB with their O/S, which the shell could use to store file metadata, do searches, provide views etc. The DB could also replace the registry, which is also a mini DB.