C++/WinRT是一个language projection for Windows Runtime (WinRT) APIs。Windows Runtime 1是Windows用来公开其API的基础架构。它旨在成为平面的基于C的Win32 API的继承者（尽管您可以同时使用Windows Runtime和Windows API）。
C++/WinRT（像任何其他语言投影一样）将基于COM的Windows NT接口转换为自然的惯用语言模式，C在C/WinRT的情况下是C++。最值得注意的是它做了3件事：

• 它通过将引用计数绑定到智能指针的对象生存期来自动化COM对象的资源管理。
• 它在COM的错误报告（基于HRESULT返回值）和基于C异常的C错误报告之间进行转换。
• 它将基于IAsyncInfo的Windows XP异步模式Map到C++20协程。

发布了几项新技术，（然后是新的）Windows作为一个交付渠道。最明显的一个是新的UI框架。据我所知，它 * 仍然 * 没有一个名字。它曾经被称为 “Metro”，“Modern UI”，“Fluent Design”。我听到的最新术语是 ”Windows Presentation Platform“。它使用Direct 2D渲染，通常使用XAML编写。
虽然经常与Windows演示平台混淆，但Windows演示平台只是该技术的客户端，而不是Windows演示平台本身的一部分。
另一个重要的点是，Windows SDK不强制使用任何特定的UI库或框架。它在经典的桌面应用程序（直接使用Win32，MFC，WTL，wxWidgets等编写）或.NET应用程序（Windows Forms，WPF）中的工作效果与在XAML/Windows Presentation Platform UI应用程序中的工作效果一样好。
1* Windows SDK使用COM的现代化版本公开。组件可以使用多种语言进行消费和创作。组件使用符合ECMA-335的元数据（.winmd文件）对其公共接口进行编码。该技术本身不依赖于.NET或SDK。*

IInspectable的回答事实上是正确的，但多一点上下文可能也会有所帮助...
C++/CX（也称为Visual C++ /ZW开关）、Windows运行时库（WRL）和C++/WinRT基本上都做同样的事情：提供一种从C调用“Windows运行时”样式API和类型以及创作“Windows运行时”样式API和类型的机制。
OP问题涉及到一个更基本的问题：Windows运行时API的意义是什么？
最初的Win32 API是为本机代码设计的，大多数程序都是用C或C编写的。组件对象模型（COM）是作为一种使用相同的基本应用程序二进制接口（ABI）来处理运行时版本控制（和许多其他功能）的方法而创建的。C是使用COM的一种更自然的方法，但从技术上讲，您仍然可以通过各种宏等来使用C。
.NET和其他Managed语言是后来沿着的，而且使用不同的呼叫机制。您可以使用原生Interop来取得Win32或COM API，但它们通常不是以“C#友善”的方式运作。各种“ Package 函数组件”已经建立，提供了更自然的C#方式，让您从根本上存取C/C API和型别。
随着互联网的发展，特别是万维网的发展，另一类应用程序是使用HTML5+JavaScript编写的。它们没有任何特定的Win32或COM API访问权限，因此需要编写特殊的模块和库来弥补功能上的差距。

• 因此 *，考虑到所有这三种主要方法，“Windows运行时”风格是一种将COM的功能与. NET的反射丰富的元数据相结合的方法。其理念是，API只需编写一次，即可用于C++、C#和HTML5+JavaScript。

当然，除了能够调用ABI之外，使用API还有很多问题，而且每种语言的范例都非常不同，但从系统编程的Angular 来看，这就是问题的关键所在。
还有一个“通用Windows平台”，它使用Windows运行时API，它本身有三个基本的“应用模型”：XAML、DirectX和XAML+DirectX。如果这些应用程序是用C编写的，它们可以大量使用C/WinRT，但你也可以从Win32桌面应用程序使用Windows运行时API。
WRL实际上是“ATL 2.0”，是第一次尝试用Windows运行时API解决C互操作性问题。您可以使用它来使用和创作Windows运行时类型，但这是相当多的手工工作，而且没有很好地公开文档。Win32桌面应用程序中的主要实用工具是Microsoft::WRL::ComPtr智能指针。
如果你想知道为什么C/CX存在，请参阅this blog series。它本来是C的一个易于使用的模型，但是它经常与托管C混淆（它使用相同的保留关键字，但是与托管C或.NET完全无关），并且不受其他编译器的支持。
如果您想了解更多关于使用C/WinRT的一般原因，请参阅此MSDN Magazine article。它旨在成为使用Windows运行时API的一种更友好的C方式，可移植到其他非Microsoft编译器，它确实需要C17语言的特性，因此它对C++的质量有很大的提高编译器。“

**更新2023;**忘记WinRT和Metro Apps，改为学习UWP。

UWP（通用Windows平台），Metro和WinRT都是微软最新更改的结果，微软在很短的时间内对其应用程序框架进行了如此多的更改，我相信这就是您和许多其他开发人员面临的混乱背后的原因（source）。
这些框架背后的一个小故事：

*地铁应用

对于Windows 8，微软计划将所有东西都转移到平板电脑和移动的，并开始摆脱PC，因为他们发明了名为Metro Apps的东西。正如你可能已经注意到的，Metro应用程序，出现了一次，然后在不到一年的时间里，它们消失了。

*WinRT

正如预期的那样，微软是/是错误的“PC仍然活得很长”，所以他们不得不在Windows 8的大失败后紧急发布，为此，他们发布了Windows 8.1，他们把所有的想法都推到了那个版本中（大多数想法都是在beta版，而不是完整的WinRT），WinRT是第一次在Windows 8.1下分发的主要框架，WinRT倾向于取代Metro应用程序，主要是取代旧的Windows API“Win32”。

*UWP
通用Windows平台应用程序最终在Windows 10下发布，您可以将其视为WinRT的继任者，它是相同的技术，但只是具有一些功能的不同版本，UWP的主要功能是所有UWP应用程序都可以在PC，平板电脑和手机上运行几乎相同的二进制文件。

• 至于WPF

这是一个旧的框架，被发明来为PC制作富UI桌面应用程序。

*Windows窗体

一个死的技术，它只是在维护现在（在撰写本文时），没有更新将被释放了。
你可能会注意到所有这些技术WinRT，UWP和WPF都有类似的语法，对象，控件...等等，但不要让它愚弄你！WinRT和UWP根本不是基于WPF的，尽管它们都有.XAML文件。