There has been lot of queries regarding differences between 5.0 and 6.0 and we thought it would be useful to our customers and also people involved in Windows CE development to know more about it. This article will be the first in the series of articles about Windows CE 6.0.
The major changes in 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.
Process address space
The existing implementation of Windows 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 eg. as mentioned in the 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 wastage in Virtual address space. A quick question would be why then such architecture was 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 later articles to come.
Figure 1
Windows CE 6.0 has moved towards the 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 is more like desktop like process switching like 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 Windows CE allows a user process to go up to 1 GB. The other 1 GB is towards DLLs, shared memory and Kernel shared heap. The shared memory is for backward compatibility with Windows 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. The important part is one process cannot view another process data directly like Windows CE 5.0. It has to go through kernel API to get data from other processes.
Device driver architecture changes
Windows CE driver developers should know that the Windows CE 6.0 allows kernel mode device drivers and user mode device drivers. The idea of kernel mode drivers is for more security and robustness. OEMs can prevent drivers from getting accesses to kernel resources by third party drivers and hence can offer more security to his installation. OEMs can ship in with kernel mode drivers for all their peripherals and for add on peripherals they can allow the third parties to load kernel drivers only if they are signed by them, otherwise the drivers shall run only in user mode. However user mode drivers shall be able to use VirtualCopy for only the memory space defined in the registry. Earlier Windows CE 5.0 allowed the user mode drivers to Virtual copy any memory region other than the ones mentioned in the registry for them.
Filesys.exe, device.exe and GWES.exe which were earlier part of the user mode have been moved in to the kernel mode. The calls to SetKMode and setting process permissions so that other processes can be accessed are not possible due to the reasons mentioned above. Drivers which use these calls have to be rewritten.
System call performance
In windows CE 5.0 any system call 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 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 the desktop architecture. The flow chart shown in Figure 3 illustrates that.
Figure 3
Conclusion – OEM Relish
Microsoft has added lot more technologies in 6.0 and also has renamed Windows CE as Windows embedded. Apart from this, Windows CE 6.0 seems to be an OEM relish with many security features enhancement and performance improvements like moving the filesys.exe, device.exe and GWES.exe to the kernel. OEMs also have a OAL update feature that will be provided by Microsoft from time to time so that if there is any bug fixes, OEM need not rebuild the images and can just update the OAL on the fly. The next few articles will talk about new technologies in Windows CE 6.0 and also how to port a BSP from 5.0 to 6.0. For Windows CE BSP, Drivers development on Windows CE please write to sales@e-consystems.com with the subject Windows CE BSP/Driver Development.
We use cookies to ensure that we give you the best experience on our website. You can change your cookie settings at any time but our site requires cookies to function properly.
You may not be able to access content or other services correctly without cookies. Know more
We use cookies to ensure that we give you the best experience on our website.
Mr. Thomas Yoon
+82-10-5380-0313
Articles
Employee Login
