为什么WinRT不受管理?

use*_*719 164 .net c# windows-8 windows-runtime

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

Han*_*ant 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,截至今天,在托管编译器上根本没有做过任何工作.

编辑:着名的微软程序员和博主拉里奥斯特曼在一个现已删除的答案中留下了相当好的评论.我会在这里引用它来保存它:

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

  • 我不知道编译器,但我很确定WinRT .NET预测在CLR上做了很多工作.他们可能已经重用了COM Interop代码,但也存在差异(例如``IInspectable`允许你执行诸如查询对象的实际类类型或所有支持的接口列表之类的东西,并且使用winmd文件可以为所有人调整WinRT元数据进入反思).并且winmd文件也不能立即用作互操作程序集,CLR必须专门处理它们. (13认同)
  • 所有3种语言都有工作来支持语言预测. (13认同)
  • 我声称现在'WinRT的最佳绑定'实际上是C#.CLR绑定甚至超越了相当快的COM互操作,并且开发预览中的.NET语言已经通过'await'实现了对无处不在的异步功能的出色支持.在一些演示中,C#代码比C++代码做了很多,并且更容易工作.也许以后C++会得到一个异步助手扩展,但在这个版本中,C++ async看起来很糟糕.并且你不太可能从垃圾收集CLR泄漏长期内存,而不是循环问题的C++实现.C#FTW! (13认同)
  • @Hans:第三个投影是所有CLR语言的CLR(主要是C#和VB).此外,WinJS不是投影,它是一组支持库.投影直接内置在Chakra JS引擎中. (13认同)
  • 不确定,你是在忽视大象.IInspectable是1997年陷入困境的IDispatch的替代品.你为微软工作,随时可以泄露一些秘密:) (5认同)
  • 你需要向Larry提出秘密的秘密,他就是那个为此工作的人.:)我不是任何直接参与其中的团队,所以我唯一的优势就是更早看到预览版本.无论如何,我确实在这里发布了我的探索性摘要:http://interrupt19h.blogspot.com/2011/09/so-what-heck-is-winrt.html - 你可能会发现它很有趣.哦,以及"大象",你的意思是.NET投影中的弱refs /显式对象释放? (2认同)

And*_*ndz 25

WinRT是不受管理的,因为它旨在替代Win32 - Windows的最低级开发人员可访问API.非托管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/