Windows CE 6.0 Architecture Douglas Boling President Boling Consulting Inc. www.bolingconsulting.com Speaker Douglas Boling dbolingmedc @ bolingconsulting.com Author – “Programming Microsoft Windows CE 3rd Edition” Trainer – Classes on Windows CE.
Download ReportTranscript Windows CE 6.0 Architecture Douglas Boling President Boling Consulting Inc. www.bolingconsulting.com Speaker Douglas Boling dbolingmedc @ bolingconsulting.com Author – “Programming Microsoft Windows CE 3rd Edition” Trainer – Classes on Windows CE.
Windows CE 6.0 Architecture Douglas Boling President Boling Consulting Inc. www.bolingconsulting.com Speaker Douglas Boling dbolingmedc @ bolingconsulting.com Author – “Programming Microsoft Windows CE 3rd Edition” Trainer – Classes on Windows CE App Development Windows CE OAL Development .NET Compact Framework Consultant – Work with companies to help their Windows CE application and platform development efforts Agenda Overview - Introduction Windows CE 6 Memory Model New Features Compatibility BSP Changes Brief History What we’ve been doing Pegasus/Alder Cedar Macallan Windows CE 1.0 11/1996 Windows CE 3.0 4/2000 Windows CE 5.0 8/2004 Tomatin NMD FP SP1 SP2 2.11 2.12 Jameson McKendric 4.2 4.1 Birch Talisker Yamazaki Windows CE 2.0 11/1997 Windows CE .NET 4.0 1/2002 Windows CE 6 H2/2006 Windows CE Limits From Windows CE 1 to Windows CE 5, Windows CE has always had limits 32 processes at any one time 32 MB Virtual Memory per process Windows CE 5.0 Memory Model 2 GB Kernel Space Kernel Shared Memory Single 2 GB VM for all Processes Slot 32 Slot 31 : : Slot 7 Slot 6 – Explorer.exe Slot 5 – Services.exe Slot 4 – GWES.exe Slot 3 – Device.exe Slot 2 – FileSys.exe Slot 1 – ROM DLLs Slot 0 – Execution 32 Slots for Processes Execution Slot and Shared DLL Slot 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 Windows CE 6.0 Memory Model Windows CE Memory Model 2 GB Kernel Space Kernel Filesystem GWES Drivers 2 GB per Process Process Code User VM 32 K Process 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 Application Virtual Memory Space 0x80000000 User Space 2 Gigabytes Each process has its own mapping Shared System Heap 255 MB R/W for OS components Read only for user process RAM Backed Mapfiles 256 MB RAM Backed Mapfiles Mapped at fixed location for better backwards compatibility Shared User DLLs 512 MB All DLLs – code and data Same mapping across all processes Data pages are unique physical pages Code pages are shared 0x40000000 Process space 1 GB per process Executable code and data VM Allocation File Back Mapfiles 0x00000000 Kernel Virtual Memory Space 0xFFFFFFFF Kernel Space 2 Gigabytes Fixed mapping independent of user space CPU Specific VM System Trap Area Kernel VM 256 / 512 MB Kernel Virtual Memory Shared by all kernel Servers and drivers Object Store (128MB) Ram file system & ram registry Kernel XIP DLLs (128 MB) All XIP DLLs in kernel Static Mapped Uncached 512 MB Uncached access to physical memory Static Mapped Cached 512 MB Cached access to physical memory 0x80000000 New OS 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 New OS Layout Applications User Space SHELL SERVICES.EXE Services Services Services Services UDEVICE.EXE User Mode Services Drivers Services Services COREDLL / WINSOCK / COMMCTRL / WININET / COMMDLG KCOREDLL.DLL KERNEL.DLL Kernel Space OAL (NK.EXE) OAL.DLL Boot Loader DEVICE.DLL FILESYS GWES NETWORK Drivers Hardware 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% Windows CE 5.0 System Calls Application makes call PSL jump Service Application (FileSys) (Device) (GWES) Kernel Validates parameters Maps Service into Slot 0 Possible Cache Flush Calls into to the service Service Runs Returns to Kernel Kernel Kernel Maps App into Slot 0 Possible cache flush Returns to App Windows CE 6.0 Beta System Calls Application makes call Application Same call to coredll.dll App stays mapped during the call Kernel Validates parameters Calls into to the service Kernel Service Service Runs Returns directly to the app New Features New Features New Security Model “Trust / Run / No Load” model gone New: “Trust / No Load” Prepares operating system for ACL security Windows XP-like Access Control List security to be implemented in the future New Features New File Systems ExFAT Large file support Large volume support UDFS 2.5 read only support 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 New Features New driver support USB On-the-go (OTG) New USB Function / Host class drivers Enhanced VoIP support VoIP support over wired and WLAN networks Full-featured phone application Updated SIP signaling and Media stack (RTC 1.5) New Features Wireless LAN enhancements Multiple radio support and faster AP-AP roaming Added 802.11i support for WPA2 compliance Added 802.11e support for QoS Bluetooth enhancements BT protocol stack performance optimizations Enhanced BT profiles: A2DP, AVRCP Compatibility Compatibility Binary compatibility for applications is the key goal Well behaved applications will work w/ little/no changes Compatibility maintained through CoreDLL Minimize impact on Win32 APIs Changes hidden in API libraries Apps using undocumented techniques… Will likely have to be modified Such as passing handles or pointers between processes Main changes will be in drivers and services Some drivers will migrate with little work Application Porting Test Cases WM 5.0 ported to Windows CE 6.0 Beta Running Windows CE 5.0 commercial applications on Windows CE 6.0 Beta Compatibility Tester Identifies removed / deprecated / changed APIs Supports both static and runtime analysis Produces a detail report of any 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 BSP Changes Windows CE 6 Beta BSPs Family BSP Kernel Will be in the beta release (Yes/No) Intel Mainstone III (CARMv4i Step) Yes Plato VoIP Reference ARMv4i Platform Yes Device Emulator ARMv4i Yes Aruba Board ARMv4i No TI OMAP 2420 ARMv6 Yes MIPS NEC Rockhopper SG2 Vr5500 MIPSII & II_PF, MIPSIV & IV_FP Yes SH4 Hitachi/Renesas Aspen SH4 Yes x86 x86 (CEPC) X86 Yes ARM Code Title Speakers EMB321 Porting a Windows CE 5.0 BSP to the next release of Windows CE Travis Hobrla; Don Weber EMB308 Windows CE Secure Boot Loader Steve Maillet; Glen Langer OAL Changes OAL split from kernel Becomes “NK.EXE” Kernel code becomes “Kernel.DLL” Enables separate updates Overall OAL structure remains the same Same OEM functions OAL / kernel interface through shared structures Windows CE 5.0 OAL Design Kernel OAL KITL library IOCTL library Interrupt library RTC library OS Timer library Cache library Caches Startup library Serial port Ethernet port USB port Timers Hardware RTC Windows CE 6.0 OAL Design kernel.dll NKGLOBAL NKStub.lib OEMGLOBAL KITL IOCTL oal.exe (nk.exe) Caches Hardware IOCTL library Cache library Timers Interrupt library OS Timer library RTC Startup library RTC library kitl.dll USB port Ethernet port Serial port Drivers Two types of drivers will be supported Kernel Mode for performance User Mode for robustness The overall structure of the drivers remains Main changes are in how the drivers access client memory Drivers are still DLLs Same Stream interface Kernel Mode Drivers Operate in kernel’s address space Calls to operating system functions very fast ISRs and ISTs operate in the same process space Thunking layer available for user interface services Drivers needing the best performance should be kernel mode Such as those with lots of quick API calls User Mode Drivers Loaded by udevices.exe No access to kernel structures or memory Same API support as applications Examples: Expansion buses like USB and SDIO Drivers where performance is not a factor should consider moving to user mode Called less often and do more work Porting Drivers to the New Windows CE OS Most drivers become kernel mode drivers Driver writers must focus on security and stability Maximum backward-compatibility is maintained Though, some driver modifications are required Deprecated APIs Asynchronous buffer access User Interface Handling Caller Process Mapping (5.0) 4200 0000 4000 0000 3E00 0000 0600 0000 0400 0000 0200 0000 0000 0000 At call to DeviceIoControl When DeviceIoControl processed Slot 32 Slot 32 Application (Slot 31) Slot 31 . . . . . . Slot 3 Slot 2 Device Mgr FileSys Slot 31 Clone Slot 3 Device Mgr Slot 2 FileSys Slot 3 Clone Caller Process Mapping (6.0) Kernel Kernel Drivers Application Before Call Kernel space hidden from application Application space visible to application Kernel Kernel Drivers Application During Call Kernel space visible to driver Application Space visible to driver Handling Calls App memory already mapped correctly Can access it without re-mapping pointers Marshalling Helper Library Provides APIs for handling user data Deprecated APIs: SetProcPermissions, MapPtrToProcess, MapCallerPointer, … Driver Pointer Safety OS checks buffers referenced by caller parameters Buffers are accessed checked Embedded pointers are valid but not access checked Safe drivers should use CeMapCallerPointer / CeCloseCallerBuffer Paranoid drivers should force duplication of buffer Asynchronous Access Windows CE 6 forces new treatment of asynchronous access from driver to application Old: SetProcPermissions to change thread access rights New: CeAllocAsynchronousBuffer / CeFreeAsynchronousBuffer to marshal data Summary Great new architecture Removes the old limits Performance expected as good as current Memory footprint similar OAL / Driver porting fairly straightforward Questions dbolingmedc @ bolingconsulting.com © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.