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.