Microsoft still paying the price for botched Vista with muddled development strategy

Professional Developers Conference 2003. Windows Longhorn is revealed, with three “pillars”:

  • Avalon, later named Windows Presentation Foundation (WPF)
  • Indigo, later named Windows Communication Foundation (WCF)
  • WinFS, the relational file system that was later abandoned

With the benefit of hindsight, Microsoft got many things right with the vision it set out at PDC 2003. The company saw that a revolution in user interface technology was under way, driven by the powerful graphics capabilities of modern hardware, and that the old Win32 graphics API would have to be replaced, much as Windows itself replaced DOS and the command-line. XAML and WPF was its answer, bringing together .NET, DirectX, vector graphics, XML and declarative programming to form a new, rich, presentation framework that was both designer-friendly and programmer-friendly.

Microsoft also had plans to take a cut-down version of WPF cross-platform as a browser plugin. WPF/Everywhere, which became Silverlight, was to take WPF to the Mac and to mobile devices.

I still recall the early demos of Avalon, which greatly impressed me: beautiful, rich designs which made traditional Windows applications look dated.

Unfortunately Microsoft largely failed to execute its vision. The preview of Longhorn handed out at PDC, which used Avalon for its GUI, was desperately slow.

Fast forward to April 2005, and Windows geek Paul Thurrott reports on Longhorn progress:

I’m reflecting a bit on Longhorn 5048. My thoughts are not positive, not positive at all. This is a painful build to have to deal with after a year of waiting, a step back in some ways. I hope Microsoft has surprises up their sleeves. This has the makings of a train wreck.

Thurrott was right. But why did Longhorn go backwards? Well, at some point – and I am not sure of the date, but I think sometime in 2004 – Microsoft decided that the .NET API for Longhorn was not working, performance was too bad, defects too many. The Windows build was rebased on the code for Server 2003 and most of .NET was removed, as documented by Richard Grimes.

Vista as we now know was not a success for Microsoft, though it was by no means all bad and laid the foundation for the well-received Windows 7. My point though is how this impacted Microsoft’s strategy for the client API. WPF was shipped in Longhorn, and also back-ported to Windows XP, but it was there as a runtime for custom applications, not as part of the core operating system.

One way of seeing this is that when Longhorn ran into the ground and had to be reset, the Windows team within Microsoft vowed never again to depend on .NET. While I do not know if this is correct, as a model it makes sense of what has subsequently happened with Silverlight, IE and HTML5, and Windows Phone:

  • Windows team talks up IE9 at PDC 2010 and does not mention Silverlight
  • Microsoft refuses to deliver a tablet version of Windows Phone OS with its .NET application API, favouring some future version of full Windows instead

Note that in 2008 Microsoft advertised for a job vacancy including this in the description:

We will be determining the new Windows user interface guidelines and building a platform that supports it. We’ll eliminate much of the drudgery of Win32 UI development and enable rich, graphical, animated user interface by using markup based UI and a small, high performance, native code runtime.

In other words, the Windows team has possibly been working on its own native code equivalent to XAML and WPF, or perhaps a native code runtime for XAML presentation markup. Maybe this could appear in Windows 8 and support a new touch-oriented user interface.

In the meantime though, Microsoft’s developer division has continued a strong push for .NET, Silverlight and most recently Windows Phone. Look at Visual Studio or talk to the development folk, and you still get the impression that this is the future of Windows client applications.

All this adds up to a muddled development story, which is costly when it comes to evangelising the platform.

In particular, eight years after PDC 2003 there is no clarity about Microsoft’s rich client or RIA (Rich Internet Application) designer and developer story. Is it really WPF, Silverlight and .NET, or is it some new API yet to be revealed, or will IE9 as a runtime play a key role?

There is now a little bit more evidence for this confusion and its cost; but this post is long enough and I have covered it separately.

VN:F [1.9.18_1163]
Rate this post
Rating: 9.4/10 (7 votes cast)
Microsoft still paying the price for botched Vista with muddled development strategy, 9.4 out of 10 based on 7 ratings

Related posts:

  1. Microsoft’s muddled licensing for Office Web Apps
  2. Making sense of Microsoft’s Windows 8 strategy
  3. The strategy behind Mono has shifted: ten years of open source .NET
  4. Microsoft’s Vista Capable campaign: where it all went wrong
  5. Nokia Lumia strategy needs time, may not have it

2 comments to Microsoft still paying the price for botched Vista with muddled development strategy

  • There’s another part to that story in that the WPF that shipped was not the Avalon that was demoed at PDC03. Jim Alchin kiled that project, and what we ended up with was a much simplified version of the original WPF vision written very quickly to fill the gaps and at least deliver something with Vista. I wonder if the nerfing of WPF is as much to blame for the malaise, as it’s clear the platform that shipped will never be able to match that vision (and the matching WPF/E concept).

  • Vic Klien

    Hi Tim,

    The Windows OS and the applications that ship with it absolutely must load fast. I believe that’s the key technical issue that prevents WPF or any .NET from really playing a role in the OS or its applets.

    Spinning up a new .NET processes (including WPF) takes a relatively long time and has a relatively large memory footprint compared to a native Win32 process. Every millisecond counts when the OS is booting. It is just too expensive to pay the “.NET-tax” at boot-up time.

    Most custom applications written by and for end-users don’t have as stringent perf requirements, so .NET/WPF make sense there. .NET is unquestionably a richer more productive environment, if you don’t have to start fast and be light-weight.

    My guess is that the Windows OS team would have been happy to use WPF as their UI, but this perf reality prevented that.

    That is why this rumored native-code XAML UI has me interested. I would like the be able to get the goodness of a XAML UI, but be free to choose whether the underpinnings are lean-and-mean C++ (suitable for use in an OS applet), or full featured .NET.

    Vic