.net – Windows体系结构中的CLR,Win32,WinRT

底部的图表非常具有误导性.它显示了您作为程序员需要了解的内容.如果你创建一个WinRT应用程序,那么旧的winapi不是你直接处理的东西.它被WinRT api取代,你只能用它来获取操作系统服务.

实施方式非常不同. CLR仍然在winapi上运行,就像在桌面应用程序中一样.它与非托管代码互操作,Windows基本上是一种非托管操作系统.对于WinRT来说,它是一个基于COM的非托管api.

每个WinRT应用程序实际上都是一个进程外的COM服务器,就像30年前使用过的服务器一样.它确实以特殊模式运行,微软在管道中添加了一个额外的层,使UAC工作.它被称为“app容器”,它的工作方式类似于沙盒.就像UAC阻止程序访问某些目录或注册表项一样,如果用户没有通过UAC提示升级,则应用程序容器会阻止程序使用麻烦的winapi函数.导致可用性或安全性问题或者电池耗电过快的类型. WinRT已经取代了这种winapi功能.

COM有点臭名昭着,它是微软使用的通用互操作解决方案,但编程并不是特别容易.微软做了很多工作来使COM更加可用,主要是通过完全隐藏它.值得注意的是,类型库被替换为.winmd文件,这是一个非常强大的版本,可以表达更多细节.他们使用.NET元数据的数据格式.

他们隐藏COM的关键方式是内置于各种运行时支持库中的语言投影.对于C,它隐藏在C/C++X语言扩展和运行时库中.对于Javascript,它隐藏在Chakra执行引擎中.对于托管代码,它隐藏在.NET框架内,并在参考程序集中使用[TypeForwardedTo].语言投影从WinRT类型和行为转换为特定于语言的类型.基本的东西,比如COM错误代码被转换为异常. WinRT HSTRING类型转换为System.String.等等.

在一些地方,语言投影透过裂缝窥视,在奇怪的看似限制中可见.像WinRT组件必须始终是密封类,COM的副作用不支持实现继承.或者,您可以在组件中公开DateTimeOffset,但不能在DateTime中公开.并且一些WinRT类型不能很好地映射到.NET类型,IBuffer是臭名昭着的.