A STUDY ON WINDOWS MOBILE 6.

5
OPERATION SYSTEM
Author: Thang Minh Le
thangmle@gmail.com

1
WINDOWS MOBILE – INTRODUCTION

Unlike a computer, an embedded device is created with its own purpose. While the
same computer operating system (OS) can be installed on different desktops with no
difficulties, there is unlikely an embedded system which can be used for all embedded
devices. The simple reason to this matter is embedded devices come with large
differences in their hardware designs. There is no embedded system that can meet
different needs of all embedded devices. Microsoft knows that in order for their product
to be widely adopted in large different embedded devices, their embedded operating
system must provide to OEMs the ability to build a custom operating system image with
the functionality that is necessary for a given device. Windows Embedded CE (or
Windows CE) was designed with this intention. The first version of Windows CE was
released to the market in 1996 under the code name Pagasus. It was targeted to Pocket
PC and handheld PC devices. During this time, most of existing mobile phones were not
met the requirement to run Windows CE. Year of 2002 marked the first version of a
Windows operating system for mobile devices named SmartPhone 2002 (a.k.a Pocket PC
2002). Having a separated OS for smart phone from the rest of products supported in
Windows CE is a strategic step from Microsoft to put more focus on mobile devices.
Since then, Microsoft has actively developed and released a couple versions of windows
systems for smart phones including Windows Mobile 2003, Windows Mobile 5 and
Windows Mobile 6. On October 6, 2009, Microsoft announced the release of Windows
Mobile 6.5 which was un-intended release as a gap for a full-touch feature which will be
rolled out in Windows Mobile 7 in mid of 2010.

In this study, we are going to examine the latest and greatest version of Windows for
mobile devices, Windows Mobile 6.5. Even though Windows Mobile (WM) is a
separated product, its kernel is still remained the same as in Windows CE product.
Following this, Windows Mobile 6.5 is running on the kernel of Windows CE 5.0.2. The
term Windows Mobile 6.5 kernel and Windows CE 5 kernel are used intellectually in this
study. And they both indicate the same kernel.

2
WINDOWS MOBILE – DEVELOPMENT REQUIREMENT
SUPPORTED PLATFORMS

Unlike Windows CE where OEMs have to build their OS design to create an

associated hardware platform, things in Windows Mobile are much easier. Windows
Mobile 6.5 product supports only two platforms:

Pocket PC (Windows Mobile Standard)

Smart Phone (Windows Mobile Professional).

This greatly simplifies Windows Application developers’ life since their applications
are built to run on a platform instead of a specific device. It means if an application is
built to run on smart phone platform, it is guaranteed to run successfully on all smart
phone devices.

SUPPORTED PROGRAMMING LANGUAGES

There are several approaches that can be taken when developing applications for
Windows Mobile powered devices. Developers can choose a programming language
which they feel comfortable to work with. They can also use more than one programming
language for different components in their application depending on different needs.
Windows Mobile comes with many supported development languages:

Visual C++: is considered a "native" development language. Applications written
in Visual C++ can talk directly with kernel APIs and hardware layer with no
intervening layer (unlike Visual C#, for example). Visual C++ should be used in
projects require fast response, interacting with Win32 API and access low level
components of Windows Mobile system.

Visual C# and Visual Basic .NET: are "managed" development languages.
These languages are considered as high programming languages. Most developers
choose these languages to build their applications for the sake of its easy to learn
and maintain. Also, using these languages, developers can access to
Microsoft.WindowsMobile class library which is a set of .NET components that
contain classes, enumerations, and delegates, that make up the managed part of
the Windows Mobile SDK. The WindowsMobile class library is to supplement
the .NET Compact Framework class library, and provide the benefits of Rapid
Application Development (RAD) for creating new mobile applications.

Client-side Jscript: The web browser included with Windows Mobile powered
devices - Internet Explorer Mobile - supports JScript. JScript is a superset of the
language most commonly known as JavaScript. A JScript application is executed
inside the web browser, and uses the web browser's window for input and output.
It is possible to make use of AJAX programming techniques to provide a degree
of user interaction, and to communicate with a remote server.

ASP.NET: While JScript is a client-side solution to writing Internet-style
applications, ASP.NET is a language used to build server-side services. With
ASP.NET, you can write applications in Visual C# or Visual Basic .NET that
reside on a web server, and perform complex processing, including creating user
interface controls, and accessing databases. ASP.NET isolates the device

3
 characteristics from the application, making it straightforward to run one
application on many difference device-types.

SOFTWARE DEVELOPMENT TOOLS:

Windows Mobile product was shipped with a lot of tools and software to help
developers in the process of building and deploy WM applications. Developers can take
full advantages to rapidly develop, test and deploy their applications on targeted devices.
These supported softwares include:

Microsoft Visual Studio 2005

ActiveSync

Windows Mobile Device Center (WMDC)

Device Emulator

Cellular Emulator

Hopper Test Tool

DEVELOPMENT SOFTWARE REQUIREMENTS:

Windows Server 2003

Windows Server 2003.

Microsoft Visual Studio 2005, Standard Edition or above. SP1 recommended.

Microsoft .NET Compact Framework v2 SP1. SP2 recommended.

ActiveSync 4.5.

Windows Mobile 6 Professional SDK, or Windows Mobile 6 Standard SDK, or both.

Windows XP

Windows XP SP2.

Microsoft Visual Studio 2005, Standard Edition or above.

Microsoft .NET Compact Framework v2 SP1. SP2 recommended.

ActiveSync 4.5.

Windows Mobile 6 Professional SDK, or Windows Mobile 6 Standard SDK, or both.

Windows Vista

Windows Vista.

Microsoft Visual Studio 2005, Standard Edition or above.

Microsoft .NET Compact Framework v2 SP1. SP2 recommended.

For synchronizing data, the Windows Mobile Device Center is required.

Windows Mobile 6 Professional SDK, or Windows Mobile 6 Standard SDK, or both.

4
WINDOWS MOBILE – OVERVIEW

Figure 1 - Windows Mobile Components

Windows Mobile 6.5 has plenty of features which a mobile device ever needs. When
we look at the system as a whole, WM is one of the top operating systems for mobile
devices. The OS is built with many cutting-edge features including:

5

Basic features: telephone API, SMS messaging, vibration, screen resolution
recognition…

Most-wanted features: Bluetooth, Wi-Fi, web browser, media player…

High-end features: GPS, international language, speech recognition…

Figure 2 – Windows Mobile operating system architecture

Windows Mobile 6.5 has its kernel from Windows CE 5.0.2. Figure 2 shows a picture of
Windows CE 5 architecture. The system is divided into four different layers:

Application Layer: this layer contains most custom applications. An application
in this layer runs in user mode. Applications run in this layer are considered as un-
trusted codes. A crash in these applications in this layer will not cause a severe
damage to the whole system. Usually, an application will be shut down by the
system without bringing down other components. Applications in this layer are
built directly with coredll.dll library. Some of applications in this layer are
included in Windows Mobile product. But most of applications are developed by
third parties to provide different services to end-users. Applications in this layer
interact with below services mainly through a set of system service APIs
including a subset of Win32 APIs. We will discuss in detail later how an
application in user-mode uses a system service.

Operating System Layer: this layer contains all required services of an operating
system. These services include file system management, memory management,

6
 device manager, IO service, communication and networking… All of services in
this layer are operating in kernel mode. Codes that run in kernel mode must be
well tested since any crashes will potentially bring down a whole system and
cause a severe damage. This layer is mainly maintained by Microsoft. The
implementation of this layer is delivered together with Windows Mobile product.

OEM Layer: This layer is reserved for OEM vendor components. OEMs are
responsible for building some of very-low level components which mainly
interact with hardware devices. These components include system bootstrap,
memory map, interrupt handlers…

Hardware layer: this layer represents all hardware components of a device.

In general, Windows Mobile has a good separation layer. Each layer has different
roles and responsibilities. Microsoft is taking client oriented as an excellent approach to
separate WM platform into different layers. Each layer represents for different client of a
platform. Application layer targets to application developers. Operating system layer is
mainly for Windows Mobile developing team. OEM layer is for OEM vendors who build
mobile devices. Each layer provides a running environment for a certain group of
processes and libraries. Having a good layer separation improves the portability of
components. A change of a component in a layer has very less impact on other
components in different layers. Communication between two adjacent layers usually goes
through a well-defined set of API methods. This abstracts away the detailed
implementation of a method. A component from upper layer only needs to know which
API to execute without knowing how this method can be done. For embedded systems, a
separation of operating system layer and OEM layer is crucial. This maximizes the
portability of a system on different devices having different hardware designs with no or
less modification in its kernel. This separation makes thing easier for OEM to do a kernel
update. Vendors only need to download the latest OS patch and link with their HAL
components to create a new device platform. Then, end-users can download and install
the new release on their devices.

7
WINDOWS MOBILE – KERNEL OVERVIEW

Figure 3 – Windows Mobile Kernel

Coredll.dll: is a main library which is linked directly to WM applications. When the

system loads an application into memory, it also makes sure to load coredll.dll with it
into user mode memory. We will look into more details later to where coredll.dll resides
in OS memory.

Nk.exe & Nk.lib: these are considered the core kernel service of WM platform. They are
responsible for all main OS services such as virtual memory, scheduling,
synchronization… Besides, kernel process (Nk.exe), WM OS also uses a process server
library (PSL) which is a process that implements a set of APIs for applications to call.
These processes include:

Filesys.exe: this process is responsible for all file system management. FileSys.exe loads
file system drivers.

GWES.exe: GWES.exe loads device drivers presenting a standard set of functionality for
all similar devices. Drivers that GWES loads might expose the stream interface or they
might expose other interfaces. Having alternatives make accessing the drivers much
faster. GWES loads display drivers, printer drivers, and touch screen drivers.

8
Device.exe: Device Manager is a process that tracks loaded drivers and their interfaces. It
runs continuously and launches from the kernel. Device Manager can notify the user
when device interfaces become available and unavailable. A user or the system itself can
make device interfaces available or unavailable. Device Manager sends power
notification callbacks to device drivers and provides power management services.

Services.exe: Host process for system services

Splitting things into different processes makes operating system more organized. But it
also increases complexity and time consumption when performing context switching.
System processes are mostly running in kernel space, while WM applications are running
in user space. Accordingly, in order for an application uses services from these system
processes, WM kernel must perform context switch from user mode to kernel mode.
After this switching is complete, the kernel will have to put current thread which
associates with application process to one of above process and start executing the
method. These tasks are relatively expensive but not too expensive as will be explained
later in memory model. The worst case is each system process only supports a set of
related APIs. A call to an API method which is available in filesystem.exe, in turn, calls
another API defined in device.exe which, in turn, calls a method of device driver which is
loaded in user mode can cause a performance issue. In this case, WM operating system
has to perform many extra tasks:

1. The kernel makes context switch from user mode to kernel mode and puts current
thread into filesystem.exe process and executes a required method available in
filesystem.exe.
2. When it comes the time to call another API in device.exe, WM kernel then puts
current thread from filesystem.exe process space to device.exe process space and
executes corresponding method API defined in device.exe
3. Now, it is time to call a method that is implemented in device driver that is loaded
with the application in user mode. WM kernel must perform context switch from
kernel mode back to user mode and executes this method in user-mode device
driver.
4. When the method returns, the kernel again performs another context switch from
kernel mode back to user mode and puts current thread back to device.exe
5. Then, WM kernel puts current thread back to filesystem.exe
6. Finally, it performs context switch from kernel mode to user mode and puts back
current thread into its original process.

As you can see, in the worst case scenario, each system service call might cause
current thread jumping back and forth between kernel mode and user mode at least twice,
and so many process space changes. This is the bottleneck in performance of current
Windows Mobile OS. The above worst-case scenario only happens when device driver is
operating in user space. WM allows device driver can operate in either user mode or
kernel mode. There are cases developers have to put their device drivers in user mode
such as OEM blocks the ability to register device driver in kernel mode or for the sake of
stability, device drivers should be loaded in user mode to avoid system crash.
Fortunately, the latest kernel of Windows CE 6 already addressed this performance issue.

9
However, since WM 6.5 still has its kernel core from Windows CE 5. It is subject to this
performance issue.

Memory Layout: The 32 processes x 32MB (32x32) limitation

Figure 4 – WM OS memory layout Figure 5 – WM OS memory layout

Windows Mobile memory layout shares many of common attributes from operating
system like Windows XP. It is a 32-bit operating system which has a total memory
address of 4GB. This address space is divided into different areas.

As shown in Figure 4, the operating system has a reserved area of 2 GB (hexadecimal

addresses 8000 0000–FFFF FFFF) in the upper address space where only code with
privileged access (referred to as kernel mode or KMode) can run. This area is often
referred to as the kernel address space.

The lower 2 GB (0000 0000–7FFF FFFF) is the user address space. The user address
space is actually divided into 64 equal parts of 32 MB each called slot memory.

The upper part of the user address space (slots 33–63) is the large memory area that
includes things like memory-mapped files and resource-only DLLs. This area is also used
for the object store. In many situations, a better option for large memory allocations is to
use memory-mapped files. You can make memory-mapped files work very much like
ordinary file system files, including the ability to create, open, write, read, seek, close,
and delete them. Therefore, a memory-mapped file can be a great alternative to any
temporary file that your application can create and use only during the execution of your
application. Because memory-mapped files are created in the same memory area as the
large memory allocations described previously, they share the same attribute of being
available to all loaded processes. Memory-mapped files are therefore another option for
sharing data between processes. In a managed application, this is the place where all

10
assemblies (including Mscorlib.dll and the application's executable file and DLLs) are
loaded.

Slots 2–32 are reserved for the other loaded processes in the system. Each new
process is loaded in one of these process slots, and when it is running, it is copied (by
means of some simple aliasing of the virtual address space) to the active process slot (0).
The reserved area shown earlier in Figure 4 actually contains all of the other loaded
processes in the system (slots 2–32), as shown in Figure 5. Considering the fact that
many devices have several processes loaded already when they are started (such as
filesys.exe and device.exe) and that the user probably wants to use other applications in
parallel, the actual number of processes that your application can occupy is more limited
than that.

The first two slots (0 and 1) are the application space that includes the currently
active process (slot 0) and the loaded execute in place (XIP) DLLs located in ROM (slot
1). The application space (0000 0000–03FF FFFF) is used by the currently active
(running) process and the loaded ROM DLLs.

Slot 0: holds the currently running process,

and just above a small reserved area (guard
section of 64 KB), it includes the executable
code and data (starting at address 0001 0000).
It also includes the virtual memory
allocations, such as the application heaps and
thread stacks. In a managed application, this
is where the application domain heap, just-in-
time (JIT) compiler heap, and garbage
collection heap are located. The numerous
heaps are created to avoid memory
fragmentation.

Slot 1: the DLLs located in ROM are run.

When loaded, they are available to all
processes. A good example is
COREDLL.DLL, which is always loaded at
Figure 2. Application space the top of slot 1 and is always available to all
running processes. In a managed application,
this is where the common language runtime is loaded. (The runtime consists of the DLLs
MSCOREE.DLL, MSCOREE2_0.DLL, and NETCFAGL2_0.DLL.)

As already mentioned, the 32-MB process memory can be a real limitation. If your
application needs an even larger memory allocation—for example, 64 MB—it isn't
possible to allocate that memory in the process memory. The memory allocation actually
occurs, but in the same memory as the memory-mapped files. The threshold is 2 MB, so
if the request memory allocation is larger than 2 MB, that memory area is used.

Advantages: the limitation of 32 processes x 32 MB does provide some benefits in term

of performance and implementation. Switching process is much easy since the kernel
only needs to copy memory slot of process to be run to slot 0. Keeping 32 slots of
11
memory of all processes available at all time allows direct access to memory space of any
processes running on the system. Applications can take advantage of this fact to quickly
retrieve data even though this is not a good practice.

Disadvantages: Nowadays, mobile devices can reach gigabyte of physical memory. The
address space of 32 MB per process is really tiny to do any good thing on it. Even worse,
32 MB is the largest memory space that a process can access. In reality, this address
space is much smaller. Without paying attention into memory usage, an application can
easily run out of its address space. Also, the ability of accessing other process memory
spaces exposes security concerns.

Windows Mobile context switch: a logical context switch

All WM applications are running in user-mode. When applications need to perform

system calls which are part of Win32 APIs, the system will perform context switch to
move execution from user-mode to kernel mode. The call will be dispatched to a correct
standalone process and execute the system call method on this process. Windows Mobile
APIs are implemented by a set of server processes. Besides the kernel process (nk.exe),
we have other server processes: filesys.exe, gwes.exe, device.exe, services.exe. When an
application calls an API from one of these server processes, the application thread
actually jumps into corresponding server process. And the execution of the API call is
done on the application thread. In WM, context switch occurs when application raises an
exception. All exceptions go to the kernel first. The kernel marshals (maps) arguments,
adjusts permissions, flushes cache and TLB if necessary, and finally sets things up so that
the thread continues execution at the desired API inside the desired server process. The
thread, now running inside the server process, executes the real API call. When the call
finally returns it takes another exception, because during the API call setup the kernel
sets the return address to another specially-coded invalid address. During the return the
kernel again adjusts arguments, permissions, and other state as necessary.

Advantages: the context switch in WM OS does not perform a full hardware context
switch as in normal operating systems. Instead, it only performs a logical context switch.
Usually, kernel mode and user mode are different privileges supported by a processor. By
checking a privilege of an executing thread, a processor can either allow or block certain
instructions. User mode is a restricted privilege, while kernel mode is a full privilege. In
order to switch between these two modes, kernel must perform some assembly codes.
Hence, context switching (a.k.a hardware switching) is the most hardware dependent
codes in a kernel. In WM operating system, user mode and kernel mode are understood
as the ability of accessing different areas of memory address space. If an application is
operating in kernel mode, in addition to its own memory process space, the application
can access the reserved area of 2 GB (hexadecimal addresses 8000 0000–FFFF FFFF).
An application in user mode can only access it own memory slot which is 32 MB.
Implementing a logical context switch simplifies the kernel code. Freeing kernel from
hardware dependency makes Windows Mobile OS able to operate on any hardware
devices with little modification. In term of performance, performing logical context
switch takes less time than hardware context switch. Using logical context switch, WM
OS can provide developers an option to choose whether they want their applications to
run in user mode or kernel mode at any given time.

12
Disadvantage: Logical context switch does not take full advantage of different privileges
from hardware layer. It is easier for attackers to get control over the system after they
pass some security checks.

CONCLUSION
Windows Mobile system has all required features of an operating system for mobile
devices. The kernel has a good architecture design. System services are divided into
different processes. Each process operates in its own memory space. The relatively
simple memory layout used in Windows Mobile OS makes things easier for memory
management. The ability of accessing other processes’ memory address space helps a lot
in inter-process communication. This achieves a better performance due to arguments are
passed by pointers instead of marshalling and un-marshalling values. Despite all of these
benefits, Windows Mobile system really needs to lift up the 32 processes x 32 MB
limitation. This is the big obstacle which prevents developers from building any rich
applications running on Windows Mobile devices. That is for the WM operating system
alone. In term of platform features, the current WM platform is missing important touch-
screen feature and other nice-to-have features such as zooming, screen display rotation…
Also, Windows Mobile platform should provide a rich library to Java applications.
Missing support for Java applications exposes a much larger impact then the existing 32
processes x 32MB limitation.

REFERENCES
Windows Mobile Developer Center - http://msdn.microsoft.com/en-ca/library/bb158486.aspx
Windows CE Base Team Blog - http://blogs.msdn.com/ce_base/default.aspx
Stanislav PavLov & Pavel Belevsky - Windows Embedded CE 6.0 Fundamentals

13