Windows CE 7 Architecture

Windows CE5 was based on a microkernel architecture.

In this type of architecture, the device drivers run in user mode which means that I/O handling routines are embedded into user-mode applications. It also means that the synchronization between the processes that share driver access needs to be done at application level, which is tricky.
NK.exe is the most privileged process of the operating system. It can access kernel memory addresses and make kernel calls.
Since Windows CE6, the architecture moved to a monolithic kernel architecture.


With this architecture, drivers and services have been moved to kernel space as dlls. NK.exe is still the most privileged process but this new architecture, by breaking the inter-process communication lines, enhances performances globally.

Component	Description
GWES.dll	Graphic, Windowing and Events Subsystem. It loads device drivers and manages their interface while loaded.
DEVMGR.dll	Device Manager. It loads stream interface device drivers and manages their interface while loaded.
I/O Resource Manager	Part of Device Manager that enumerates the available resources from registry
FILESYS.dll & FSDMGR.dll	File system manager and file system driver manager.
Networking Dlls	Network functionality (HTTP, TCP/IP, FTP...)
UDEVICE.exe	User mode process that runs device drivers in user-mode
OAL	OEM Abstraction Layer. Gives to the kernel an access to OEM hardware and maps interrupts with logical IDs
COREDLL.dll	OS API (semaphore, thread, mutex, critical section...)
K.COREDLL.dll	Kernel version of CoreDll (kernel device drivers links against this one)

Device driver: User mode vs Kernel mode

From performance point of view, it is better to embbed a driver in kernel space.
From security point of view, a bug in the driver might jeopardize the whole system.
For robustness, udevice.exe provides installable device driver feature, thus protecting the kernel.

Interrupt management

Component	Description
Kernel Interrupt Service Handler	Can handle up to 64 separate hardware IRQS sources. It determines interrupt priority level and calls an ISR hooked to it and then sets event that is associated with interrupt ID (SYSINTR ID)
Interrupt Service Routines (ISRs)	Hooked to IRQ in kernel mode. Acknowledges hardware and determines interrupt ID
Interrupt Service Threads (ISTs)	Device-specific servicing for the specified Interrupt ID. Must signal completion of processing to hardware.

1. A device raises a registered interrupt.
2. The kernel catches the interrupt and calls the related Interrupt Service Routine (ISR).
3. ISR handles the interrupt and exits as quick as possible.
4. IST in driver is signaled to process the interrupt.
5. IST completes processing.

Cem SOYDING

Author & Editor

Senior software engineer with 12 years of experience in both embedded systems and C# .NET