Windows Runtime – Dial in the right expectations before reading up

Three days on from the announcement of the Windows Runtime at Microsoft’s Build conference the marketing dust is settling and the full picture emerging. As you begin to read up what the Windows Runtime actually is you’ll need to set your expectations to the right level or you run the risk of being disappointed. But set them appropriately and I think you’ll see that an exciting developer journey lies ahead.

Leading up to the conference I was hoping for a new lean-and-mean User Interface platform for writing any kind of Windows application. But that isn’t what Windows Runtime is about. As things stand this week, Windows Runtime is about producing Metro-style applications (think Windows Phone 7) optimised for running on Tablet devices. Windows Runtime is aimed squarely at the solar plexus of iOS and Android 3.0.

Miguel de Icaza and Tim Anderson have already done a good job of writing up what has been announced so far about Windows Runtime (or WinRT). But here are the two key points to notice:

• Metro-style apps run in a sandboxed environment. As with Windows Phone 7, apps have to declare upfront, through a manifest built in at compilation time, which capabilities of your PC they intend to use. Access to APIs is monitored at runtime by the Runtime Broker, which prevents your app from doing anything naughty. Only certain parts of the .Net Base Class Libraries can be used, and even native developers are limited as to which Win32 or COM objects they call. Apps can only talk to each other through the WinRT-endorsed Contracts, which allow for Sharing, File-picking etc.

  To a developer all this sounds like a horrible restriction. But it is wonderful for users, who can have much more confidence that applications they install from the new App Store will not get up to mischief.

• Metro-style apps are always full screen and immersive. Windows Runtime does not provide a general-purpose windowing system. Several presenters at the conference mentioned that support for overlapping windows have been intentionally left out. And for one simple reason: they don’t work well in a touch-centric environment.

Windows Runtime is not (at the moment) a general purpose runtime. It may get there eventually, but for the time being it is focused on building the kinds of apps and games that today you might run on the iPad, the Xoom, or (once the lawyers have finished their fisticuffs) the Galaxy Tab. Think of it as Silverlight-on-Steroids-With-Native-Extensions for Tablets and you won’t go far wrong.

As speakers at Build conceded, there are many kinds of application that would not fit the Metro-style. Visual Studio is one. Photoshop is another. Microsoft Office is (possibly) a third. For these kinds of apps, keyboard, mouse, menus, toolbars, ribbons and dialog boxes still works best.

This means Win32 and WPF are still very much alive. Though there are no sessions about it at the conference, WPF 4.5 has been announced with a number of not-insignificant new features, including the promised fix for the Win32 airspace restrictions (though nothing has been said about hosting Silverlight controls in WPF apps).

I’m no prophet, but I don’t believe this is the last we’ll hear about WPF.