为什么说WinRT取代了Windows API
Sam*_*Sam 7 windows api winapi windows-runtime desktop-bridge
几乎所有关于新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 Runtime(WinRT)API取代了Win32 API.这不是微软所说的.在许多方面,WinRT试图从.NET Framework的失败中学习取代Win32 API.这包括微软不试图推动WinRT作为替代品,而只是一种新的做事方式.
实际上,您提到的应用程序无法使用WinRT API实现的原因并不多.新的API包含了许多旧功能.您可以用C++编写WinRT应用程序,生成的应用程序是本机可执行文件,而不是托管可执行文件.甚至可以使用Win32 API的子集.
虽然Adobe通过将其应用程序移植到WinRT几乎没有收获,但预计微软会这样做.他们重写了大部分Visual Studio以使用.NET框架.如果有的话,WinRT API可以实现更多新环境.
由于种种原因，这种情况已经有所改变，但以下是您为什么要在当前Windows应用程序开发中（约2017年）在Win32上使用WinRT的原因：
- UWP应用利用WinRT
- Win32应用程序可以使用Desktop Bridge转换为UWP应用程序
- Windows 10 S 要求所有应用程序都必须通过Windows应用商店
因此，使用WinRT将为新的Windows 10 S仅商店应用程序范例调用较少的时间来转换项目和代码。
对于WinRT与Win32API与.NET，.NET和WinRT都部分地由Win32构建。IIRC，他们使用它的子集。至少在2012年，ArsTechnica在Peter Bright的文章“转向过去以推动Windows的未来：深入研究WinRT”中传达了这一信息。这就是该堆栈图的来源，或者至少是在那里使用的：
- “所有应用程序都需要通过商店”。太阳尚未升起的那一天，我会发现一些积极的东西。回到第一台带有 Windows CE 的 PDA 的时代，您可以在没有任何外部参与的情况下对自己的设备进行编程。这是一个特点。我有计算机要计算 - 我的方式。而且我不需要一些公司来循环我的开发周期。我的设备 - 我的代码。没有其他人需要在循环中。 (4认同)