我假设这个问题是关于 WinRT 的,否则它完全太模糊而无法回答。
底部的图表非常具有误导性。它从你作为程序员需要了解的角度展示了你的观点。如果你创建了一个 WinRT 应用程序,那么旧的 winapi 就不是你直接处理的东西了。它已被 WinRT api 取代,您只能使用它来获取操作系统服务。
实现方式非常不同。CLR 仍然很大程度上运行在 winapi 之上,就像它在桌面应用程序中一样。并且它与非托管代码互操作,Windows 本质上是一个非托管操作系统。WinRT 也是如此,它是一个基于 COM 的非托管 API。
每个 WinRT 应用程序实际上都是一个进程外 COM 服务器,就像 30 年前使用的此类服务器一样。它确实在一种特殊模式下运行,微软为使 UAC 工作的管道添加了一个额外的层。它被称为“应用程序容器”,它像沙盒一样工作。就像如果用户没有被 UAC 提示提升权限,UAC 会阻止程序访问某些目录或注册表项,应用程序容器也会阻止程序使用麻烦的 winapi 函数。那种会造成可用性或安全问题或电池耗尽过快的类型。WinRT 可以替代此类 winapi 函数。
COM 有点臭名昭著,它是微软使用的通用互操作解决方案,但它并不是特别容易编程。微软做了很多工作来使 COM 更可用,主要是完全隐藏它。值得注意的是,类型库被替换为 .winmd 文件,这是一个大大增强的版本,可以表达更多的细节。他们使用 .NET 元数据的数据格式。
他们隐藏 COM 的一个关键方式是内置在各种运行时支持库中的语言投影。对于 C++,它隐藏在 C++/CX 语言扩展和运行时库中。对于 Javascript,它隐藏在 Chakra 执行引擎中。对于托管代码,它隐藏在 .NET 框架中,在参考程序集中带有 [TypeForwardedTo]。语言投影从 WinRT 类型和行为转换为特定于语言的类型。基本的东西,如 COM 错误代码被转换为异常。WinRT HSTRING 类型被转换为 System.String。等等。
有几个地方的语言投影从裂缝中窥视,在看似奇怪的限制中可见。就像 WinRT 组件必须始终是密封类一样,COM 的副作用是不支持实现继承。或者,您可以在组件中公开 DateTimeOffset,但不能公开 DateTime。并且某些 WinRT 类型不能很好地映射到 .NET 类型,IBuffer 是臭名昭著的。