My 20 Minute Experience with WinFX

The May CTP of WinFX is out (along with Beta 2’s of Vista and Office). This release should be functionally equivalent to the released product and therefore deserves some sort of play time and review. However, since I happen to be knee deep in another project, I could afford only 20 minutes.

First, a disclaimer. In my previous life I spent a year working on Avalon (WinFX’s real name) and have a pretty close relationship with it. Actually I spent most of my time playing with the imaging aspect of it. My contributions were all in the .NET namespace System.Windows.Media.Imaging and in the native COM DLL WindowsCodecs.dll. The code for the .NET imaging components is hosted in the managed DLL called PresentationCore.dll (along with everything else in the kitchen). However, that code isn’t at all interesting because it is just a thin wrapper over the real imaging code of WindowsCodecs.dll. While WindowsCodecs annoyingly does not include its own COM typelib, you can get a flavor for it by looking at the static classes under MS.Win32.PresentationCore that start with the letters “WIC”. Anyway, I’m pretty proud of that code even though my small contributions lay purely in its design and test. In WindowsCodecs.dll, you will find some of the most robust and easy to use imaging code available anywhere. Well, that’s how I feel about it anyway.

So what about the rest of WinFX Runtime Components? Well, it has a lot of rough edges.

Let’s start with the installation. All-in-all you’re talking about a 24 MB download (2 MB for the installation app which then downloads 22 MB for the actual product). That’s pretty steep considering you also need to install version 2.0 of the .NET framework if it’s not already there. That means you have 46 MB of downloading to do before you can witness your first WinFX application from a clean XP SP2 install. Oh well, we all have broadband connections now right? Also, this is a non-issue if you are running Vista.

Once the beast is installed things get boring from there since MS doesn’t ship any demos with it. This makes sense given that this is “just” a set of programming libraries and they need to keep the installation size down (if you consider 22 MB “down”). However, that doesn’t change the fact that it’s pretty boring.

If you want to see something interesting go on over to the Petzold Book Blog and his WinFX book site. There you will find a great tool called “XAML Cruncher”. XAML is the XML-based declarative language for describing application user interfaces. This is a simple text editor that gives a live preview of the UI that results from whatever XAML you enter. Think of it as the Read-Eval-Print-Loop (REPL) of WinFX.

XAML Cruncher uses WinFX’s new deployment system for applications. This deployment system attempts to give WinFX applications a standardized and safe method of installation. There are just two major problems with it.

First, it does not work with Firefox (at least, for version 1.5.0.3 and as the application is hosted by Mr. Petzold). I hope that this is a bug that will get fixed in the release, but it is pretty disheartening to see such malaise on the part of the programmers towards a user’s right to choose their own programs. What does the web browser have to do with downloading a someone’s application? NOTHING! And yet it makes or breaks the experience. I am an application developer. If I have the choice between a deployment system that can only reach 50% of my customers and another that reaches 100%, which should I choose? The answer’s obvious, and that is why this bug should be priority #1 for the Microsoft WinFX deployment developers.

Second, and this is just as important, the error reporting features suck. When the installation fails for whatever reason (perhaps because you are using Firefox?) the installation box simply gives a glib and misleading error message. For instance, when using Firefox, the error:

“Cannot Start Application: Cannot download the application. The application is missing required files. Contact the application vendor for assistance.”

So not only is a deployment bug not identified, but the vendor is blamed. Great! Sometimes you have to wonder what the Product Managers are thinking. As a smaller point, they also break the standard Windows message box functionality of allowing the user to copy the box’s text by hitting Ctrl+C.

When one clicks on the Details button, they are then greeted by a whole lot of programmer info. Woe to any non-programmer who has to read that mess to figure out what is going wrong.

OK, enough whining about the deployment app. Let’s move onto WinFX proper. When you get XAMLCruncher working, you will be greeted with some minimal XAML and a huge button. The huge button is actually the result of the XAML.

XAML is a very very very very verbose declarative language. When it was first being designed, it was supposed to be human readable and writable (like HTML). However, Microsoft has long since abandoned that goal. There are tools to generate XAML, but, just as in HTML, it is best to get familiar with the underlying language before giving up and using a tool. Some, like Mr. Petzold, think of the use of the tool as a crutch. His thoughts in Does Visual Studio Rot the Mind? are very fun reading.

I have a few issues with declarative languages, and one such issue was immediately brought up when I played with the first XAML file I grabbed from Mr. Petzold’s site: UnicycleMan.xaml. After loading the file, the little guy on the cycle was making his way around the curve just as expected and declared in the XAML. There is a problem though. On my system (AthlonFX 64 X2, Radeon X800GT) the guy is constantly followed by his ghost: a flickering afterimage of his state about 1 second previous.

Yes, this is a beta version of WinFX and bugs are to be expected. The problem lies here: WinFX will not be shipped bug free. That’s just a standard problem with large pieces of software developed by large groups of people. Let’s say that one of the bugs that makes its way into the final product is just as obvious and easy to replicate as this “ghost” bug. What is the application developer to do then? His code is perfect! It declares that a little guy should go around the curve. Know where does it declare that there should be a flickering ghost following him. The developer is then faced with three options: (1) Wait for MS to fix it, (2) Figure out a work around, (3) Stop using WinFX.

No rational company would delay the deployment of their own app on the hopes that another company will fix their bugs. It makes no business sense. So option 1 is out the door. What about 2? Workarounds are as familiar to developers as clipping shears are to a gardener. The problem with these workarounds in XAML however is that we have no experience debugging declarative languages. Where is the flicker bug? Is it in the matrix animation code? Is it in the video driver? Who knows! We have no debugger to help us. The best one can do is guess and check: try changing some XAML and see if that fixes it, if not, change something else. This is a horrible way to program.

And what about the third option? We could always go back to Win32, but for some reason not everyone likes to spend years implementing and debugging their own graphics engines. I don’t know why not, they just don’t!

So where is the programmer left? Well, between a rock and a hard place. That is why developing WinFX applications (and ASP.NET applications too) is sometimes so frustrating: everything works beautifully until it doesn’t. When you get to that point, you’re pretty much on your own.

That’s the thought that I last had when concluding my 20 minute experience with the May CTP of WinFX. And that’s the thought I’ll leave you with.