Programming Windows: WinRT (Premium)

It all began with a lie.

“What’s the Windows 8 app platform going to look like?” Steven Sinofsky asked rhetorically, opening his keynote address at Build 2011 that September. It was the same question we’d all been asking since his bizarre Windows 8 reveal at D9 months earlier. “The Windows 8 platform for Metro-style applications lets you pick the language you want to use … What we’ve done is, we’ve reimagined the Windows APIs. And we call them the Windows Runtime or WinRT.”

As he said all this, a slide with a diagram depicting the Windows 8 platform---curiously labeled as Windows 8 Platform and Tools despite the absence of the latter---displayed behind him on stage. The diagram was, in a word, problematic. It made existing desktop frameworks and environments like native Win32 and .NET seem small and insignificant when compared to the new Metro-style app framework, WinRT. And it confused the relationship between Win32, .NET, and WinRT, making them all appear as if they interacted directly with the Windows kernel.

But Sinofsky’s description of WinRT was even less accurate.

“WinRT provides … an application model, … communication and data objects, graphics and media, devices and printing,” he said. “And all of these together are natively built into Windows. This is not a layer on top of Windows, this is Windows. All native code built to reflect in different languages.”

That is not what WinRT was.

WinRT was not native code. It was very much a layer on top of other code, specifically COM (the Component Object Model), which was itself built on top of Win32, the native Windows APIs. So WinRT was not a reimagining of the Windows APIs. It was a reimagining of .NET frameworks like the Windows Presentation Foundation (WPF), but designed for mobile apps, not desktop apps. And it was not as technically sophisticated as .NET. Indeed, it was in some ways a major step backward.

Even the name Windows Runtime was a lie, as WinRT is not, and does not include, a runtime of its own (as does .NET). It did provide many of the services with which .NET developers were by then familiar, but WinRT was not a managed code environment because it ran outside of .NET and on top of COM and Win32, which are unmanaged environments. That said, WinRT apps were sandboxed, as is the case with apps on mobile platforms like Android and iOS, to prevent them from behaving insecurely and unreliably, while introducing major cross-app data sharing limitations that Microsoft tried to solve through new Windows 8 system services like Share and its contracts.

The WinRT APIs were heavily influenced by .NET, which would help Microsoft-focused developers make the transition more easily. But they also introduced a third implementation of XAML, the XML-based system for declaratively creating app user interfaces, after WPF and Silverlight, and the differences between each would bedevil developers for years. And the WinRT APIs were all a...