为什么 WinRT 是非托管的？

WinRT 是一个 替代品，用于古老的基于 C 的 Winapi。它是一个必须在许多运行时环境中可用的 api。20年前，C api 相对容易互操作。从那以后，COM 成为了90年代后半期的万能胶。实际上，Windows 中常用的任何语言运行库都支持 COM。

垃圾收集器是语言运行时实现细节。收藏家。NET 与 Javascript 的收集器有很大的不同，例如。在其中一个中创建的本机对象必须遵守收集器的非常严格的规则。这反过来意味着他们必须创建特定于每个语言运行时的 WinRT 版本。这是不行的，即使像微软这样的大公司也没有能力为每个语言绑定创建和支持特定的 WinRT 版本。也没有必要，因为这些语言已经支持 COM。

目前，WinRT 最好的绑定是 C + + ，因为 COM 在显式内存管理中工作效率更高。在新的 C + + 编译器扩展的大量帮助下，使其自动化，非常类似于旧的 _ com _ ptr _ t，使用类似 C + +/CLI 的语法来避免它。与托管语言的绑定相对简单，因为 CLR 已经具有优秀的 COM 互操作支持。WinRT 还采用了。NET.Afaik，到目前为止还没有对托管编译器做过任何工作。

编辑: 拉里奥斯特曼，一个著名的微软程序员和博客写手，留下了一个相当不错的评论在一个现已删除的答案。为了保护它，我在这里引用一下:

WinRT 是非托管的，因为操作系统是非托管的。通过按照设计的方式设计 WinRT，它获得了用许多不同语言表达的能力，而不仅仅是 C + + 、 C # 和 JS。例如，我可以很容易地看到一组 Perl 模块，它们实现了在桌面上工作的 WinRT API。如果我们在。网络，这将是非常困难的

WinRT 是非托管的，因为它旨在取代 Win32—— Windows 中可访问的最低级别的开发人员 API。非托管 API 仍然是可以公开给开发人员的最具潜在性能的 API，理由是总是可以在其上包装托管 API，这正是“预测”所做的。

这也意味着 C + + 开发人员可以使用 WinRT 而不必跳过 C + +/CLI 引入的框架(参见 https://www.stroustrup.com/bs_faq.html#CppCLI)这确实意味着如果你想使用 WinRT，你仍然需要学习 COM。

真正的问题是“为什么 COM 是必要的?”？为什么微软要发明它？因为普通的 C + + 没有 COM 的所有附加设施对于真正的 OOP 工作来说是不够的，而且 Stroustrup 声称 C + + 给了你“可移植性”，这在实际工作中是非常虚伪的。参见 https://webmechs.com/webpress/2011/11/09/c-versus-objective-c-as-api-substrate/