I spoke last week at a user group in the Boston area, the fourth time I've done so since the Windows 8 Developer Preview was released last fall. And not coincidentally, this was the fourth time in a row I spoke exclusively about Windows 8: People are fascinated by--and scared by--Microsoft's next operating system in ways they haven't been since Longhorn or, perhaps, Windows 95. It's something that I even I need to keep in the back of my mind since of course I have my own doubts, most of which are directly related to Microsoft's refusal to speak clearly about its plans.
That said, the groups I speak to are largely made up of very technical people with a business focus, so they have specific concerns about Windows 8, as well as specific kinds of concerns. Still, many of their questions are generally interesting even to non-technical people. So I figured I could address some of these questions in a series of articles about Windows 8 that will serve as background for the material I'm preparing for the book Windows 8 Secrets.
First up is the new Windows Runtime, or WinRT, since this forms the core of the new operating system and is, perhaps, the centrally most confusing concept in Windows 8 thanks to its position, or relationship, with the Start screen and Metro-style apps, and, of course, the classic Windows desktop and those applications as well.
Note: This is a guide for end users, not developers or Windows internals experts. The goal here is to be accurate conceptually, and it's likely that there are some technical omissions or shortcuts in this article, given the nature of the topic. While I'm not hugely concerned about that sort of thing, I am interested in any errors you do find. So do let me know.
It's also worth noting that this is one area where Microsoft has been very forthcoming. We criticize them for silence, but with WinRT, the company has been transparent, though of course the topic is complex and confusing.
OK, let's dive in.
As a modern operating system, Windows has, of course, always had a runtime engine, an environment in which native applications run. One of these native applications is very special, since it provides the interface with which users interact with that runtime and environment; that application is called the shell. In the Windows 3.x days, Program Manager was the Windows shell. But that changed in Windows 95 to Windows Explorer, a situation that continued through the most recent Windows version, Windows 7.
In Windows 8, the Explorer shell is being replaced by the Start screen. But this isn't just a surface change, and the Start screen isn't "a thing on a thing." Instead, the Start screen, as the new Windows shell, is the visual representation of a new runtime engine which in this case is simply called the Windows Runtime, or WinRT for short.
And the Explorer desktop, interestingly, is essentially an app, or at least a separate environment, that runs alongside the new shell. One might conceptually (though not technically) compare this to the situation with MS-DOS and Explorer in Windows 9x: Both existed, both ran next to each other for all intents and purposes. And both had various tendrils into the other such that, for example, Explorer and the Windows 9x runtime actually relied on DOS in some ways. These things are never as clean as depicted in Microsoft's diagrams.
Architecturally, WinRT fits into Windows at a very deep level, which makes sense. Thanks to componentization work that began in the buildup to Windows Vista in the mid 2000s, Windows is now highly componentized, a modular system in which different components, or parts, can be mixed and matched, like a puzzle with multiple solutions, to form different Windows 8 versions, including the phone, the desktop versions, Server, and so on.
At the base of this architectural view of Windows is Windows Core, or what used to be called MinWin. This includes the Windows kernel, user mode, services, and other low-level bits. WinRT, interestingly, does not completely sit on top of Windows Core. Instead, much of WinRT is part of Windows Core. This, of course, explains Microsoft's contention that the new Windows runtime is not "a thing on a thing". It's the Windows runtime engine, pure and simple.
As with Windows itself, the Window Runtime is itself also made up of layers that provide levels of functionality to the shell and to Metro-style apps. At the bottom, conceptually, are low-level services such as memory management, cryptography, and globalization; these are considered part of the Windows Runtime Core. Above them are layers related to devices (including sensors), media, and communications and data (contacts, local and cloud storage, web, notifications, and much more). And above that is the UI layer, with the various WinRT-supported app development models: HTML5/CSS, XAML, DirectX, and the like.
(Developers use APIs for each of these layers, contained in the Windows 8 SDK, to create Metro-style apps. These APIs are, for now, horribly (un)documented, so its unclear what quantity of high-quality apps we can expect without a lot of handholding from Microsoft. That situation, of course, will improve over time.)
Microsoft explained this even more simply at the BUILD conference last September, as it turns out. Microsoft WinRT development manager Martin Lovell said during his session "Lap Around the Windows Runtime" that "WinRT is the Windows platform."
Accepting Microsoft's contention that WinRT is indeed the new Windows runtime engine, we arrive at an obvious question: Why? Why would Microsoft replace something that has worked so well and so efficiently with something that is so new, so different, and--for now, at least--this untested and, to developers, unknown?
I think the simplest way to explain this is that Microsoft had hit a brick wall with its existing technologies. To understand this, I'm going to need to take a short detour into how Windows software has been developed over the past 15 years.
Win32, the API/developer basis for its Explorer-based platform, isn't just long in the tooth--it was created for Windows NT in the early- to mid-1990s--it's been usurped by more modern APIs several times, starting with the C++-based MFC (Microsoft Foundation Classes), but more recently by managed code, .NET-based environments including the .NET Framework, Windows Presentation Foundation and Silverlight.
For all the advantages of .NET, the central problem is that it does not produce "native" code. That is, .NET environments, by nature, are abstractions of the native environment that are, yes, more elegant, but also further removed from the core of Windows. So they suffer from performance issues above all, but also from the fact that they offer only a subset of the full spectrum of possible platform capabilities. So developers often turn to C or even assembly language when they need better performance, or to access functionality that is simply not exposed by whatever .NET environment they chose.
But what if .NET-style development were to become "native" Windows development? Doesn't this sound like the best of both worlds?
Hard core developers may bristle at the notion that WinRT development is "native" development, but it's a fair enough assertion. Using the new WinRT-based APIs available in Windows 8, developers can use the modern, managed code languages they love from .NET--like C# and Visual Basic--along with the XAML user experience markup language and the familiar, clean, and modern managed code-style APIs. WinRT is also more egalitarian than .NET since it also offers even more choice: Now you can also use web technologies--HTML 5, CSS, and JavaScript--which are simpler and more approachable, or those with serious performance needs can use DirectX. In each case, however, the developer benefits from over a decade of improvements to these types of programming interfaces. Win32, suddenly, isn't just out of date. It's passé.
There's a bit more to this evolution, some of which involves the notion of asynchronous programming and so on, but let's not get too far afield. The point is that Microsoft is modernizing everything here: The runtime engine and shell for users, but also the development tools, languages, APIs, frameworks, environment, and more. Everything is being overhauled to be better, simpler, and more modern.
That's the theory, anyway.
From the user's perspective, these changes will have important ramifications, not just in the way you interact with Windows on a day-to-day basis but also in such areas as how Windows and the apps that run in it are updated over time. This isn't a surface coat of paint, it's a complete reset, though of course the addition of the "legacy" Windows desktop provides the important backwards compatibility that customers expect and Microsoft always delivers. Microsoft calls this a "no compromises" approach. Again: The best of both worlds.
As with any evolution, there will be growing pangs. This is what happened when we moved from DOS/Windows 3.x to Windows 95 to NT as well. During that transition, DOS migrated from being the core OS to being an integrated runtime engine and then, finally, to being a simple command line interpreter that ran on top of the "real" OS.
In Windows 8, WinRT and the Start screen will run alongside Win32 and the Explorer desktop. Both environments will be available to the user, and each will have its strengths and weaknesses in different scenarios. Win32 will, for now, include functionality that is simply not available in WinRT, though hopefully that will change over time. But WinRT, of course, is where the action is: Though some small updates to the Win32 APIs have indeed been introduced in Windows 8, Win32 is largely deprecated and heading towards maintenance mode. All of the big changes and improvements are, and will be, occurring in WinRT.
Over time, I expect Explorer to be further deprecated and eventually removed. Knowing Microsoft, this will happen slowly because of compatibility concerns. But WinRT and its Metro-style user experience is the future, regardless, and WinRT is the runtime engine that will drive a new generation of Windows versions. It's as exciting as it is scary.
