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 asynchronous, a new complexity that would likewise bedevil many developers, at least until they got used to this new style of programming, which supported multiple tasks running in the background. Worse, this new asynchronous model prevented direct access to the file system, among other limitations.

The weirdest thing about WinRT, perhaps, was that it exposed its APIs in three incompatible ways, which is why Sinofsky claimed that developers could choose the programming language they preferred. That is, developers who targeted WinRT could write code in C/C++ and XAML, C#/Visual Basic and XAML, or JavaScript and HTML/CSS. By this point, XAML was well-understood, but allowing developers to alternatively use HTML—and even simpler and better understood markup language—to create Windows app UIs was inarguably innovative and, at the time, fascinating. (And yet another attempt by Microsoft to usurp web technologies in Windows in proprietary ways.) And Microsoft drove home that point by creating many of its in-box Windows 8 apps—like Mail, Calendar, and the Windows Store—in JavaScript, HTML, and CSS.

To show off how easy it was to create Metro-style apps, Sinofsky brought out Antoine Leblond, who was at the time a senior vice president at Microsoft, and in charge of the Windows Store. Leblond’s appearance was meant to invoke previous developer-focused presentations at the PDC, Microsoft’s now-defunct developer show. But it was delivered at a blistering pace, and all of the meaningful code was canned, meaning that it was written ahead of time and simply pasted into the developer tools over time rather than written live. Not helping matters, the micromanaging Sinofsky interjected and interrupted Leblond repeatedly, when he should have simply left the stage to an expert instead.

Befitting the capabilities then possible with WinRT, the “apps” that Leblond (sort of) wrote on stage were simplistic and highlighted mobile technologies like multitouch. The first was written in JavaScript, HTML, and CSS, which was seen as more inclusive, though the Microsoft-focused developers in the audience would probably have preferred seeing the more familiar C# and XAML.

The “first bit of real Windows 8 code,” as Leblond put it, involved WinRT’s Metro-style replacement for the File Open dialog, a sophisticated desktop interface that Microsoft had steadily evolved over the years. Coding this replacement, called the File Open Picker, was familiar enough, and it resembled the code that developers had used previously for the File Open dialog, but with some asynchronous coding changes. But the File Open Picker itself was a stripped-down and simplistic full-screen interface that allowed users to select files in certain parts of the file system or, intriguingly, via any compatible Metro-style apps.

After several interruptions from Sinofsky, Leblond then showed how a Metro-style app could integrate with Windows 8’s Share interface via the Charms, a non-discoverable toolbar of system services that would appear if you swiped in from the right side of the display. He also used Expression Blend—a Microsoft tool for graphic artists to use to create XAML-based app user interfaces—to edit HTML-based app’s UI; Blend had been updated to support HTML as well.

For the grand finale, Leblond then submitted this basic app to the Windows Store, though the process had been dramatically simplified for the demo. “It’s like ordering a pizza,” Sinofsky claimed bizarrely.

With that out of the way, Leblond moved on to create something the audience would better relate to and understand: a C#/XAML app. Unfortunately, this came with a fairly obvious slight: he didn’t create a new C#/XAML app but instead resurrected a Siverlight/.NET app, or what the Windows 8 team considered a legacy app, and “upgraded” it to WinRT.

To do this, Leblond took the code from a two-year-old Silverlight app that had been made by Microsoft’s Scott Guthrie and documented on his blog, and then made code changes to make it a Metro-style app. He didn’t do this live on stage, of course: instead, Leblond showed a Visual Studio project representing the Silverlight app, and then he opened a second project representing the pre-made WinRT conversion.

“I’ve only had to make a handful of changes to this [code],” Leblond claimed, noting that most of them were just namespace changes to account for the move from Silverlight—which used .NET-based System namespaces—to WinRT, which used Windows namespaces. But the networking APIs were also different because of WinRT’s insistence on asynchronous code, and Leblond had had to make changes to the app launching code since the Silverlight app ran in the browser. The result was a Metro-style app that looked just like the browser-based Silverlight original. And then he changed the XAML to use a WinRT grid control so that it looked more natural in Windows 8. (Leblond also adapted Guthrie’s app to run on Windows Phone 7, but this, too, was not done live on stage.)

And that was it. Leblond was on stage for just 30 minutes, give or take, and he had really shown off only a small selection of WinRT functionality, all of which had been prepared ahead of time. But Sinofsky’s keynote, curiously, still had over an hour to go: he filled the rest of the time showing off Windows 8 hardware compatibility in a numbingly boring segment with Mike Angiulo, and then went back into demo mode, this time focusing on more fundamental and desktop-type features like Client Hyper-V, file copy improvements, multi-monitor improvements, and the like. The keynote ended—after a brutal 2 hours and 15 minutes—with an appearance by Windows Live’s Chris Jones, who showed off some of the new apps his team was creating for Windows 8.

They were all rudimentary and, frankly, a bit embarrassing considering what his team was accomplishing at the time on the web.

That night, Microsoft released the Windows 8 Developer Preview for download. It was available in three versions, one a 64-bit release with built-in developer tools—Visual Studio 11 Express for Windows 8 and Expression Blend 5—and then separate 32-bit and 64-bit versions without the tools. The Developer Preview was not feature-complete: most of the apps that Microsoft intended to ship with Windows 8, including the Windows Store and the Windows Live apps, were not yet ready. And so Microsoft instead included several sample apps instead. That they were built by summer interns was perfect, as their skill levels neatly met the capability level of the platform.

Sinofsky then explained that Windows 8 would require three more milestones before general availability (GA): Beta, Release Candidate (RC), and Release to Manufacturing (RTM). “It is different than what we did with Windows 7,” he said. “You might remember that with Windows 7, the preview didn’t even have any of the new UI. And we didn’t do that much [new] UI. With the bold new Metro-style user interface in Windows 8, you’re getting it all now. And it’s at the same state of readiness.”

(Sinofsky would in fact change the schedule again. But as with Windows 7, the more ambitious Windows 8 would still steamroll to a conclusion within the same three-year timeframe.)

The developer-heavy audience had erupted into applause several times during the Build 2011 keynote, which is confusing, not just in retrospect, but when you consider the immaturity of the user interfaces they were shown. But it’s important to remember that Sinofsky and his Windows team were still riding a Windows 7 high, and while that success had not kicked off a new generation of Windows apps, it was still an enticing possibility for the audience. Perhaps this latest gambit would be the push needed to put new app development over the top for the first time in a decade.

But not everyone was happy with what they had seen.

After 12 straight years of focusing its developer efforts on .NET, Microsoft—or at least the Windows team—had turned its back on .NET. As a result, Build 2011 was decidedly lacking in .NET content. The phrase “.NET” had been uttered exactly one time in that 2 hours and 15 minutes of babble, and only in passing, where it was lumped in with other legacy technologies that the Windows team was now busy trying to obsolete. (Consider the tiny blue square representing .NET in the architectural diagram that Sinofsky first displayed.)

“Carl [Franklin] and I were at Build 2011,” Richard Campbell said during a History of .NET presentation, referring to the co-host of their influential .NET Rocks podcast. “And we walked out of that conference, looked at each other, and said, ‘what if .NET didn’t rock?’” As a contingency plan, the two created a second podcast for cross-platform developers. “We were worried. Lots of people were worried.”

.NET and C# would go on to survive the Sinofsky pogroms. But that was largely a matter of luck: thanks to the efforts of Miguel de Icaza, whose companies Ximian and Xamarin ported .NET and C# in turn to Linux, iOS, and Android, Microsoft’s managed code environment was no longer reliant solely on Windows. Microsoft would go on to acquire Xamarin and, thanks to de Icaza’s influence, it would even open-source .NET, a multiyear effort that only recently concluded.

“Three years later, it was apparent that .NET still rocked,” Campbell said, noting that he and Franklin then killed the other podcast to focus solely on their original topic of interest. “But this was the toughest point [for .NET], in 2011,” Campbell added.

It sure was. But the millions of .NET developers who were unsure of WinRT and the direction that the Windows team was forcing them down only needed to take a look at the WinRT APIs to fully understand how bad things had gotten. There were some good ideas in there, to be sure. But WinRT, like the Windows 8 platform on which it ran, was a nightmare.