KURT KENNETT
SENIOR DEVELOPMENT MANAGER, WDC CORE OS
MICROSOFT CORPORATION
Introduction to Windows CE
Versions
Design Goals
Windows CE Fundamentals
Terminology
Processors, CPUs, SoCs
OS Components and projects
Windows CE Architecture
Kernel, Threads, Processes, Drivers
Memory map for User & Kernel Space
OS Layout and Component Interaction
Understanding Windows CE OS Image Development
Overall Goal
Critical Steps along the way
Development Iteration and Debugging
System Generation (SYSGEN)
Board Support Package
Initially was to be used in two products
Set-top boxes
Pulsar Small PDA with new UI
Divergence in requirements
Some independent actions resulted in Pursuing a Win32 API
Subset
An entirely different object-oriented OS was used for quite a
while.
Another group was doing WinPad Windows 3.1 handheld
Pulsar was weird, WinPad was underpowered with problems
backing up the hardware design
Blew them up, talked to OEMs about what to build, then
settled on a few core points.
A few false starts.
CE 1.0, 2.0, 2.x, 3.0, 4.x (.NET), 5, and now 6
Pegasus/Alder
Windows CE 1.0
11/1996
Cedar
Macallan
Windows CE 3.0
4/2000
Windows CE 5.0
8/2004
Tomatin
NMD FP
SP1 SP2
2.11 2.12
Birch
Windows CE 2.0
11/1997
Jameson
4.1
Talisker
Windows CE
.NET 4.0
1/2002
McKendric
4.2
Yamazaki
Windows CE 6
9/2006
Win32 API Subset
Portable to different architectures (ARM, MIPS, SH)
Real-Time
Modular
Run from ROM
Minimal RAM
Design considerations:
Not supposed to be the be-all end-all of Operating Systems
applicable to all tasks.
Suitability to task - The right tool for the right job.
Start from zero want the most functionality with the least
cost.
What do we need as opposed to what do we leave out.
Windows Embedded Standard
Windows Embedded Enterprise
Componentization of desktop to allow for systems with much higher power
or processing demands, and/or closer parallels and parity with what is
available to the desktop.
Kiosk-type interaction with expanded feature set and little or no porting time.
Point of Service
Specific enhancements, systems, and services to enable the PoS scenarios and
integration with customer data management systems.
These systems should be used instead of CE when:
Power requirements for peripherals are much greater
Specific facilities for services are not available in CE.
Existing software is written for the desktop and uses some APIs and facilities that
would require significant effort to port.
Cases where CE should be used instead of them.
Cost per license needs to be low
Flexibility in platform choice is needed
Power requirements are stringent (battery)
Physical portability
Ingrained systems that need to be small (physical size, memory size, storage size)
PND
Point of Service
for Embedded systems
Consumer
Portable media
Thin Client
Entertainment
Medical
Telematics
for Embedded systems
Industrial Automation
Robotics
General Embedded
Industrial Automation
Thin Client
General Embedded
Module
EXE or DLL Code that will run or is part of CE 6.0
Component
The smallest unit of functionality that you can add to an OS
design.
OEM Adaptation Layer (OAL)
Low level hardware platform specific library - abstracts the
hardware architecture from the kernel
Board Support Package (BSP)
OAL + drivers + bootloader + configuration files for a
particular hardware platform Board
OS Run-Time Image
Everything in the OS Design is built into a file containing
ROM data & code (usually NK.BIN)
For Windows CE,
Microsoft creates an
OS kernel for each
architecture. Then that
kernel can be used on
platforms that have
that same flavor of
chip.
The Board support
package that is tied
together with a Kernel
allows for new features
and enhancement that
Microsoft could never
be able to plan for.
Microsoft
Windows CE
Kernel
X86
(ARCH)
ARM
Board
Support
Package
SoC
SH
MIPS
(Ti,QC,Marvell,,etc.)
SD 4.0
ARCH
X86
MIPS
ARM
SH
CPU CORE
CPU / SoC
Board
80486
phyCore270
Pentium
MARVELL
PXA27x
ARMv5TE
ARM11EJ-S
QUALCOMM
7X00
TI OMAP
3430
EM-X270
Mainstone
III
Board
OS Components
DEVICE
MANAGER
phyCore270
USB CORE
DISPLAY
SYSTEM
USB HOST
WINDOW
MANAGER
EM-X270
Mainstone
III
DEBUG SHELL
ARCH
X86
Board
phyCore270
MIPS
EM-X270
Window CE
Project
(VS Solution)
COLLECTION
INDUSTRIAL
OF OS
APPLIANCE
COMPONENTS
ENTERPRISE
WEB
PAD
ARM
SH
Mainstone
III
MY COOL
WINDOWS CE
PROJECT
OS Components
DEVICE
MANAGER
DISPLAY
SYSTEM
WINDOW
MANAGER
DEBUG SHELL
ARCH
Board
X86
X86
KERNEL
MIPS
MIPS
KERNEL
ARM
ARM
KERNEL
SH
SH
KERNEL
phyCore270
EM-X270
Mainstone
III
Window CE
Project
(VS Solution)
INDUSTRIAL
APPLICANCE
ENTERPRISE
WEB
PAD
MY COOL
WINDOWS CE
PROJECT
OS Components
DEVICE
MANAGER
DISPLAY
SYSTEM
WINDOW
MANAGER
DEBUG SHELL
OS Kernel is the heart of the system.
You cannot have a system without it.
Some systems can be kernel-only!
Specific features distinguish CE 6.0+ from CE5.x and
before
2 GB of Virtual Memory per process
32K processes
64K Global Handle Table
Unified Kernel
Critical OS components moved into kernel space
Improved system performance
Increased security and robustness
High degree of application compatibility
All these things are similar to other Operating Systems
Thread
A piece of code that can be scheduled to run by the kernel
A unit of execution
May be launched by a process or a driver
Process
Launched from an executable file
A collection of threads (at least one) with a common execution
environment
Can create threads to handle interrupts
Driver
A DLL, (dynamically loaded library) loaded into the kernel or into
a user-mode driver host process.
Can create threads to handle interrupts
2 GB
Kernel
Space
Kernel
Filesystem
GWES
Drivers
2 GB
per
Process
Process Code
User VM
32 K
Processes
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
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
Shell
Services
Manager
UM Driver
Manager
Services
User Mode
Drivers
Applications
Applications
Applications
Applications
User
Mode
OS DLLs (Coredll, Winsock, CommCtrl, )
KCoredll.DLL
Kernel.DLL
OAL.EXE
FileSys.DLL
GWES.DLL
Device.DLL
Kernel Drivers
Bootloader
Hardware
Kernel
Mode
kernel.dll
NKGLOBAL
OEMGLOBAL
NKStub.lib
KITL IOCTL
oal.exe
(nk.exe)
IOCTL
library
Caches
Interrupt
library
Cache
library
Timers
Startup
library
OS Timer
library
RTC
library
RTC
kitl.dll
Hardware
USB
port
Ethernet Serial
port
port
What do we want to get out of this at the end?
We want:
To create an OS image that contains a set of Windows
CE system components .
To have the image contain:
- The Microsoft Kernel for the CPU were using
- Our OAL that adapts the kernel to the board were using.
- Any other things we need to communicate with the running
operating system.
To be able to execute the image on the board, either
by:
1) Burning the image file into ROM.
or
2) Downloading the image file into RAM to execute it from
there.
Specify the BSP we intend to use
The BSP must have the drivers/functionality we need
in our end product.
Specify the OS components we need
The Windows CE Catalog allows us to select OS
components and automatically have their
dependencies included.
We can optionally add our own components and
specify our own dependencies for those components.
Configure features to suit our development needs.
Build an image
Download the image.
Execute and Debug the image.
Development is an iterative process.
Build
Download
Observe and Tweak
Debug and step through code.
Make changes
Repeat as needed.
Decreasing iteration time increases productivity.
The Windows CE OS Design and build process is friendly to
iterative development on a specific set of static components.
This can allow for platform or feature specific tweaks and
changes to enable maximum functionality and performance.
Windows CE SubProjects provide a mechanism to enhance
and extend a Windows CE Image and iterate on developing
those components to the state they are effective in your
product.
Windows CE 6 comes with a very wide array of components.
If functionality for all components was always included in a kernel
the resulting system would be very large in size and slower than was
necessary.
It is ideal to configure the kernel, the device drivers, and the
systems+services so that something that is not used is not included
in the image. Examples:
A web browser and everything it depends on
Image compression and rendering for a system with no display.
Power management for a system that is AC powered.
This is the componentization model.
Executing a SYSGEN for an OS Design is the process of filtering
the full system headers and libraries and extracting the pieces that
you are using.
The result is a set of system headers and libraries that are unique to
your configuration of OS components.
You get a Lean and Mean system with minimal overhead.
As we saw previously, the Board Support Package
(BSP) we choose to use determines the
functionality available.
The BSP is where the OAL and drivers come from.
The BSP is the abstraction layer that lets many
different Windows applications execute on
potentially very different hardware.
The OAL for a BSP is customized and optimized to
fit the particular platform.
If you are going to extend a platform from the
default supported by its BSP you typically need to
have access to the BSP sources.
Board
phyCore270
ARM
KERNEL
EM-X270
Mainstone
III
Window CE
Project
(VS Solution)
INDUSTRIAL
APPLICANCE
ENTERPRISE
WEB
PAD
MY COOL
WINDOWS CE
PROJECT
OS Components
DEVICE
MANAGER
DISPLAY
SYSTEM
WINDOW
MANAGER
DEBUG SHELL
Board
Support Package
OS Components
DEVICE
MANAGER
phyCore270
ARM
KERNEL
Hardware
EM-X270
Mainstone
III
DISPLAY
SYSTEM
WINDOW
MANAGER
DEBUG SHELL
Board
Support Package
Driver
ARM
KERNEL
OAL
OS Components
DEVICE
MANAGER
DISPLAY
SYSTEM
DEBUG
KITL
WINDOW
MANAGER
ARM
Core
Hardware
DEBUG SHELL
An Architecture-Specific Kernel
A Board-Specific OEM Adaptation Layer (OAL)
Some sort of data transport for KITL
ARM
KERNEL
OAL
KITL
The kernel already knows how to talk to the CPU core,
which is the same for every CPU of a particular
architecture.
The OAL must abstract everything else.
2006 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
