Why is WinRT unmanaged? [closed]

Solution 1:

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

Solution 2:

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/