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?

Not sure I really agree with Scoble here. I talk with the WinForms and Avalon folks a lot on a regular basis, and I think trying to pick a date in the future like "2012" or "2014" is a Bad Thing.

I spent many years working on WinForms and I love that technology dearly. I know almost all of the current development team on WinForms. I talk with them all the time, and I try to have a good grasp on their plans for the future.

I have been working on or with Avalon for a couple years now. I think I have a relatively good handle on what we are producing and how this maps to the WinForms technology.

The idea that people should adopt WinForms because Avalon is 8 years out is just ridiculous. People should adopt WinForms because it is a great development platform for creating smart client applications. People should adopt WinForms because it puts them in a great position for transitioning to Avalon when they choose to.

I think that customers should move to managed code because of all the things that Scoble mentions - it is our future platform, where we are investing in going forward, and the best platform for writing applications (productivity, power, etc.).

Developers know when they are ready to adopt new technologies based upon *their* customer's feedback. For some developers they will have customers that want Longhorn exploitive apps on day 1. For other developers they will have to wait. There are still people writing code (lots of it!) for mainframes, Win98, and OS/2.

Ian correctly points out that Avalon is more than just eye candy [link fixed]. I'm glad he made this point - all the flash in Avalon is really about providing easier ways to have computers interact with people (both on the input and output side).

One point that I have to disagree with, is this unnatural belief that everyone seems to have that it's not code if it has angle brackets. I hear people say this about XAML, HTML, XSL/T, and more. Just because it's markup doesn't mean it isn't code. Pure HTML + CSS, that I would classify as much more "document" than code... XAML and XSL/T, those are both pretty clearly in the code space. What is the line between Perl, C#, XAML, XSL/T, etc?

The key aspect isn't about if the language is declarative, imperitive, a mix, or what... the key aspect is the abstraction layer that you program to, and the number of constructs that you have to understand to intepret the code. XAML is a declarative abstract language with a very few number of constructs... all making it simple to understand (hopefully).

The declarative thing is nice (especially for tools), and I think it is a key aspect. But declarative isn't some magic powder... i look at looping constructs in XSL/T and I get truly scared... it is often better to have a combination of declarative and imperitive code that try to go with a "pure" declarative model.

Jon posts hist own comparison of MXML and XAML, to which Rob responds...

The CSS debate was a huge one internally, and in the end I think you will find visual triggers, timelines, and visual trees to be a powerful way to change the appearance of controls... One of my big issues with CSS is that it really only works for "already known" customization points. With VisualTrees you can specify arbitrary new appearance using vectors, images, video, text, etc.

In my previous post I don't think I was clear about the methodology that Avalon uses to hack (err, customize) the XAML parsing. This caused Pete Cole to observe:

"That a hack is 'by design' doesn't make it any less of an inelegant, unsatisfactory hack. This does explain some of the bizarre syntax I have previously complained about. One wonders if the implementation of XAML is becoming like writing Word Processors - you end up putting in kludges/hacks in the code to cope with particular strange cases. That's OK a) the hack works and b) its invisible to the 'user' (they just see the programming formatting correctly as they expect) - hacking implementation of a 'programming' language ain't going to work." [Pete Cole]

The interesting to note, it is actually the Style object that implements the custom parsing and serialization of markup to support the "as use" syntax. This interface is documented and discoverable (both by tools and developers). In addition any component can implement the interface and customize their parsing.

Hack, maybe. Invisible, no.

Marku (over at Codito ergo sum) has figure out that XAML is really a thinly disguised build engine... heh heh... Seriously though, it is a good observation that XAML is really just a way to persist a set of CLR objects (of course, a specific set of objects with a specific gramar... not to be confused with a general purpose serialization engine... )

From Chris Sells...

"Marc Clifton, author of the MyXaml open source project, publishes a series of articles exploring opportunities for improvement for the Avalon architects to consider:

• Is Microsoft Bollixing Up XAML?--a look at "tag names are class names"
• Is Microsoft Bollixing Up XAML? -- The joys of VisualTree
• Is Microsoft Bollixing Up XAML? -- The case of the missing collection
• Is Microsoft Bollixing Up XAML? -- Decorating the house of cards"

I hate to defend stuff, generally I like the debate more than one sided... hopefully Marc will hear some of my responses and respond...

First, generally about style. Yep, Marc, you are right Style is messed up. Before we dive into the tag names are class names issues, lets address "Set"... right now it looks like we are fixing that one in a future release (I say looks like because of the standard caveats, etc... current plans always subject to change and still looking for feedback from customers, blah blah...).

The tag name issue - which for style we call "As Use" syntax - was a concious decision where Avalon broke the XAML rules.

Yes, as we have said many times, XAML is broader than Avalon. Don Box and I have shown XAML being used for console apps and more. In this case, Avalon decided that the markup model for style, strictly following the XAML rules, would have been horrible.

The problem starts with cloning. Since styles are effectively defining templates that need to be applied to multiple elements, you have the issue of defining what things need to be copied, and what can be assigned. In early builds of Avalon we used an implicit cloning model. We would create an instance of the element tree and then clone the tree, using several models for accomplishing this. It turned out not to work very well.

As part of the Avalon rearchitecture last year we moved to an explicit cloning model - enter FrameworkElementFactory. The element factor was an explicit object that would create new instances of another class and apply that style to it. Hence we could now create elements in a reasonable fashion. Of course, the markup ended up looking horrible:

<Style>
    <Style.VisualTree>
        <FrameworkElementFactory Type="DockPanel" ... />

So we came up with an alternative - what if Style had special parsing logic (by implementing an interface) and would basically switch the parser over from generating elements, to generating factories. Ah... now from an imperitive code model, we had explicit cloning, but from a markup model we had code you could understand. We then applied the same hack (uhm, i mean design) to the element explar - which gave us "<Button Background='Red' />"

I agree completely that the style tag breaks a bunch of XAML rules, and this was by design. The correct way to parse XAML is to instantiate the appropriate CLR types and inspect them for the various interfaces (IAddChild, IParseContent [or was it IParseLiteralContent?])... XAML is a way of binding XML to CLR objects.

And for the last bit - the magic missing collections... here is a continued debate on the Avalon team. Having a collection specified for every tag is a pain, so we introduced IAddChild as a way for a specific object to control the parsing of child elements and text. If we are using this interface too much, we should fix it - however the interface (and capability) is needed to support the final leaf nodes of the tree - eventually someone has to consume the text nodes in the XML document ;-)

Anyway, some of the issues that Marc brought up we are actively addressing, some we think are there by design... regardless, lets keep the conversation going and keep the feedback coming... we are listening!

My latest article seems to have appeared up on MSDN... The Blinking Lights Division is this month's (or bi-month's) column in Inside Avalon...

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, e