At Build in September 2011, Microsoft put out an architecture diagram, which in Microsoft circles has become either famous or infamous depending on your perspective. The diagram shows Windows Runtime (ie WinRT) and the bits that feed into it. Here it is:
The odd thing about this diagram is that everyone wants to redo it. Here's some examples from the week after Build. Six months later, people are still redoing it. It has a tendency to elicit exclamations of "hang on, that makes no sense!" That's because it doesn't make any sense. That diagram is not about cold, hard logic – it's about something else entirely.
Start by imagining that it's 1999. To build apps on the Microsoft stack, on the desktop side you were typically looking at VB6 for desktop, or maybe something like Delphi, or Java. On the web site, you had Classic ASP. You could either write plain Classic ASP in VBScript, or you could write COM components in VB6 and consume them on the pages. Either track was rubbish, and Microsoft deserved to have someone come in and eat their lunch.
If you're in charge of Microsoft's developer toolset in 1999 you might take a blank sheet of paper and think: "Right! How do we do this differently?" From there, you draw out something that looks like .NET. Well, really it looks a lot like Java. Imitation is the best form of flattery as we know. But the point is this – .NET turns out to be actually really good when it's released. It's a massive step forward and takes all of the embarrassment off of the table. People want to use it, and they do.
If over the next 10 years that exercise is repeated, you end up starting from a point that your development toolset and runtime platform looks pretty good. So when the exercise is redone, small improvements are made – eg Linq, lambda expressions, MVC, etc. We even get Silverlight, which improves the capabilities of targeting native apps (despite what I may think of it).
But at some point over the run-up to Windows 8, someone threw their .NET toys out of the pram, leaving the COM-and-C++-drenched WinRT to entice cluckiness out of the onlookers. Seems a strange move, given that there's no external pressure on Microsoft to "fix" .NET …
Enter WinRT
Take this quote from the MSDN sub-site on Metro-style apps:
"You write Metro style apps using familiar technologies like HTML5, JavaScript, and Cascading Style Sheets, Level 3 (CSS3), or XAML, with C++, C#, or Microsoft Visual Basic code-behind."
Umm … why is C++ getting top billing there? Accepted you can do .NET in Managed C++, but if you put 1,000 .NET developers in a room maybe one would be rocking Managed C++. Noises about the importance of C++ started to materialise before Build, and at the time I thought it was weird. But a key message about WinRT is that it is about C++.
(This isn't an isolated example – in the run-up to Build there was a lot of chatter about a resurgence of C++ in the developer toolset.)
A stand-out good explanation of WinRT on Stack Overflow starts by saying that WinRT "uses COM as a base". Uh … what? COM? Is it 1999?
WinRT, as I've indicated, defies straightforward explanation. One way to think of it is that it's an attempt to reboot the Win32 programming model. With WinRT, rather than opening a file using the Win32 CreateFile function you'd use the Windows.Storage.StorageFile class, which lives in Windows.Storage.dll.
OK, but as a .NET developer I've had System.Net.FileStream for about 10 years.
Aha! But Metro-style apps are sandboxed and protected and trustworthy – perhaps the idea of wrapping CreateFile is to stop the developer going outside of the sandbox? OK, so on the one hand Windows is pretty good at locking down a process identity's file access. On the other hand we already have IsolatedStorageFile in .NET which does exactly that. (And we've had it since v1.) We also have Code Access Security (CAS) to further block running outside of our permissions manifest.
WinRT implies that the way we're doing that job in .NET is rubbish – but actually the way you do it in both is exactly the same. Well, except that the WinRT one isn't garbage-collected because WinRT doesn't have garbage collection. Because it's 1999. Or they just wanted to make it look more like iOS development. One of those.
I should reiterate here that .NET is not going away. Run the CLR in a Metro-style app and you'll be using a special "profile" that limits access (much like the .NET Client Profile introduced in .NET 4). Here's a list of things you need to change when moving to the Metro-style profile, and here's a list of supported namespaces. The v1 implementation is likely to be a bit naff – it always is – but none of the .NET stuff is actually being killed.
(Before panic ensues – the CLR within Metro-style apps does garbage collection in the usual way, so if you're writing proper managed code, you're fine. It's still 2012 if you do that.)
A fashionable reboot
Rebooting things is fashionable. (We've all seen the new Sherlock, right?) But if you're Microsoft and you're deciding to reboot something, why on earth choose Win32?
Most developers on Microsoft use .NET. If you're hacking around in Win32 you're doing something pretty weird. Most line-of-business applications involve shunting data in and out of a database, some network comms, and building up a method to present that data. Is Microsoft saying that we all need to be C++ developers to do that now?
This is why the architecture diagram presented at the top of this piece doesn't make any sense. It assumes a logical motivation for introducing it, but actually WinRT is pure politicking.
WinRT is more about representing the message that developing for the Microsoft stack is not about .NET than it is about helping developers get stuck into building Metro-style apps. You just have to look at that diagram – there is virtually no mention of .NET on there, yet (I reiterate) the vast majority of developers who build software for Windows spend all of their time in .NET. One possible reason why you would go out with a message that .NET was not "for the win" is that you hated it and wanted to take it for a quiet ride out to the desert so you could bang it on the head and bury it in an unmarked grave, then return and insist that you loved .NET but it's just a bit wayward, because look, it hasn't come back from that desert trip.
Now, is that likely? Well …
.NET was not invented by the core Windows team; it came out of its developer division. If you design operating systems, you're not going to like .NET. It's an abstraction layer that sits over an operating system. It also looks a lot like Java in terms of architecture. What you like if you build operating systems is very low-level, very fast, very tight code. You also hate garbage collection, because that does stuff when you're not expecting it. Philosophically, the worlds of OS engineering and .NET do not go well together.
Ironically, WinRT would be great if it weren''t for Windows 8. I'm all for improvements, and an object-oriented API such as WinRT and the COM improvements are lovely in isolation. The problem it that at the moment the Windows team have 100% of the airtime because they own Windows 8's new touch-centric user interface (ie Metro).
Maybe I'm wrong. Maybe the WinRT message is just what happens if you don't spend that much time with .NET because day-to-day you work further down the stack. Hanlon's Razor is a fabulous thing for cutting through the crap.
And yes, like everyone else, I've tried redrawing the architecture diagram. Like everyone else, I gave up.
Matthew Baxter-Reynolds is the keynote speaker at the first Windows 8 Conflab being held in London on April 18.