Introduction
There have been lot of questions regarding differences between Windows CE 5.0 and Windows CE 6.0, and we thought it would be useful to Windows CE developers and OEMs (original equipment manufacturers) to know more about these changes. This article is the first in a series of articles on this subject.
The major changes in CE 6.0 are:
The existing implementation of CE 5.0 supports only 32 MB per process and is based on the Slot implementation. Every process apart from its native slot (Slot 2 33) used Slot 0 while running. For example, as mentioned in Figure 1, if filesys.exe running from Slot 2 has to run, then it has to run from Slot 0. So, if a.exe belonging to Slot 24 is running from Slot 0 apart from its native slot 24, all other processes also occupy the respective virtual address space. This actually leads to a waste in Virtual address space. A quick question would be, therefore, why was such an architecture arrived at when it was known that it is not scalable. The answer to this is beyond the scope of this article, and shall be discussed separately in future articles.
Figure 1
Windows CE 6.0 has moved toward more of a desktop OS format. Each process can now occupy up to 1 GB of address space, and the number of processes can be up to 32K. Microsoft confirms that it has tested up to 2600 processes running simultaneously. The process switching function is more like desktop like process switching; for example, every time a process switch happens, the entire TLB is flushed, data and instruction cache is invalidated, and fresh page tables are created (if the process is new). Compared to Windows CE 5.0, this should take more time to switch a process. Figure 2 illustrates the architecture in Windows CE 6.0.
Figure 2
You can see that Windows CE allows a user process to go up to 1 GB. The other 1 GB is allocated to DLLs, shared memory, and Kernel shared heap. The shared memory is for backward compatibility with CE 5.0 for sharing of files across processes. The DLLs, which were earlier restricted to 32MB of space (Slot 1), are now allowed to have 512MB of virtual address space starting from 0x40000000. An key aspect of this new architecture is that one process cannot view another process data directly, unlike in Windows CE 5.0. A process has to go through the kernel API to get data from other processes.
Device driver architecture changes
CE 6.0 implements both kernel mode device drivers and user mode device drivers. The use of kernel mode drivers provides enhanced security and robustness. OEMs can prevent drivers from gaining accesses to kernel resources by third party drivers, and hence can offer more security to his installation. OEMs can ship products with kernel mode drivers for all of the peripherals they supply, and for add on peripherals they can allow third parties to load kernel drivers only if they are signed by them, otherwise the drivers are restricted to run in user mode. However, user mode drivers are restricted to use Virtual Copy for only the memory space defined in the registry. In contrast, Windows CE 5.0 allowed user mode drivers to Virtual Copy any memory region other than the ones mentioned in the registry for them.
In CE 6.0, Filesys.exe, device.exe, and GWES.exe -- which were earlier part of user mode -- have been moved in to kernel mode. Calls to SetKMode and setting process permissions, so that other processes can be accessed, are not possible due to the reasons mentioned above. Consequently, drivers that use these calls have to be rewritten.
System call performance
In CE 5.0, system calls from a user application to a service process such as GWES.exe was tedious. A trap signals the event of the system call to the kernel. The kernel then switches the process to the service executable GWES.exe. Once GWES.exe returns, the kernel switches the process back to the user application. In CE 6.0, since GWES.exe is part of the kernel, there is no process switching and the user application goes to its application. This is very similar to what takes place in the desktop architecture. The flow chart shown in Figure 3 illustrates that.
Figure 3
Conclusion
With the release of CE 6.0, Microsoft has added lot more technologies, and has also renamed the OS from "Windows CE" to "Windows Embedded CE." Of significance, CE 6.0 boasts many security feature enhancements and performance improvements, such as moving filesys.exe, device.exe and GWES.exe into the kernel. OEMs have also gained an OAL update feature that will be provided by Microsoft from time to time, so that when there are bug fixes, they won't need rebuild the images and can just update the OAL on the fly. The next few articles in this series will explore new technologies in Windows CE 6.0 and also how to port a BSP from CE 5.0 to CE 6.0.
There have been lot of questions regarding differences between Windows CE 5.0 and Windows CE 6.0, and we thought it would be useful to Windows CE developers and OEMs (original equipment manufacturers) to know more about these changes. This article is the first in a series of articles on this subject.
The major changes in CE 6.0 are:
- Process address space is increased from 32MB to 1 GB.
- Number of processes has been increased to 32K from 32.
- User mode and kernel mode device drivers are possible.
- Device.exe, filesys.exe, GWES.exe has been moved to Kernel mode.
- SetKMode and set process permissions not possible.
- System call performance will improve.
The existing implementation of CE 5.0 supports only 32 MB per process and is based on the Slot implementation. Every process apart from its native slot (Slot 2 33) used Slot 0 while running. For example, as mentioned in Figure 1, if filesys.exe running from Slot 2 has to run, then it has to run from Slot 0. So, if a.exe belonging to Slot 24 is running from Slot 0 apart from its native slot 24, all other processes also occupy the respective virtual address space. This actually leads to a waste in Virtual address space. A quick question would be, therefore, why was such an architecture arrived at when it was known that it is not scalable. The answer to this is beyond the scope of this article, and shall be discussed separately in future articles.
Figure 1
Windows CE 6.0 has moved toward more of a desktop OS format. Each process can now occupy up to 1 GB of address space, and the number of processes can be up to 32K. Microsoft confirms that it has tested up to 2600 processes running simultaneously. The process switching function is more like desktop like process switching; for example, every time a process switch happens, the entire TLB is flushed, data and instruction cache is invalidated, and fresh page tables are created (if the process is new). Compared to Windows CE 5.0, this should take more time to switch a process. Figure 2 illustrates the architecture in Windows CE 6.0.
Figure 2
You can see that Windows CE allows a user process to go up to 1 GB. The other 1 GB is allocated to DLLs, shared memory, and Kernel shared heap. The shared memory is for backward compatibility with CE 5.0 for sharing of files across processes. The DLLs, which were earlier restricted to 32MB of space (Slot 1), are now allowed to have 512MB of virtual address space starting from 0x40000000. An key aspect of this new architecture is that one process cannot view another process data directly, unlike in Windows CE 5.0. A process has to go through the kernel API to get data from other processes.
Device driver architecture changes
CE 6.0 implements both kernel mode device drivers and user mode device drivers. The use of kernel mode drivers provides enhanced security and robustness. OEMs can prevent drivers from gaining accesses to kernel resources by third party drivers, and hence can offer more security to his installation. OEMs can ship products with kernel mode drivers for all of the peripherals they supply, and for add on peripherals they can allow third parties to load kernel drivers only if they are signed by them, otherwise the drivers are restricted to run in user mode. However, user mode drivers are restricted to use Virtual Copy for only the memory space defined in the registry. In contrast, Windows CE 5.0 allowed user mode drivers to Virtual Copy any memory region other than the ones mentioned in the registry for them.
In CE 6.0, Filesys.exe, device.exe, and GWES.exe -- which were earlier part of user mode -- have been moved in to kernel mode. Calls to SetKMode and setting process permissions, so that other processes can be accessed, are not possible due to the reasons mentioned above. Consequently, drivers that use these calls have to be rewritten.
System call performance
In CE 5.0, system calls from a user application to a service process such as GWES.exe was tedious. A trap signals the event of the system call to the kernel. The kernel then switches the process to the service executable GWES.exe. Once GWES.exe returns, the kernel switches the process back to the user application. In CE 6.0, since GWES.exe is part of the kernel, there is no process switching and the user application goes to its application. This is very similar to what takes place in the desktop architecture. The flow chart shown in Figure 3 illustrates that.
Figure 3
Conclusion
With the release of CE 6.0, Microsoft has added lot more technologies, and has also renamed the OS from "Windows CE" to "Windows Embedded CE." Of significance, CE 6.0 boasts many security feature enhancements and performance improvements, such as moving filesys.exe, device.exe and GWES.exe into the kernel. OEMs have also gained an OAL update feature that will be provided by Microsoft from time to time, so that when there are bug fixes, they won't need rebuild the images and can just update the OAL on the fly. The next few articles in this series will explore new technologies in Windows CE 6.0 and also how to port a BSP from CE 5.0 to CE 6.0.
0 nhận xét:
Đăng nhận xét