为什么不对WinRT进行托管？[关闭]

164

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

c# .net windows-8 windows-runtime

— 用户名
source

这是一个坏电话，就像关闭它一样糟糕。现在，您坚持使用参考文献和资料来源，并且通过关闭问题来将其切断。现在，您从从事此工作的程序员那里删除了出色的资源。

— 汉斯·帕桑

我投票否定主题，因为这没有解决实际的编程问题。只是好奇而已。由于这个问题，没有程序员会更改其代码。

— Raymond Chen

@Kev通过这种推理，诸如“地球是如何形成的？”之类的问题的在科学界绝对是可怕的，因为它引起了很多宗教猜测。这个问题有很好的答案-仅仅因为它吸引了很多错误的答案，并不意味着这是一个不好的问题。真的，为什么不将这个问题转移到P.SE？

— 宫坂丽（Rei Miyasaka）2012年

@casperOne对于许多开发人员来说，这是一个合法的“白板”问题-我们想知道该决定的大概技术原因，以便我们可以在其他地方应用相同的推理。是因为垃圾收集器难以分析？是因为它可以更轻松地访问较低级别的硬件抽象吗？如果没有技术原因，那就很不幸了，但这与问题本身的质量完全无关。

— 宫阪丽

我同意@HansPassant; 此问题需要重新打开并视为有效。“为什么它不受管理？” 关于WinRT基础知识，这是一个很好的问题。

— 罗伯·帕金斯

Answers:

190

WinRT 替代了古老的基于C的Winapi。它是必须在许多运行时环境中使用的api。早在20年前，C api相对易于互操作。从那时起，这种情况一直在发展，COM成为1990年代后半叶的通用粘合剂。实际上，Windows中常用的任何语言运行库都支持COM。

垃圾收集器是语言运行时实现的详细信息。例如，.NET的收集器与Javascript的收集器有很大不同。在任何一个中创建的本机对象必须遵守收集器的非常严格的规则。反过来，这意味着他们将不得不创建特定于每种语言运行时的WinRT版本。那是行不通的，即使像Microsoft这样大的公司也负担不起为每种语言绑定创建和支持特定的WinRT版本。鉴于这些语言已经支持COM，所以也没有必要。

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

编辑：著名的Microsoft程序员和博客作者Larry Osterman在一个已删除的答案中留下了相当不错的评论。我在这里引用它来保存它：

WinRT不受管理，因为操作系统不受管理。通过按设计方式设计WinRT，它具有用多种不同语言（不仅仅是C ++，C＃和JS）表达的能力。例如，我可以很容易地看到一组Perl模块，这些模块实现了可在桌面上运行的WinRT API。如果我们在.Net中实现它，那将非常困难

— 汉斯·帕桑特
source

我不了解编译器，但是我很确定WinRT .NET投影在CLR上做了很多工作。他们可能重用了COM Interop代码，但也存在差异（例如，IInspectable让您执行诸如查询对象的实际类类型或所有受支持接口的列表之类的操作，并使用winmd文件可以将WinRT元数据将其投射到Reflection中）。而且winmd文件也不能立即用作互操作程序集，CLR必须专门处理它们。

— 帕维尔·米纳夫2011年

不确定，您忽略了大象。IInspectable是1997年陷入困境的IDispatch的替代产品。您为Microsoft工作，可以在这里随意泄露一些秘密:)

— Hans Passant

所有3种语言均已完成工作以支持语言预测。

— 恢复莫妮卡·拉里·奥斯特曼

我声称现在“ WinRT的最佳绑定”实际上是C＃。CLR绑定甚至在非常快的COM互操作之外都进行了优化，并且开发预览中的.NET语言已经为“ await”对无处不在的异步功能提供了出色的支持。在一些示例中，C＃代码比C ++示例做得更多，并且工作起来更容易。也许以后C ++将获得异步帮助程序扩展，但是在此版本中，C ++异步看起来很糟糕。与周期问题的C ++实现相比，从垃圾回收CLR中泄漏长期内存的可能性较小。C＃FTW！

— Govert

@Hans：第三个投影是所有CLR语言（主要是C＃和VB）的CLR。WinJS也不是一个预测，它是一组支持库。投影直接内置在Chakra JS引擎中。

— 恢复莫妮卡·拉里·奥斯特曼

WinRT不受管理，因为它打算替代Win32-Windows最低级别的开发人员可访问的API。不受管理的API仍然是最有可能表现给开发人员的一种，其推理是，始终可以将受管API封装在其之上，这正是“投影”所做的。

这也意味着C ++开发人员可以使用WinRT，而无需跳过C ++ / CLI引入的麻烦（请参阅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/

— 安兹
source

Bjarne关于C ++ / CLI的思想的更新链接： stroustrup.com/bs_faq.html#CppCLI