Unlessyou’ve been living under a rock for the past couple of days, you’veno doubt heard the news about the impending Longhorn scope cuts. Here are themajor points that I took away from the announcement, along with my thoughts oneach:
WinFS is pretty much gone.
This didn’t raise my eyebrows too much. The problems that WinFS tries tosolve are very hard – and I’m not referring to the technicalchallenges. Sure, coming up with a way of attaching metadata to documents atthe file system level has its fair share of technical hurdles to overcome but Ithink MS is more than up to the task. The real problems are more high-level; thereally hard stuff involves figuring out what all that metadata should looklike. Even then, once the physical representation problem has been solved,there’s still the nasty issue of shared semantics – gettingeveryone to agree on what all this metadata actually means is a reallyhuge task. The vision for WinFS is great, but I don’t think we’llbe getting there anytime soon. Cutting WinFS makes a lot of sense.
Indigo will be available on down-level platforms.
Oooh, shiny! This is nothing new. Indigo has always had plans to make itselfavailable on non-Longhorn systems, so this shouldn’t come as much of a surprise.It’s really a non-announcement and more of reminder of plans that havebeen around for a long time.
Avalon will be available on down-level platforms.
This one did throw me for a loop, because at the PDC Avalon was presented asbeing (in part) a complete reworking of the kernel-mode driver stack. It’salso a new programming model (XAML) and a bunch of new framework classes, butthey all rested on these kernel-mode modifications that would exist only inLonghorn. In fact, I seem to remember someone asking at the PDC if Avalon wouldbe supported on down-level OS’s, with the answer being an emphatic “no”because Avalon relied on Longhorn-specific changes to the core OS in order towork properly. Thus, I’m rather interested to see what Avalon-on-XP willlook like.
If I had to guess, I would imagine that it would be XAML and the frameworkclasses coded to work against the existing Windows display subsystem. What doesthis mean for glitch-free media playback? Where does the vector-based desktopcompositing engine come into play? I have a sneaking suspicion that those twoelements will be noticeably absent from Avalon, because it’s myunderstanding that they took heavy dependencies on the updated kernel. Assumingthat Avalon-on-XP means that no kernel-mode changes will be required to run thesoftware, I doubt that Avalon will be anywhere close to the product that we sawat the PDC. If you take away all the Avalon features that depend on the kernel,what’s left? XAML for WinForms? It’s an interesting programmingmodel, sure, but it’s not central to what I see as the core Avalon story.Hopefully, someone will come forth and convince me that the Avalon situation isnot as dire as it seems to be on first glance.
Longhorn is now a date-driven release.
Perhaps the clearest message conveyed in the announcement is that Microsoft iscommitted to getting Longhorn out by 2006, and is willing to sacrifice featureset in order to do so. This marks a major shift in positioning, as it makesLonghorn more evolutionary then revolutionary. Presumably, this decision wasmade to inject upgrade revenue back into the Windows business, but I’mwondering if it will have the intended effect.
Questions, questions, questions.
If you look at the “three pillars of Longhorn” presented at the PDC(Indigo, Avalon, and WinFS), one is now entirely gone and the other two are notstrictly going to require Longhorn in order to run. Perhaps they weren’tload-bearing pillars after all. It does raise a question, though -- if notIndigo, Avalon, and WinFS, what exactly are the key components of Longhorn?What’s the value proposition? What’s the compelling reason toupgrade? If people were on the fence about making the move to Longhorn beforethis announcement, I don’t see how those people are going to be moreconvinced to upgrade now.
I have a feeling that there are major components of this story that have yet tobe revealed, and that next week will clear things up. What I really want toknow is this: As a customer, why should I upgrade to Longhorn and not justsettle for Avalon/Indigo on XP or 2003?
Thoughts on "The Announcement"
Sunday, August 29 2004 - blog
- #1 Mike Dimmick on 8.30.2004 at 4:39 AM
-
My guess is that Avalon on Longhorn will get to use the new Longhorn Driver Model and will be better accelerated than on XP. On Windows XP, it will have to use DirectX in shared, windowed mode, falling back to software rendering more often. It might even end up using *shudder* GDI. This is more or less what current Longhorn pre-Alphas (build 4074) do, by my understanding.Indigo is plumbing. I'd expect that it will require XP SP2 for the HTTP.SYS device driver, but otherwise should be unchanged.Longhorn will still offer new features not in previous versions. One that I'm looking forward to is Transactional NTFS - generalised transaction support for file data (not just file system metadata) in the file system. I started a series in June about changes to the Win32 API, which should give some clues: find it at http://mikedimmick.blogspot.com/2004/07/changes-to-win32-api-in-longhorn.html. I haven't written any more in the series recently because, well, I'm lazy, and Microsoft have swapped some decorations on the declarations from e.g. IN to __in, leading to a lot of false positives from the diff tool.
- #2 Ian Griffiths on 9.01.2004 at 1:41 AM
-
"If you take away all the Avalon features that depend on the kernel, what’s left? XAML for WinForms?"I think there's a lot more left than that. It seems likely that glitch free will not work in XP, and Microsoft have already indicated that desktop composition will also probably be a Longhorn-only thing.So the quality of the visuals will be better on Longhorn than XP.But while high quality visuals are an important goal for Avalon, they're definitely not the whole story.I'm just as enthusiastic about the new programming model, which is very definitely *not* Windows Forms with XAML.You can actually write Windows Forms apps with XAML in the Longhorn pre-releases today, and there are some crucial differences between doing that and writing Avalon apps.Windows Forms is essentially a bunch of wrappers around HWNDs. It takes the model we've had for ages and wraps it in .NET. It does a remarkably good job of hiding the cruft for the most common use cases, but the cruft is all lurking there nonetheless, and can still bite you just as hard as ever.Avalon is a very different model. And for me, one of its key attractions is how much simpler it makes a lot of things. Because it was designed with XAML in mind, it is much more straightforward to get some things done with XAML+Avalon than it is with Windows Forms + Avalon.All we really lose with a downlevel XP version is a little of the chrome... (Particularly animated chrome, I would guess. And it's not that it won't be available, it's just that the constraints on what works and what's too ambitious will be in different places. And XP will presumably glitch moving stuff from time to time.)While I happen to really like the chrome, I think to dismiss Avalon as being just the visuals is to miss a lot of the benefit.
