Windows 8引入了WinRT，它类似于.NET但不受管理。 为什么不受管理？这是性能问题吗？这是否意味着垃圾收集不适合低级API？
答案 0 :(得分：190)
WinRT是基于C语言的古老Winapi的替换。它是一个必须在许多运行时环境中可用的API。回到20年前，C api相对容易互动。从那以后，COM继续发展，在20世纪90年代后半期，COM成为了普遍的粘合剂。实际上，Windows中常用的任何语言运行库都支持COM。
垃圾收集器是一种语言运行时实现细节。例如，.NET的收集器与Javascript的收集器非常不同。在任何一个中创建的本机对象必须遵守收集器的非常严格的规则。这反过来意味着他们必须创建特定于每个语言运行时的WinRT版本。这是行不通的，即使像微软那样大的公司也无法为每种语言绑定创建和支持特定的WinRT版本。鉴于这些语言已经支持COM，也没有必要。
目前，WinRT的最佳绑定是C ++，因为COM可以更有效地使用显式内存管理。在新的C ++编译器扩展的帮助下，它使其自动化，非常类似于旧的_com_ptr_t，具有类似C ++ / CLI的语法以避免它。绑定到托管语言相对简单，因为CLR已经具有出色的COM互操作支持。 WinRT还采用了.NET的元数据格式。 Afaik，截至今日，在托管编译器上根本没有做过任何工作。
编辑：着名的微软程序员兼博主Larry Osterman在一个现已删除的答案中留下了相当不错的评论。我会在这里引用它来保存它：WinRT未受管理，因为操作系统未受管理。通过按照设计方式设计WinRT，它可以用许多不同的语言表达，而不仅仅是C ++，C＃和JS。例如，我可以很容易地看到一组Perl模块，这些模块实现了可在桌面上运行的WinRT API。如果我们在.Net中实现它，那将是非常困难的
答案 1 :(得分：25)
WinRT是不受管理的，因为它旨在替代Win32-- Windows的最低级开发人员可访问API。非托管API仍然是可以向开发人员公开的最具潜在性能的API，并且推理总是可以将托管API包装在其上，这正是“预测”所做的。
这也意味着C ++开发人员可以在不跳过C ++ / CLI引入的环节的情况下使用WinRT（参见http://www2.research.att.com/~bs/bs_faq.html#CppCLI）这意味着如果你想使用WinRT，你仍然需要学习COM。
真正的问题是'为什么COM是必要的？为什么微软必须发明它呢？因为没有COM的所有附加功能的普通C ++不适合真正的OOP工作，并且Stroustrup声称C ++给你的“可移植性”在工作现实方面是非常不诚实的。见http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/