1. ME-I-US Windows CE The next version Base on Presentations at Medc 2006 by Boar-Ming Hsieh and John Hatch Avi Kcholi Mobile&Embedded Israeli User Society

2. ME-I-US first shared source competition Nic Sagez, has asked me to invite you to participate in the first shared source competition The program manager in charge of the Windows CE source code You can find a description of the competition at: http://www.windowsfordevices.com/articles/AT5277795134.html Nic Sagez, has asked me to invite you to participate in the first shared source competition The program manager in charge of the Windows CE source code You can find a description of the competition at: http://www.windowsfordevices.com/articles/AT5277795134.html

3. ME-I-US Agenda Overview - Introduction Windows CE 5.0 – Recollect Windows CE 6.0 Beta – Overview New Features Compatibility Drivers Overview Real-time Platform Builder Overview - Introduction Windows CE 5.0 – Recollect Windows CE 6.0 Beta – Overview New Features Compatibility Drivers Overview Real-time Platform Builder

4. ME-I-US Overview Targeted to embedded devices Pocket PC, Smartphones, STBs, Thin clients, AutoPC, PMC, control panels, robots, etc. Benefits Flexible, adaptable, configurable, small Supports ARM, MIPS, SH, x86 Real-time Simple driver model Power conscious Shared source Tiered licensing model Targeted to embedded devices Pocket PC, Smartphones, STBs, Thin clients, AutoPC, PMC, control panels, robots, etc. Benefits Flexible, adaptable, configurable, small Supports ARM, MIPS, SH, x86 Real-time Simple driver model Power conscious Shared source Tiered licensing model

5. ME-I-US Overview However, Windows CE 5.0 has a memory model limitation It only supports 32 processes and 32 MB per process These limitations has now been removed with Windows CE 6.0 New Virtual Memory Model However, Windows CE 5.0 has a memory model limitation It only supports 32 processes and 32 MB per process These limitations has now been removed with Windows CE 6.0 New Virtual Memory Model

6. ME-I-US

7. Windows CE 5.0 Memory Model Virtual Memory Map 2 GB for Kernel Single 2 GB mapping for all processes Divided up into 32 MB “slots” 32 Process Limit Each process has one 32 MB slot 32 slots for processes Shared memory Upper half of user space is shared memory Read / Write by all processes Virtual Memory Map 2 GB for Kernel Single 2 GB mapping for all processes Divided up into 32 MB “slots” 32 Process Limit Each process has one 32 MB slot 32 slots for processes Shared memory Upper half of user space is shared memory Read / Write by all processes

8. ME-I-US :::::::: Shared Memory Kernel 32 Slots for Processes Single 2 GB VM for all Processes Execution Slot and Shared DLL Slot Slot 0 – Execution Slot 1 – ROM DLLs Slot 2 – NK.exe Slot 3 – Filesys.exe Slot 4 – Device.exe Slot 5 – GWES.exe Slot 32 Slot 7 – Services.exe 2 GB Kernel Space Slot 8 Slot 31

9. ME-I-US

10. Introducing the New Kernel 2 GB of Virtual Memory per process 32,000 processes Unified Kernel Critical OS components moved into kernel space Improved system performance Increased security and robustness High degree of backwards compatibility 2 GB of Virtual Memory per process 32,000 processes Unified Kernel Critical OS components moved into kernel space Improved system performance Increased security and robustness High degree of backwards compatibility

11. ME-I-US 32 K Process 2 GB per Process 2 GB Kernel Space New Win CE Memory Model Process Code User VM User VM Memory Mapped files User DLLs Kernel Filesystem GWES Drivers...

12. ME-I-US User Space Shared User DLLs 512 MB RAM Backed Mapfiles 256 MB Shared System Heap 255 MB Process space 1 GB per process User Space 2 Gigabytes Each process has its own mapping R/W for OS components Read only for user process RAM Backed Mapfiles Mapped at fixed location for better backwards compatibility All DLLs – code and data Same mapping across all processes Data pages are unique physical pages Code pages are shared Executable code and data VM Allocation File Back Mapfiles 0x00000000 0x40000000 0x80000000

13. ME-I-US 0x80000000 Kernel Space 2 Gigabytes Fixed mapping independent of user space 0xFFFFFFFF All XIP DLLs in kernel Cached access to physical memory Uncached access to physical memory Ram file system & ram registry Kernel Virtual Memory Shared by all kernel Servers and drivers System Trap Area CPU Specific VM Kernel VM (if supported by CPU) 256 MB Kernel VM 256 MB Object Store (128MB) Kernel XIP DLLs (128 MB) Static Mapped Uncached 512 MB Static Mapped Cached 512 MB

14. ME-I-US OS New Layout Moving critical drivers, file system, and graphical window manager into the kernel Kernel version of Coredll.dll Same APIs without the thunks Benefit Greatly reduces the overhead of system calls between these components Reduces overhead of all calls from user space to kernel space Increase code sharing between base OS services Moving critical drivers, file system, and graphical window manager into the kernel Kernel version of Coredll.dll Same APIs without the thunks Benefit Greatly reduces the overhead of system calls between these components Reduces overhead of all calls from user space to kernel space Increase code sharing between base OS services

15. ME-I-US

16. Performance & Size Improvements expected in process switching Same performance Thread Switching Memory Allocation System Calls Some slow down with interprocess calls Now involves data marshalling Size increase is less then 5% Improvements expected in process switching Same performance Thread Switching Memory Allocation System Calls Some slow down with interprocess calls Now involves data marshalling Size increase is less then 5%

17. ME-I-US Win CE 5.0 System Calls Application makes call PSL jump Kernel Validates parameters Maps Service into Slot 0 Possible Cache Flush Calls into to the service Service Runs Returns to Kernel Kernel Maps App into Slot 0 Possible cache flush Returns to App App Service Kernel

18. ME-I-US Win CE 6.0 Beta System Calls Application makes call Same PSL jump App stays mapped during the call Kernel Validates parameters Calls into to the service Service Runs Returns directly to the app App ServiceKernel

19. ME-I-US

20. Security Early Threat Modeling of the kernel Working with Microsoft Secure Windows Team and penetration testers Double checked design to tighten up System Calls Handles Exception Handling Memory Allocation Loader And many other components Early Threat Modeling of the kernel Working with Microsoft Secure Windows Team and penetration testers Double checked design to tighten up System Calls Handles Exception Handling Memory Allocation Loader And many other components

21. ME-I-US Security and Robustness Features Improved parameter validation for system calls Per-Process Page and Handle tables Greatly improves Process isolation Improves code robustness Secure Stack System calls run on special kernel side stacks Safe guards system calls from stack tampering Robust Heaps Heap control structures separated from heap data Safe Remote Heaps for OS components OS servers can open heaps in user process R/W for servers, R/only for user Performance optimization and safe from tampering Improved parameter validation for system calls Per-Process Page and Handle tables Greatly improves Process isolation Improves code robustness Secure Stack System calls run on special kernel side stacks Safe guards system calls from stack tampering Robust Heaps Heap control structures separated from heap data Safe Remote Heaps for OS components OS servers can open heaps in user process R/W for servers, R/only for user Performance optimization and safe from tampering

22. ME-I-US

23. New Features Per-Process Page Tables Each process has its own page table Pointers are unique to each process Enables the new virtual memory model Increases security Per-Process Handle Tables Each process has its own handle table Handles have reference and usage counts Increases security Increased programming robustness No more stale handles Per-Process Page Tables Each process has its own page table Pointers are unique to each process Enables the new virtual memory model Increases security Per-Process Handle Tables Each process has its own handle table Handles have reference and usage counts Increases security Increased programming robustness No more stale handles

24. ME-I-US New Features Continued Large Memory Mapped File Support Support for mapping views into very large files Up to 64-bit files Big benefit for in car navigation and multimedia Secure Loader Enables of control of which executable and DLLs get loaded by the system Uses encrypted signatures to identify the files Foundation for a code based security model Security is based on knowing what code is running instead of who the user is Large Memory Mapped File Support Support for mapping views into very large files Up to 64-bit files Big benefit for in car navigation and multimedia Secure Loader Enables of control of which executable and DLLs get loaded by the system Uses encrypted signatures to identify the files Foundation for a code based security model Security is based on knowing what code is running instead of who the user is

25. ME-I-US New Features Continued User Mode UI service Displays UI in user mode for kernel mode drivers Keeps drivers from launching windows from inside the kernel Virtual Alloc Ex functions Memory management functions for drivers Just like the Windows XP APIs Enables drivers to allocate memory in user processes User Mode UI service Displays UI in user mode for kernel mode drivers Keeps drivers from launching windows from inside the kernel Virtual Alloc Ex functions Memory management functions for drivers Just like the Windows XP APIs Enables drivers to allocate memory in user processes

26. ME-I-US New Features Continued Marshalling Helper Functions Helper functions for interprocess data marshalling Services that help drivers to handle user data Monotonic clock Always forward going clock independent of user clock Enables services to calculate elapsed time Marshalling Helper Functions Helper functions for interprocess data marshalling Services that help drivers to handle user data Monotonic clock Always forward going clock independent of user clock Enables services to calculate elapsed time

27. ME-I-US New Features Continued User Mode Services and Drivers Run all services and some drivers in User Mode host Saves kernel resources and increases robustness Separate OAL OAL has been split from the kernel Allows independent updates Kernel updates and OEM OAL updates can be done independently Enables easier device updates User Mode Services and Drivers Run all services and some drivers in User Mode host Saves kernel resources and increases robustness Separate OAL OAL has been split from the kernel Allows independent updates Kernel updates and OEM OAL updates can be done independently Enables easier device updates

28. ME-I-US

29. CPU Requirements The same CPUs as Windows CE 5.0 ARMV4I and above MIPSII with sync instructions (ll, sc) x86 SH4 Best performance is on CPUs with Physical tagged caches Virtual-tag-cached CPUs have a small performance penalty and limitation on virtual mappings Same hardware as Windows CE 5.0 The same CPUs as Windows CE 5.0 ARMV4I and above MIPSII with sync instructions (ll, sc) x86 SH4 Best performance is on CPUs with Physical tagged caches Virtual-tag-cached CPUs have a small performance penalty and limitation on virtual mappings Same hardware as Windows CE 5.0

30. ME-I-US Compatibility Binary compatibility for applications is the key goal The general structure of the OS will be the same Will maintain compatibility in CoreDLL Minimize impact on Win32 APIs Changes hidden in API libraries Continue to shared DLL code Well behaved SDK applications Should work with little or no changes Apps using undocumented techniques Will likely have to be modified Such as passing handles or pointers between processes Main changes will be in how drivers access client memory Some drivers will migrate with little work Binary compatibility for applications is the key goal The general structure of the OS will be the same Will maintain compatibility in CoreDLL Minimize impact on Win32 APIs Changes hidden in API libraries Continue to shared DLL code Well behaved SDK applications Should work with little or no changes Apps using undocumented techniques Will likely have to be modified Such as passing handles or pointers between processes Main changes will be in how drivers access client memory Some drivers will migrate with little work

31. ME-I-US Porting Incompatible Apps Some applications will need work Improper use of handles nonstandard memory usage Use of some Windows CE specific APIs Remove old tricks and workarounds Such as handle sharing and pointer tricks Our verification approach Ported Windows Mobile 5.0 to Windows CE 6.0 Beta Running Windows CE 5.0 commercial applications on Windows CE 6.0 Beta Some applications will need work Improper use of handles nonstandard memory usage Use of some Windows CE specific APIs Remove old tricks and workarounds Such as handle sharing and pointer tricks Our verification approach Ported Windows Mobile 5.0 to Windows CE 6.0 Beta Running Windows CE 5.0 commercial applications on Windows CE 6.0 Beta

32. ME-I-US Other Porting Drivers will require some work System calls Use of worker threads Access to caller’s memory BSP will need some work New memory mappings Changes to OAL to support image updates Drivers will require some work System calls Use of worker threads Access to caller’s memory BSP will need some work New memory mappings Changes to OAL to support image updates

33. ME-I-US Compatibility Tester Identifies removed, deprecated, and changed APIs Supports both static and runtime analysis Produces a detail report of any compatibility issues it finds Includes documentation and suggestions We will release it before Windows CE 6.0 RTM Will allow customers to prepare ahead of time Identifies removed, deprecated, and changed APIs Supports both static and runtime analysis Produces a detail report of any compatibility issues it finds Includes documentation and suggestions We will release it before Windows CE 6.0 RTM Will allow customers to prepare ahead of time

34. ME-I-US

35. Kernel Mode Drivers Drivers are loaded in the kernel space by device.dll Have full access to the kernel’s data structures and memory APIs used do not change Link to a kernel version of coredll.dll called kcoredll.dll Thin layer for API compatibility Directly links the services together without thunk layer Drivers needing the best performance should be kernel mode Such as those with lots of quick calls Drivers are loaded in the kernel space by device.dll Have full access to the kernel’s data structures and memory APIs used do not change Link to a kernel version of coredll.dll called kcoredll.dll Thin layer for API compatibility Directly links the services together without thunk layer Drivers needing the best performance should be kernel mode Such as those with lots of quick calls

36. ME-I-US User Mode Drivers Loaded by udevices.exe Mostly the same APIs as Kernel Mode No access to kernel structures or memory Kernel will marshal parameters during system calls Examples Expansion buses like USB and SDIO Keyboard and touch Drivers where performance is not a factor should consider moving to user mode Called less often and do more work Loaded by udevices.exe Mostly the same APIs as Kernel Mode No access to kernel structures or memory Kernel will marshal parameters during system calls Examples Expansion buses like USB and SDIO Keyboard and touch Drivers where performance is not a factor should consider moving to user mode Called less often and do more work

37. ME-I-US Handling Calls App memory already mapped correctly Can access it without re-mapping pointers Don’t need – These APIs are being removed SetProcPermissions MapPtrToProcess, UnMapPtr Accessing callers memory CopyIn / CopyOut ReadProcessMemory / WriteProcessMemory Virtual Alloc Ex APIs Marshalling Helper Library Provides APIs for handling user data App memory already mapped correctly Can access it without re-mapping pointers Don’t need – These APIs are being removed SetProcPermissions MapPtrToProcess, UnMapPtr Accessing callers memory CopyIn / CopyOut ReadProcessMemory / WriteProcessMemory Virtual Alloc Ex APIs Marshalling Helper Library Provides APIs for handling user data

38. ME-I-US OAL Changes OAL split from kernel Merged into NKLoader Enables separate updates Overall OAL structure remains the same Same OEM functions Access kernel through kernel interface Changes to the OAL initialization Memory mappings for new memory model OAL split from kernel Merged into NKLoader Enables separate updates Overall OAL structure remains the same Same OEM functions Access kernel through kernel interface Changes to the OAL initialization Memory mappings for new memory model

39. ME-I-US

40. Windows CE is a Real-Time OS Real time is being able to respond to an interrupt in a bounded maximum time Analysis by OMAC User Group shows that 95% of real-time applications require between 0.5ms to 10 ms respond time And tolerate 10% variations, or 50µs to 1ms jitter Real time is being able to respond to an interrupt in a bounded maximum time Analysis by OMAC User Group shows that 95% of real-time applications require between 0.5ms to 10 ms respond time And tolerate 10% variations, or 50µs to 1ms jitter Interrupt every.5 ms to 10 ms 50µs to 1 ms Jitter Typical Real-Time Requirements

41. ME-I-US Real-Time Kernel Windows CE achieves real-time by the design of the kernel and the drivers The majority of the kernel and driver code can be interrupted The uninterruptible parts are small discrete units so interrupts can be handled quickly The length of the largest part is biggest latency Windows CE 6.0 Beta kernel and drivers are designed with the same real-time constraints Windows CE achieves real-time by the design of the kernel and the drivers The majority of the kernel and driver code can be interrupted The uninterruptible parts are small discrete units so interrupts can be handled quickly The length of the largest part is biggest latency Windows CE 6.0 Beta kernel and drivers are designed with the same real-time constraints

42. ME-I-US Windows CE Test Results Respond time test using the following configuration Samsung SMDK2410 development board 200 MHz ARM with 16x16 cache Windows CE 5.0 with full UI Running a WMV video Respond time test using the following configuration Samsung SMDK2410 development board 200 MHz ARM with 16x16 cache Windows CE 5.0 with full UI Running a WMV video ISR startsIST starts minimum 1.2 µs31.7 µs average 3.3 µs67.2 µs Maximum 13.3 µs103.0 µs Time in microseconds (µs) Windows CE Real-Time Test Results

43. ME-I-US Win CE 6.0 Beta Real-Time The new kernel has the same response times as the current kernel May even perform slightly better because of reduced system call overhead Performance between app and kernel will be better Drivers and services in services.exe will be slightly worse The new kernel has the same response times as the current kernel May even perform slightly better because of reduced system call overhead Performance between app and kernel will be better Drivers and services in services.exe will be slightly worse

44. ME-I-US Platform Builder No more multiple tools for development Platform Builder now a plug in wizard in Visual Studio 2005 OS designs are located now under %WINCEROOT%\OSDesigns An OS design directory hierarchy is new too %WINCEROOT%\OSDesigns\OSDesign1 \OSDesign1 – directory for the OS design OSDesign1.ncb – VC++ Intellisense data base OSDesign1.sln - Visual Studio solution OSDesign1.suo – Visual Studio solution user options No more multiple tools for development Platform Builder now a plug in wizard in Visual Studio 2005 OS designs are located now under %WINCEROOT%\OSDesigns An OS design directory hierarchy is new too %WINCEROOT%\OSDesigns\OSDesign1 \OSDesign1 – directory for the OS design OSDesign1.ncb – VC++ Intellisense data base OSDesign1.sln - Visual Studio solution OSDesign1.suo – Visual Studio solution user options

45. ME-I-US OS Design directory structure %WINCEROOT%\OSDesigns\OSDesign1\ OSDesign1 RelDir Device_Emulator_ARMV4I_Debug Device_Emulator_ARMV4I_Release Subproject1 WINCE600 Name of BSP for OS design cesysgen OAK %WINCEROOT%\OSDesigns\OSDesign1\ OSDesign1 RelDir Device_Emulator_ARMV4I_Debug Device_Emulator_ARMV4I_Release Subproject1 WINCE600 Name of BSP for OS design cesysgen OAK

46. ME-I-US OS design templates

47. ME-I-US The catalog No more OSDesignView tree Catalog view now shows selected components Add components to design just by checking checkbox No more OSDesignView tree Catalog view now shows selected components Add components to design just by checking checkbox

48. ME-I-US Adding an application Adding a new project is very straight forward In the Solution Explorer right click on the Subprojects node Add a new project Add an existing project Adding a new project is very straight forward In the Solution Explorer right click on the Subprojects node Add a new project Add an existing project

49. ME-I-US New project wizard

50. ME-I-US Added project The newly added project is both a SOURCES project and has a PBXML file to describe the project to the IDE

51. ME-I-US

52. Questions….. Thank You for coming