about windows CE 3.0
These notes relate mostly to sa1100 based devices
the paths refer to files in the platform builder and
shared source for windows ce 3.0. Many cpu dependend files can be found in a Board Support Package, the wince420 emulation edition has sources to many more tools.
how does it boot
- cpu starts at address 0, mmu disabled
- the bootloader checks if it needs to run, otherwise it start the kernel
( by jumping to 0x41000 )
ODO/KERNEL/HAL/ARM/FWP2.S function Startup
is the entrypoint into the kernel.
- Startup initializes some IO, and calls KernelStart passing it a pointer
to the memorymap table
- the memorymap is defined in
PRIVATE/WINCEOS/COREOS/NK/KERNEL/ARM/ARMTRAP.S function KernelStart
sets up a pagetable, and initializes the MMU, and continues execution from
PRIVATE/WINCEOS/COREOS/NK/KERNEL/ARM/MDARM.C function ARMInit
PRIVATE/WINCEOS/COREOS/NK/KERNEL/KWIN32.C function KernelInit
- then the scheduler is started
- the first process created is 'nk.exe', the first thread started is 'SystemStartupFunc'
- then 'RunApps' thread is created.
- filesys.exe is executed
- filesys starts stuff from HKLM\\Init : device.exe, gwes.exe, shell32.exe, services.exe, connmgr.exe, ...
how are systemcalls implemented
- a call is made to an invalid address in the range 0xf0000000 - 0xf0010000
- this causes a prefetch-abort trap, which is handled in
PRIVATE/WINCEOS/COREOS/NK/KERNEL/ARM/ARMTRAP.S function PrefetchAbort
- the systemcall number is determined by 0xf0010000-(256*apiset+apinr)*4
- the api set handles are defined in
- the aipnrs are defined in several files, for example SH_GDI calls are defined
- the actual systemcall function is located by
PRIVATE/WINCEOS/COREOS/NK/KERNEL/OBJDISP.C function ObjectCall
- then executed.
- at 0xffffc800 is the global KDataStruct, as defined in
- the contents of the aInfo part is defined in
- detailed layout for arm/wce42
thread handles and id's
In windows CE 3.0 there are no functions to obtain a threadhandle from a threadid.
(threadid's can be found by iterating over a toolhelp-snapshot (created with
fortunately the handle and id are always exactly the same.
(as can be seen at the bottom of DoCreateThread in
- the lower 2 bits of a handle are always
10 ( or
(handle & 3)==2 )
- bits 28-2 of the handle with bit 31 set to '1' form the address of a HDATA structure
or in other words:
HDATA *phdata= (HDATA *)(0x80000000+((DWORD)handle&0x1ffffffc));
- in this struct, at offset 0x14 is a pointer to a CINFO struct, which determines
what type of handle this is. (f.i. PROC, THRD, EVNT, ...)
- at offset 0x18 is a pointer to the actual object (f.i. PROCESS, THREAD, EVENT, etc )
- the HDATA and CINFO structs can be found in
- here you can find sources of how to dump handle structures
- dump of all handles found on my system
- dump of all systemcalls found on my system
This is systemcall SH_WIN32 ( 0 ), function 99 ( OEMIoControl )
which can be found in
this function is quite different for each OEM!