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
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
WINUSERAPI int WINAPI MessageBoxA(…);
…
Read more: All Your Base Are Belong To Us
QR:
Posts
