November 2011
Volume 26 Number 11
Editor's Note - A Game of Risk
By Michael Desmond | November 2011
.png "Michael Desmond")
When Microsoft announced the Windows Runtime (WinRT) stack at the heart of Windows 8 during the BUILD conference keynote in September, everyone in the room knew the game had changed.
In the decade since Microsoft launched the Microsoft .NET Framework and transitioned many developers to managed languages like C# and Visual Basic .NET, the company has adroitly leveraged its vast developer community. Every step along the way, Microsoft ushered its incumbent programmers forward with the promise of reusing existing code, working with familiar tools and exercising well-honed skills.
The strategy is both brilliant and obvious, and strangely mimics the late rounds of the board game Risk, when players inevitably spill enormous piles of armies onto the board. I’ve played my share of Risk and know well the incalculable glee that comes from cashing in a trifecta of cards for 60-plus armies. When you show up with numbers like that, things get done(yeah, I’m looking at you, Irkutsk).
The Trouble with Asia
The problem facing Microsoft, as any Risk player knows, is that even the massed armies of .NET developers couldn’t, metaphorically speaking, hold Asia—that vast and vulnerable continent on the Risk board that has been the undoing of so many players. Smartphones, tablets and the emergence of HTML5 as a development target have created huge new frontiers—frontiers the Microsoft .NET strategy was simply not designed to address.
WinRT, however, is.
The WinRT stack at the heart of Windows 8 takes the .NET strategy and turns it inside out. Rather than urge developers to move into new languages, like Visual Basic .NET or C#, WinRT exposes its capabilities to multiple languages. By projecting the functionality of native Windows APIs into each language, Microsoft has thrown open the doors to a potentially huge community of developers across the C++, C#, Visual Basic .NET and JavaScript domains.
Microsoft is able to do this by implementing the APIs in a language-neutral fashion, including metadata that each language environment uses to “project” the APIs into its environment in a natural way. For example, at the lowest level, the WinRT APIs use HRESULTs for error reporting, but those errors are projected into languages like C# and JavaScript as exceptions.
The names of properties themselves also are specifically cased for each language, so a C++/C#/Visual Basic developer sees properties in Pascal-casing, while a JavaScript developer sees them in camel-casing, just like other APIs he already knows.
From C++ coders tuning multithreaded applications to JavaScript hobbyists hoping to create the next “Angry Birds,” WinRT effectively broadens the definition of the phrase “Windows developer.”
As one member of the WinRT development team told me: “The ability to write native apps in JavaScript/HTML opens up the world of Windows to a developer community that’s probably an order of magnitude larger than the .NET developer community.”
That noise you just heard was the sound of Microsoft slapping another set of Risk cards onto the board. That’ll be 90 more armies, please.
Taking the Board
Microsoft is articulating a path to extend WinRT even further.
“The beauty of the solution here is twofold,” the WinRT team member said. “One is that the architecture easily allows for additional languages to be supported in the future, where that environment would again have immediate and direct access to native APIs. Two is that developers can also create their own APIs in this model—what we call WinRT components—such that they can plug into the language projections just as the native APIs do.”
The result: “Hybrid” apps where the most appropriate language can be used for different parts of the software. So a math-intensive physics engine written in C++ can be utilized directly from, say, JavaScript.
Will Microsoft’s bold strategy attract enough developers to help it win the board? As any Risk player knows, a lot depends on the roll of the dice. But it’s clear that Microsoft is in a far better position today to address the challenge than it was just a few months ago.