35

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?

8
  • See the tag info.
    – user207421
    Commented Feb 1, 2020 at 23:43
  • 2
    @user207421 it doesn't really answer my question. Could you help me see what I am missing? Possibly a small extract from the tag info that answers my question in its entirety? Commented Feb 1, 2020 at 23:46
  • 2
    Further reading, en.wikipedia.org/wiki/C%2B%2B/WinRT, github.com/Microsoft/cppwinrt
    – M.M
    Commented Feb 1, 2020 at 23:58
  • Looks like it has free COM authoring, would have loved to have that 15 years ago :)
    – M.M
    Commented Feb 2, 2020 at 0:03
  • @m.m: It doesn't. While MIDL 3.0 is a vast improvement over the old MIDL, you're still required to write your MIDL files if you wish to export types from your components. cppwinrt.exe does generate headers from .winmd files. But that's not entirely new. We had .TLB's 15 years ago already. Commented Feb 2, 2020 at 0:11

4 Answers 4

36

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 to 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 (WinRT) 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 UWP ("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.

1
30

C++/WinRT is a language projection for Windows Runtime (WinRT) APIs. The Windows Runtime1 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.


1 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.

32
  • 3
    Is it a complete replacement for the Win32 API? I don't see anyone talking about C++/WinRT except for the link you have in the answer. Commented Feb 1, 2020 at 23:05
  • 9
    I don't know how widely it is really used. I believe it's replaced everything that used to be WRL and C++/CX inside Microsoft. Outside Microsoft I have not ever seen a job offer that indicated use of C++/WinRT (or even just native Windows Runtime development). MS have done an entirely poor job of explaining, what the Windows Runtime is, how language projections fit into that picture, and how UWP is not the same as the Windows Runtime. It seems like everyone thinks that the Windows Runtime is managed code, best used with C#, and requires targeting the UWP (all 3 are wrong). Commented Feb 1, 2020 at 23:19
  • 5
    So what is the primary way to do Windows development nowadays? Still Win32? Some other C++ library/API? Is it something like C# and related libraries? Commented Feb 1, 2020 at 23:23
  • 5
    That really depends on what you need. For my personal tools I often just use a classic Desktop UI, a main dialog, scripted within an .rc file, plus a lot of C++/WinRT to interface with the Windows Runtime. And a fair amount of Win32 API calls, either because there's no equivalent in the Windows Runtime, or simply because it's less of a hassle to open a file in the Windows API. You can mix all of that inside a single application, even a command line application. Using XAML with C++/WinRT is still troublesome. It's fun, when it works, but it frequently doesn't. Commented Feb 1, 2020 at 23:39
  • 3
    @jul: The information is scattered around the MSDN. The most enlightening tidbit - to me - is from The Component Object Model: "COM [...] is not an object-oriented language but a standard. [...] The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers. Object-oriented languages [...] provide programming mechanisms that simplify the implementation of COM objects [...]." Commented Feb 29, 2020 at 14:03
-1

I think the first paragraph on this page explains it well: https://learn.microsoft.com/en-us/windows/win32/desktop-programming

The Win32 API (also called the Windows API) is the original platform for native C/C++ Windows applications that require direct access to Windows and hardware. It provides a first-class development experience without depending on a managed runtime environment like .NET and WinRT (for UWP apps for Windows 10). This makes the Win32 API the platform of choice for applications that need the highest level of performance and direct access to system hardware.

It doesn't sound like it's a replacement or successor to Win32.

-3

I visted this post to know what Qt installer-binary to download/use; that with WinRT suffix or that without WinRT suffix.

But existing answers really don't help.

And it seems, because I need to support Windows 7, I will download/use that without WinRT suffix.

Note that ucrt and msvcrt suffixed binaries seem to both run fine on Windows 7, check other suffixes instead.

In detail

  • Win32 : since 32 bit epoch (but Win32 is API name, has nothing to do with 32 bit vs 64 bit, and is even used by 64 bit binaries).
  • Metro : since Windows 8.0 (but died shortly after).
  • WinRT : since Windows 8.1.
  • UWP (Universal Windows platform) : since Windows 10, and can NOT run on Windows 7, but is allowed to use good old Win32 (Win32 does not die soon).

Why Windows 7?

In some countries, shops called "Game Net" exist, which're basically just arcade shops, but with only PCs, and all connected to same LAN (local area network).

Windows 7 uses less RAM and CPU, and as a plus, many PCs have free license to use Windows 7.

Hence, such PCs are optimal choice for said Game Nets, and it is very much desirable to support Windows 7.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.