A Study on Windows Mobile 6.5 Operation System

1

A STUDY ON WINDOWS MOBILE 6.5

OPERATION SYSTEM

Author: Thang Minh Le

[email protected]

2

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.

3

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

4

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.


� ActiveSync 4.5.


Windows Vista

� Windows Vista.

� Microsoft Visual Studio 2005, Standard Edition or above.


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


5

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:

6

� 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,

7

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.

8

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.

9

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.

10

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

11

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

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

Figure 2. Application space

12

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.

13

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

A Study on Windows Mobile 6.5 Operation System

Documents

Transcript of A Study on Windows Mobile 6.5 Operation System