The Windows CE New Kernel

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.