Yesterday I received my order for Vista Ultimate and Office Ultimate. I'm already running Vista RTM bits on my main machine at home (I had a Beta and RC version, so I upgraded to RTM bits as soon as they were available internally. I believe this is the correct thing to do based on corporate policy... if not, someone should let me know. I did buy a full copy for every machine in my house once it was available).

This morning I kicked off the installation of Office, or rather the upgrade. Some comments:

• the new packagine is clever, not too intrusive but distinctive. I think I like it.
• Product keys suck. Having to type of 25 digit string of characters to install software is frustrating for me. Not too big of a deal on my PC - the one I really really really hate is doing this on the XBox.
• The installation is running, and so far I have only had 1 UAC dialog prompt.

I really enjoy using Office 2007 at work, so I'm pretty happy to finally have it up and running at home.

 

Oh, wait... not really. $499 for a fully equiped desktop running Vista (OK, you need to add a monitor)... $699 for a laptop. I know this isn't quite as good as Sells' $365 Vista machine, but it's a good start.

It's great to see Vista release. I spent a lot of time working on WPF, which I believe is one of the core parts of the new Vista experience. The Avalon team, depending on how much of the organization you include, peaked at around 250 people, with another 250 people working in the "Windows Client Platform and Documents" team that Avalon was part of. It was a massive effort. The overall team built features ranging from the XPS document format, the desktop window manager, WPF, and the Windows Imaging Components (WIC) - to name just a few.

I'm proud of what this team accomplished, and I'm extremely proud to have been part of that team.

Congratulations to everyone who contributed to this release. I know we would have all liked to see it get out the door before now, but we have a lot to be proud of.

... now, let's get back to work and make it even better!

Greg Schechter blogs again... now all DWM, all the time... well, kinda.

Thanks for the response Miguel... I'm still trying to digest the Slashdot thread also (I'll respond on Slashdot for that thread... )...

Before I start, I'm not taking any of this personally - I really enjoy debate, regardless of the opinions. As far as I'm concerned, bring it on! More Feedback == Better.

Security

The low-tech (aka phishing, aka con artist) attacks are being worked on. The social engineering and human behavior/interaction research is happening, it's just not on my team.

As for the "weakest link" characterization of ClickOnce, I think you are confusing some things.

ClickOnce is a deployment technology that improves upon the base technology introduced in .NET 1.0 for downloading and loading code. ClickOnce supports a subscription and application manifest. A principle advantage to the approach is that a customer can establish a subscription to an application and get automatic updates. In addition, the application manifest creates a complete descriptions of the parts of the application - enabling both validation and download/install/uninstall to be implemented by the system.

Next in the stack is CAS - Code Access Security. This is the security system built into the CLR. This technology has been in place since .NET 1.0, and we are continuing to iterate on it. In addition in Whidbey (the version of the CLR that we are talking about here) has a new level of application level security that can "lock back" the permissions of the loaded assemblies to that of the application, further limiting attack vectors.

In the middle of this is the TrustManager. This is a piece of code that provides a user with a single consistent prompt to determine what they want an application to be allowed to do. For example the application might request higher permissions or local installation. The goal here is to remove the half dozen security dialogs that users get prompted with today, and messy installation wizards, with a consistent user experience, giving them complete information.

All of this technology together, gives us the user experience that is (as you put it) one of the fundamental reasons for Avalon to exist. A perfect (or much more secure) computer would be one that you never plug into any network and have no software installed. You wristwatch is pretty secure is my guess.

We are doing usability studies on all of this, to validate that this is going to improve the situation... I'll keep you posted.

Complexity

I've used a handfull of GUI libraries; VB6, IE, WFC, AWT, Swing (limited exposure), KDE/QT (very limited exposure), and Cocco (limited exposure). Cocco was amazingly complex in my usage, the library felt like MVC on steroids with a pretty cool UI designer. KDE/QT felt a lot like WFC in C++, fairly straight forward. Swing, was, well, swing. MVC everywhere, powerfull, but very complex. I found that at JavaOne most of the Swing sessions started with a 15 minute talk on how you really can make Swing fast if you just understand MVC more. I think that the recent versions of Swing are much improved on this, my data is a little dated here. AWT was simple, but I felt that the event adapter model and peer model didn't lend itself to good usability, toolability, or performance. Anyway, I could go on... I'll try to take a look at Tk and XView, if they offer better simplicity, it would be great to learn from them.

The point about abstracting implementation from API is very interesting. The COM model has a very clear abstract, but removes the ability to deal with implementation inheritance. The AWT model of peers supported inheritance, but the real meat of what you wanted to deal with was locked away in the peer. We really wanted to embrace the "component framework" model that is present in ASP.NET and Windows Forms (yes, I know they have a peer model because of the HWND, but the WndProc is directly accessible, etc.)... the idea was to provide component developers full access to the implementation and not special case any Microsoft code as much as possible. The idea being, anyone should be able to implement "Button" and do all the same features we did, with no penalties.

This does come at the cost of more public exposure, but we hoped it would be worth it.

I know that Button is too trivial of an example to really talk about, so lets talk about lists, or more specifically ListBox. In most programming models that I've used the ListBox has a data model of providing strings - this is the Win32/AWT way (I think Cocco also?). Windows Forms added support for "object", but basically you had to .ToString() the thing to get it to display... unless you implement your own custom rendering. In all the systems I've seen the custom rendering is implemented in a completely different programming model - paint code in most systems.

Avalon has a simple "scalable" model. When I say scalable I mean to imply that the API starts simple but can scale up to support complex scenarios without requiring a massive leap in understanding - pay for play in complexity.

<ListBox>
    <string>Hello</string>
    <Image Source="http://..." />
    <Button>Hello</Button>
</ListBox>

You then can get into styles to manipulate all of this:

<Style>
    <ListItem />
    <Style.VisualTree>
        ....
        <Rectangle RadiusX="5" RadiusY="5" />
        ...
    </Style.VisualTree>
</Style>

The key thing is that I never had to switch programming models. Yes, if you try to digest everything at once (styling, binding, commanding, visual trees, etc.) then the system is complex - but the goal was scalability - Make simple things simple, and hard things possible.

Standards

First, an old post from Joe Beda about SVG and XAML.

Second, dismissing the CSS debate isn't really fair. A critical part of our design is unification. We didn't want one markup model for vector graphics, one for styling, one for 3D, one for data, etc. Another part of the unification was "Markup == OM", that is, we didn't want a separate markup programming model from code. HTML is this way, the markup and the code have a loose relationship. If we ignore the unification debate, I can understand how it seems simple to say "you should have used SVG".

Avalon is a developer platform. We want to enable an entirely new breed of applications that span UI, graphics, and media. Integration of typography with imaging with video with controls with styling is a core part of our value proposition. We aren't trying to create a new 3D system or animation system, we are creating a new developer platform.

First, before anyone but Miguel reads this post, please read Miguel's comment on Longhorn changes.

I'll wait.

No, go read it first, this post will still be here after you are done.

Ok, now that we all have the same context, let's continue.

Security

I totally agree, this is a huge issue. Phishing attacks, spyware, malware, viruses, and more are out there and probably the largest problem facing computer science today. This isn't a Microsoft, Linux, or Java issue - this is a "good guys" issue. Windows XP SP2 is probably the best response to Miguel's security concerns. The integrated firewall, security center, and dozens of other security related features are really the first line of defense.

After the basics are resolved there, I would say that the new enhancements to the security system in Avalon are a great step. Not only is Avalon built from the ground up to be secure, but we are enhancing the security system for better application level security, and simpler more understandable presentation of security decisions to the user (hopefully in most cases this means no decision).

As to the specific issue of Phishng that Miguel brings up, that is still mostly a research level issue, which I'd love to see creative solutions to. In Windows today there is the secure desktop, but you must press Ctrl+Alt+Delete to get to it first.

Complexity

Ouch, I take this one to heart. As an architect on Avalon I find it to be my failing when someone says that it is too complex. To be honest, the specific issue that Miguel raises around the object hierarchy is something that I hoped most people wouldn't find to be a huge issue. I figured that most people would look at the features available on the class they were using (like Button), instead of digging into the object browser. The factoring (or over factoring) is our attempt to have a clean model.

From experience, I can think about WinForms. There we had a significantly large simple base class - Control. It implemented almost all the functionality common to the framework, but as such, it implemented properties that some controls outright ignored. Some folks claimed this made WinForms too complex because you couldn't know which properties would affect which controls.

I'm not claiming that Avalon has it right, the object model depth is something we continue to debate, but I will say that we did made a conscious descion to balance OM cleanliness with OM hierarchy.

As for the "fully cooked" argument... come on Miguel. You are looking at something that isn't even a beta product.

Ignoring Standards

Interestingly enough, we never "ignored" standards. We spent a huge amount of time understanding and evaluating the existing standards. SVG and CSS both were passed on because they weren't adaquate to meet our needs. WinFX is a platform for the next decade or longer - we can't start with a base that doesn't meet our needs.

Wesner posted about this a while ago... I posted about it also...

Canvas model

I'm pretty sure that Miguel is talking about "retained mode graphics" here, not our Canvas layout panel...

Avalon is actually more of a smart caching model for graphics. In fact we can run in fully immediate mode, where the visual provides the drawing instructions when needed. The big delta with Avalon is that the display is always buffered, primarily for compositing reasons (we use compositing instead of clipping like User32).

Lack of a GUI designer

This is spot on - I completely agree. Luckily this isn't the first that we've heard this issue, and I'm hoping that we have a great story when we release.

Final Thoughts

Miguel closes with some comments about the "death march" that may happen: "I realized that the Avalon folks now must do two products instead of one: they need to build an Avalon for Longhorn, and another Avalon that will run on XP. It seems that they just added a pile of work to a team that was not ready to release their software."

I'm not sure where Miguel got the idea that we would have a different source base for Longhorn and XP. The "pile of work" is there - shipping for multiple platforms is a lot harder than one - but this isn't an order of magnitude difference.

Miguel, thank you for a very well thought out post, with a lot of good feedback. I disagree with a lot of your points, but you have a lot of valid concerns. I'm particularly concerned/interested in more issues around complexity. As the title of my blog indicates, I believe strongly in simplicity. Every day I try to make Avalon simpler - in fact I really do have a review goal to make the beta of Avalon simpler than the PDC build.

For everyone else out there - keep the feedback coming. We are listening!

[updated: fixed a spelling error]

In all the conversations about what is possible on XP and isn't, one thing I've neglected to mention is the idea of WinFX on Longhorn.

Let's take something like Avalon, which will have some limitations on Windows XP. While we are still working out the details, there is a possibility that reliable hardware acceleration may not be possible on Windows XP due to the display driver model. For now, lets imagine that we can't hardware accelerate on XP. Longhorn will still contain the new Longhorn Display Driver Model. This means that WinFX applications running on Longhorn will run with hardware acceleration, even if it isn't possible on Windows XP.

When people worry over limitations that may be imposed on WinFX downlevel, it's important to note that those limitations may be significantly different (or removed altogether) on Longhorn.

Wait! Before you panic about application compatibility. The example above talks about Avalon, today there are already circumstances where software fallback or hardware acceleration will be used - we already ensure that these two modes will be completely compatible.

In the comments on Ryan's post, he asks:

"My next question, though... with all the talk, can you guys back up your decision to do the downlevel support."

Great question. Unfortunately I really can't answer, I mean realistically the decision was made far above my pay grade. I can talk about why I think we made the decision, but in the end this was a decision made by Jim Allchin, Steve Balmer, and Bill Gates. Seriously, they were involved in the final decision making process.

I believe that we made this decision primarily based on customer feedback. At the PDC and WinHEC we got consistent feedback from developers that they wanted Avalon downlevel. Of course, they also said they wanted Avalon to run on all platforms (including Altair), but we knew that they really just wanted Windows XP <G>! Seriously, feedback from developers was consistent - they wanted the developer platform to be available (in some form) on a broader range of operating systems.

As a stockholder, I have to ask the question - Why would you give away the developer platform?! As a stockholder I want MSFT to monetize every technology they can to increase revenue and drive shareholder value. Ah, but nothing is ever that simple.

Let me introduce a pet theory of mine - Developer value vs. Consumer value. Developer value drives developers to adopt some given platform for building their applications. These applications drive adoption by consumers for the value of the application - not the platform. Consumer value (of the platform) is driven by end user facing features. There are also IT administrator value, and tons of other value propositions, but for now lets talk about Dev and consumer.

Developers want the platforms they target to be available to the broadest set of consumers. Consumers want the platforms they use to run the boardest range of applications. Consumers also want the platforms they use to offer the richest experiences.

To me, having WinFX broadily available is all goodness for developers (whom I love). Having Longhorn focus on delivering amazing experiences is goodness for consumers (whom I also love).

Ah, Ryan doesn't like our decision to redist Avalon downlevel (probably the first person I've heard of who doesn't like it)...

He makes four points, from what I can see:

1. Xamlon provides Avalon's value on XP
2. The WinFX redist will be 100MB-200MB
3. Avalon on XP is going to have massive technical problems
4. Avalon on XP means big Avalon feature cuts

Let's tackle these one at a time...

Avalon and Xamlon

Xamlon, from what I can tell, seems to be a XML to C#/VB/etc compiler. It is mostly a clone of the XAML syntax, and supports binding to WinForms classes. My appologies if I don't understand it enough. An XML dialect for describing UI is only one aspect of Avalon. Avalon represents an entirely new display system, from a new font engine (including support for new OpenType features), animation engine (with hardware acceleration), control library (with composition), application model (including rich browser integration), and more.

Avalon's tenets are "Best of the Web, Best of Win32", while the declarative definition of UI is definetely one of the "Best of the Web" parts, it's ridiculous to boil down 3 years of work from 300+ people to this one feature.

WinFX redist size

I'm amazed that Ryan knows the size of our redist - I don't yet. We are still working out the plans here, but at the moment I can't comment on how big I think the redist will be. Having fear over the "possible" redist size seems like a bad way to make decisions.

Avalon on XP technical problems

I'm still fairly suprised at Ryan's "knowledge" of our internal state, he says "Obviously, the technical problems are going to be far and wide". Yes, there are going to be technical challenges to overcome (robust hardware acceleration on the XP driver model, for example) but claiming that these are "far and wide" is again, quite a bit premature. I've worked with most of the teams on Avalon and we are identifying any potential issues with running on XP. We've identified some, but overall we are solid.

Joe Beda has a great post about some of the limitations...

Avalon feature cuts

I'm not sure why Ryan thinks that going to XP means feature cuts. When shipping a product the number of platforms you support is mostly a testing issue, it means a large matrix for running your tests against. Yes, there is a lot more surface area for developers to manage, but the presence or absence of a platform doesn't relate 1:1 with features. From our product planning standpoint, the reality of a hard date for Longhorn is more important. Now that we have a solid date, we can get much more realistic about features. I'm not saying that we aren't going to change the feature set (somewhat), but rather that the primary motivation, generally, is the date rather than the platform list.

 

As for Ryan's claim that "I can’t speak for anyone else, and I doubt you will see any criticism from within Microsoft because it is a career limiting move, but I will say that I am very disappointed."... give me a break. When I disagree with MS policy/decisions I'll say it. In this case I believe this is exactly the right thing to do for developers, consumers, and Microsoft.

I'd happily help Benjamin out on his OSCOM 4 challenge... Just drop me a line!

Soma (you know, the VP that runs the developer tools division at Microsoft) sez "keep writing managed code on the .NET Framework today", and I can't agree more!

Joe expands on my simplistic answer to the "can Avalon run on XP" question:

"

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 encompass 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.

" [EightyPercent.net]

John Montgomery talks a bit about the behind the scenes of the recent announcement... I have to say that I completely agree with him. That Microsoft is still willing to a) try massive undertakings and b) willing to make major course corrections, is an indication to me that the company is still vibrant and strong. The great thing (to me) is that senior management has now cleared the runway for us development teams to execute...

While I thought that WinFX and Longhorn where much more than that, I really like Peter Torr's Hello World post to illustrate the trials and tribulation of shipping.

"In the end, Microsoft got what it wanted, but not in the way it wanted. They said that Longhorn was going to be a revolutionary operating system, and I believe that it will be. The architectural side will definitely improve, but the revolution will take place where it really belongs, in ensuring that computers are as easy to use, easy to manage, and resiliant to attack as possible. And that can only be good for everybody." [Robert McLaws]

Jeremy chimes in on the announcements...

Well, the news is out now, and everyone is starting to talk about it.

Personally, I am totally excited about this. For the past couple weeks we’ve been working out what this means for Avalon, and so far it is shaping up to look pretty good.

<highLevelStuff>
Longhorn in 2006, with a firm commitment from management, is a great thing. Getting more components of WinFX running on more platforms is a great thing. Indigo was already on this plan, and I’m happy to have Avalon on that plan also. We listened to developers, and they all resoundingly told us that more of WinFX needed to be downlevel, so we are doing it. WinFS was a big bet, and still is, the fact that it will be a bit later doesn’t lessen the importance or commitment to it.
</highLevelStuff>

But what does this really mean to Avalon?

Since that is the team I work on, it’s really the only thing that I feel informed enough about to talk about… Let me try to answer what I think will be the most common questions (for the official FAQ, check out WinFX on down-level):

1. How can Avalon run on XP, I thought you said it required Longhorn?
Probably the deepest dependency Avalon has on Longhorn is in the new display driver technology. The DX stack is largely designed for a single application to have absolute control over the video card at a time (think full screen gaming). To really do multiple 3D applications running simultaneously with a composited desktop, we needed to make the GPU a shared resource. In the new Longhorn Display Driver Model (LDDM) we were introducing technology for resource virtualization and scheduling support on the GPU. Without this, we have some tough problems to solve, not intractable problems, but tough. Realistically though, there will be some limitations to what we can do on XP – I just don’t have that complete list today.

2. What does this mean for developers?
Obviously the availability of Avalon for Windows XP and Windows Server 2003, in addition to Longhorn, will make it viable for a lot more developers to begin developing applications using Avalon. This is really a large part of our reason for wanting to move downlevel.

3. Is this why you haven’t been blogging for a while?
Partially, planning for this has been occupying a lot of my time… hopefully I can get back to blogging more regularly!

4. Does this announcement change your sump pump plans?
No. Unfortunately my sump pump doesn’t run Windows XP today, so this will not change my plans.

5. Will <insert your favorite feature /> be in the Windows XP version of Avalon?
I can’t say at this point. As with any product as we push towards the release date the feature set will change (new features from customer requests, features cut for one reason or another).

6. What does this mean for WinForms development?
I love WinForms. I worked on WinForms for years, and I still believe it is the best way to build smart client applications today. WinForms will continue to be the way to build smart client applications for the next several years, even after WinFX is released. WinForms is available on more platforms (Win9X, Win2K, etc.) and has a more mature control set and tools story. We are working hard on a great story for migration and interop between WinForms and Avalon.

7. I read in <insert news site /> that Avalon is cut, is that true?
No. We are absolutely committed to delivering Avalon, and from everything I’ve been told, heard, and am planning - we will ship it!

8. Will Avalon have a visual designer?
We are working on our tools plan, but I don’t have anything to announce today.

9. Does this change how your team is working?
Our team is generally excited by this plan, with change there is always some trepidation, but almost everyone is jazzed about being about to deliver more value to more customers. The team is probably going to shift their primary development platform to Windows XP for the next several months, but we will still have Longhorn as a primary test platform. This new plan gives us a lot of clarity about what we are delivering. Otherwise, not much else changes - our core mission of "best of the web, best of Windows" remains unchanged and our philosophy of unifying documents, ui, and media remains unchanged.

I can’t wait to get this stuff into developer’s hands. The fact that I can now ship this stuff to a large set of customers makes me super excited. This is exactly what developers have been asking us for, and now we are able to give it to them!

 

Daniel has started up his series of intro to Avalon 3D... which he called 3D for the Rest of Us. Of course, the first thing I want is the source to all his samples!

I have a confession to make... I'm not a 3D expert. I know the basics of 3D using Maya. I've dabbled with just enough math to know the names of some of the things I need to do 3D. But, I have another confession - I lust after 3D. I've always wanted to be the guy who could build cool 3D worlds. But alas, I haven't ever taken the time to get down and dirty with Direct3D. Now, of course, I have a job requirement to understand 3D.

Because of my lack of deep understanding, I went straight to the source and cornered Daniel in the hallways and asked what material I should start studying. He offer to give me a short tutorial on how to build 3D using Avalon, on the condition that he could post it to his blog. I had to accept.

Anyway, the first tutorial isn't posted yet, but keep an eye on Daniel's Blog...

Daniel Lehenbauer joins the fray... Daniel is a dev working on the Avalon 3D support...

I have good news and bad news...

The good news is that I found out today the real specs for the IBM T221, one of the super high density displays (204dpi)... IBM's display is 22.2 inches with a max resolution of 3840x2400... this thing is truely spectacular in person (there is one floating around the hallways in my building)... It can accept anywhere from 1 to 4 DVI inputs... very cool...

The bad news is that I also found out that I misquoted just about every one of the specs in my blinking lights article... Hopefully it will be relatively trivial to get MSDN to post an update...

Sorry for any confusion, and if anyone finds any other glaring technical issues please let me know!

So IanG and Jason Olson have run across the glorious Avalon UIContext.

There is some debate internally about if we should allow UIContext.Enter() at all. The problem is that your context may get pinned to a specific thread (for example, if you host an HWND or use COM). Once you have a pinned context you need to marshal the call to the right thread, you can't just call enter.

The question is then: Should we have an API that works depending on the state of the context but provides occasionally the simple pattern (UIContext.Enter()) or should we have one API that is always guaranteed to work but is harder to use (UIContext.Invoke/BeginInvoke)? 

Marc Clifton seems a bit frustrated that XAML isn't the end all be all serialization engine. XAML is a general purpose markup format, but in Longhorn there will be a new general purpose serialization engine.

XAML was designed to be a compromise markup format, that balanced the toolability and readability aspects of a markup. You can think of HTML as a markup that was squarely designed to be readable, but not very toolable. SOAP on the other hand is very toolable, but almost impossible to read. In the design of XAML we constantly walk the line between the two. XAML has support for inline code, customer parser extensions, and multiple representations of the same structure.

In Longhorn there will be a new serialization engine in WinFX. The goal of this new engine is to unify the scenarios addressed by the XmlSerializer, SoapFormatter, and BinaryFormatter.  This engine (residing in the existing System.Runtime.Serialization namespace) will allow serialization and deserialization of any CLR object graph (graph is a carefully chosen word here) to a variety of different formats (including XML and your own custom ones, if you wish).

Lets compare the two methods:

XAML

• Objects must conform to a specific contract (public properties, empty public constructor)
• Extensions done through interfaces on objects (in other words you must load CLR types to serialize or deserialize the format)
• Only supports object trees (no graph support)

System.Runtime.Serialization

• Any object regardless of shape can be serialized (properties, fields, events, private or public data)
  Extensions done through declarative metadata (DataContract attribute), which means you only need metadata or schema to parse
• Graph or tree structure

XAML is designed to be more of a mix between a document and a programming language (something like ASP.NET's markup) with a fixed grammar where as System.Serialization is designed to consume and produce arbitrary XML and CLR graphs.

My last meeting was down near the conference center so I'm hanging out in the back of the room for Steve Lasker's presentation. There are a lot of MVPs here. I hope that Don & I will be entertaining for the group... I think this group of folks have been in presentations all day, which makes for some tired MVPs... maybe we should serve beer in our presentation?

Wesner has been spending time with color, the good old color from WinForms. Interestingly enough, there are reasons for the odd behavior he describes...

When working on WinForms and ASP.NET we really wanted to unify some of the system types, and color was a pretty problematic one. The issue was that ASP.NET wanted to allow all the oddities of HTML (including the ability to use bogus or out of range values) for color, while WinForms wanted to allow all the oddities of User and GDI+ (including system colors that represent a logical color). The solution - lets to it all!

So the Color class was born.

We debated a lot internally if Color should be 64-bit scRGB or 32-bit RGB... in the end GDI+ (if i recall correctly) ended up punting on full 64-bit support for color, however we knew in the future they would want to move there. The internal data structure of color therefore uses a 64-bit value to store the color, but only ever utalizes the first 32-bits.

Next, to support the various ASP.NET round tripping issues, we needed to store the string name of the color.

Finally, we have a state bit to determine what is determining the color - basically is this a natural RGB, known color, or named color. Known colors are just the magic colors that are part of the web and win32 built in color set (Red, ControlText, etc.). We wanted to track the known colors both for dealing with the whacky Win32 system colors, and to preserve the knowledge that a color was specified as "red" not as 255,0,0.

That is what we have today - a big color class that can do a lot, but has a lot of idosyncricies...

In Avalon we are moving to a full 64-bit color engine (native scRGB support) with support for multiple color spaces (you can specify colors in CMYK, etc.). Our color object won't be shared by ASP.NET, so we don't have some of the name based stuff that we have to worry about, and right now our plan is not to support Win32 system colors - but rather to solve the same problem using our styling and resource system to have a more natural and evolvable system instead of the magic colors.

A couple points...

1. Why didn't Nikhil tell me he was doing something this cool?
2. Yes, Nikhil is the guy that wrote "Web Matrix" in his spare time
3. Nikhil is one of the few developers that I have met that is also a great graphi designer

Check out his very cool bexier spline designer...

Rory chimes in on some people saying that XAML should go... Of course, if I said something like "Just because you don't like the fact that Microsoft created a new markup language, you want to rip it out and replace it with something else. Did you stop for even a moment to consider what a monumental task that would be? Why don't you just ask for someone to repaint the Empire State Building? Or have it moved a block over? Or transported to Sweden?" people would just assume that I'm lazy and don't want to do the work...

Ryan is doing too many cool things to link to them one at a time... Just subscribe to his feed and check out the cool Longhorn (and Avalon!) stuff he is writing...

Tim comments on the London ISV event [via Scoble]... "I had wondered whether Microsoft might rewrite MSHTML in managed code, or else create a Longhorn web browser that converts HTML to Avalon rich text. Chris said no. He said that MSHTML is a complex body of code which does an extraordinary job of rendering even malformed HTML. Since the Internet works on the assumption that this kind of web page renders successfully, and since there are so many quirks and workarounds in MSHTML, Microsoft's developers did not dare to replace it. I hope I'm representing Chris's comments accurately. In essence, it suggests that IE will remain broadly as-is, well, for ever."

Of course, "for ever" is a mighty long time... but I can say for certain, MSHTML is a complex body of code, and as with User32, GDI, etc., we will think long and hard about the application compatibility bar before we start thinking about rewriting that code... But, as James Bond says, "Never say never"...

If you are intersted in where we are headed with XAML, you should really read Rob Relyea's blog... in one of his latest posts he outlines one of the debates we are currently having about how we want to expose complex properties (like Brush) in markup...

It's taken me a while to wrap my head around this whole service orientation thing, and this indigo thing, and... well, everything. Reading Dare's post about Objects and Messaging I can really see how people get this stuff confused. In ObjectiveC all method calls are really sending messages (in the implementation, I believe they really do send messages)... so, does that qualify as service orientation?

Well, remember the 4 pillars of service orientation:

1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not types
4. Policy based compatibility

None of these actually say that messaging is part of service orientation. Messaging is one technique to accomplish some of these goals, it isn't a fundamental tenet of service orientation.

"What excites me is the possibility that generics and other new CLR constructs as they come will also be integrated into the OS. I have not really seen any generic mechanism used at the API level in any operating system, since generics often were a compile-time feature, not a run-time feature as it is in .NET." [Wesner]

We are spending a lot of time these days debating generics in WinFX... generics will be in the CLS for Longhorn, so we are free to use them. Right now there is purely a process/engineering issue where we need to get all the various pieces together to make generics work (NGEN, C++, etc.)... obviously in the PDC build there wasn't a lot of generics, but hopefully in future releases you will see more generics in the APIs...

Martin has an interesting bliki entry on commands... we are trying to work through the design of Avalon commands internally... once we get something solid enough, I'll try to post some of the design docs...

Wesner has noticed that XAML can be used pretty broadly as a document format "If application developers start writing document-based applications that follow the Avalon model of deriving new classes from existing elements, or even simply reusing existing elements, and turning on some of Avalon's designer services, XAML could quickly become one of the most common file formats."

In fact, if you look at the container support in Longhorn (System.IO.CompoundFile, if I remember right) there is more than just XAML in here. With Longhorn we are doubling down on OLE compound files to have a good way to have complex documents with rich metadata.

Rory had an epiphany... Indigo is key. As Don says "No program is an island".

Rob Relyea (master of XAML) is back in force on his blog, and started with a great post about XAML compilation...

Windows and Office have often had an interesting leap frog-ing behavior, and Wesner points out that with Longhorn we are pushing the envelope in Windows...

Interestingly I think going forward we will see more innovation from application vendors - Longhorn will give developers so much more to build with that they can build much more distictive looking appliations.

For those of you that still want more... Here is the latest .NET Show, include Don and I in another reprise of the Lap...

Don & I have finished our presentation now... I did my 10 minute keynote demo (B) and then the first hour of the presentation was focused on the fundamentals (I did the talking, B-)... after lunch we did 2 hours to cover the three pillars of Longhorn (A)... overal, I guess I'd give myself a B+ rating then...

We talked with press for about 30 minutes after Bill's gig, then hung out with the delegates (attendees) for another hour or so - it was great fun. I've really enjoyed the UK gig, however I wish I had done a better job on the first hour of the talk (a B- is below what I'm willing to accept <G>)...

Anyway, tonight is the Blogger's dinner at Masala Zone - we tried to organize a pre-func at a local pub, but unfortunately we never choose a venue... looks like we will have a pretty good showing (40 comments at this point, something around 30+ people claiming they are going to show <G>)... Don's bet is we will hit around 20... still sounds like it will be a smashing good time!

As a side note - Megan (my wife) watched me present for the first time ever today. Very interesting. She's going to be at the blogger's dinner tonight also. An interesting experience to merge facets of your life like this <G>

I had a meeting at work today where I was asked to explain a bit about Avalons multiple trees, events, property system, resources, styles, etc... I didn't quite get to all of it, but I thought I'd share some of my explanation here...

Pre-reading... The Avalon rearchitecture Part 1, Part 2, and Part 3.

Trees

Avalon has One Tree, right? Well, that was what I claimed in a previous post... Of course, by now you should know that I firmly believe in the saying that "facts obscure the truth". From the view of the Avalon rearchitecture we did go down to one tree, however reality is never that clean.

Avalon as a "visual tree". That tree is a tree of objects that derive from MSAvalon.Windows.Media.Visual. Visual can be conceptually thought of as a rendering surface. In fact there are several types of visuals (2d rendering, 3d rendering, video, etc.). The base element class - MSAvalon.Windows.UiElement - derives from Visual also. Thus, the "visual tree" is a tree of visuals, some of which are also elements.

<LowLevelDetail BoredomFactor="High">
The "visual tree" is actually not really the display tree. The managed visual objects are compiled (converted, rendered, whatever you want to call it) into a "composition tree". This is built up of unmanaged "comp node" objects that are what we use for low level rendering and animation. It is these comp nodes that can animate and render at display refresh speed (yes, that means updating 60Hz+). No user code (or managed code) ever makes it to the composition tree - this is critical to maintain glitch free video and animation (not because of the GC or anything... the design of the composition tree could be an entire post...)... Communication between the composition tree and the visual tree is done through two one way message pipelines - one inbound, one outbound.
</LowLevelDetail>

Within this visual tree we needed to splice in things like a <Bold> or <Paragraph> - which can't be simply represented as a single visual (imagine a bold or paragraph that splits multiple pages). To facilitate this, we created a notion of the "logical tree" - that is a parent pointer (and children) that are not associated always with the visual hierarchy, but can have non-visual nodes in the tree.

Events

Events come in three flavors - preview events, bubbling events, and simple events.

Preview events (like PreviewKeyDown) travel down the tree from the root to the target element. Imagine if you press the key "A" inside of a textbox. The window at the root of the tree will first get the PreviewKeyDown event, followed by each element that is a parent of the textbox, until eventually the preview event makes it to the textbox.

Bubbling events (like KeyDown) travel from the target up to the root element. Again, imagine the textbox and your press "A". In this case the textbox gets the KeyDown event first, followed by each of the parents of the textbox, until eventually the event makes it all the way to the window.

Simple events (like TextChanged) only are raised on the target element. Almost all the property changed events are simple events (also called "Direct only" events).

Events are dealt with in two stages - build route, and invoke. Build route basically traces the path from the target element to the root of the tree. Then, during invoke, each element in the route is invoked with the event - either starting at the begining of the route or the end. The route will include elements from both the logical and visual tree - thus, you can handle the TextBox PreviewKeyDown event in the Bold element that is wrapped around it!

Properties

The Avalon property system - called the dependency property system - was originally designed as a way for our engineers to reuse code. We found that all of our properties wanted to share a great deal of features; inheritence, styling, change notification, attached storage, data binding, validation, etc. We didn't want to duplicate all the implementation of this for every property, so we had to find a way to make this work consistently across the platform. In addition, we didn't want the consumers of these components to have to learn a new concept, so we knew that we needed to leverage the existing CLR property system.

Dependency properties are defined with a token - the DependencyProperty - that uniquely identifies the property and lets the definer specify the various services that they want associated with that property. The definer then implements a CLR accessor for easy use. Thus, when you say "button1.Backgorund = Brushes.Red;" the dependency property system is actually invoked, and allowed to provide the implementation of that property.

This is a much more abreviated version of the discussion, but probably long enough to bore you all...

Jeff Bogdan is one of the other architects on Avalon... He and I signed up to write a column on MSDN, he got to publish the first article in the series... Hopefully Jeff will keep on me to make sure I don't let this die like the last series I told MSDN that I would do! :)

Michael Earls has stirred up a lot of responses to his plea for Microsoft bloggers to talk more about the here and now...

"Here's my point, enough with the "this Whidbey, Longhorn, XAML is so cool you should stop whatever it is you are doing and use it".  Small problem, we can't.  Please help us by remembering that we're still using the release bits, not the latest technology." -- Michael

Dare, Don, Harry, and Scoble have responded...

Michael responded to the responses...

"My plea was not so that the advanced developers of Microsoft would stop posting about new technologies, it was merely to get them to remember where we're coming from and take a few extra seconds to connect the "now" with the "next"." -- Michael

I think this clarifying point is a great one. I write my blog to talk about what I do all day, whether it is working on the house, driving at the race track, or building Longhorn. My goal in my blog is not to be a corporate mouthpiece, but rather just communicate with an entire ecosystem of people out there (of course, this could cause another round of blog-examination for me...)

Michael's comment is valid - connecting the here and now with the future is absolutely key. Not just for blogging about Microsoft and/or technology, but when talking about almost anything. One of the great skills of a presenter is to grab the audience, typically by describing the here and now, and how whatever they are talking about will move you from the here and now to a better future.

I worked on WinForms, .NET, and Visual Studio for years (well, my time in Visual Studio was mostly in the VJ++ team, which, well, anyway...) so I should spend more time talking about how WinForms, etc, contribute to the design of Longhorn... and how code and developers can migrate forward.

I don't intend to stop talking about Longhorn - it is what I work on every day (regardless of if I'm in the office! <G>) - it is part of my DNA at this point.

Interestingly CLauer thinks we develop Avalon on Windows XP... "My understanding is that the development teams that are working on WinFS, Avalon and Indigo are neccessary working on today's systems, Windows XP to name it. So, obviously, current pre-alpha builds of each of these three Longhron pilars have to run on Windows XP. I do not understand how it could be otherwise."

While the build lab does produce builds compiling on a shipping operating system (I actually don't know if they run Windows Server 2003 or Windows XP, but I think it is Win2K3?), developers run Longhorn.

If memory serves about 14 months ago it became a requirement that we dogfood Longhorn to use Avalon. For the first year or more of Avalon's existence Windows XP was the base we built on, however as we added more dependencies, and got more people using the bits, we could no longer support using WinXP as the dogfood environment, so we all upgraded to Longhorrn.

Of course, trying to develop a component and have your main dev machine be running a daily build of a pre-Beta operating system is quite a challenge. Some days you come in and upgrade to the daily build only to find that some core part of the OS decided to break that day. Of course, this is one of the ways we try to drive quality - by having the developers feel the pain if something is broken, generally it gets fixed very quickly. In addition even our VPs dogfood Longhorn, so you can imagine that occasionally there is a lot of pressure to fix something if their machines break!

The answer to the question is a little of both - we compile the new version of the operating system on both released Windows and Longhorn, but we only debug, test, and run (obviously) on Longhorn.

Sami did some DLL hacking and got Avalon running on Windows XP... I missed the post, but someone internally forwarded me that he was asking what I thought of this. I guess there are a couple points here:

Avalon is a Longhorn only feature.

One of the big new changes that isn't yet in the Longhorn builds is the new video driver model. Once that goes in, you really won't be able to run Avalon on XP. In addition when the desktop composition stuff gets turned on (it wasn't in the PDC handout build) there will be a tight dependency between Avalon and the Longhorn User32.

As with any single feature in an operating system, you can manage to get it running elsewhere. If you really wanted you could probably copy the Longhorn Kernel32 over to an XP machine, however eventually you will need to copy most of the OS over to XP to make all the features work.

Early on in the Avalon development we actually ran Avalon on XP all the time (there was no real "Longhorn" yet). For more than a year now Avalon was only running on Longhorn. Now that we are pushing towards Beta 1 the number of inter-dependencies between components are increasing.

In short, while you may have been able to get this working on the PDC build, this won't be possible in the future builds.

I guess my advice to Sami, I wouldn't bother publishing the steps needed for this. Not only is it a completely unsupported configuration, it is also something that won't work going forward.

Wes is lamenting the lack of a formal doc/view framework in Avalon... I can say that as of today we don't have plans (at least on the Avalon team) to produce a doc/view framework ala MFC (as with all statements about products these are subject to change at any time, especially with feedback <G>).

A couple key points that Wes makes:

"In MFC, we start with a full implementation of a document-based application that does nothing; all the infrastructure (opening, edit, printing, windowing, OLE, etc) is in place, and developing an application involves simply modifying the do-nothing application to do something. The best thing about this approach was that almost all the testing for the the infrastructure code came for free."

However, he continues, we took a step back in WinForms:

"In WinForms, we lost that, although there is a project underway called Genghis to restore the missing glue tying all the framework objects together into a document-based application."

Genghis creator Chris Sells (who is now a 'softie) often gives me grief for our decision not to do a doc/view framework.

At this point, it is all about resources. In Avalon we are rebuilding the core infrastructure for the presentation platform in Longhorn. We have a new driver model[1], graphics stack, control library, and application model. All of this with a unified approach allowing for integrated documents, ui, and media. This has been an amazing undertaking. Prior to PDC 2003 we had already spent over 2 years working on Avalon.

The issue is that we don't have enough time or resources to do everything, and right now the doc/view framework has fallen off of our plate (it was considered).

I've talked with people from the C++ team (that own MFC) and the .NET Client team (that own WinForms) to see if they have the resources to build a doc/view framework on top of Avalon. The nice thing about a doc/view framework (going the way that MFC did) is that it can be layered on top of a core framework. No news yet as to if they can or will do it, but we are listening to the feedback and trying to understand how we could tackle this.

"Other than the strange Objective C syntax, I found much to my liking in Cocoa. I was surprised to see support for name-value pairs, which look similar to Dependency Properties in Avalon. Cocoa does use the familiar MVC paradigm, with the standard NSController, NSApplication, NSDocument, NSWindow, NSControl objects. NSWindow, NSApplication and other "NSViews" derive from NSResponders, which implements the "Chain of Responsibility" design pattern. Even though, I have never seen Cocoa before, I know how it works because it follows the same pattern as every other framework. I know that Cocoa's NSResponder is the same as TCL's Bureaucrat, which is the same as MacApp's EventHandler."

I've spent a small amount of time programming in Objective C against Cocoa, and I also found it very elegant, but overly complex to do simple tasks. My personal believe is that MVC paradigms should always be layered on top of a simple object oriented component based framework. There is a large class of developers that don't understand MVC and you can never hide complexity completely.

"But my fear is that, while document-based applications based on Avalon may become more flashy, they will look more like web-pages and less like Office-style applications. I not getting the sense that Avalon is paying attention to the traditional document-editor application."

I disagree with your view here, but I totally understand the concern. Right now we are trying to crawl before we run. Avalon has a complete editing infrastructure with extensible mechanisms for adorners, backend stores, selection, etc. With a couple simple controls and properties you can create a editing surface for writing documents, media (animations, vector graphics, etc.), and ui (traditional forms). While we do lack the doc/view framework as an intrinsic, we are spending a lot of time trying to make sure that the platform provides the core services to allow for a great document editor...

[1] All WinXP drivers will continue to be supported, rather there is a new driver model that will be more robust, blah blah...

Don Park has an alternative to reusing the XML hierarchy for visual hierarchy for things like XAML...

 <XAML>
  <Window ID="root">
   <Window.Background>Blue</Window.Background>
 </Window>
  <Button ID="mybtn">Hello World</Button>
  <Insert object="btn" into="root"/>
  <Center object="btn" to="root"/>
  <Move object="btn" x="10" y="20"/>
 </XAML>

We are currently having a big debate internally around the usage of Uri and String in our APIs.

Use Uri not String

URI cannonicalization and escaping is very complex and people always get it wrong, so you must have a single codebase to do the work. Beyond that, converting from each form of a URI can introduce artifacts, so once you resolve (my shorthand for canon, escape, etc.) the URI you can really never go back to a string and try to resolve again (not precisely true, but basically). In Internet Explorer the resolving of URIs was a huge source of security issues, so we can't repeat that mistake in WinFS.

Offer both Uri and String

Using a single codebase for resolving URIs is great, just don't make developers suffer by having to create URIs everywhere. Developers think of URIs as strings, not complex objects.

The pattern should look like:

class MyComponent {
    void SetSomething(string uri);
    void SetSomething(Uri uri);
    Uri GetSomething();
}

The idea being that developers can call either version of the API. The implementation of SetSomething(string) would do nothing more than new up a Uri and call SetSomething(Uri).

Use Uri not String

The problem with the above pattern is that in a component based system you have people calling components through multiple layers. If internal MSFT develoepers (and third party component developers) start calling the string version, we get back into the "string -> uri -> string -> uri" world which introduces loss of data (hence security issues).

Offer both Uri and String

We should just have a rule that says once you convert a Uri to a string, never go back. Then developers on the leaf of a component hierarchy would do the conversion, and it would transfer back.

Use Uri not String

Ahh, that is a great view, however history has shown us that doesn't work. It isn't possible to guarantee that no one converts back to a string, and therefore we will ship a bunch of components with this.

... And the debate continues to rage...

As has been mentioned many times before, XAML is a generic programming model for working with CLI object trees. Don even wrote a console application in XAML. As part of our effort to really nail down the format and rules for XAML, we are doing some internal design reviews of XAML. Right now we have assembled Gudge, Don, Rob, and myself.

The four of us came up with a long list of our pet peeves and issues (for example, using a PI for the Mapping directive makes it impossible to embed XAML inside of a SOAP message).

Rob is the program manager owner of the XAML spec, and is looking for anyone out there that has strong opinions about some of these issues to make comments on his blog... What is missing from or broken about XAML?

We gave out bits at the PDC to ellicit feedback from people, Here is an opportunity to directly spout off to the owner of the specification of XAML!

Interesting... Drew Disects Avalon...

Joe dives into the details on the visual system in Avalon.

Markus has started blogging.. Markus is working as a program manager on the Avalon Performance team... yes, he has a lot of work ahead of him :)

Adam Ulrich commented on my last Avalon rearchecture post:

"Mustn't controls have some inherent _general_ knowledge of their visuals?

My example: a scrollbar must know that it has some logical element that relates to visual elements that equate to a thumb, and that it can move along logical element that relates to visual elements that define some path."

Someone once told me that facts obscure the truth (actually many people have told me that)... There are several (small number) of controls that must have deep knowledge of their visuals. The slider portion of the scrollbar needs to have knowledge of it's visuals, although the scrollbar doesn't. The scrollbar istelf is composed of a repeat button (line up), slider (which is the well and thumb), and another repeat button (line down). I don't think in the PDC builds it's quite this clean, but this 3 controls will be (hopefully! <G>) the way we build the scrollbar later this milestone.

Generally an element should have contracts with it's visuals with commands, databinding, attached properties, and named styles.

Commands are how the repeat button should bind to the LineUp/Down command on the scrollbar. Databinding allows you to bind the value of the scrollbar to the value of the slider nested within. Attached properties are used to allow the element to locate a child within - for example the ListBox looks for the ItemsControl.ContentOwner property on a child element, and that element becomes the parent for all the generated content from the list items. Named styles would be the way that you could replace sub sections of a control, this would typically only be used on more complex controls (like a data grid, or something of that ilk).

"Rich Everywhere" is a phrase I like to use to talk about Avalon. We want to enable every control to support any rich content, interaction, and presentation. Part of being rich is actually having a system that people can understand, tool, and build these great experiences on the platform.

In DOTNET the number of customization points brought about a big problem. You could customize the look of an element up to a certain point, but then you would have to completely change your programming model to use the presenter. Presenters couldn't be authored in XAML, and you weren't able to create elements dynamically inside of the presenter, so you ended up being limited to using low level drawing calls.

ECM

We had to solve the notion of "rich content". There is this tension between flexibility and programmability. For the VB developer, we want to enable something as simple as:

Dim b As New Button()
b.Text = "Hello World"

For a web developer we want to enable something as rich as:

<Button>
    <GridPanel><Video ... /><Text>Hello <Bold>World!</Bold></GridPanel>
</Button>

The problem was to do both with a single object model. We talked about having two buttons - a "simple" and a "rich" button. No. We talked about having multiple properties - "Text" and "Elements". No.

Then the idea came - borrow some pages from WinForms and ASP.NET, mix in some new twists, and viola!

ECM (I forget what the abreviation stood for originally...) was the idea to have a mechanism to take arbitrary CLR objects and convert them to UIElements. If the CLR object happened to be a UIElement, we were done. If it wasn't, then we could create a visualization for that data item using TypeConverters, ToString, or a data style. Basically that means that button now has a "Content" property, that is of type "System.Object". If you pass a string in, we stuff that string into a text element, and if you pass a GridPanel in, then we just display it.

Controls have 3 flavors - No content (Border, etc.), Singular Content (Button, etc.), Multiple Content (ListBox, etc.).

You can mix and match; a Menu has a header (Singular Content) and a list of menu items (Multiple Content) - so we have something called a "HeaderedItemsControl"...

Only use elements

When I talked about simplicity, I mentioned that we doubled down on element composition. Another side effect of this was to unify the programming model for all customization. You could now completely change the look of an element all declaratively in XAML.

Once we have this model, we now have a tenet that all controls must not have inherit knowledge of their visuals. This allows developers to completely change the look of any built in control without having to change the behavior at all.

Part of the original goals of Avalon was to leverage the power of the GPU. The idea of hardware accelerated 2D graphics has been around for a long time, but it hadn't really taken off yet (remember, we started Avalon in early 2001 [fixed date]). Today it seems pretty obvious that leveraging the GPU for 2D is the right path, but at the time that we started there was a lot of concern about the type of hardware that we would require.

One hugely controversial decision that we made early on was to write Avalon in managed code. From a platform component, the CLR is still immature. It's getting better by leaps and bounds. The work to integrate the CLR into Yukon, moving the entire system to 64-bit, and the work in .NET 1.1, and Whidbey have made the system amazing. Again, when we started .NET was just first released in beta. Also, the development teams working on Avalon are used to the C and C++ toolset that they had been working with for the past twenty years. The decision to move to managed code was a fun process, but that I'll leave for another day.

The DOTNET tree was not measuring up to performance goals. The startup time was slow, but more troubling was that the scalability of the system - the number of elements that we could create and manipulate was just too small. To acheive our goals around richness we would need a system that could scale to tens of thousands of elements, and we were only a couple thousand elements displayed in a reasonable performance. Layout was slow, working set was huge, it was a bit scary.

Before we began the rearchitecture we spent a bunch of time focusing the entire team on performance. We started doing deep analysis and looking at how the system hung together. We created two virtual teams to try and drive the performance effort - a bottoms up team that was focusing on tuning components and code, and a top down team that was looking at the design of the system to see what we could do architecturally to make the system faster. When we started the rearchitecture effort we took the data from the bottoms up and top down team as baseline data.

We had several simplifications that we hoped would contribute to better performance:

• One tree
• Simplified property engine
• CPS/DPS

One tree

By unifying the tree, we felt that for UI scenarios we would see a huge performance benefit. Specifically you would only have a single node for a element (like a Rectangle) where as before you might have up to 3 objects. Also, the connections between the elements would be much more simplified, there was no need for back pointers from the visual tree to the element tree to managed input, etc.

Simplified property engine

The original property engine from DOTNET was designed to support a very complex expression evaluation system, track dependencies, deal with complex CSS-style rules, etc. Part of the rearchitecture was the decision to cut several of these features to make the property system much simpler, and therefore (hopefully) faster.

CPS/DPS

The DOTNET layout engine, using presenters, was a single monolithic system. That system handled everything from a single absolute X,Y layout up to a complex paginated table. The issue was that for all the simple UI scenarios we were doing a ton of work for relatively no value. The solution was to create the "Control Presenter System" that would handle basic UI layout, and a more advanced "Document Presenter System" that would deal with the rich pagination and typographic layout.

By the time we finished the design for all of this we had actually completely removed the concept of presenters from the system, but the name CPS/DPS stuck for the architectural design. Funny how those things happen.

As we rolled out the architecture proposal the performance aspects of the proposal were probably the most controversial. No prototype can accurately represent how a system will behave in the "wild", and our performance team had previously heard promises of large changes helping performance. Unfortunately we were never able to get a 100% accurate measurement of the perf gains, but we had to make a decision. As with a lot of decisions, you never have all the information that you would like to have.

During the implementation and conversion to the new architecture we hit several perf snags. We didn't get any huge working set improvements (we are still working on this today), however we did achieve our scalability. The system (in our tests, no warrenties implied, etc.) scales linearly as you add more elements. The largest I've done is a couple hundred thousand elements... it was really slow, but it didn't crash.

Best performance bug: I forget the root cause, but when you ran a specific test the working set of the app would hit around 1.2GB (yes, gigabyte!) before the app would die.

We have made a couple other changes to the system since the big rearchitecture - the new styling system is one example - and we continue to try and make the system faster. The PDC bits are clearly way below what we want for performance.

The Avalon rearchitecture that happened earlier this year was motivated by several things (in my mind... hmm... another time for a disclaimer - as with anything that happens each participant will have a slightly different version of the "truth". As time goes their becomes more and more difference between each persons view. So, all that follows here is my fuzzy recollection of what happened, and shouldn't be missinterpreted to be the only "truth" of what happened...)...

• Simplicity
• Performance
• Flexibility

Before I start, I need to tell you about a few new names - DOTNET and WCP. Our old architecture bits lived in a source tree where the root name was "DOTNET". I wasn't on the team when this name was choosen, but I'm guessing that it was picked because the Avalon team was an early adopter of managed code, and so they named the directory after .NET. When we began work on the new architecture we picked a new directory name, "WCP". When I refer to WCP and DOTNET design, these are nothing more than the names of two directories in our build tree - these aren't product names, no warrenties apply, blah blah...

Simplicity

The DOTNET model had some pretty severe problems with complexity of the design. Their tended to be 7 ways to do anything, and many of them tended to be massively complex. The reason for this was pretty simple - we had 400 people working on the product and all of them were trying to build the "best" of whatever they were working on. The best example that I have is how to customize the appearance of your control... we had templating, presenters, element composition, visuals, etc... I can't remember the complete list, but at one point there were actually 7 full featured ways to customize this.

Probably the most maligned peice of technology in DOTNET was this thing called "Presenters". Presenters were a very well thought out, robust, and complete technology. Basically it was an abstraction over layout and rendering, which allowed for any control to have any display. Presenters allowed for pluggable rendering, pagination, virtualization, etc. They allowed for a clean separation between the visual tree and the element tree.

Ah, which reminds me - we had a lot of trees at the time. There was the element tree which was where your buttons and listboxes lived, and the visual tree which was the retained mode managed scene graph, the presenter tree which was a "kinda" tree that was made up of the presenters and their relationships  to their child presenters (basically an element may or may not have an element. For example, text formatting elements like "Bold" didn't have a presenter, they used their parent presenter), and we had a composition tree, etc.

Presenters where this great thing, however they were very complex to use, and they had a fairly different design center and programming model than the rest of the system.

Our solution to simplify a lot of this in WCP was to make a couple big bets - Element composition and a unified tree.

Where in DOTNET we had a separate tree for elements, visuals, and presenters - in WCP we have a single tree of nodes. For various reasons we have multiple "views" on the tree - Logical and Visual - they actually share nodes. Some people find this 1.5 tree system to also be confusing and we are still looking at ways to simplify this.

Element composition was the biggest bet by far. We are now using elements for all display composition. When you see a button in the PDC build, there are actually 17 elements inside of that button. Rectangles, Borders, DockPanels, Text, etc. Using a single feature for all rendering allowed us to remove some of the duplicate ways of customizing the display of the elements. In addition, we settled on a single styling system that included the ability to style the "visual tree" of any element.

To be continued...

The early votes are in, and it looks like people want to hear about anything besides my sump pump...

What is the deal with the MSAvalon namespace? To start, this namespace will (obviously) change. Generally we are never allowed to ship any product with any cool codename or team name in the product, so we picked this name intentionally to make it easy to remove later. Most likely MSAvalon will be renamed to "System" - the idea being that the classes that constitute "Avalon" will be in the System.Windows namespace. If you got one of the PDC namespace posters, you will notice that we actually used System.Windows on that poster.

Why did we use a namespace that is easy to replace? Because we ran out of time.

Depending on who you read and talk to, you may have heard some of the story of the Avalon team. I'm not talking about the Avalon umbrella term that we used at the PDC, but rather the group of people that work directly on the team inside of Microsoft called "Avalon". At the PDC we rolled up a bunch of teams under the term "Avalon" as a way of talking about all the great client presentation technology that a lot of teams are working on. A large portion of this work is being done directly on the Avalon team, however we have determined long ago that 99% of the populate really could care less about the organizational structure of Microsoft, so we decided to reuse the name. Fun, right?

Avalon the team was formed almost 3 years ago. It was formed by merging almost 400 people from various teams working on client presentation technologies - some people from Internet Explorer, some people from User32, GDI32, DirectX, WinForms, etc, etc, etc... a lot of people with a wide variety of opinions. As the team gelled and worked on the vision of a unified presentation platform for UI, Documents, and Media they did a lot of experiments and writing of core fundamental code.

About 2 years ago, the Avalon team really started cooking. They had a shared vision and were working hard on producing the large body of code to replace User32, GDI, etc... They began to get some internal customers (a few) and start to actually look at the developer expierence and really think about what people could do with all this great technology.

About a year ago, we really noticed some fundamental problems in the design of some of the components. We made a super hard decision to step back and do a rearchitecture of some major portions of the system. We revisited the tree model that we had, the way controls fit together, our styling system, binding, and more. The end result was a new architecture that was a more holistic view of the entirity of Avalon.

Even with the PDC on the horizon, we made a tough call to begin coding on the rearchitecture, with the goal being feature complete on the new design for the PDC. A lot of people, from a lot of teams, put in a tremendous amount of effort to get this work done in time. However, there were still components that were built on the old architecture of Avalon, and we couldn't break them with only a few months left before PDC. We decided to make the old architecture and new architecture Avalon bits run side by side - and hence we needed a namespace for the new bits. MSAvalon was born.

Once we get the last of the internal customers that depend on the old architecture bits moved over to the new architecture, we will retire the old namespace and eventually remove the DLLs from the build. After that, we can do the monster namespace change to move to the new namepsace.

It was really interesting some of the discussions that we had around this change. There were really two camps inside of the team - one said that we should ship the old architecture bits as they were more mature and had more features. The other camp said that we should push as hard as we can to give the developers at the PDC a preview of the design that we were moving forward with. There wasn't a perfect answer - the old design would show more of the intent of what we wanted to accomplish, but the new design would show more of our developer API.

In the end we decided to push forward with the new design - getting feedback from developers about our new model was determined to be the top priority. We need to hear if the explicit styling mechanism, element composition, data binding, logical tree split, etc, are usable and in the right direction.

There was amazing effort put forth by so many people to make this happen it was mind boggling. Taking a team of 400 people, and an even larger group of internal customers and partners, and making a radical design change 8 months before a public release was an amazing risk... I really hope you all feel that it was the right decision...

I still owe a code sample about using DependencyObject from a previous post (I will write that!), however I'm curious what would interest the couple people out there that read this... besides my boring opinions about the universe, and my adventures with aquatics, what do you want to read about?

1. Design issues that we are tackling for the next release of Windows (Beta 1?)?
2. History of the PDC bits (how we formed Avalon, etc.)?
3. How to code with the PDC bits?
4. Some other topic?

I'm happy to do a combination of all of the above, or skip them all... what do you care about... I just don't want to becoming boring... that would just be sad.

Rob gives the scoop on why XAML is XML...

Sam asks "the ability to modify the rendering and content of the document on the fly?  Isn't that lost by a compile to bytecode approach?"...

Sorry for the delay in responding, Sam's post has been sitting in my inbox while I found a couple minutes to respond... There are lots of comments on Sam's post directly that respond to this, but I thought a more detailed answer might prove interesting for everyone...

First, as people pointed out there is a difference between XAML (the programming model) and Avalon (the presentation system).

Using XAML, you can invoke the parser at anytime:

DockPanel d  = (DockPanel)Parser.LoadXML("<DockPanel xmlns=\"http://schemas.microsoft.com/2003/xaml\"><Button DockPanel.Dock=\"Fill\">Hello</Button></DockPanel>");

(Appologies if the code doesn't compile, i'm not sitting in front of a Longhorn machine right now)

However - that XAML can't contain any def:Code fragments, because at this time we don't do dynamic compilation on the client during parsing.

In addition to dynamic execution of the compiler, you can also programmatically create elements:

DockPanel panel = new DockPanel();
Button b = new Button();
panel.SetDock(b, Dock.Fill);
b.Content = "Hello";
panel.Children.Add(b);

Of course, you can also set events:

b.Click += new ClickEventHandler(MyHandler);

In fact, the parser is really just doing a bunch of "new DockPanel" and "new Button" calls when it parses the XAML. XAML is just another view on code... You can do everything in code that you can do in XAML - and you can do it dynamically with a strongly typed simple programming model.

Don has a secret... He knows how to make XAML work for any object... I guess it's not a secret anymore.

Rob is a PM on the Avalon team. He owns the XAML spec. He also is a member of the Avalon architecture team (with me and a few other folks).

Rob has a blog.

See rob blog.

Blog Rob, Blog.

Rob's first task, to do some postings that cover some of the Avalon overview presentations that he has done in the past.

Hillel Cooperman, of Aero fame, now has a blog... with RSS (now <G>)!

Erik Arvidsson asked in a comment: "What was the reasoning for not making the UI elements extend XmlElement? Since XAML is supposed to be an XML language it would seem obvious that one should be able to use the W3C DOM."

Yet another often discussed issue internally. To start, lets consider the following markup:

<Window ...>
    <Window.Resources>
        <SolidColorBrush def:Name="MyBackground" Color="Red" />
    </Window.Resources>
    <Button Background="{MyBackground}">
        <myobj:Customer Name="Chris Anderson" />
    </Button>
</Window>

In the fabulous XML DOM I would get, of course, a bunch of nodes. The root node would be the "Window" tag, and would have children "Window.Resources" and "Button". Of course, we have already gone astray.

In XAML we recognized that properties (which can be attributes) often contain complex values (for example, the Resources property on the Window in the above example is actually a type of map/dictionary). However, sometimes they can contain simple values (like Color="Red" on the brush). Thus, you can end up with any attribute in XAML also being a compound property, which makes it a nested tag. Thus, these two are syntatically equivalent:

<Button Background="Red" />
<Button><Button.Background>Red</Button.Background></Button>

Which makes it problematic to use the XML DOM out of the box. In addition, lets flashback to that first example above - the SolidColorBrush is not actually a UIElement. While the Button and Window are both UIElements, the SolidColorBrush is just a CLR object. It would not appear in your element tree, and asking the Window or Button for it's visual children would never produce the brush. Second problem.

Finally, check out the "myobj:Customer", this is an example of a random business object (maybe a WinFS thing? maybe just something I invented) that I wanted to create in the markup. Since XAML is programming model for targeting arbitrary CLR objects, there is no requirement about the OM that these objects must implement to be serialized into the XAML (well, there are a few, but they are simple things).

Given these three things, we felt it would actually be confusing for developers if we implemented the XmlElement OM. The XmlElement OM is about traversing an XML document - the Avalon element tree can be persisted into an XML document, but it can also be generated from C#, your custom markup, or any other format that you dream up. In addition, using .NET 1.x you can serialize any .NET object into XML also - so that would argue that everything should derive from XmlElement (yes, I know that some people would applaud this! <G>).

Remember - XAML is just one of the programming models for targeting the Avlaon presentation classes.