Over the past few days commute, I've been reading Peter Bright's history of the Windows APIs. It's quite fascinating, and very much worth a read. The article is quite long, but it covers everything from Win16 to WinRT, stopping in OLE, COM, .NET, DCOM and everywhere else on the way.
The Longhorn vision was not without its problems, however. The chief problem was it depends on .NET. While .NET has seen substantial uptake among a certain kind of developer, it has left others out in the cold. The early adopters of .NET were developers working on internal line-of-business (LOB) applications, and even as the platform has grown and evolved, that hasn't really changed. Developers of large desktop applications—think Office, or Photoshop, or even games—have stuck with native code and the Win32 API.
Windows Longhorn - and the release of Vista - was the exact time I left the Windows space for my personal use. I bought a Mac back then, and I've not looked back. While the "failure" of Longhorn wasn't the motivating factor in me moving, Microsoft's apparent (at the time) refusal to move to .NET, despite pushing it hard to developers, made no sense to me. The refusal to ship .NET 2.0 as even an optional update to XP SP2 still strikes me as small minded, even after 7 years.
At the same time, Apple was going through an almost identical process, and they handled it very, very differently. They had the [Carbon API's](http://en.wikipedia.org/wiki/Carbon_(API)), which were very C-like, and [Cocoa](http://en.wikipedia.org/wiki/Cocoa_(API)), which is a fully object oriented framework. Carbon came from OS9 (forward ported to OSX) where as Cocoa came from NeXT and started its Apple-based life in OSX 10.0.
There is some written history about it, but the crux of it is, Apple kept Carbon around in 32-bit form, until OSX 10.5, when they announced that Carbon would never be ported to 64 bit. After that, the only API option available for 64bit apps was Cocoa (which is 32 bit and 64 bit). Companies had the better part of a decade to move over, and while a lot of them did, some - Adobe, Microsoft and even Apple being some of the biggest - left it until the last minute.
I think Apple's way, in this case, was a better one, and one that I wish Microsoft had done: Keep the old API around (win32 / Carbon), but deprecated. Push the new one like crazy (WPF/Cocoa) and once it has some traction, kill the old one with a few years of notice.
Microsoft is actually doing this right now, but I think, once again, they have botched it. WinRT is based a lot around the .NET framework, and it uses XAML for the presentation layer. You can write code in C++ (managed or native - WinRT a big COM library) or C#. Or JavaScript. But if you want to use the new Metro UI, and have it run on ARM and on Intel, you really need to be writing it your code in C# + XAML. Fat binaries only make sense if you are porting old code over, and there is a good chance, if you are doing WinRT/Metro, you're doing something new.
Where I think they really fell down is this: WinRT isn't the .NET framework. It's similar, but is different enough that code doesn't just port. It's so far removed from Win32 that that code will never port over. It's the worst of both worlds, but I suspect someone in Microsoft has put a stake in the ground: We need a new API, and this is going to be it. If thats the case: bravo. It is a move in the right direction - a new, well designed, OO API, one that they should have come out with in the Vista era, but was half executed upon, in the form of WPF.
* Until Microsoft decides on a single name for the Metro-style apps, I'm going to call them Metro-style. It was - and is - such a good name. Windows Style? Windows 8 Style? Microsoft Style? All boring, unimaginative names for something which is quite critical. Pick one. Please.
