What is C++/WinRT exactly?

Question

I have been searching around the web. I get that:

C++/WinRT is provided as a standard C++17 header file library

But what is it really? Is it a new Object oriented replacement for the age-old Win32 API? Is it a replacement for the Qt framework on Windows? Is it a networking library (most examples seem to be about networking). Is it a GUI framework? Is it the preferred way to write new Windows applications? Is it a replacement for the infamous MFC library?

Answer 1

C++/WinRT is a language projection for Windows Runtime (WinRT) APIs. The Windows Runtime¹ is the foundational infrastructure used by Windows to expose its APIs. It is intended to be the successor to the flat, C-based Win32 API (although you can use the Windows Runtime and the Windows API side by side).

C++/WinRT (like any other language projection) translates the COM-based Windows Runtime interfaces to natural, idiomatic language patterns, C++' in case of C++/WinRT. Most notably it does 3 things:

• It automates resource management of COM objects by binding the reference counting to object lifetimes of smart pointers.
• It translates between COM's error reporting (based on HRESULT return values) and C++ error reporting based on C++ exceptions.
• It maps the Windows Runtime's asynchronous patterns based on IAsyncInfo to C++20 coroutines.

---

Several new technologies were published using the (then new) Windows Runtime as a delivery channel. The most obvious one being the new UI framework. To my knowledge, it still doesn't have a name. It used to go by the names "Metro", "Modern UI", "Fluent Design". The latest term I've heard it called was "Windows Presentation Platform". It's rendered using Direct2D, and commonly authored using XAML.

While often conflated with the Windows Runtime, the Windows Presentation Platform is merely a client of the technology. It is not part of the Windows Runtime itself.

Another important point is, that the Windows Runtime does not mandate use of any particular UI library or framework. It works equally well in a classic desktop app (written in straight Win32, MFC, WTL, wxWidgets, ...) or a .NET application (Windows Forms, WPF) as it does in an application with a XAML/Windows Presentation Platform UI.

---

¹The Windows Runtime is exposed using a modernized version of COM. Components can be consumed and authored by a wide variety of languages. Components encode their public interfaces using ECMA-335 conforming metadata (.winmd files). The technology itself does not rely on .NET or the CLR.

Answer 2

IInspectable's answer is factually correct, but a little more context might help as well...

C++/CX (a.k.a. the Visual C++ /ZW switch), Windows Runtime Library (WRL), and C++/WinRT all do basically the same thing: Provide a mechanism for calling "Windows Runtime" style APIs & types from C++ and for authoring "Windows Runtime" style APIs & types.

The OP question gets to a more fundamental question: What is the point of Windows Runtime APIs?

The original Win32 API was designed for a native code world, and most programs were written in C or C++. The Component Object Model (COM) was created as a way to handle runtime versioning (and many other features) using the same basic Application Binary Interface (ABI). C++ is a more natural way to use COM, but you can still technically use C through various macros and what not.

.NET and other managed languages came along later, and use a different calling mechanism. You can use native interop to get to Win32 or COM APIs, but they generally don't work in a very "C# friendly" way. Various 'wrapper assemblies' have been created provide a more C# natural way to access fundamentally C/C++ APIs & types.

With the growth of the Internet and in particular the Worldwide Web, another class of applications are written using HTML5+JavaScript. They don't have any specific access to Win32 or COM APIs so special modules & libraries are written to cover the functionality gaps.

SO given all three of these major approaches, "Windows Runtime" style is an approach which combines the features of COM with the reflection-rich metadata of .NET. The idea being that an API could be written once and be usable by C++, C#, and HTML5+JavaScript.

Of course there are a lot of issues with using an API beside just being able to call the ABI, and each of those language paradigms are quite different, but from systems programming view that's the point of it all.

There is also a "Universal Windows Platform" that uses Windows Runtime APIs which itself has three basic 'appmodels': XAML, DirectX, and XAML+DirectX. These are the kinds of applications that can make heavy use of C++/WinRT if they are written in C++, but you can also use Windows Runtime APIs from Win32 desktop apps.

WRL is really "ATL 2.0" and was the first attempt at a solution for C++ interop with Windows Runtime APIs. You can use it to consume and author Windows Runtime types but it's a fair amount of manual work and not documented publicly very well. The primary utility in Win32 desktop applications is the Microsoft::WRL::ComPtr smart-pointer.

If you want to know why C++/CX exists, see this blog series. It was intended to be an easy-to-use model for C++, but it's often conflated with Managed C++ (it uses the same reserved keywords, but is not at all related to Managed C++ or .NET) and not supported by other compilers.

If you want to know more about the general reason for C++/WinRT, see this MSDN Magazine article. This is intended to be a much more C++-friendly way to use Windows Runtime APIs, is portable to other non-Microsoft compilers, and is increasingly being used both internally and externally for Windows Runtime development. It does require C++17 language features and therefore pushes hard on the quality of your C++ compiler.