As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

47

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 PassantJul 27 '12 at 13:07

7

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 ChenJul 27 '12 at 13:23

15

@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 MiyasakaAug 2 '12 at 7:01

20

@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 MiyasakaAug 4 '12 at 23:32

4

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 PerkinsJul 18 '13 at 1:08

2 Answers
2

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

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 MinaevSep 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 PassantSep 17 '11 at 22:23

13

There was work done in all 3 languages to support the language projections.
–
Larry OstermanSep 18 '11 at 1:19

12

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!
–
GovertSep 20 '11 at 20:36

12

@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 OstermanSep 26 '11 at 5:03

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.