Since Microsoft showed off the features in Windows 8 at their Build conference, the internet and many office water coolers have been riddled with discussions about WinRT.. what it is, how it works, why should you use it versus something else, etc. Hopefully in this post I can provide some clarity.

First, a little history lesson: Microsoft originally wrote this thing they called the Win32 API. The Win32 API was written in C++ and littered with data types like the “lpzstr” and where developers had to do black magic tasks like “cracking messages” (it’s more benign than it sounds, honestly). We couldn’t pass big, bloated, complicated data structures around on the call stack so the use of the Win32 API was typified by the act of bundling up all your parameters to an API method into some obtuse, bit-packed “thing”, making the call, and then getting a response, which could be just as obtuse and bundled. Heaven help you if you wanted to hook into the bowels of the API so you could receive notifications and messages in your own code.

Then along came COM (yes, I’m skipping OLE and DDE for you history buffs… it’s too traumatic for me to write about). COM, which stands for Component Object Model, was an API. More than an API, it was a binary standard for allowing components written in (virtually) any language to communicate with each other. Those of us who had to write our own COM components or consume them are familiar with “DLL hell”. This is when the act of trying to make versioned components make sense on your system goes straight to hell in a handbasket. An important thing to note is that while COM provided an object-oriented, component-style layer to expose and consume functionality, the Windows UI was still very much the Win32 API.

Now we finally get to the .NET Framework, a managed runtime environment that claims to solve the problems of DLL at the same time as making UI development easier, more developer-friendly, and much more intuitive. We start with Windows Forms and eventually get technologies like XAML, WP, and Silverlight to build our user interfaces. Despite support for 64-bit and being a boatloat more powerful and complex, we’re still all sitting on top of something that strongly resembles the original Win32 API … we’re just insulated from it, and by insulated, I mean we’re sitting in a warm cozy ski lodge while the underlying API is freezing its ass off on the top of the mountain. This brings us all the way up to .NET 4.5. That’s right, .NET 4.5 is still going through a similar stack of abstractions to get to the underlying system that we go through today. This point is important.

Now we get WinRT. Contrary to popular belief, WinRT is not just a re-branding of the Windows API. It isn’t a codename for .NET 4.5. WinRT is actually a UI (among other things, including file system & device access) library written in C++. The reason I took so long getting to this point with the history lesson is this:

WinRT is the biggest single change to the Windows desktop development story since the arrival of the Win32 API.

WinRT takes many of the classes and features that we’re used to having available to us in .NET and re-writes them in native C++. Much of the .NET BCL (Base Class Library) that we take for granted has now been cleaned up and made available within WinRT – again, in native code. Rather than making us suffer through yet another poor interop layer, WinRT is also built with its own self-describing metadata. This allows Microsoft to generate C#, JavaScript, and C++ class libraries. These class libraries aren’t just cheap shunts, but rather they surface the concepts available within WinRT in ways that seem familiar and, more importantly, idiomatic, to the developers who have been working in those environments for years. When your “appx” (Silverlight devs, think “.xap” here) bundle is loaded, WinRT figures out what kind of host process is needed (an HTML engine, a CLR process, or a C++ process) and then fires up your app within the WinRT sandbox.

So, regardless of how it is implemented in the underlying WinRT C++, a collection exposed to JavaScript will look like a vector whereas it will look like a .NET collection complete with Add() and Remove() methods to a C# developer and it will look as it should in C++ as well.

So – how do you decide if you’re going to use WinRT or if you’re going to continue with the standard desktop application story? Well, in general, if you want access to the “Metro” style, then you’re going to need to use WinRT. If your application just doesn’t fit with Metro (or has a complicated UI that makes no sense to expose to touchable surfaces) then you’ll continue using standard .NET 4.5 technology.

WinRT applications have the potentially to finally give Microsoft a good mobile and slate environment. Windows CE, PocketPC, and Windows Mobile were all terrible attempts at shoehorning a desktop operating system into a mobile form factor. Windows 8, with WinRT apps and the Metro style, has the potential to give both big-monitor desktops and slates/tablets a compelling and engaging experience.

For us developers, this means 400+ million potential happy customers.