c# - 为什么 WinRT 不受管理？

Question

Windows 8 引入了 WinRT，它类似于 .NET，但不受管理。为什么不受管理？是性能问题吗？这是否意味着垃圾收集不适合较低级别的 API？

Answer 1

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

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

目前，最好的 WinRT 绑定是 C++，因为 COM 通过显式内存管理更有效地工作。在新的 C++ 编译器扩展的充分帮助下，使其自动化，非常类似于旧的 _com_ptr_t，使用类似 C++/CLI 的语法来避免它。绑定到托管语言相对简单，因为 CLR 已经具有出色的 COM 互操作支持。WinRT 还采用了 .NET 的元数据格式。Afaik，到目前为止，托管编译器还没有完成任何工作。

编辑：著名的 Microsoft 程序员和博主 Larry Osterman 在现已删除的答案中留下了相当不错的评论。我将在此处引用它以保留它：

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

Answer 2

WinRT 是非托管的，因为它旨在替代 Win32 - Windows 的最低级别的开发人员可访问的 API。非托管 API 仍然是可以向开发人员公开的最具潜在性能的 API，其理由是始终可以在其上包装托管 API，这正是“投影”所做的。

这也意味着 C++ 开发人员可以使用 WinRT 而无需跳过 C++/CLI 引入的障碍（请参阅https://www.stroustrup.com/bs_faq.html#CppCLI）这确实意味着如果您仍然需要学习 COM你想使用 WinRT。

真正的问题是‘为什么需要 COM？为什么微软必须发明它？因为没有 COM 的所有附加功能的普通 C++ 不足以用于真正的 OOP 工作，而且 Stroustrup 声称 C++ 为您提供“可移植性”在工作现实中是非常非常不诚实的。见https://webmechs.com/webpress/2011/11/09/c-versus-objective-c-as-api-substrate/