The Web today is full of rumors about the demise of Silverlight, .NET, Win32, and nearly anything else that doesn’t align immediately with Metro-style apps. Indeed, it seems sometimes that we are so eager to focus on “what’s dead” that we forget to look at the new announcements and try to figure out “what’s alive”.
From a brief analysis of the Windows 8 Developer Preview, Visual Studio 11 Developer Preview, and whatever bits of information delivered at the conference sessions, I think I have a pretty decent mental picture of what’s going on.
First of all, a managed Metro application (e.g. written in C#) will still load the CLR. I confirmed this by launching a Metro application and inspecting it with WinDbg – I was even able to load SOS and run basic commands. The CLR version bundled with the preview is 4.0.30319.17020, and that’s the version that gets loaded inside a Metro app. (It’s curious to note that even though the Visual Studio setting dictates “Any CPU” and the Windows version is 64-bit, the actual process is 32-bit.)
Symmetrically, a “fully” .NET application (e.g. a WinForms app) can reference the WinRT metadata assemblies and use WinRT APIs. This will be a necessity in some cases, for example to tap into the WinRT sensor APIs.
Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem.)
What about the limitations, then, that a Metro application has in terms of API surface? Indeed, a Metro application written in C++ will be able to access only a part of the Win32 API surface, and this is accomplished through a bunch of preprocessor definitions. For example, the MessageBox function is not available for Metro-style apps, and its declaration is protected in the header file as follows:
#pragma region Desktop Family
WINUSERAPI int WINAPI MessageBoxA(…);
For managed applications, the Metro projects in Visual Studio are targeting a special subset of the .NET framework, and will not have access to all the classes – not even all the classes of the .NET Client Profile. For example, the System.IO.FileStream class is not available.
Although these limitations may seem artificial, annoying, and counterproductive, there is probably a good reason for having them. The Metro UI and Metro apps are a fresh start for Windows applications and their developers. There is no trivial way to port an existing UI app to Metro without a considerable UI redesign. It’s also a great opportunity to enforce additional limitations that make sure Metro apps respect the user’s privacy, conserve battery power, integrate well with the UI guidelines, and live in harmony within the application sandbox.