WinRT and .NET in Windows 8

September 15, 2011


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

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.

To summarize, WinRT does not replace .NET, nor does it compete with .NET – and the same applies to Win32. You can write server and client applications using .NET, including WPF and Silverlight. You can write server and client applications using C++, including Win32 and MFC. However, if you choose to believe in the Metro way, you can write Metro applications for Windows 8 using .NET languages or using C++ or using JavaScript, with a consistent set of APIs exposed through WinRT.

Add comment
facebook linkedin twitter email

Leave a Reply to Sasha Goldshtein Cancel Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. LaughingJohn September 15, 2011 ב 11:27 AM

    So presumably you can’t write a single app that supports both the metro UI and the traditional windows UI?

  2. Sasha GoldshteinSeptember 15, 2011 ב 5:56 PM

    @John: That’s right, you have to choose one or the other.

  3. David NelsonSeptember 16, 2011 ב 12:50 AM

    It was my understanding that Metro apps could still access the file system, they just have to declare their intention to do so (which has to be approved by the user) or the call will fail at runtime. Is that not the case? Or is there another mechanism for directly accessing the file system in WinRT other than FileStream?

  4. Bradley GraingerSeptember 17, 2011 ב 2:11 AM

    I also noticed that my “Any CPU” app was running as 32-bit. It seems that this is controlled by a new option in the VS project properties dialog: Prefer 32-bit (which is on by default). Maybe it’s a compatibility option to allow Any CPU apps to be created but run them in a more “familiar” mode by default?

  5. leonidSeptember 17, 2011 ב 7:36 AM

    Don’t you think it would be more appropriate to say that WinRT sits on top of kernel rather than it is a wrapper around Win32?

  6. Computer GuySeptember 20, 2011 ב 7:23 PM

    But who writes a single app and puts all the logic in one place. From what I have learned, if you layer your applications then in theory you could reuse 80% of your code and all you would need to do is re-write the UI portion of you application. Retrieving data does not require a UI, but the data library could be used in a Metro App or a Classic App. I don’t think MS wrote two version of IE from the ground up. One app for metro and one for classic. There is even a Metro remote desktop and a classic one as well. Again I don’t think these are two completely different apps written two different ways from the ground up. If you design your app right then you should be able to reuse the core logic in either metro or classic and just write different UI components.

  7. Sasha GoldshteinOctober 11, 2011 ב 8:25 AM

    @David Nelson: Yes, you can access the file system – but only approved locations. Most locations require adding capabilities to the app manifest (e.g. pictures, videos, etc.)

    @leonid: No, because most if not all WinRT APIs are wrappers on top of existing functionality in Win32 or COM components.

    @Computer Guy: Ideally you’re right, but it’s quite easy for library code to become dependent on particular APIs that might not be available in the Metro profile. And then porting – even the lower layers – might pose difficult.

  8. zzzNovember 29, 2011 ב 3:14 AM

    Is it possible to write winRT app in C?

  9. Sasha GoldshteinDecember 9, 2011 ב 8:00 AM

    @zzz: It should be possible, using the C-style COM bindings. Not very pleasant though.

  10. upsMarch 6, 2012 ב 9:46 AM

    I have a Dll that uses Win32 APis. Is it possible to use this dll (and its functions) in a Win8 Metro app?

    Thanks in advance!

  11. NewtonAugust 13, 2012 ב 4:05 AM

    Hi Sasha!

    Is it right to say that WinRT is 100% built on top of the Win32 APIs?

    I am wondering if you have found at least one example of an API that is clearly not using Win32.

    Please share your findings with us.


  12. ZwCreateMutantApril 28, 2013 ב 8:30 PM

    Just a note: ntdll.dll isn’t a part of the glorious Win32\Win64 subsystem as you listed it. Latter uses it since ntdll is the core interface between any subsystem and the NT kernel. Maybe WinRT libraries also use ntdll directly as Win32 does, apart from using it through Win32.