Avalon Changes7:23:07 AM

Everyone is still digesting what exactly is going on with Avalon, WinFS and Longhorn.  Scoble is a great place to start for links to the reaction in general.  ChrisAn also has some Q&A on what this means to Avalon.

I think that I can answer some more questions that people might have.  I'll take the Q&A format that ChrisAn used.

1. What does this mean for the Avalon graphics architecture as you presented it at WinHEC?
Actually, things mostly don't change from an architectural point of view.  We will have to make some tweaks and compromises to ensure that Avalon runs well on XP and W2K3.  All of these compromises will be because we probably won't be able to update any system binaries (User32, GDI, etc.)

2. You said that Avalon had to have Longhorn to work well.  Now it is going to run on XP and W2k3.  What gives?
There were some very good reasons for us to restrict Avalon to run just on Longhorn.  However, when looking at what customers said and our schedule, it made more sense to bend on some of those reasons than to force developers to wait for wide adoption of Longhorn before being able to write apps.  Here are some areas where we are going to have to get creative in making Avalon work on XP and W2k3:

1. Lack of the LDDM (Longhorn Device Driver Model). Right now the XPDM (XP Driver Model), wrt DX, is really built to work well for one app at a time.  It uses first come, first server, winner take all approach to resource allocation.  While Avalon runs just fine on the XPDM, it isn't clear that lots of Avalon apps running at the same time will work really well without the LDDM.  There are also concerns around the stability of current DX drivers under the XPDM.  These drivers have been written with the gaming market in mind.  Using them for every day applications may push them to some breaking points.  All sorts of options are being considered on how to deal with this.  And for machines that we can't support hardware acceleration on, we always have our software rendering layer that we can fall back to.  Early on we decided no to rely on hardware being available on every machine.  That decision is paying off now.
2. Inability to really tweak User32. In Longhorn builds we had the ability to do "child window redirection".  This is a Win32 interop solution where child hWnds get redirected by the system to a bitmap that the Avalon compositor then hosts.  This allowed Win32 content to alpha blend and rotate just like any Avalon content.  Since we won't be able to change system binaries on older systems, we won't be able to do this redirection on XP and W2k3.  We'll have to find a compromise solution to hosting legacy content.  You probably won't be able to treat it like regular Avalon content.  Eventually we want to be able to support these advanced legacy hosting solutions, but it probably won't work on XP and W2k3.
3. Terminal Services and Remote Desktop. We were planning on remoting Avalon at a completely different layer.  It is unclear how we will address this issue on platforms other than Longhorn.  The long term plan and architecture still encompasses enhanced remoting.
4. Media decoding system.  A lot of the video hosting relied on components being delivered from the media team.  Since we are now perhaps shipping via a different mechanism than they are, the level of integration and interdependencies are now up in the air.  We are working on figure that out.
5. Desktop Window Manager.  The DWM will still exist and be included as part of Longhorn.  There are no plans to make the DWM run on XP and W2k3.  The cross process UCE architecture presented at WinHEC remains unchanged for when Avalon apps are running under the DWM on Longhorn.

3. How has the Avalon vision changed?  Is it a less ambitious plan now?
The long term Avalon vision hasn't changed.  We still want to enable the same hardware accelerated, media rich, easy to develop, network connected application platform that we've been talking about since the 2003 PDC.  The real change here is a new pragmatic staged approach to getting it out the door and in the hands of developers.  If we've talked about some feature or doodad that has to be compromised to make Avalon work under these new constraints, don't worry.  Chances are that that feature is still on the list for when we can do it.

4. What is your personal opinion on these changes, Joe?
Thanks for asking!  Personally I'm really excited by these changes.  It is painful to have to sacrifice (at least when running on XP and W2k3 -- they may "light up on Longhorn") some of the features that require deep changes to the system but the overall result of being able to deliver Avalon to XP and W2k3 outweigh that pain dramatically.  Anything we can do to get Avalon out the door on a more deterministic schedule and to deliver it to a wider audience of developers seems like a good thing to me. 

Making hard decisions like this is necessary to get big projects out the door.  While it would have been great if we had figured some of this stuff out a year (or more) ago, this is better late than never.  $50 billion in the bank (or whatever it is these days) is a lot of money but it still doesn't buy you a crystal ball to see in to the future.