166

Windows 8 introduces WinRT, which is like .NET but unmanaged. Why is it unmanaged? Is it a performance issue? Does it mean garbage collection is not suitable for lower level APIs?

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
user380719
  • 9,663
  • 15
  • 54
  • 89
  • 56
    This was a *bad call*, as bad as closing it. You now insist on references and sources, you cut that off earlier by closing the question. Now you *deleted* excellent sources, from the programmers that worked on it. – Hans Passant Jul 27 '12 at 13:07
  • 9
    I voted as off topic since this does not address a practical programming question. It's just curiosity. No programmer is going to change their code as a result of this question. – Raymond Chen Jul 27 '12 at 13:23
  • @HansPassant - the deleted answers contain hearsay, speculation and personal opinion rather than actual verifiable facts. Yes there may be two or three (current and ex) MS employees chipping in on the comments but we want proper verifiable *answers*. The question itself is already suspect because it's attracting these types of answers. It's up there with questions like "Why isn't Windows written in .NET?" – Kev Jul 27 '12 at 13:31
  • 17
    @Kev By that reasoning, questions like "how was the planet Earth formed?" would have been absolutely terrible in the science community because it attracted a lot of religious speculation. There are good answers to this question -- just because it attracts a lot of bad answers doesn't mean it's a bad question. Really though, why not just move this question to P.SE? – Rei Miyasaka Aug 02 '12 at 07:01
  • @ReiMiyasaka This question is off topic for P.SE. P.SE is not the dumping ground for anything that is not constructive on Stack Overflow. – casperOne Aug 04 '12 at 23:20
  • 22
    @casperOne It's a legitimate "whiteboard" question for a lot of developers -- we want to know the presumably technical reasons for the decision, so that we might apply the same reasoning elsewhere. Is it because the garbage collector is difficult to profile? Is it because it gives easier access to lower level hardware abstractions? If there are no technical reasons, then that's simply unfortunate -- but that has nothing at all to do with the quality of the question itself. – Rei Miyasaka Aug 04 '12 at 23:32
  • @ReiMiyasaka If it was phrased as such, it's a legitimate question, but this question doesn't resemble anything near the question you posed in your comment. – casperOne Aug 04 '12 at 23:34
  • 3
    @casperOne What?? It's actually phrased almost exactly like my question: "Is it a performance issue? Does it mean garbage collection is not suitable for lower level APIs?" – Rei Miyasaka Aug 04 '12 at 23:35
  • @casperOne Maybe we should take this to meta -- I think there's something interesting to be said about the classification of a question like this one. – Rei Miyasaka Aug 04 '12 at 23:35
  • 7
    I agree, with @HansPassant; this question needs to be reopened and treated as valid. "Why is it unmanaged?" is a very good question with respect to WinRT fundamentals. – Rob Perkins Jul 18 '13 at 01:08
  • 2
    "No programmer is going to change their code as a result of this question." Really? I came here because I consider throwing out WPF for something better, and WinRT is a candidate I need to know more about. – Bent Tranberg Dec 19 '15 at 12:39
  • @bre: I'm not sure how an answer to this question would help you determine, that WinRT were somehow *"better"* than WPF. If this is about performance, then nothing fundamentally changes when using a CLR language. As with WPF, you still have lots of managed-unmanaged transitions. If you want to forego that, you'd have to pick an unmanaged programming language (C++ with or without WRL, C++/CX, C++/WinRT). That's essentially a rewrite, not just a change to your code. – IInspectable Sep 13 '18 at 09:08

2 Answers2

195

WinRT is a replacement for the age-old C-based Winapi. It is an api that must be usable in many runtime environments. Back 20 years ago, a C api was relatively easy to interop with. That has moved on since then, COM became the universal glue in the last half of the 1990s. Practically any language runtime in common use in Windows supports COM.

A garbage collector is a language runtime implementation detail. The collector for .NET is very different from the collector for Javascript for example. The native objects created in either must observe the very strict rules of the collector. Which in turn means that they would have had to create WinRT versions that are specific to each language runtime. That won't do, even a company as big as Microsoft cannot afford to create and support a specific WinRT version for every language binding. Nor is it necessary, given that these languages already support COM.

Right now, the best binding for WinRT is C++ since COM works more efficiently with explicit memory management. With ample help from the new C++ compiler extensions that make it automatic, very similar to _com_ptr_t of old with C++/CLI-like syntax to avoid it. Binding to managed languages is relatively simple since the CLR already has excellent COM interop support. WinRT also adopted the metadata format of .NET. Afaik, no work has been done at all on managed compilers as of today.

EDIT: Larry Osterman, a well known Microsoft programmer and blogger, left a rather good comment in a now deleted answer. I'll quote it here to preserve it:

WinRT is unmanaged because the OS is unmanaged. And by designing WinRT the way it was designed, it gains the ability to be expressed in many different languages, not just C++, C# and JS. For instance, I could easily see a set of Perl modules which implement the WinRT APIs which work on the desktop. If we had implemented it in .Net, that would have been extremely difficult

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 14
    I don't know about compilers, but I'm pretty sure that WinRT .NET projection had a lot of work done on CLR. They might have reused COM Interop code, but there are differences also (e.g. `IInspectable` lets you do things like query an object for its actual class type or the list of all supported interfaces, and with winmd files one can project WinRT metadata for all that into Reflection). And winmd files are not immediately usable as interop assemblies either, CLR has to handle them specially. – Pavel Minaev Sep 17 '11 at 22:16
  • 5
    Not sure, you are ignoring the elephant. IInspectable is a replacement for IDispatch which got stuck in 1997. You work for Microsoft, feel free to give away some of the secrets here :) – Hans Passant Sep 17 '11 at 22:23
  • 2
    You need to bug Larry for secrets, he's the guy who worked on it all. :) I'm not in any of the teams that had direct hand in this, so my only advantage is in seeing the preview builds earlier. Anyway, I did post my exploratory summary here: http://interrupt19h.blogspot.com/2011/09/so-what-heck-is-winrt.html - you may find it interesting. Oh, and by "elephant", do you mean weak refs / explicit object release in .NET projection? – Pavel Minaev Sep 18 '11 at 00:25
  • 1
    @Pavel - no, the elephant is RCWs not implementing IDisposable. – Hans Passant Sep 18 '11 at 01:11
  • 13
    There was work done in all 3 languages to support the language projections. – Larry Osterman Sep 18 '11 at 01:19
  • 14
    I'd claim that right now 'the best binding for WinRT' is actually C#. The CLR binding is optimised even beyond the pretty fast COM interop, and the .NET languages in the dev preview already implement excellent support for the ubiquitous async functions with 'await'. In a few of the demos the C# code did a lot more than the C++ samples, and worked more easily. Maybe later C++ will get an async helper extension, but in this version C++ async looked terrible. And you're less likely to leak long-term memory from the garbage collecting CLR than the cycle-problematic C++ implementation. C# FTW! – Govert Sep 20 '11 at 20:36
  • 1
    @Larry: C++/CX to project C++, WinJS to project Javascript, what's the third one? .NET has 2.5 languages already. – Hans Passant Sep 25 '11 at 21:40
  • @Pavel: what //build talk discussed what was changed in the clr? The 'what's new in .NET 4.5' session never mentioned WinRT. – Hans Passant Sep 25 '11 at 21:40
  • 13
    @Hans: The 3rd projection is the CLR for all CLR languages (primarily C# and VB). Also WinJS isn't a projection, it's a set of support libraries. The projection is directly built into the Chakra JS engine. – Larry Osterman Sep 26 '11 at 05:03
  • Thank you! This finally makes sense - I've been wondering a long time about it. – laktak Nov 12 '12 at 16:33
  • You may be interested that calls across componets are faster in C# than C++.. surprised me but it may be polymorphic inline caches of the jit. – user1496062 Aug 23 '13 at 06:33
  • 1
    "they would have had to create WinRT versions that are specific to each language runtime". If only there was some kind of Common Language Runtime... – J D Sep 01 '13 at 03:04
25

WinRT is unmanaged because it is intended to be a replacement for Win32 - the lowest level developer accessible API for Windows. An unmanaged API is still the most potentially performant one that can be exposed to the developer and the reasoning goes that it will always be possible to wrap a managed API on top of it, which is precisely what 'projections' do.

It also means that C++ developers can use WinRT without jumping through the hoops that C++/CLI introduces ( see https://www.stroustrup.com/bs_faq.html#CppCLI ) It does mean though that you will still have to study COM if you want to use WinRT.

The real question is 'why is COM necessary? why did Microsoft have to invent it?' Because plain C++ without all the added facilities of COM is inadequate for real OOP work and Stroustrup's claims of C++ giving you 'portability' are very very disingenuous in light of the working reality. See https://webmechs.com/webpress/2011/11/09/c-versus-objective-c-as-api-substrate/

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
Andz
  • 1,315
  • 1
  • 12
  • 14