Porting the .NET Compact Framework to Symbian
Phones
Frank Siegemund, Robert Sugar, Alain
Gefflaut and Friedrich
van Megen, European Microsoft Innovation Center
|
 |
ARTICLE
PDF Version |
Abstract
This paper presents our experiences in porting selected parts of the
.NET Compact Framework to Symbian smartphones. Our port includes support
for basic services such as threading and file access, low-level networking
modules as well as Web Services. We also present a portable .NET GUI
for the Symbian platform. The paper shows how the programming models
of .NET can be efficiently mapped to the runtime structures provided
by operating systems for resource-constrained devices such as the Symbian
OS. In a detailed analysis, we compare the performance of our port to
that of Java and native code.
1 INTRODUCTION
During the last two decades, mobile phones have become almost ubiquitous.
As a result of this development, it is increasingly important for companies
to offer applications for mobile users that seamlessly interoperate
with server-based business software in order to improve customer satisfaction
and service availability. The .NET Framework has been a popular platform
for creating such applications and services both on stationary computers
and Windows CE-based mobile devices. While Windows CE-based smartphones
are getting increasing attention, however, a number of phones are currently
based on the Symbian operating system. According to a recent study
by Canalys [Canalys], the Symbian OS owned 63.2 % of the mobile device
OS market at the end of the third quarter 2005.
A core problem of the Symbian OS is that application development
on this platform is considered to be difficult. Taking into account
the
need for companies to offer services to a broad range of mobile users,
it would therefore clearly be advantageous to have a .NET Common Language
Runtime (CLR) available on Symbian-enabled devices. .NET developers
could then reuse code instead of reimplementing applications from the
ground up in an entirely different programming environment. Reimplementation
can be especially cumbersome since commonly used CLR/.NET features
may not be natively present on different programming platforms [Sin03]
(e.g., floating point support is absent in some J2ME profiles, SOAP
Web Services support may be missing, XML and graphics programming model
might differ). These issues mean that direct code reuse is not possible,
which results in increased costs and is likely to introduce new program
errors. Having a CLR running on Symbian smartphones implies that developers
could implement applications for this platform using the same programming
environment and tools offered by the .NET Framework. With respect to
convenience, this would be a significant step forward for application
development under Symbian.
In this paper, we present our experiences in porting selected parts
of the .NET Compact Framework to the Symbian operating system, and
report on the major design decisions that had to be made during this
work. The main challenge was to map the programming model of the .NET
Compact Framework (or, more precisely, of .NET programming languages
like C#) onto the programming model provided by the Symbian OS. Because
of the considerable gap between these two models, which is a result
of the resource constraints of many Symbian-enabled devices, porting
.NET technologies to Symbian poses specific problems that are addressed
in the remainder of this paper. After having discussed these issues,
the paper gives an overview of the memory requirements of our port
and provides a detailed performance analysis of basic services such
as string handling and of our GUI implementation.
In summary, the paper answers the following core questions:
- Is it feasible to have a .NET Compact Framework CLR running
on resource-constrained Symbian smartphones?
- What are the main obstacles when porting the .NET Compact
Framework to Symbian?
- Is it possible to implement a portable .NET GUI on resource-constrained
Symbian smartphones?
- What is the expected performance of carrying out .NET applications
on the targeted device platform?
The remainder of this paper is structured as follows: The following
section summarizes related work. Sect. 3 presents the current status
of our port. Sect. 4 shortly reviews the .NET Compact Framework architecture,
provides information about the Symbian operating system, and compares
the hardware constraints of Symbian smartphones with those of other
.NET hardware platforms. Sect. 5 reports on our experiences and the
major design decisions we had to make while porting the .NET Compact
Framework to Symbian phones. It also shows how we dealt with the specific
characteristics of Symbian and its programming model. In Sect. 6 we
evaluate our implementation, and Sect. 7 concludes this paper.
2 RELATED WORK
The number of programming languages targeting the Common Language
Infrastructure (CLI) [CLI,MG00] has been steadily increasing over the
last years.
Besides the variety of available programming languages [BKR04,Gut01,
Ham03,SSM00], however, CLI-compliant virtual execution systems are
also increasingly used to facilitate application development across
different hardware platforms and operating systems. Examples for this
development are Microsoft’s Rotor and 3rd party Mono and DotGNU
implementations of the CLI [DotGNU,Mono, SNS03]. While these implementations
aim at supporting .NET on operating systems such as Unix and MacOS,
the major difference to our work is that we investigate an operating
system that is explicitly designed for resource-restricted mobile devices.
As a result, constraints with respect to the amount of available memory,
computational resources, and restrictions in the functionality provided
by the operating system pose challenging new problems and research
questions that we needed to address.
There are papers (e.g., [Opera] and [Helix]) dealing with several
obstacles that arise when porting applications to the Symbian operating
system.
Some of the described approaches are also applicable in the context
of our work and helped us find a direction for our project. The migration
to other hardware platforms or operating systems is recognized as one
of the most difficult and error-prone processes during the lifetime
of a software product [BLWG99]. George and Wong [GW04], for example,
address the problems that arise when porting a powerful real-time operating
system such as Windows CE .NET to a different hardware platform, while
Kontogiannis et al. [KMW+98] try to automate tasks of the migration
process. As for the .NET Framework, its architectural design aims at
simplifying migration to a different hardware platform by means of
the Platform Adaptation Layer [SNS03].
Because of the resource constraints of many Symbian smartphones,
this paper focuses on the .NET Compact Framework [NetCF] – which
itself was designed for mobile devices and first implemented to run
on Windows
CE. The .NET Compact Framework already considers some of the typical
constraints of mobile platforms but does not deal with the unique constraints
and programming models of operating systems such as Symbian.
Most Symbian smartphones ship with a Java Virtual Machine (JVM) already
installed on the phone [RV01] (J2ME MIDP, the Java 2 Platform Micro
Edition Mobile Information Device Platform targets resource-restricted
mobile devices such as mobile phones). A .NET Compact Framework implementation
for smartphones should therefore be at least comparable to Java ME
implementations with respect to provided functionality and resource
consumption [Sin03]. Nevertheless, there are major differences between
Java and .NET that make a direct comparison difficult: (1) Java bytecode
is often interpreted while the CLR primarily uses Just-in-Time (JIT)
compilation. (2) There are international standards for the CLI and
C#, while there is no such standard for Java (there is a Java Community
Process, though). (3) .NET supports many programming languages – with
J# also a flavor of Java. This can make direct comparison difficult
because the advantage of language integration can imply architectural
decisions affecting the performance of the CLI. (4) The .NET Compact
Framework comes with functionality that is not natively supported by
J2ME MIDP. However, there are a range of publicly available add-ons
and class libraries that support much of this functionality also on
the Java platform.
The company AppForge [Forge] has a product called Crossfire that
aims at enabling cross-platform application development on mobile devices
using .NET programming languages. To the best of our knowledge, .NET
applications are transformed into a device-specific custom format that
is then executed on a phone. Thus, the main difference to our work
is that we aim to have a complete CLI-compliant virtual execution system
running directly on Symbian-enabled mobile phones. We also strive for
a greater integration into the .NET programming environment by exposing
the same interfaces for Web Services and GUI programming as with the
.NET Compact Framework.
Building efficient graphical user interfaces on top of the Symbian
OS poses challenging problems because of the resource constraints of
the targeted device platform. Compared to stationary PCs and PDAs,
Symbian smartphones have relatively small displays, often no touch
screens, and relatively weak processors (cf. Sect. 4). Hence, several
design decisions have to be evaluated when realizing GUI functionality
on such a hardware platform. An interesting approach to GUI programming
in the context of .NET is outlined by Bishop and Horspool [BH04], who
propose an XML-based GUI description notation that allows programmers
to abstract from much of the low-level issues of GUI programming. Their
Views GUI engine [BW05] provides an implementation of this approach
for different operating systems and adds the functionality of the System.Windows.Forms
library to Rotor. Some of these concepts are used and extended in Mirrors
[Mil05].
Rashid et al. [RTCE04] compare the performance of native Symbian
code with interpreted Java applications, and Raghavan et al. [RSL04]
reports
on a model-based performance evaluation of applications on mobile devices.
In the scope of our work, test suites provided by IBM [jMocha] covering
basic features such as method calls, thread creation, and data access
were used to carry out performance comparisons.
3 CURRENT STATUS
Overview
In the current version of our prototype it is possible to execute
.NET Compact Framework applications on two selected Series 60 smartphones.
The Series 60 platform from Nokia was our first target because it is
the most popular User Interface (UI) platform for Symbian phones at
the moment. However, we would like to emphasize that our design does
not rely on any UI platform on top of the core Symbian OS, but instead
depends only on low-level runtime structures that are provided by the
core operating system. Consequently, only a very small subset of our
project – the Symbian application that starts the actual .NET
execution engine – has to be rewritten when porting our work
to a different Symbian UI platform. Ease of portability across different
Symbian devices is important and was a major factor influencing our
design decisions because there are not only many different flavors
of the Symbian OS itself but also a range of different UI platforms
on top of it (such as Series 60 or UIQ). 
Figure 1: Starting .NET applications on a Symbian
smartphone.
The core modules of functionality supported by the .NET Compact
Framework CLR can be classified as (1) basic services, (2) storage,
(3) networking, (4) GUI, and (5) device support [SNS03]. Our prototype
for Symbian implements all main basic services such as threads, synchronization
mechanisms, timers, events and mathematical support functionality.
Regarding storage, it is possible to work with files and XML; XML
can be read from files into internal data structures, modified in
memory, as well as written back to and exchanged over Symbian’s
file system. The current implementation does also support low-level
networking over the socket interface, Web requests, and Web Services.
Of central importance in our work was to keep the existing .NET programming
interfaces unchanged in order to make the development process on
the Symbian platform as easy as possible. Another result of keeping
the programming interfaces intact is that all the development tools
available for the .NET Compact Framework are still supported. For
example, programmers can make use of the established way to implement
Web Services in the .NET Framework, which facilitates Web application
development. Keeping programming interfaces unchanged is also important
for the GUI implementation in our prototype because it implies that
GUI layout tools such as the Form Designer embedded into Visual Studio
can be used to design user interfaces. Because of this, our port
includes a portable GUI for Symbian-enabled devices. As the last
module of functionality, the .NET Compact Framework supports the
interaction with various kinds of devices over IrDA, Bluetooth, or
USB. Our port, however, does not support these different communication
interfaces so far. Instead, Web Services operate on top of GPRS or
GSM; simple messaging functionality for sending SMS has also been
implemented.
Application Development and Application Startup
Considering the wide range of supported functionality, an interesting
question is how a programmer can actually use this functionality
to develop applications for Symbian smartphones. The simple answer
to this question is that application development for Symbian smartphones
does not differ from application development for Windows-based devices.
In fact, the same programming environment and tools can be used during
the development process. Typically, an application that has been
written in a language supported by the .NET Compact Framework (e.g.,
C#) is compiled on a desktop computer using the standard compiler
for this language (e.g., csc for C#). The result of this compilation
is an EXE file in the Portable Executable (PE) file format. This
file – without any modifications – is copied to a Symbian
smartphone and executed there inside the .NET virtual execution system.
There are several ways to start .NET applications on a Symbian
smartphone. For example, each .NET application can be exposed as
a separate icon
on the phone’s main screen. The disadvantage of this is that
an additional installation step is required when deploying the application
to create the icon. Furthermore, as the phone screen itself is quite
small, too many icons can reduce usability and make navigation difficult.
Another possible deployment path is to start applications from within
a separate tool. Users would then use this tool to browse the contents
of their phone and start an application by just clicking on it. Our
choice was to follow a similar approach by starting .NET applications
from within the Web browser on Symbian smartphones. As can be seen
in Fig. 1, a user opens the Web browser from the main phone menu.
Each .NET application is then exposed as a bookmark that references
a local application file. By clicking on the bookmark, the .NET execution
engine is started as an embedded application inside the Web browser
and automatically loads and runs the referenced application file.
Fig. 1 depicts the process of starting .NET applications on Symbian
smartphones based on the example of a simple text-based Web Service
application.
GUI
Besides text-based applications, our prototype also supports applications
with a more sophisticated user interface. As can be seen in Fig.
2, the corresponding GUI implementation is based on custom controls
that are similar to that on Windows-based smartphones. The reasons
for this design decision are described in more detail in Sect.
5. Currently, a range of different GUI controls are available.
We support
windows and dialogs, labels, text boxes, push buttons, combo
boxes, radio buttons, picture boxes, and menus (see Fig. 2).
Figure 2: A portable .NET GUI on a Symbian smartphone. 4 ARCHITECTURE
OVERVIEW
Fig. 3 gives an overview of the .NET Compact Framework architecture
and its underlying components. As can be seen, the major constituents
of this general architecture are (1) the actual hardware of the
mobile device, (2) the operating system that provides access to this
hardware,
(3) the runtime environment, which maps the instructions of a (4)
.NET application onto instructions of the operating system and
the underlying hardware [SNS03,MG00].
Figure 3: Overview of the .NET Compact Framework
Architecture. In the following, we will shortly describe
these individual components before we present our experience in porting
parts of the .NET Compact Framework to Symbian.
Hardware Constraints
A crucial aspect when trying to target a different computing platform
for .NET is to be aware of the computational and functional restrictions
of the underlying hardware.
In January 2006, the Symbian Web site listed 44 different Symbian
OS phones, of which 19 were distributed by Nokia, 16 were built for
NTT DoCoMo’s FOMA network (10 from Fujitsu, 4 from Mitsubishi,
1 from Motorola, and 1 from Sharp), and the others were manufactured
by companies such as Sony Ericsson or Panasonic. For 24 of these
44 phones, for which more detailed information could be found, we
looked more closely at the technical specifications.
All of the investigated phones are built around ARM processors
or variants such as the OMAP 1510 from Texas Instruments, which itself
is based on an ARM architecture. The processor speed varies from
104 MHz for the ARM4T processor to 220 MHz for an ARM5 CPU. The fact
that ARM processors are used in Symbian smartphones has made our
port significantly easier since JIT compilers were already available
for this hardware platform – most Windows CE devices also feature
ARM-based cores.
The most striking difference when comparing Symbian smartphones
to Windows CE devices is in the amount of random access memory available.
According to [MR], the amount of volatile memory available for
applications
on the Nokia 3650, the Nokia 6630, and the new Nokia N90 is 1.9
MB, 7 MB, and 21 MB, respectively. This is the amount of free RAM
after
the OS has started. Early Symbian phones generally had less than
4 MB of RAM and only the newest models feature more than 10 MB;
Windows Mobile devices have generally much more RAM than that. We
suspect
that the main reason to limit volatile memory apart from cost is
battery consumption. Continuous refreshing of the memory modules
can reduce standby time significantly. Hence, non-volatile memory
(most of the new phones come with an MMC card) is preferred for
storage.
Table 1: Hardware characteristics of Symbian Series
60 and Windows Mobile devices Tab. 1 depicts typical
hardware characteristics of Symbian Series 60 devices on the low-end
(Nokia 3650), medium-tier (Nokia 6630) and high-end (Nokia N90, a
recently introduced smartphone). For comparison the table also contains
specifications of Windows CE-based devices. The iPAQ H3650 is one
of the first iPAQs that featured a .NET Compact Framework, while
the Dell Axim is a new model. It should be noted that other Symbian
devices exist with different characteristics, such as the Ericsson
P910i with a touch screen or the more powerful Series 90-based Nokia
Communicators.
As a summary, we have found that none of the hardware constraints
of Symbian smartphones should make it impossible or infeasible to
port the .NET Compact Framework to the Symbian platform. Especially
the memory constraints of Symbian smartphones, however, need to be
considered when making design decisions.
Operating System
The second layer of the .NET Compact Framework architecture (cf.
Fig. 3) is made up of the operating system, in our case the Symbian
OS. In many respects does the Symbian OS considerably differ from
Windows CE, which has been the standard platform for hosting the
.NET Compact Framework CLR. These differences affect elementary features
such as multitasking, error handling, file access, and networking.
They have therefore a significant impact on our goal to port the
.NET Compact Framework.
Here are some of the Symbian characteristics that so far caused
most of the problems in our project (Sect. 5 presents a more detailed
description of these issues):
- A C++ dialect that redefines basic language structures
- No writable global and writable static variables allowed
in DLLs
- Extensively used client/server model that, for example,
implies constraints for accessing file and networking functions
- Event-driven programming model with a focus on non-preemptive
multitasking
-
Symbian’s error handling and cleanup model
- Concepts from the Unix/Windows world such as environment
variables as well as several file and networking functions are
missing
CLR Architecture Overview The .NET Compact Framework CLR is made up of the following main
components [SNS03,MG00]: (1) class libraries, (2) execution engine,
and (3)
platform adaptation layer (cf. Fig. 3).
The goal of the .NET Compact Framework class libraries is to provide
a basic set of classes, interfaces, and value types that constitute
the foundation for developing applications in .NET. For example,
support for integers, boolean values or strings, functionality for
performing I/O, classes for handling exceptions, and methods for
collecting information about loaded classes are all included in the
class libraries of the .NET Compact Framework.
The execution engine is the core component of the CLR – it
provides the fundamental services necessary for executing managed
code. While the execution engine consists of a large number of individual
components, some of its most important parts are: (1) a just-in-time
(JIT) compiler (or alternatively an interpreter), (2) a garbage collector,
and (3) a class and module loader. The decision whether to use a
JIT compiler or to immediately carry out generated instructions in
an interpreter depends on the resource constraints of a given platform.
Our port is based on a JIT compiler, not on an interpreter.
Because the design of the .NET Compact Framework anticipated operating
system portability, access to core operating services occurs through
a platform adaptation layer (PAL). The main responsibility of the
PAL is to map calls from the execution engine to functions provided
by the underlying host operating system. In other words, the PAL
serves as the main mediator between the operating system (Symbian
OS in our case) and the CLR. As a result of the architectural design
of the .NET Framework, the PAL is the core component that needs to
be reimplemented when porting the .NET Compact Framework to Symbian
OS.
5 PORTING THE .NET COMPACT FRAMEWORK
In the following, we describe our port of selected components of
the .NET Compact Framework to the Symbian platform and discuss the
major design decisions that affected our work. In order to do that,
this section analyzes the characteristics of the Symbian operating
system that caused most of the problems in our project, and proposes
solutions for dealing with these issues.
We would like to point out that the result of our work is a research
prototype, not a complete and thoroughly tested product. The main
focus of our project was on evaluating whether it is feasible to
port the .NET Compact Framework to Symbian phones by means of an
exploratory approach. Having said this, the port runs stable and
we were able to develop a range of neat applications based on our
work.
C++ Dialect
The flavor of C++ that is used to implement native Symbian applications
caused several problems in our project. In particular, Symbian C++
introduces some peculiar language features and programming models
that were primarily introduced because of the limited device capabilities
of Symbian smartphones. On the other hand, it appears that some of
the restrictions and models of Symbian C++ still exist merely because
of historical reasons and because of compatibility issues [EB04].
Important differences between Symbian C++ and standard C++ include:
(1) different standard data types, (2) missing standard libraries
such as a libc, (3) a special exception handling mechanism, and (4)
a different memory management model.
First, the usage of simple data types such as int or unsigned long
are not recommended by the Symbian Software Development Kit (Symbian
SDK); so types such as TInt and TUInt32 had to be used instead. Although
these naming differences appear to be purely syntactic at first sight,
they can result in hard to find errors when porting complex software
such as the .NET Compact Framework CLR.
Second, as the full libc is not supported by Symbian, a basic implementation
had to be attached to our project containing memory management (like
memcmp) or C-type string manipulation functions (such as strlen).
The STL (Standard Template Library) is also not supported in Symbian
due to size limitations.
Third, the GNU C++ implementation of exception handling was not
mature enough at the design time of EPOC (the old name of Symbian),
thus
the Symbian architects employed a more lightweight approach to error
handling – the “trap harness” mechanism. A function
called User::Leave() corresponds to the throw directive, while the
TRAP and TRAPD macros are called instead of catch. Exception objects
were also replaced by simple error codes.
Finally, as mobile phones are switched on for long periods of time,
the ability to reclaim all unused heap cells was crucial in the design
of the Symbian operating system. Therefore, a mechanism called “two-phase-construction” is
used during object creation, and a “cleanup stack” structure
makes sure that every object created on the heap is destroyed after
it has been used.
Writable Global and Writable Static Variables in DLLs The Symbian operating system was designed with memory-constrained
devices in mind. Therefore, it tries to avoid all unnecessary allocations
or wastage of main memory. To prevent allocation of memory for writable
static data in DLLs, which would have to be allocated for each application,
and to enable eXecution In Place (XIP), DLLs that are stored in ROM
are not copied to RAM when executed. As a consequence, the programming
environment does not support writable static or global data because
the segment containing these values in the DLL is not writable.
If this requirement is not a major issue when writing new applications,
it becomes a major problem when porting applications that have been
designed to run on operating systems supporting writable static data.
This is the case for the original Microsoft .NET Compact Framework,
which usually runs on top of Windows class operating systems. Two
strategies can be envisaged to solve this problem. First, rewriting
the libraries was ruled out as a viable solution since the number
of writable static data was too large to enable a manual rewrite
of the libraries. The second strategy, which is the one we followed
as a way to get a test version of the .NET Framework working as soon
as possible, consists in loading in RAM all DLLs used by the .NET
Compact Framework application. In order to do this, we designed and
wrote a specific loader. Starting the Framework is then realized
by calling the loader. The loader is in charge of downloading in
RAM the image of the .NET Compact Framework binary, as well as all
libraries that it needs (including the writable data section). The
loader also performs the necessary relocation in order to prepare
the execution. Once relocation is done, the loader identifies the
entry point defined in the .NET Compact Framework binary and jumps
to its location. Although this solution works, it is far from optimal
since it can result in a possibly high memory footprint. While this
is not a problem in our feasibility assessment, this issue would
have to be addressed in a complete port of the .NET Compact Framework.
Executing .NET Portable Executables
When a .NET application – which is usually generated using
a development environment and a compiler on a Windows-based PC system – is
to be executed on a Symbian phone, it must be assigned to our .NET
Compact Framework implementation for execution. As .NET compilers
generate files in the standard .NET portable executable file format,
it is possible to distinguish any .NET application from native Symbian
applications. Luckily, the Symbian OS provides the concept of so
called Recognizers, which are used to assign certain file types to
selected applications. For example, HTML files can be associated
with a Web browser, PDF files with an Acrobat reader, etc. As this
association can be based on more that just the file extension and
allows us to analyze the file to be executed, we use a special Recognizer
to launch .NET applications.
Dealing with Symbian’s Client/Server Framework
The Symbian OS introduces a range of servers to deal with system
resources on behalf of different clients. Examples of such servers
are the file server, the socket server, and the window server. Servers
are usually located in a different process or at least a different
thread than the clients that want to access their services. The problem
with Symbian’s client/server model from the perspective of
the .NET Compact Framework is that only the client thread that creates
resources for interacting with a server can use and destroy them.
This has some important implications for a port of the .NET Framework,
and especially the Platform Adaptation Layer (PAL). Imagine that
there is a .NET application consisting of two threads that both want
to access a file. In this scenario, the PAL would be responsible
for mapping the file access to corresponding operating system functions.
For example, there would be a function like PALFile_Write() that
sends a request to the Symbian file server to write data to a file.
However, because only the client thread that created the connection
to the file server can actually write to a file, the two .NET threads – which
are both mapped to Symbian threads in our implementation – are
not allowed to access the file. This problem persists independently
of whether both threads want to write data to the same file or not;
what matters here is only the fact that they want to access the file
system. To solve this problem, we introduced a mediator thread that
handles all communication with the file server. Symbian OS threads
that represent application threads in .NET interact with this additional
thread in order to access files. For the PAL implementation, this
means that PALFile_Write() does not interact
with the file server directly, but instead issues a request to the
intermediary thread
that communicates with the file server. A similar mechanism is used
to handle networking and console access.
Figure 4: Implementing PAL functions on standard
operating systems (left) and on Symbian (right)
Fig. 4 shows the effect of Symbian’s client/server model and
its security restrictions on the implementation of PAL functions.
The left side of Fig. 4 shows how PAL functions on standard operating
systems such as Windows or Unix simply map calls from the execution
engine to the corresponding functions of the underlying operating
system. In this model, the main task of PAL functions is data marshalling
so that the parameters coming from the .NET framework are appropriately
transformed into parameters for the operating system. In contrast,
efficient access to Symbian OS functions (cf. right-hand side of
Fig. 4) in the PAL requires an additional thread that sequentializes
requests from different application threads. Besides the added complexity,
another problem in this context is that many of the PAL functions
must be carried out in an asynchronous way in order to deal with
potential deadlock risks introduced by the sequentializing thread.
Imagine, for example, two .NET threads that are used to write data
to and retrieve data from a Socket; one .NET thread shall be responsible
for sending and the other for receiving data. If now the receive
function of the second thread is passed to the mediating PAL thread
before the send is actually performed by the first .NET thread, and
the receive call is implemented as a synchronous call (blocking),
this will cause a deadlock since the send will never be performed.
Hence, PAL functions in Symbian are not allowed to block, which again
increases the complexity of the PAL implementation on this particular
operating system.
Dealing with Symbian’s Focus on Cooperative Multitasking
In the desktop domain, preemptive multitasking replaced cooperative
multitasking years ago when resources became cheaper and PC-like
systems much more computationally powerful. Furthermore, using preemptive
multitasking for different computations that need to be carried out
concurrently is much easier from a programmer’s point of view
than having to deal with the burden to split a long-running task
into subtasks in order to guarantee responsiveness [BRH90,JSM91].
However, although the Symbian operating system supports preemptive
multitasking, switching between different preemptive threads is considered
very expensive and programmers are strongly encouraged to use cooperative
multitasking instead [EB04,Har03]. To support programmers in handling
cooperative multitasking, Symbian introduced the concept of Active
Objects as a programming paradigm. Together with a so-called Active
Scheduler, Active Objects are supposed to facilitate the programming
of non-preemptive concurrent tasks.
However, cooperative multitasking using Active Objects has still
the disadvantage that if there is a long-running calculation, it
only will give control to another task if it is finished. As this
might severely reduce the responsiveness of a user interface, for
example, books on Symbian programming [EB04,Har03] strongly suggest
manually splitting long-running tasks into smaller subtasks that
can faster pass on control to other subtasks, thereby improving the
overall responsiveness of the system. Unfortunately, this does not
map well with the notion of threads in .NET because threads in .NET
are generally viewed as being preemptively scheduled. To deal with
this issue in a port of the .NET Compact Framework there are several
theoretical solutions:
(1) If there is a thread in .NET, it is possible to generate a
preemptively scheduled thread in the Symbian operating system and
accept the effect
on system performance this does imply. (2) When the execution engine
requests a new thread to be created for a thread in a .NET application,
a new Active Object could be created that handles the associated
task. However, this would mean that we would need a mechanism to
automatically find a location in the code where this active object
can pass on control to a different task. Finding a place where this
can be done requires at least the help from the JIT compiler or special
statements in the .NET code that would have to be used by a programmer.
(3) Another important issue with threads is that Symbian’s
client/server model (see previous subsection) forces us to introduce
preemptively scheduled threads on the operating system layer to sequentialize
access to servers (the file server, for example). In order to reduce
the number of low-level Symbian threads, it is possible to use a
single sequentializing thread for all different servers. The downside
of this, however, is that a .NET thread that wants to output a string
on the console might need to wait for a different .NET thread that
wants to do file access. Whether this can be accepted depends mainly
on the concrete .NET application. In the current state of our port,
.NET threads are directly mapped to preemptively scheduled threads
on the Symbian operating system layer.
GUI
Symbian allows access to the GUI at several layers. The OS itself
provides a common graphics server that provides the main window,
basic drawing functions, and event handling mechanisms. Direct screen
access is also possible. On top of that there are several phone-specific
graphics libraries, the most common being the AVKON library built
for Series 60 phones.
Four distinct approaches were identified that can be followed when
implementing the GUI:
- Using a portable graphics library to create a System.Windows.Forms-compliant
GUI for Symbian smartphones. The main advantage of this approach
is that by using a portable graphics library the .NET GUI interface
does not rely on the specific user interface platform of a particular
smartphone model. Consequently, the GUI can be easily deployed
on different Symbian phone models such as Series 60 devices and
Ericsson
phones. On the other hand, the look-and-feel is different from
native Symbian applications, which might reduce usability.
-
Mapping .NET user interface calls to AVKON or alternative UI
libraries.
This would be the most convenient solution, but there are significant
differences between the two APIs. Major problems include the
creation of resource files that the Symbian GUI framework relies
on and several
threading issues that prevent multiple threads from accessing
the same control or controls from having a parent-child window
relationship.
-
Providing access for device-specific GUI libraries such as AVKON.
This would place the burden of dealing with a device-specific
library on the .NET developer, but proxy objects and helper functions
could
assist her during the process. A major problem of this approach
is also that a GUI application cannot be deployed on other devices
supporting
the .NET Compact Framework, such as Windows-based smartphones.
-
XML-based GUI abstractions. It is possible to create
an abstraction for interface designers at a higher level [APP99].
In the Views GUI
engine [BH05,Mil05], for example, an XML-based notation simplifies
the implementation of user interfaces in Rotor across different
operating systems.
Considering the above alternatives, the major design decision when
implementing a .NET GUI for Symbian smartphones is whether to base
the user interface upon the controls provided by the underlying operating
system or not. As already mentioned in Sect. 3, we have decided to
remain in full control of the drawing process by using custom controls
that are similar to the ones on Windows-based smartphones. The main
advantage of this approach is that we increase the portability of
GUI applications across different .NET platforms because we can expose
the standard APIs of System.Windows.Forms to application programmers.
An important implication of this is that all the standard programming
tools that are available for .NET application development – as
for example the Form Designer that is integrated into Visual Studio – can
be used for application development on Symbian as well. I.e., an
application developer can graphically arrange the GUI controls she
needs in her program as well as implement the standard delegates
that are assigned to GUI events using the tools integrated into Visual
Studio. Afterwards she can then deploy the resulting application
without any modifications on a Windows- as well as on a Symbian-based
smartphone. As mentioned above, a potential problem with our approach is reduced
usability because of performance issues and because the controls
of .NET applications differ from the ones provided by native smartphone
applications. With respect to performance, Sect. 6 shows that our
implementation provides very good responsiveness. In fact, in our
demo applications there is no apparent difference in performance
to native GUI applications. A problem that remains is that our GUI
controls differ from those of Series 60 and UIQ. On the other hand,
Windows-like controls expose a very good usability, and many phone
owners know how to handle Windows-like controls from their PCs at
home or at work. We therefore think that GUI applications implemented
using System.Windows.Forms provide an easy to handle user interface
for owners of Symbian smartphones.
6 EVALUATION
The purpose of this section is to provide a detailed performance
evaluation of our implementation. The evaluation consists of four
main parts: (1) an overview of the memory requirements of our port,
(2) a performance analysis of basic services such as method calls
in comparison to a Java Virtual Machine, (3) an analysis of the performance
penalties caused by Symbian's programming model, and (4) a performance
analysis of our GUI implementation in comparison to native drawing
primitives.
We have to emphasize that the results shown here assess only the
performance and memory requirements of our port. This port was done
as a means to evaluate the feasibility of porting the .NET CF to
Symbian devices. Hence, the following figures should not be used
as a general comparison between Java and .NET (for example, [Sin03]
provides a technical comparison of the different virtual execution
systems).
Memory Requirements
Sect. 3 reviewed the hardware characteristics of today’s
Symbian smartphones and identified the low amount of available memory
as
one of the main constraints of this device platform. While certain
methods can be used to reduce the amount of RAM required by a virtual
execution system, the amount of non-volatile memory necessary to
host our current implementation is as follows:
First, the size of the non-managed part of the virtual execution
system is 1.6 MB. This includes the JIT compiler, the garbage collector,
and the entire PAL implementation. The 1.6 MB also includes most
of the GUI code. (Note that our figures are only valid for our port;
they do not apply for the commercially available .NET Compact Framework.)
If no GUI is required, the corresponding DLL is of course not needed
on the actual device. It should also be kept
in mind that the performance of the GUI on resource-constrained device
platforms is of central importance, so that most of the GUI functionality
has to be implemented in native code. Consequently, the System.Windows.Forms
managed code library primarily contains mappings to the portable
windowing toolkit and the underlying graphics library. It is also
noteworthy that because of Symbian’s DLL model (no writable
static variables) native code can be designed in such a way that
only a small amount of the 1.6 MB has to be loaded into RAM. In our
current prototype, however, all of the 1.6 MB is loaded into RAM
when a .NET application is executed on a Symbian smartphone.
Second, the size for managed code libraries is the same as on the
standard .NET Compact Framework for Windows, except for the GUI libraries
System.Drawing and System.Windows.Forms. The reason for this is that – except
for the GUI – we could leave all managed code untouched. In
fact, this was one of our main design goals because it ensures that
we expose exactly the same programming model on Symbian devices as
on Windows smartphones. The amount of memory for managed code libraries
depends on the desired functionality. To get a text-based application
up and running together with file and networking functionality requires
882 KB of managed libraries. These libraries are loaded into RAM
in our implementation. The managed GUI libraries take another 90
KB at the moment (remember that most of the GUI functionality is
in native code). The biggest chunk of memory is required by the managed
code XML library, which is 1.16 MB in size. This library is necessary
for Web Services support.
In summary, our current implementation requires 3.7 MB of flash
memory for all the functionality we have discussed in this paper.
Regarding
the size of flash memory on newer smartphone models, this should
not be a problem. Newer phone models also have ever more sophisticated
cameras integrated, and therefore an increasing demand for flash
memory to store pictures and applications. In this context, 3.7 MB
of flash for a virtual execution system including managed libraries
seems reasonable. In the current version of our framework, all necessary
libraries are loaded into RAM, which is a waste of resources. Consequently,
although 3.7 MB is a very small size for an execution engine it still
leaves much room for improvements. This is a work item that we want
to address in the future.
Performance Analysis of Basic Services
In the following, we compare the time necessary to execute .NET
code on our platform with the time needed to execute corresponding
Java
code on Symbian smartphones. As it would be difficult to interpret
the runtime characteristics of complete applications written for
.NET and Java – due to the different algorithms and optimizations
Java and .NET runtimes might use – our approach is instead
based on micro-benchmarking. Micro-benchmarks are simple programs
(usually loops) targeting a single functionality such as memory allocation
or thread synchronization. Because of the simplicity of the underlying
programs, porting the benchmarks to both Java MIDP and .NET is relatively
simple.
In order to carry out the evaluation, we chose a suite of micro-benchmarks
originally written by IBM to measure the performance of simple
Java operations in a standard Java Virtual Machine (JVM) environment
[jMocha].
These benchmarks originally targeted the desktop versions of Java
and thus are using APIs that are not available on a Symbian smartphone.
Therefore, we selected relevant tests from this benchmarking suite
and adapted them so that they could be executed by the JVMs installed
on our Symbian smartphones. As a result, benchmarks for the reflection
interface of Java were omitted as well as tests targeting file
access functions (file access is not supported on the smartphone
JVMs used
in our tests).
The other major change in the benchmarks dealt with timing issues.
Instead of dynamically calculating the number of iterations of
a test, we hard-coded the number of iterations for each benchmark
based
on the duration of a test. This was done because it simplifies
porting of the test framework to C#, and because it ensures that
all tests
are carried out the same amount of times on different devices.
For the above reasons, test results measured with the selected
benchmark
suite on another hardware platform cannot be directly compared
to the results presented in this paper.
Table 2: Time for running benchmarks (in ms). Tab.
2 shows the results of running the tests. The first micro-benchmark
in our evaluation measures memory read latency by accessing the elements
of arrays. The test varies the size of the arrays as well as the
patterns in which elements are read [jMocha]. The second micro-benchmark
measures the efficiency of calling a single method. The test distinguishes
between calling a plain and a synchronized method. The third micro-benchmark
deals with thread creation. This test sequentially creates threads
and waits for them to start. Since the Symbian documentation in many
places warns against the overhead involved when creating threads
we were especially curious how well our implementation behaves compared
to the Java thread implementation. The fourth micro-benchmark measures
the time necessary to create new objects and the overhead caused
by inheritance. In particular, it tests the creation of small objects
derived over two generations. To some degree, this test also illustrates
the performance of the memory subsystem. The fifth micro-benchmark
measures the performance of comparing strings. The last three tests
concentrate on measuring the performance of general array handling
operations (e.g., initialization and copying). Both Java and C# provide
support for a system-level array copy function a programmer should
use for performance reasons. The CopyArray test therefore has two
versions, one using the system-level function, the other using a
naive copy of the array using a loop. While this might result in
a performance penalty for a runtime that interprets code, we do not
expect a big performance hit when code is generated by a JIT compiler.
Similarly, the InitArray and SumArray micro-benchmarks provide two
versions, one using a simple loop, the other using unrolling to limit
the cost of the loop overhead.
The first column of Tab. 2 shows the name of the micro-benchmark.
The second lists the parameters used to run the micro-benchmark.
Columns three and four show the results, in milliseconds, of the
Java micro-benchmarks when executing them on the JVMs that were already
installed on the smartphones used for our experiments. The next three
columns show the results when carrying out the benchmarks in a .NET
Compact Framework runtime. As can be seen in the table, we have used
two different phones (Phone A and Phone B) and a standard PDA in
our experiments. Phone A runs Symbian OS version 6.1, has 3 MB available
memory, and a 104 MHz processor, while Phone B runs Symbian OS version
8.0a, and has 10 MB of available memory and a 220 MHz processor.
The PDA is a T-Mobile MDA II running PocketPC 2003. Although not
directly comparable, the results obtained with the PDA are useful
to find out whether performance differences between Java and .NET
are a problem of our PAL implementation or shared between .NET runtimes
on different platforms.
As a general result, the speed of our port of the .NET Compact
Framework is comparable to the corresponding Java implementation
on Phone B
and sometimes significantly faster on Phone A. A likely reason for
this is that the JVM on Phone A seems to use an interpreter, while
Phone B comes with a JIT. In two occasions, however, our port of
the .NET Compact Framework is much slower than the Java runtime on
the same device. These cases correspond to tests calling synchronized
methods (we are 4.8 times slower on Phone A) and spawning threads
(we are 52 times slower on Phone A).
In case of synchronized methods, the Java implementation of a synchronized
method call takes twice as long as calling a method that is not synchronized.
It is remarkable, however, that this is much faster than the time
needed in our port, where calling locked methods is 157 times slower
than an unsynchronized method call on Phone A. We expected calls
to a synchronized method to be only slightly slower compared to the
unsynchronized version. Furthermore, since there is no real concurrency
involved (as only one thread in this test calls the functions), we
did not expect a major difference. Our first assumption was that
our implementation of the corresponding PAL functions is responsible
for the poor performance. Comparing this to the tests running on
the PDA, however, revealed that the real reason might partially reside
in the implementation of the Compact Framework itself. This is because
even on the PDA locked code runs 39 times slower than a function
not using the lock statement. Spawning a thread is also considerably
slower in our Symbian .NET Compact Framework implementation than
in the Java implementation. These problems have been solved in newer
releases of the .NET Compact Framework.
Performance Impact of Symbian Constraints
In Sect. 5 we discussed the implications of Symbian’s programming
model on the implementation of CLI-compliant virtual execution systems.
One of the core problems in this context was that additional threads
had to be introduced in the PAL in order to sequentialize requests
from different .NET application threads. As the usage of preemptively
scheduled threads in Symbian is strongly discouraged, we evaluated
the impact of additional threads in the PAL (cf. Fig. 5 and Fig.
6). As a result it can be said that the performance penalty caused
by the sequentializing PAL thread depends on the complexity of the
.NET function that has to be mapped to the underlying operating system.
If its complexity is high, the performance penalty is acceptable
because the overhead caused by additional thread switches is small
compared to the time needed to carry out the actual function. For
average operations, however, the performance penalty can be significant.
Fig. 5 shows this for a function that puts the cursor to a specified
location on the console window. If the requests from the execution
engine are passed through the additional thread (upper curve in Fig.
5) this causes a performance penalty of around 20 %.
Figure 5: Performance penalty of sequentializing
PAL threads. As the usage of preemptively scheduled
threads seems to be problematic in Symbian, another experiment was
carried out in which we tried to measure the impact of preemptively
scheduled threads. In the experiment we created up to 31 threads
that repeatedly called a single function, and measured the performance
of carrying out 100’000 function calls. The operating system
distributed these calls equally so that each thread issued approximately
the same amount of calls. In the case of 10 threads, each thread
would invoke the function around 10’000 times. As can be seen
in Fig. 6, the amount of threads does indeed have a significant impact,
which is different from a Windows environment. On the emulator, for
example, which runs in a Windows environment, the curve is flat.
The impact of threading on system performance can be quite different
between operating systems [ZY98]. Fig. 6 does also compare the performance
difference between native and managed threads. As expected, managed
threads (see upper curve in Fig. 6) cause a nearly constant performance
overhead.
Figure 6: Performance difference between managed
and native threads. GUI Performance
A main problem of many GUI implementations that do not rely on
the GUI controls provided by an underlying operating system is bad
performance and insufficient responsiveness. As our GUI model is
based on a portable graphics library and windowing toolkit (and
does not use Symbian controls), this subsection is devoted to analyzing
the performance of our portable .NET GUI for Symbian smartphones.
Generating a portable UI on a smartphone is a two-step process.
First, the controls and other UI elements are drawn to an off-screen
bitmap.
In a second step, the off-screen bitmap must be copied to the smartphone’s
screen. Both of these processes take place in unmanaged code. In
order to evaluate the performance of the drawing process itself,
Fig. 7 compares Symbian’s DrawLine function with the implementation
in our portable graphics library. As can be seen, both implementations
are comparable. The performance penalty of the Symbian DrawLine function
is probably a result of Symbian’s client/server model. The
result of this is that drawing a line would internally require interaction
with a Symbian server that is responsible for drawing. This assumption
is supported by the fact that the performance of more complicated
Symbian drawing functions (rectangles, text, etc.) is usually better
than our implementation. Nevertheless, the .NET GUI implementation
for Symbian smartphones has a very good performance.
Figure 7: Performance of the DrawLine function in
Symbian and in our portable graphics library. Fig.
8 compares different methods for copying the generated off-screen
bitmap to the phone’s display. Not surprisingly, this process
is very time consuming if the off-screen bitmap is copied bit by
bit to the display using Symbian’s plot function (see left
bar in Fig. 8). When considering the internal format in which Symbian
is storing bitmap data – no conversion between different data
formats is then necessary – the transfer to the phone’s
display can be very fast. According to our measurements this takes
about 5 ms. We were also interested in the difference between direct
screen access and drawing to a Symbian window. As can be seen in
Fig. 8, the difference between both approaches is negligible so that
we draw to a Symbian window in our implementation instead of using
direct screen access. This has certain advantages with respect to
event handling.
Figure 8: Copying the off-screen bitmap to the smartphone
display.
7 CONCLUSION
This paper evaluated the feasibility of porting the .NET Compact
Framework to Symbian smartphones. Our analysis shows that the specifics
of the Symbian OS and the resource constraints of today’s
smartphones make porting difficult but not impossible. The gap
between the programming model of .NET and that of Symbian – e.g.
its focus on cooperative multitasking and its local client/server
model – were the main obstacles in our project. Our work
also proves it possible to realize a portable .NET GUI on Symbian
smartphones that conforms to System.Windows.Forms and offers good
responsiveness. Last but not least, we verified that the performance
of carrying out .NET applications on Symbian is comparable to that
of Java applications.
8 ACKNOWLEDGMENTS
We would like to thank Gerd Rausch for helping us with the implementation.
We thank Wolfgang Manousek, Mark Gilbert, and Ivo Salmre for
their helpful comments and their continuous support throughout this
project.
We also would like to thank the Microsoft .NET Compact Framework
team and the anonymous JOT reviewers.
REFERENCES
[AP99] Abrams, M.; Phanouriou, C.; Batongbacal, L.; Williams, S.;
Shuster, J.: “UIML: An Appliance-Independent XML User Interface
Language”, 8th International World Wide Web Conference, Toronto,
Canada, May 1999.
[BH04] Bishop, J.; Horspool, N.: “Developing Principles of
GUI Programming using Views”, 35th SIGCSE Technical Symposium
on Computer Science Education, pp. 373-377, Norfolk, USA, March 2004.
[BKR04] Benton, N.; Kennedy, A.; Russo, C.: “Adventures in
Interoperability: The SML.NET Experience”, 6th International
ACM SIGPLAN Conference on Principles and Practice of Declarative
Programming, pp. 215-226, August 2004.
[BLWG99] Bisbal, J.; Lawless, D.; Wu, B.; Grimson, J.: “Legacy
Information Systems: Issues and Directions”, IEEE Software,
vol. 16, no. 5, pp. 103-111, 1999.
[BRH90] Baruah, S.; Rosier, E.; Howell, R.: “Algorithms and
complexity concerning the preemptive scheduling of periodic, real-time
tasks on one processor”, Journal on Real-Time Systems, vol.
2, no. 4, pp. 301-324, November 1990.
[BW05] Bishop, J.; Worrall, B.: “Towards platform interoperability:
retargeting a GUI library on .NET”, 3rd International Conference
on .NET Technologies, Plzen, Czech Republic, May 2005.
[DotGNU] The DotGNU project, http://www.dotgnu.org.
[Canalys] Analysis for the high-tech industry, http://www.canalys.com.
[CLI]
ECMA and ISO/IEC C# and Common Language Infrastructure Standards,
http://msdn.microsoft.com/netframework/ecma/.
[EB04] Edwards, L.; Barker, R.: Developing Series 60 Applications,
A Guide for Symbian OS C++ Developers, Addison-Wesley, 2004.
[Forge] AppForge, http://www.appforge.com.
[Gut01] Gutknecht, J.: “Active Oberon for .NET: An Exercise
in Object Model Mapping”, First Workshop on Multi-Language
Infrastructure and Interoperability, September 2001.
[GW04] George, M.; Wong, W.: “Windows CE for a Reconfigurable
System-on-a-Chip Processor”, International Conference on Field-Programmable
Technology 2004, pp. 201-208, December 2004.
[Ham03] Hamilton, J.: “Language Integration in the Common Language
Runtime”, ACM SIGPLAN Notices, vol. 38, no. 2, pp. 19-28, February
2003.
[Har03] Harrison, R.: Symbian OS C++ for Mobile Phones, Wiley & Sons,
2003.
[Helix] Wright, G.: “The Symbian porting project on HelixCommunity.org”, https://symbian.helixcommunity.org.
[jMocha] The jMocha Microbenchmark Framework and Suite for Java,
http://www-124.ibm.com/developerworks/oss/jmocha/index.html.
[JSM91] Jeffay, K.; Stanat, D.; Martel, C.: “On non-preemptive
scheduling of periodic and sporadic tasks”, 12th Real-Time
Systems Symposium, pp. 129-139, December 1991.
[MG00] Meijer, E.; Gough, J.: “Technical Overview of the Common
Language Runtime”, Microsoft white paper, 2000.
[Mil05] Miller, D.: “Mirrors: a system for GUIs using reflection
in .NET 2.0”, Technical Report, University of Pretoria, South
Africa, September 2005.
[Mono] The Mono project, http://www.mono-project.com.
[MR] Mobile Review Web site, http://www.mobile-review.com.
[NetCF] The Microsoft .NET Compact Framework, http://msdn.microsoft.com/smartclient/understanding/netcf/.
[Opera] Porting Opera to EPOC, http://www.symbian.com/developer/techlib/papers/khopera/opera%5Fkeithhollis.htm.
[RSL04] Raghavan, G.; Salomaki A.; Lencevicius, R.: “Model
Based Estimation and Verification of Mobile Device Performance”,
Fourth ACM International Conference on Embedded Software (EMSOFT ’04),
Pisa, Italy, pp. 34-43, September 2004.
[RTCE04] Rashid, O.; Thompson, R.; Coulton, P.; Edwards, R.: “A
Comparative Study of Mobile Application Development in Symbian and
J2ME using Example of a Live Football Results Service Operating over
GPRS”, IEEE International Symposium on Consumer Electronics,
Reading, UK, pp. 203-207, September 2004.
[RV01] Riggs, R.; Vandenbrink, M.: Programming for Wireless
Devices with the Java 2 Platform Micro Edition, Addison-Wesley, 2001.
[Sin03] Singer, J.: “JVM versus CLR: a comparative study”,
2nd International Conference on Principles and Practice of Programming
in Java, pp. 167-169, Kilkenny City, Ireland, June 2003.
[SNS03] Stutz, D.; Neward, T.; Shilling, G.: Shared Source
CLI Essentials, O’Reilly, 2003.
[SSM00] Simon, R.; Stapf, E.; Meyer,
B.: “Full Eiffel on the
.NET Framework”, Microsoft Developer Network, July 2002.
[ZY98] Zabatta, F.; Ying, K.: “A Thread Performance Comparison:
Windows NT and Solaris on a Symmetric Multiprocessor”, 2nd
USENIX Windows NT Symposium, Seattle, WA, 1998.
About the authors
Cite this article as follows: Frank Siegemund, Robert Sugar, Alain
Gefflaut, Friedrich van Megen: “Porting the .NET Compact Framework
to Symbian Phones”, in Journal of Object Technology, vol. 5,
no. 3, April 2006, Special issue: .NET Technologies 2005 Conference
2005, pp. 83-106 http://www.jot.fm/issues/issue_2006_04/article4
|
