为什么WinRT的非托管?WinRT

2023-09-02 20:44:58 作者:愚人自演i

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成了普遍胶在20世纪90年代的后半段。实际上在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.

编辑:拉里·奥斯特曼,一个众所周知的微软程序员和博客,留下一个相当不错的评论在现在删除的答案。我在这里引用它以preserve它:

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它被设计的方式,它的收益是pssed在许多不同的语言,而不仅仅是C ++,C#和JS EX $ P $的能力。例如,我可以很容易地看到一组的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