Windows CE采用了典型的分层结构。
在Windows CE 5.0的文档中,微软公司将其分为四个层次,从下到上依次为:
硬件层;
OEM层;
操作系统层;
应用程序层。
而在Windows Embedded CE 6.0中却划分为User Mode(用户模式)和Kernel Mode(内核模式)两个“层”,CoreDLL等DLL同时出现在两个层中,驱动程序也可以被加入到内核中,以前的.exe可执行模块基本上都变成了.dll。体系结构的变化相对较大。
硬件层;
OEM层;
操作系统层;
应用程序层。
而在Windows Embedded CE 6.0中却划分为User Mode(用户模式)和Kernel Mode(内核模式)两个“层”,CoreDLL等DLL同时出现在两个层中,驱动程序也可以被加入到内核中,以前的.exe可执行模块基本上都变成了.dll。体系结构的变化相对较大。
Windows Embedded CE 6.0的体系结构如下图所示。

回顾一下Windows CE 5.0是如何将各个模块结合在一起的,它被设计成一种围绕服务而存在的用户模式的进程,叫做PSLs(Process Server Libraries,进程服务库),NK.exe在内核态下运行,而操作系统的其他部分则各自独立地运行在用户模式下,比如文件系统Filesys.exe、图形窗口和事情子系统GWES.exe、驱动管理器Device.exe。这样分开的设计让操作系统更加健壮,但这些为整个操作系统提供主要功能的服务提供者却是以不同进程的身份出现,如果要使用某操作系统提供的服务,则会使得至少发生一次的进程切换,就连一个简单的函数调用都不例外。这对系统的效率影响是比较大的。
而Windows Embedded CE 6.0却不同,它将所有系统需要提供的服务部分“转移”到系统内核的虚拟机(Kernel’s Virtual Machine),这样做的好处是当发生系统调用时,已经变成了进程内的一个调用。这样做也引入了一些不稳定机制,比如驱动程序被加入到内核,Windows Embedded CE 6.0默认情况下就是将驱动运行在内核模式。虽然提高了系统的效率,但如果驱动程序不稳定,将对系统的整体稳定性产生非常严重的影响,这也是我们所不愿意看到的。当然,并不是所有的驱动程序都是在内核运行的,在Windows Embedded CE 6.0安装完成之后的驱动程序是在用户模式下运行的,这样更有利于系统的安全,但以牺牲设备的性能为代价。下图展示了Windows Embedded CE 6.0里的系统模块。

通过上图大家会发觉,以前在Windows CE 5.0中的各种系统模块,比如Filesys.exe、Device.exe、GWES.exe等,都变成了Filesys.dll、GWES.dll、Device.dll,只有NK.exe还是原来的名字,变的不仅仅是名字,因为在Windows Embedded CE 6.0中这些服务已经不再是一个个单独进程,而是一个个系统调用。虽然NK.exe的名字没有变,但已经不再是Windows CE 5.0中的NK.exe了,Windows CE 5.0中NK.exe提供的各种功能将由Kernel.dll来替代,NK.exe中仅仅包含一些OAL代码和保证兼容性的程序,这样做的好处是使得OEMs和ISVs厂商定制的代码和微软提供的Windows Embedded CE 6.0的代码进行了分离,使得内核代码的升级更加容易且更加方便。
以上可以看出,系统的架构变化是比较大的,这对Windows CE的二次开发厂商来说并不是什么好消息,因为这意味着很多建立在老版本上的驱动必须进行很大规模的重新设计,但微软公司告诉他们这个过程是非常简单的,因为微软公司设计了一个补救措施,这就是图3-7中处在内核模式的一个有着古怪名字的DLL——K.Coredll.dll,名字与K.Coredll.dll非常相似,事实上它就是为了模拟K.Coredll.dll,K.Coredll.dll仍然在用户模式下运行,当内核模式下的代码调用某些在Windows CE 5.0处于用户模式下而在Windows Embedded CE 6.0中已经转移到内核模式下的API时,K.Coredll.dll则会把这个调用请求转向内核模式中相应的dll。K.Coredll.dll并不是唯一有这种机制的DLL,其他的DLL只要需要,也可以采用这种策略。
没有评论:
发表评论