为什么说WinRT取代了Windows API

在几乎每一篇关于新的WinRT API的文章中，我都会提到“WinRT是Windows的新API，它取代了旧的Win32 API”。由于WinRT的目标是开发Windows应用商店应用程序，我认为这句话似乎不成立

有很多我无法想象的应用程序可以用WinRT完成（例如Microsoft Office、Adobe产品、3D Designer程序甚至Visual Studio）。这些应用程序仍然需要Windows API（又称Win32）的功能

---

那么，为什么人们经常说WinRT API取代了Windows API呢

我不确定是否经常有人说Windows运行时（WinRT）API取代了Win32 API。这不是微软所说的。在许多方面，WinRT试图从.NET Framework的失败中吸取教训，以取代Win32 API。这包括微软没有试图将WinRT作为替代品，而仅仅是一种新的做事方式

实际上，您提到的应用程序不能使用WinRT API实现的原因并不多。新的API包含许多旧API的功能。您可以在C++中编写WrRT应用程序，结果应用程序是本地可执行文件，而不是托管程序。甚至可以使用Win32 API的一个子集

---

虽然Adobe将其应用程序移植到WinRT并没有什么好处，但预计微软会这么做。他们重写了大部分VisualStudio以使用.NET框架。如果说WinRT API使在新环境中实现更多功能变得切实可行的话。

最近由于几个原因，这种情况发生了一些变化，但下面简要介绍了在当前Windows应用程序开发（大约2017年）中为什么要在Win32上使用WinRT：

WinRT被UWP应用程序利用

Win32应用程序可以使用桌面网桥转换为UWP应用程序

Windows10s

因此，对于新的Windows10sStoreOnly应用程序范例，使用WinRT将调用更少的时间来转换项目和代码

在WinRT与Win32API与.NET的对比中，.NET和WinRT都部分使用Win32构建；IIRC，他们使用它的子集。至少这是2012年阿斯特尼卡在彼得·布莱特的文章中传达的。这就是这个堆栈图的来源，或者至少在那里使用过：

---

微软的目标是建立一个“通用”的应用平台，该平台可在所有设备（如手机、台式机、笔记本电脑和笔记本电脑）上统一运行。传统的Win32 API在Windows开发的整个历史中都是不可或缺的一部分，几乎不可能完全取代它。无论是好的、坏的、对的还是错的，我们的愿望都是让WinRT为开发人员指明所谓的Windows通用应用程序的方向。微软在推出.NET时也尝试过同样的方法，看看结果有多好（不好）。这只是“下一个流行趋势”，等待足够长的时间，它会再次消失。嗨，山姆，在过去的一年里，这个问题发生了变化。请检查我的新答案，以防影响您或您的团队。谢谢您的回复。实际上，.NET框架似乎是建立在Win32（或至少是它的一部分）之上的，如果您查看一下框架实现的内部，就会发现这一点。例如，我提到的应用程序使用了很多子窗口。VisualStudio需要做很多WinRT不允许的事情。如果其他应用程序禁止访问应用程序（沙箱），您将如何调试该应用程序？当然，.NET使用Win32，但这并不意味着它不打算取代Win32。Win32本身是基于本机NT API构建的。就像没有人使用本机NT API一样，微软期望.NET将取代Win32，也不再有人使用Win32 API。我不知道你所说的“子窗口”是什么意思，但WinRT（现在）支持多个窗口。并非所有VisualStudio都可以使用WinRT API实现，至少现在是这样，但大部分都可以。API在其当前状态下是不固定的。WinRT本身使用Win32 API的方式与.NET类似。从这个意义上讲，它也不是一个替代API。“所有需要通过商店的应用程序”。太阳还没有升起，在这一天我会发现一些积极的东西。在第一次使用Windows CE的PDA时，您可以在没有任何外部参与的情况下为自己的设备编程。这是一个特点。我有计算机来计算——我的方式。我不需要一些公司来循环我的开发周期。我的设备-我的代码。没有其他人需要参与循环。我甚至不打算为他们的设计辩护：）这有点辩护：“为什么你想在Win32上使用WinRT”