为什么 WinRT 不受管理?

Why is WinRT unmanaged?(为什么 WinRT 不受管理?)

问题描述

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

Windows 8 introduces WinRT, which is like .NET but unmanaged. Why is it unmanaged? Is it a performance issue? Does it mean garbage collection is not suitable for lower level APIs?

推荐答案

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

WinRT is a replacement for the age-old C-based Winapi. It is an api that must be usable in many runtime environments. Back 20 years ago, a C api was relatively easy to interop with. That has moved on since then, COM became the universal glue in the last half of the 1990s. Practically any language runtime in common use in Windows supports COM.

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

A garbage collector is a language runtime implementation detail. The collector for .NET is very different from the collector for Javascript for example. The native objects created in either must observe the very strict rules of the collector. Which in turn means that they would have had to create WinRT versions that are specific to each language runtime. That won't do, even a company as big as Microsoft cannot afford to create and support a specific WinRT version for every language binding. Nor is it necessary, given that these languages already support COM.

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

Right now, the best binding for WinRT is C++ since COM works more efficiently with explicit memory management. With ample help from the new C++ compiler extensions that make it automatic, very similar to _com_ptr_t of old with C++/CLI-like syntax to avoid it. Binding to managed languages is relatively simple since the CLR already has excellent COM interop support. WinRT also adopted the metadata format of .NET. Afaik, no work has been done at all on managed compilers as of today.

著名的 Microsoft 程序员和博主 Larry Osterman 在现已删除的答案中留下了相当不错的评论.我会在这里引用它以保存它:

Larry Osterman, a well known Microsoft programmer and blogger, left a rather good comment in a now deleted answer. I'll quote it here to preserve it:

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

WinRT is unmanaged because the OS is unmanaged. And by designing WinRT the way it was designed, it gains the ability to be expressed in many different languages, not just C++, C# and JS. For instance, I could easily see a set of Perl modules which implement the WinRT APIs which work on the desktop. If we had implemented it in .Net, that would have been extremely difficult

这篇关于为什么 WinRT 不受管理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！