In Windows 8, you can still keep writing classic .NET applications as you have done for the past decade. Windows 8, however, adds a new family of applications often referred to as "Metro applications." To be precise, "Metro" is the blanket term used to indicate a collection of design principles that have inspired Microsoft in the creation of the new interface of Windows 8, running side by side with the classic Windows interface. Glimpses of the Metro style are visible in Windows Phone and will likely be visible in the new releases of Microsoft's flagship products in the months to come. I agree with those who say that we can measure the real commitment of Microsoft to Metro with the next version of Office.
According to Wikipedia, Metro is a "design language" inspired by the "principles of classic Swiss graphic design" that emphasize cleanliness and readability. If Metro is mainly a design language, then a Metro application is a Windows application whose user interface and user experience are inspired by the Metro principles. In light of this, what's the role of Windows 8 and why does Metro seems to be so tightly bound to it? What's really going to be different for developers?
The .NET framework runs on top of the old Win32 API and it uses the P/Invoke mechanism to make calls from the dazzling world of managed code to the wilds of COM and C-based APIs. With Windows 8, Microsoft is undertaking an important move replacing the underlying layer through which the core of the OS functions is exposed to applications. In other words, Microsoft is attempting to touch and restructure some of the pillars of all Windows applications. They're doing so by introducing WinRT short for Windows Runtime.
WinRT is ultimately a new layer of code that is expected to provide the same core services as Win32/COM. You should be able to see immediately the deep impact of such a change: WinRT can't just be plugged in silently while keeping existing .NET applications working as usual. WinRT is the dawn of a new generation of applications. It goes beyond .NET in the sense that it would ideally require a new, revisited .NET.
Not really a realistic scenario is it? Or, at least, not a scenario that will be realistic in the space of a Windows release; and not a scenario you can enable overnight. That's why Windows 8 is presented as a dual operating system the classic Windows/.NET model and the new WinRT-based model.
WinRT-powered applications are also expected to show off a new and more modern user interface and user experience the Metro style. However, WinRT and Metro are distinct things. It is mere guesswork at this time, but it seems that you can have WinRT applications equipped with a non-Metro UI; likewise, you could have Metro-inspired applications written for classic .NET. If past history holds, it will take only a few months to see Metro-inspired UI components from major vendors. At that point, the circle will be closed and the message will be clear to everybody: Metro is the recommended UI/UX of the next Windows. And WinRT is the new runtime for building next-generation Windows applications.
WinRT and .NET
What's the relationship between WinRT and today's .NET Framework? As I said, my guess is that in an ideal world, Microsoft would have shipped a brand new .NET Framework working on top of WinRT and would have educated the masses to forget the old and embrace the new. This is ideal, but not realistic, and some common ground must be found.
WinRT offers a framework that looks like the familiar .NET Framework, but still has some key differences clear signs of the underlying idea of reworking the programming framework developers deal with. Some classes are very similar as .NET Framework classes, with only minor differences; some.NET Framework classes have a counterpart in WinRT, but in different namespaces (and renamed and refactored a bit); and some of the .NET Framework classes are not exposed to WinRT applications and are unavailable. Finally, some new classes make their debut in WinRT.
In addition, WinRT is driven by a new set of policies and this is reflected in the organization of the programming API. For example, all APIs expected to run for longer than a few milliseconds have been designed to be asynchronous. This is a huge change that introduces a significant paradigm shift for most developers. The shift, however, is partially mitigated by some new facilities available at the language level, such as the new
await/async keywords, which you may have already seen in F#. Direct file access is also restricted in the name of sandboxing and making new applications ready for a Windows-specific marketplace. That doesn't mean that you cannot permanently store data in WinRT applications: You just have to use a different API, such as the classes stored in the new
Windows.Storage namespace. To open and save documents and files, you have new file picker components that replace the standard common dialogs of Windows. You also have an ad hoc WinRT API for accessing the registry. In a nutshell, you have a new API, only a part of which exactly matches the .NET API.
Anybody outside Microsoft today who claims to have a vision regarding WinRT and what Windows 8 will become might be proved wrong in a few months. This is due to the lack of specific and detailed information at this early stage. At any rate, I feel confident stating that the new Windows runtime takes on a huge challenge: improving the Windows programming model and subsequently the foundation of Windows applications. To make this happen and push a more modern view of applications, Microsoft had to touch the ground occupied by the .NET Framework. In doing so, it considered and rejected breaking changes in the framework that serves millions of applications today. That's why we now are getting this "new" thing the new Windows Runtime.
Dino Esposito is a frequent contributor on Microsoft topics and has written several developer-oriented books for Microsoft Press.