在几乎每篇关于新 WinRT API 的文章中，我都会提到“WinRT 是 Windows 的新 API，并取代了旧的 Win32 API”。由于 WinRT 的目标是开发 Windows 应用商店应用程序，因此对我来说，这种说法似乎并不成立。
有很多我无法想象用 WinRT 完成的应用程序（例如 Microsoft Office、Adobe Products、3D Designer Programs 甚至 Visual Studio）。这些应用程序仍然需要 Windows API（又名 Win32）的功能。
那么为什么经常说 WinRT API 取代了 Windows API 呢？
最近由于几个原因，这种情况发生了变化，但以下是在当前 Windows 应用程序开发（大约 2017 年）中为什么要使用 WinRT 而不是 Win32 的简要说明：
因此，使用 WinRT 将花费更少的时间为新的 Windows 10 S Store-only 应用程序范例转换项目和代码。
关于 WinRT 与 Win32API 与 .NET，.NET 和 WinRT 都是部分使用 Win32 构建的；IIRC，他们使用它的子集。至少这是 2012 年 ArsTechnica 在 Peter Bright 的文章“转向过去为 Windows 的未来提供动力：深入了解 WinRT”中传达的内容。这就是这个堆栈图的来源，或者至少它在那里被使用过：
我不确定是否经常说 Windows 运行时 (WinRT) API 取代了 Win32 API。这不是微软所说的。在许多方面，WinRT 试图从 .NET Framework 的失败中吸取教训，以取代 Win32 API。这包括微软没有试图将 WinRT 作为替代品，而只是一种新的做事方式。
实际上，您提到的应用程序无法使用 WinRT API 实现的原因并不多。新 API 包含许多旧 API 的功能。您可以使用 C++ 编写 WinRT 应用程序，生成的应用程序是本机可执行文件，而不是托管的。甚至可以使用 Win32 API 的子集。
虽然 Adobe 将其应用程序移植到 WinRT 并没有什么好处，但预计微软会这样做。他们重写了大部分 Visual Studio 以使用 .NET 框架。如果有的话，WinRT API 使得在新环境中实现更多功能变得切实可行。