PLATFORM INVARIANT DATABASE DESIGN FOR … Series 7 SP ARM710T RISC, 32-bit ... Ericsson Mobile Companion MC218 EPOC Release 5 CPU Speed RAM ROM Flash ... and execute commands. The

PLATFORM INVARIANT DATABASE DESIGN FORINFORMATION APPLIANCES

Ulrich Grießer*, Wolfgang Hümmer, Wolfgang Lehner

University of Erlangen-NurembergMartensstr. 3, Erlangen, 91058, Germany

EMail: {uhgriess, huemmer, lehner}@immd6.informatik.uni-erlangen.de

Abstract

The idea of a smaller, lighter and a handier devices compared to huge desktop per-sonal computers or the still big and heavy notebooks came up already in the end of the80’s and the beginning 90’s. Many applications are ported to those platforms. Thispapers describes the experiences in developing a full-fledged database system and port-ing it to Palm, Epoc, and Windows CE platforms. In a first part of this paper, those oper-ating systems are explained from a developing point of view. This discussion willexpose many different properties which should be considered in the development phaseof applications running on all of those devices. As an example of a platform-invariantdevelopment, this paper details the resulting challenges and some solutions in the con-text of a platform invariant design of the IBM DB2 Everyplace 7.1 database system.

* Work was performed while author was visiting scientist at the IBM Silicon Valley Lab, San Jose(CA).

1. Introduction146

1 Introduction

The idea of a smaller, lighter and a handier device compared to the huge desktop personalcomputers or the still big and heavy notebooks came up already in the end of the 80’s and thebeginning 90’s. One of the first products available on the market was Apple’s Newton Mes-sage Pad in 1993, but new inventions in the majority of cases exhibit a lot of difficulties intheir beginning state. Apple’s Newton for example never reached a significant amount of solddevices because the market was not yet ready for this device and the handwriting recognitionsoftware was not good enough.

Only some years later, Palm Computing picked up again the idea of handwriting recognitionsoftware, simplified it and created a fast and accurate way to input data in a natural handwrit-ing way, called Graffiti ([RhMc99]). After the success of the first handheld devices in the be-ginning of the 90’s, the market for these small and handy devices increased dramatically. Ac-cording to a market share analysis of IDC, they expect an average handheld companion ship-ment increase of 44.9% each year during the next four years. Not only will the market shareof handheld devices increase in the next years, also the market of smart phones is expectedto reach around 70% of the handheld companion market ([IDC00]).

The market growth and the more widespread and increasing usage of these devices in a lotof different fields such as health care, sales automation, insurance, and education, will makeit more and more important to access vital company data. Simple reading access is most ofthe time not enough. A sales representative would like to download the current sales pricesonto his information appliance. Then being out in the field he will create a lot of new ordersdirectly on his device — back in his office he can synchronize the created orders with theback–end database management system (DBMS). The complete data transfer has to be con-sistent and secure.

Using a database management system as backend suggests to use a DBMS also on the hand-held device. However simply porting a backend database system to the device does not pro-vide a feasable way because of the application size and the limitations of the devices.

The following sections focus on the design of multi–platform applications for informationappliances and will take care of these limitations. Therefore an overview of most commonlyused operating systems for PDAs will follow an broad overview of different handheld devic-es. The major operating systems will be described in detail, their strengths and weaknessesdiscussed and their differences exposed. Thereafter, the paper addresses the platform invari-ant design of handheld applications using a database system as example. For this reason,IBM’s database management system DB2 Everyplace, its design, the porting problems to theEPOC operating system and the solutions for them are discussed. The paper closes with asummary in the last section.

2 Overview of Handheld Device Operating Systems 147

2 Overview of Handheld Device Operating Systems

After several years of invisibility, handheld devices have now developed a real market share.During the last years a huge variety of new devices and with them new operating systemshave tried to gain a part of this growing market. Not all of them were and will be successful.Good operating systems and devices will not necessarily survive in this hard fight market.Only those with the right technical and marketing strategy will stay and may expand theirposition in the handheld device market and in the new smart phone market. This contributiondoes not deal with the fact whether a device or an operating system has the right strategy tosurvive. Instead this chapter explains the three major operating systems ([IDC00]) in detail:

• Symbian Ltd. – EPOC Release 5

• Palm Inc. – Palm OS Version 3.x

• Microsoft Corp. – Windows CE Version 3.0, ”PocketPC”

The following table 2.1 mentions only a small amount of the myriad of available devices, butnevertheless it gives an overview of the big variety of handheld devices, cellular phones andoperating systems, including newer or minor operating systems, which do not yet have a sig-nificant market share.

This table shows the huge variety of personal digital assistant (PDA) operating systems and- especially for Windows CE - an enormous number of different processor types with differ-ent clock speeds. Even if most of the devices provide a Compact Flash Memory extension,the internal memory is always limited — currently up to 32MB RAM and 24MB Flash ROM.But there are still many devices on the market that have a lot less memory, such as an averagePalm OS device with 4MB RAM and 2MB ROM. Despite memory size, processor and pro-cessor speed differences, the most important distinction is the device type. Personal digitalassistants can be categorized into three major types:

• Palm–size PCs (P/PC):Their small screen size, a memory amount between 2–16 MB and handwriting recog-nition software to enter data with a pen characterize these devices.

• Handheld PCs (H/PC):Compared to Palm–size PCs Handheld PCs have a touch–type able keyboard to entera bigger amount of data, more memory, and a bigger screen. These devices are placedin the market between the Palm–size PCs and traditional notebooks.

• Smart phones (SP):These are mobile phones with extended applications like mail functionality, addressbook and others.

These three different device types do not have a very precise distinction, so any kind of mix-tures between them is possible, for example some so called Communicators are a Handhelddevice with an included mobile phone.

2. Overview of Handheld Device Operating Systems148

Handheld Device versus Desktop Personal Computer

Desktop personal computer and palm–size or handheld devices do not only differ in theirlimited screen size and the processor computing power. There are also some less obvious dif-ferences like the starting and loading time of applications or the instant power on and off,compared to the booting phase of a desktop computer. Desktop PC users do not mind to waitseveral seconds to start an application because they want to use it for an extended amount oftime. In contrast a handheld or palm–size device user is often switching between his appli-cations and is using an application for a shorter period of time. This fact implicates an easy

SP�n.a.1.2 MBn.a.n.a.Ericsson R380

P/PC�16 MB32 MB150 MHzNEC VR4122 MIPS RISC,64-bit

Casio E-125Cassiopeia

P/PC�8 MB16 MB133 MHzIntel StrongARM SA-1100RISC, 32-bit

BossaNova

Neutrino

Demo�4 MB16 MB100 MHzAMD ÉLanSC400, 32-bitForCE

VTech OS

P/PC�2 MB8 MB75 MHzRISC, 32-bitVTech Helio

Zaurus

P/PC�16 MB8 MB100 MHzHitachi SuperH SH-3RISC, 32-bit

Zaurus Icruise(MI-EX1)


Zaurus Igetty(MI-P2)

JBlend

P/PC�12 MB16 MB131 MHzNEC VR4181 MIPS RISC,64-bit

Symbol PPT 2700Series


Hewlett PackardJornada 548

P/PC�16 MB32 MB206 MHzIntel StrongARM SA-1110RISC, 32-bit

Compaq iPAQH3600 Series

Windows CE Version 3.0

SP�n.a.n.a.16 MHzMotorola DragonBallMC68EZ328

QualComm pdQ

P/PC�2 MB8 MB16 MHz

Motorola DragonBallMC68EZ328

TRGpro



PalmVII



IBM WorkPad c3PC Companion


Motorola DragonBallMC68328

Handspring VisorDelux

Palm OS Version 3.x

H/PC�8 MB8 MB36 MHzARM710T RISC, 32-bitPsion revo

H/PC�n.a.32 MB133 MHz

Intel StrongARM SA-1100RISC, 32-bit

Psion Series 7

SP�12 MB16 MB36 MHzARM710T RISC, 32-bit

Ericsson MobileCompanion MC218

EPOC Release 5

FlashROMRAMSpeedCPU

TypeMemory in MBProcessor TypeDevice

µ

Tab. 2.1: Overview of the variety of handheld devices and their operating systems

2 Overview of Handheld Device Operating Systems 149

use and minimized navigate, select, and execute commands. The high frequency of applica-tion usage makes it also necessary that each application takes care of its memory consump-tion even after the application has already been closed, because there is no reboot phase,which could be used to clean up the memory. The application’s memory consumption is al-ways limited during its execution time. To save memory all applications should be optimizedfor minimal memory consumption. In the Palm OS Programmer’s Companion, the authorseven go further and say: ”Because of the limited space and power, optimization is critical.To make your application as fast and efficient as possible, optimize for heap space first, speedsecond, code size third.” ([PPC99])

Desktop computers normally have a mouse and a keyboard to input data. For palm– size de-vices users have a touchable screen and use a pen to enter characters and symbols. Applica-tions for palm–size devices require it to be designed for minimized data input and fast andeasy use. Also the user interface is designed for easy use, efficient in its navigation and in-cludes an unambiguous and straightforward screen design. The screen size is different formost of the devices.

The most interesting part for a database management system is, that, compared to the desktopPC, handheld or palm–size devices have only memory and no external or internal disk drives.That means that all applications are stored and executed in memory. Only the operating sys-tem is persistently stored in a flash ROM. A database system on a PDA does not have to takecare of the persistent storage of its information in memory and on a hard drive. The only ex-ception right now is IBM’s ultra small hard drive called Microdrive, which can fit into aCompact Flash Card or PCMCIA socket ([PPC99]).

Table 2.2 outlines the major differences between desktop PCs and PDAs. These differencesdetermine the graphical user interface and the application design of software for handheld orpalm–size devices.

Technical Comparison of the Major Handheld Operating Systems

Before describing the major handheld operation systems in detail, table 2.3 gives an over-view of handheld devices compared to desktop operation systems like Unix and WindowsNT from a technical perspective.

PC PDA

Data input keyboard + mouse small keyboard or pen

Screen 19” monitor small color or black and white LCD

GUI complex and complete minimized navigation for efficient use

Applications long program start up instant on/off for frequent short time use

Device on/off long reboot instant power on/off

RAM memory more than 64 MB limited to 2-32 MB

Hard drive multiple GB none

Tab. 2.2: Major differences between desktop PCs and PDAs.

3. EPOC Release 5150

When comparing Palm OS or VT–OS with all the other operating systems one may note thatthe characteristics of single event driven applications of the Palm OS is important. Therfore,Palm OS will always play a special role in the platform-invariant application development.JBlend, Neutrino, or Windows CE are interesting because of their design, which is mostlyfocused on portability to different hardware platforms, such as handheld devices, or desktopPCs.

3 EPOC Release 5

The EPOC operating system has been specifically designed for its use on memory limitedand battery powered handheld or palm–size devices. To save battery power EPOC has inte-grated a power management into its operating system, for example if the battery power is lowthe user cannot turn on the back–light of the device.

In general EPOC is a multi–threaded, fully preemptive multitasking, multi– platform oper-ating system. Besides that, EPOC is component based to facilitate design across multipleplatforms and resources, such as different screen sizes, colors and resolutions, keyboard andnon–keyboard, and touch screen and non– touch screen based designs. To accomplish thiscross platform design and other features the EPOC operating system makes use of an objectoriented approach, therefore nearly all components are written from the ground up in C++.But the most important goal what the EPOC operating system wants to achieve is a very highreliability in all operating conditions, because the operating system and major applicationsmay run up for several years without even being closed or reset in any way [Symb99b].

Development

User interface

File system

Kernel

��Multithreading

��Multiapplication

��Event driven

NTFS,FAT

VFS, FFS,EXT2, etc.

?CD-ROM,

QNX, etc.

?FATRecord,database

VFATType

Windows

C/C++,Java, Basic

�

Windows

�

WindowsCE

?

Java

?

AWT, Swing

�

JBlend

WindowsUnixWindowsWindows,Neutrino

Mac, Unix,Windows

WindowsDevelopmentplatforms

C/C++,Java, etc.

C/C++, Java,etc.

CCAssembler,Basic,

C/C++,Java

C/C++,Java

Programminglanguage

��?��GUI builder

WindowsX Windows,etc.

Helio GUIPhotonmicroGUI

EIKONName

��Multitasking

WindowsNT

UnixVT-OSNeutrinoPalm OSEPOCOperatingsystem

Development

User interface

File system

Kernel

��Multithreading

��Multiapplication

��Event driven

?FAT, NFS,

?FATRecord,database

VFATType

Windows

C/C++,Java, Basic

�

Windows

�

WindowsCE

?

Java

?

AWT, Swing

�

JBlend

WindowsUnixWindowsWindows,Neutrino

Mac, Unix,Windows

WindowsDevelopmentplatforms

C/C++,Java, etc.etc.

CCAssembler,Basic,

C/C++,Java

C/C++,Java

Programminglanguage

��?��GUI builder

WindowsX Windows,etc.

Helio GUIPhotonmicroGUI

EIKONName

��Multitasking

WindowsNT

UnixVT-OSNeutrinoPalm OSEPOCOperatingsystem

Tab. 2.3: Comparison of the major Handheld Operating Systems, Unix, and Windows NT

3 EPOC Release 5 151

The major six parts of the EPOC operating systems, vi-sualized in figure 3.1, are ([Symb99c], [TAD+00]):

• The base, which includes the kernel, file system,device drivers, and the user library.

• The engine support, which provides fundamentalAPIs for data management, text, clipboard, graph-ics, sound, alarms, locale specific information etc.

• The graphics module, which provides togetherwith the GUI an input/output interface for the user.

• The graphical user interface (GUI), which formsthe basis for all EPOC Release 5 application GUIs.

• The communications module which provide anykind of communication to the outside, like TCP/IP, Serial Ports, and dial–up

• The PC connect module, which provides the connection to the desktop PC to synchro-nize and backup the data of the device.

The Base

Taking a closer view at the base of the EPOC operating system shows that it can be againsplit up into four smaller parts. The base consists of the E32 kernel, E32 user library, devicedrivers, and a file server; all of these parts are shown in the diagram of figure 3.2.

The EPOC core is a 32–bit portable, multi–threaded, fully preemptive multitasking, multi—platform micro kernel. That means that only a minimum portion of the whole system runswith kernel privilege, while many system components actually run as servers on user sidewith user privilege. One of the kernel side responsibilities is thread marshaling based uponpriorities and interrupts; consequently any thread may be preempted at any time.

Every application in EPOC runs in its own process with visibility only for its own memoryspace. Each process has one or more conceptually concurrent threads of execution. Everytime a process is initialized EPOC creates a primary thread, which is for many applicationsthe only thread. However, processes can create additional threads.

DevelopmentSupport

DevelopmentDevelopmentSupportSupport GUIGUIGUI

PCConnect

PCPCConnectConnect GraphicsGraphicsGraphics

Communi -cations

CommuniCommuni --cationscations

EngineSupport

EngineEngineSupportSupport

BaseBaseBase

DevelopmentSupport

DevelopmentDevelopmentSupportSupport GUIGUIGUI

PCConnect

PCPCConnectConnect GraphicsGraphicsGraphics

Communi -cations

CommuniCommuni --cationscations

EngineSupport

EngineEngineSupportSupport

BaseBaseBase

Figure 3.1: Structure of theEPOC Operating System

E32User Library

E32E32User LibraryUser Library

FileServer

FileFileServerServer

E32Kernel

E32E32KernelKernel

DeviceDrivers

DeviceDeviceDriversDrivers

E32User Library

E32E32LibraryLibrary

FileServer

FileFileServerServer

E32Kernel

E32E32KernelKernel

DeviceDrivers

DeviceDeviceDriversDrivers

UserUser

Figure 3.2: Constitution of the EPOC Base


Threads are executed individually and are unaware of other threads in a process. The sched-uling of threads is preemptive. Each thread is assigned a priority; at any time, the runningthread is the highest priority thread that is ready to run. Threads with equal priority are time–sliced on a round–robin basis. There is also a special process, the kernel server process,whose threads run at supervisor privilege level. This process normally contains two threads([Symb99a]):

• The kernel server thread, which is the initial thread whose execution begins at the resetvector, and which is used to implement all kernel functions requiring allocation or deal-location on the kernel heap. This is the highest priority thread in the system.

• The null thread, which runs only when no other threads are ready to run. The nullthread places the processor onto idle mode to save power and set an inactivity timer,which will turn off the entire machine if no user activity initiated within a given inter-val.

Kernel resources (shown in figure 3.3), such as the kernel heap, may be used by the kernelexecutive, operating in the context of any thread, or by other kernel–side threads. The kernelexecutive and the user library can be thought of largely as collection of functions.

A user thread may use services provided by the kernel, by I/O devices, or from other threads,which function as servers. User threads request kernel services by using the user library API.The services, such as extending the heap, timers, semaphores, creating processes and threads,in fact anything fundamental to the operation of the machine, are carried out by the kernelserver thread. User threads can request services from I/O devices, like keyboard, digitizer,screen, sound, RS232, infrared and others, by using an API provided by a user–side devicedriver library. The kernel-side device driver handles the device request itself.

As already mentioned above EPOC has specialized memory management to take care of thecircumstances on handheld devices. EPOC supports a conventional two– level memory man-agement unit, but unlike other operating systems EPOC uses only a single page directory,with each process represented by as many page directory entries as are needed to hold the

KernelKernelHeapHeap

ExecutiveExecutiveDeviceDeviceDriverDriver

LibraryLibrary

Pro

cess

Pro

cess

KernelKernel

UserUser

Pro

cess

Pro

cess

Use

rU

ser

Pro

cess

Pro

cess

Use

rU

ser

Pro

cess

Pro

cess

Use

rU

ser

Pro

cess

Pro

cess

Use

rU

ser

Ker

nel

Ker

nel

Ser

ver

Ser

ver

Figure 3.3: EPOC Kernel Structure

3 EPOC Release 5 153

relevant page tables. This approach saves RAM and is possible because there is no require-ment to support very large virtual address spaces. Memory in EPOC is allocated in consec-utive chunks in the virtual address space. A thread typically uses a single chunk which mayexpand because it includes a stack at the bottom a heap on top ([Task99]). The most impor-tant point in the memory management of EPOC is that every application is planned to run forseveral years without closing it or resetting the machine. Therefore it is essential that allmemory leaks are eliminated, because every even very small memory leak will accumulateover the time.†

The File Server

The EPOC file server provides file systems for ROM, RAM and removable media, and aninterface to allow dynamically installable file systems, such as those required communicat-ing with remote disks over a network. The drive, directory and file hierarchy is VFAT, thusmaking the file system naturally compatible with desktop PCs running Windows, OS/2 orDOS.

The file server implements a program loader, which supports both executables and dynamiclink libraries (DLL), which are executed in–place from ROM, or loaded as needed fromRAM or from removable media. A distinctive aspect of the EPOC file system is the use of32–bit unique identifiers (UIDs), which allow the type of every executable to be identified.This serves as a form of identification, used among other things for associating an applicationfile with its owning application. It also protects against accidental loading of a DLL whichis not the version or type required. UIDs are normally checked by the EPOC native loader,but in the EPOC emulation mode on Windows, program loading is handled by the runningWindows platform, so UIDs will not be checked ([Task99]).

The Graphical User Interface

The EPOC graphical user interface consists of the following four parts([Symb99b]), whichare also shown in figure 3.4:

• The so called EIKON provides the particular look–and–feel to the user interface.

• The CONtrol Environment (CONE), which provides a better interface to the windowserver.

• The window server controls access of applications to the machine’s interaction devices,like screen, keyboard and pen.

• The Graphics Device Interface (GDI) specifies the EPOC support for graphics.

† This would be too nice to be true, but in reality there are always memory leaks. The EPOC develop-ment environment has some features in the debugging mode of the emulator to check for memoryleaks. The EPOC emulator will exit with a warning, if the developer is trying to close an applicationthat has memory leaks.


To implement a user interface, the application code in an EIKON application will typicallynot just use the EIKON API but also the CONE and GDI API as shown in the figure 3.4.

Because EIKON has been designed for devices with small screens and a pen instead a mouse,there are some notable differences between EIKON and desktop GUIs. Instead of using dou-ble clicking, which is very difficult with a pen, items are activated by selection and thenclicking. The menu bar is not displayed until the user activates it, to make the most out of thelimited screen space. The dialog–programming framework forces the developer to create asimple dialog layout suitable for small screens. Applications normally occupy the wholescreen.

The CONtrol Environment (CONE) is used to provide a simplified access to the windowserver, to set a recommended framework for all user interface libraries without imposing aparticular user interface policy. The window server is responsible for the control of the ma-chine’s interaction devices. The window server is a process, which is started up when the sys-tem is booted, and remains running all the time. Because the window server process is sharedbetween all running applications, applications are therefore clients of the window server.

The Graphics Device Interface (GDI) specifies the support for graphics. Its main target is toprovide a rich set of drawing primitives, which include points, lines, rectangles, ellipses,arcs, polylines, device–independent bitmaps, and text.

Programming Tools and Languages

For EPOC Release 5 Symbian provides three different software development kits for variouslanguages. EPOC right now supports C/C++, JAVA, and OPL (Organizer Programming Lan-guage)‡, which is a proprietary basic dialect. The C/C++ development process is based onMicrosoft Visual C++. First the developer writes the application in MS Visual C++, uses its

‡ Some EPOC devices (e.g. Psion 5) already include an OPL programming environment directly onthe device.

CONECONECONE

GDIGDIGDI

Window ServerWindow ServerWindow Server

BaseBaseBase

Application CodeApplication Code

CONECONECONE

GDIGDIGDI

Window ServerServerServer

EIKONEIKON

BaseBaseBase

CodeCodeApplicationApplication

WindowWindow

Figure 3.4: Setup of the EPOC Graphical User Interface

4 Palm OS Version 3.x 155

debugger to remove all the errors out of the code while running it in the EPOC emulator. Af-ter this step the code has to be recompiled for the target machine, which is right now an ARMprocessor device. Then the code can be downloaded to the device and executed.

Symbian’s Java software development kit is based on JDK 1.1.4. It also provides AWT asgraphical user interface and JNI to write native methods. The Java SDK is normally just usedto test the Java programs first in the emulator mode before downloading it onto the device,or for writing an interface between Java and the native C++ code of the EPOC operating sys-tem. Developing in OPL means most of the time writing the code in either any available ed-itor or directly in the EPOC emulator. After compiling the code it can be directly executedon the device or in the emulator. The functionality of OPL in comparison to C/C++ is veryrestricted, but easy to learn.

4 Palm OS Version 3.x

Unlike the other handheld operating systems the hardware for the Palm Operating System(Palm OS) has been designed after the software. The reason for that was Graffiti, a third–party handwriting recognition software, formerly developed for Apple’s Newton and otherPDAs. Palm Computing improved the Graffiti software in a way that it became easy to use,accurate, and fast with only a little bit of learning the different strokes ([RhMc99]). The penused to write the Graffiti strokes or used to type on a little virtual keyboard is still the onlyinput mechanism for Palm devices.**

The Palm operating system runs on top of a preemptive multitasking, event driven, andmulti–threaded micro kernel. One task runs the user interface; others handle things like mon-itoring input. Unlike other handheld operating systems, Palm OS allows only one applicationbeing open at a time, because applications run in the single user interface thread and thereforecannot be multi–threaded. The fact that the device had been designed for the software and its

** External keyboards already exist, but are not part of the Palm product.

4. Palm OS Version 3.x156

operating system causes a very tight relationship. It is going so far that the device is under-stood as an ”extension of the desktop” ([RhMc99]). This understanding is important for Palmusers and software developers.

The following sections will give a more detailed overview about the Palm operating system,looking into the Kernel with its thread and memory handling, the file system, the optimizedgraphical user interface, and Palm OS development in general (figure 4.1).

Kernel

As already mentioned above, the Palm OS is a preemptive multitasking, multi– threaded,event driven operating system. The Palm OS kernel internals are not documented contrary toother handheld operating systems. As known so far, the Palm operating system supports be-tween 4 and 6 threads, dependent on the operating system version, which are all but one usedfor system internal functions. The one free thread is used by any user application, thereforeonly one application runs at a time. Compared to the internals of the micro kernel the memorymanagement is precisely documented.

The memory in Palm OS is handled in an unusual fashion. Like every other operating systemPalm OS uses both ROM and RAM. The flash ROM contains the operating system itself thatcan be updated with a newer Palm OS ROM image. But the interesting part of the memorymanagement is the RAM, which is used for dynamic memory allocation and persistent stor-age. The dynamic memory is used by any applications or the system while it is running. Be-sides the operating system globals it includes, the dynamic allocation of OS and applications,the application globals, and the application stack ([RhMc99]). The permanent storage in-cludes all uploaded applications as well as any data the user creates, views, or edits such asnames and phone numbers, to–dos, memos, and data that is created by any other application.Memory for both types in Palm OS is allocated in chunks, which are collected for permanentstorage in so called databases.

MicrokernelMicrokernelMicrokernel

HardwareHardwareHardware

UserInterface

FormsControlsFonts

DialogsMenus

Drawing

UserUserInterfaceInterface

FormsFormsControlsControlsFontsFonts

DialogsDialogsMenusMenus

DrawingDrawing

ApplicationsApplicationsApplications

Memory

DatabasesRuntime SpaceSystem Space

Globals

MemoryMemory

DatabasesDatabasesRuntime SpaceRuntime SpaceSystem SpaceSystem Space

GlobalsGlobals

SystemManagement

EventsStrings

Intl. TextTimeAlarmSounds

SystemSystemManagementManagement

EventsEventsStringsStrings

Intl. TextIntl. TextTimeTimeAlarmAlarmSoundsSounds

Comms

ExchangeSerial

TCP/IPIrDA

CommsComms

ExchangeExchangeSerialSerial

TCP/IPTCP/IPIrDAIrDA

MicrokernelMicrokernelMicrokernel


UserInterface

FormsControlsFonts

DialogsMenus

Drawing

UserUserInterfaceInterface

FormsFormsControlsControlsFontsFonts

DialogsDialogsMenusMenus

DrawingDrawing

ApplicationsApplicationsApplications

Memory

DatabasesRuntime SpaceSystem Space

Globals

MemoryMemory

DatabasesDatabasesSpaceSpace

SpaceSpaceGlobalsGlobals

SystemManagement

EventsStrings

Intl. TextTimeAlarmSounds

SystemSystemManagementManagement

EventsEventsStringsStrings

Intl. TextIntl. TextTimeTimeAlarmAlarmSoundsSounds

Comms

ExchangeSerial

TCP/IPIrDA

CommsComms

ExchangeExchangeSerialSerial

TCP/IPTCP/IPIrDAIrDA A

dditio

ns

Additio

ns

SystemSystemRuntimeRuntime

Lic

ense

eLic

ense

e

Figure 4.1: Architecture of the Palm Operating System

5 Windows CE Version 3.0 and ”PocketPC” 157

Unlike traditional desktop operating systems, data and code are not copied from persistentstorage, like a hard drive, to dynamic memory but are used in place. The system will executeany application in place, because the persistent storage itself is RAM and therefore can beread like dynamical memory. This memory execution concept makes it possible to have anoperating system and applications running in a memory limited environment ([RhMc99]).

File System

Palm OS does not use a traditional file system, because of its limited memory storage and anefficient synchronization with a desktop computer. Instead data is stored in memory chunkscalled records, which are grouped into databases that are similar to files. Because of this de-sign, files are not stored as a continuous piece, but are broken down into multiple records. Tosave space any database is edited in place instead of copying from the persistent storage intothe RAM ([PPC99]).

Graphical User Interface

Since Palm OS is an event driven operating system the whole graphical user interface isbased on this principle. The GUI consists of different forms, but only one at a time has thefocus and is active. Only this form will react on any events like pen down, pen up, systemkey down, and system key up. But not only the form is reacting to events, also all the objectsinside the form like buttons, list boxes, tables, fields, etc. respond to events.

Programming Tools and Languages:

The software development for Palm OS is right now based on C/C++ with a lot of differentdevelopment environments, such as Metrowerks CodeWarrior or simply the GnuCC envi-ronment. Compared to all other handheld platforms, Palm OS has the most and best graphicaluser interface editors, like Satellite Forms from Puma Inc. or IBM’s Personal ApplicationBuilder ([RhMc99]).

Besides C/C++ the developer may also develop in Assembler or CASL a proprietary basiclanguage. Some months ago Sun provided Java 2 Platform, Micro Edition with a K VirtualMachine (KVM) for the Palm operating system. The Palm OS platform is so far the only plat-form for which development on the Macintosh or Unix environment is possible.

5 Windows CE Version 3.0 and ”PocketPC”

Microsoft Windows CE was designed as a multithreaded, fully preemptive, multitasking,multi–platform operating system for devices with limited resources. Compared to older ver-sion of Windows CE, it now includes certain realtime operation system features, such as sup-port for nested interrupts, better thread response, additional task priorities, and semaphores.

5. Windows CE Version 3.0 and ”PocketPC”158

The design still has been kept modular to allow it to be customized for products ranging fromconsumer electronic devices to specialized industrial controllers. The Windows CE operatingsystem consists of four primary groups of modules (Figure 5.1).

• The kernel supports basic services, such as process, thread handling, and memory.

• Persistent storage of information is provided by the file system.

• The Graphics, Windowing, and Event Subsystem (GWES) controls graphics and win-dow related features.

• The communications interface which supports the exchange of information with otherdevices.

Besides these four main modules, Windows CE also contains a number of additional mod-ules that support tasks as COM/OLE, communication modules, PCMCIA support, RSA en-cryption, multimedia support, or managing installable device drivers. The following illustra-tion (figure 5.1) explains how these features fit into the overall structure of the Windows CEoperating system.

The Kernel

The Windows CE kernel contains the core operating system functionality that must bepresent on all Windows CE–based platforms. It includes support for process management,exception handling, multitasking, multithreading, and memory management.

The Windows CE kernel uses dynamic link libraries, which are written as reentrant code toallow applications to simultaneously share common routines, to maximize the availablememory. With this approach the amount of code required to execute applications, whichstays in the memory for a long time can be minimized.


Build -in DriversBuildBuild --in Driversin Drivers

Windows CE ApplicationsWindows CE ApplicationsWindows CE Applications

Development ToolsDevelopment ToolsDevelopment Tools

Installable DriversInstallable DriversInstallable Drivers

ShellShellShell

Persistent StoragePersistent StoragePersistent Storage

GWESGWESGWES

CommunicationsCommunicationsCommunications

KernelKernelKernel


Build -in DriversBuildBuild --in Driversin Drivers

Windows CE ApplicationsWindows CE ApplicationsWindows CE Applications

Development ToolsDevelopment ToolsDevelopment Tools


ShellShellShell


GWESGWESGWES


KernelKernelKernel


ShellShellShell


GWESGWESGWES


KernelKernelKernel


GWESGWESGWES


KernelKernelKernel

Figure 5.1: Architecture of the Windows CE Operating System

5 Windows CE Version 3.0 and ”PocketPC” 159

As a multitasking operating system, Windows CE supports up to 32 simultaneous processesand each of them is a single instance of an application. Additional multithreading support al-lows each process to create multiple threads of execution. A thread is part of a process thatruns concurrently with other parts. Threads operate independently, but each one belongs to aparticular process and shares the same memory space. The total number of threads is limitedonly by available physical memory. Although threads can operate independently, they aremanaged by the thread owning the process. One thread, for example, may depend on anotherfor information or runs concurrently to others. Thread synchronization suspends a thread’sexecution until the thread receives the notification to proceed. Windows CE provides severalsynchronization objects that enable you to synchronize a thread’s actions with those of an-other thread. These objects include: critical sections, mutexes, events and semaphores. Ad-ditionally, you can use interlocked functions or wait functions to synchronize a thread.

Windows CE implements thread synchronization with minimum processor resources, whichis an important feature for battery–powered devices. Compared to other operating systems,Windows CE uses the kernel to handle thread–related tasks, such as scheduling, synchroni-zation, and resource management, so that an application need not poll for process or threadcompletion or perform other thread–management functions. As a preemptive operating sys-tem Windows CE allows the execution of a process or thread to be preempted by any otherwith higher priority. For thread scheduling it uses a priority–based, time–slice algorithm,with 256 levels of thread priority.

The Windows CE kernel supports a single, flat, or unsegmented, virtual address space in thesize of 4 GB that all processes share. Instead of assigning each process a different addressspace, Windows CE protects process memory by altering page protections. Approximately 1GB of the total virtual memory, divided into 33 memory slots, each 32 MB in size, is reservedfor process execution. The kernel protects each process by assigning it to a uniquely reservedmemory slot, which causes the limitation to 32 processes.

Because handheld or palm–size devices usually have no disk drive, physical memory, a com-bination of ROM and RAM, plays a substantially different role on one of these platformsthan it does on a desktop computer. The unmodifiable ROM is used for permanent storageand includes the Windows CE operating system and any built–in applications that the man-ufacturer provides.

The Windows CE system maintains RAM continuously to compensate the lack of a diskdrive, the application to use RAM for persistent storage as well as application execution. Toserve these two purposes, RAM is divided into storage, also known as the object store, andprogram memory. Program memory is used for application execution, while the object storeis used for persistent storage of data and any executable code not stored in ROM. To mini-mize RAM requirements on Windows CE–based devices, executable code stored in ROMusually executes in–place, not in RAM. Because of this, the operating system only needs asmall amount of RAM for such purposes like stack and heap storage.

5. Windows CE Version 3.0 and ”PocketPC”160

Third party applications are commonly stored and executed in RAM. These RAM– based ap-plications are stored in compressed form, so they must be uncompressed and loaded into pro-gram memory for execution. To increase the performance of application software and reduceRAM use, Windows CE supports on–demand paging. With that, the operating system needsto uncompress and load only the memory page containing the portion of the application thatis currently executing. When execution is finished, the page can be swapped out, and the nextpage can be loaded.

The Persistent Storage

The persistent storage memory portion of RAM is called object store, which includes the filesystem for storage of application and data files, the database providing structured storage asan alternative to keep application data files in the registry, and the Windows CE system reg-istry used to store the system configuration and any other information that an applicationmust access.

The Windows CE file system holds executable files and data files that the user installs or cre-ates. It supports up to nine FAT volumes, which are treated as a storage card. If a storage cardhas multiple partitions, then each partition is treated as a separate volume. Files in the FATfile system are typically stored in compressed form, which are accessible with standardWin32 file system functions. To reduce the data loss during a critical failure, such as loss ofpower, the Windows CE file system is transactional. In addition, the file system implementsa transactional mirroring scheme to track FAT file system operations that are not transaction-al. The mirroring scheme restores the FAT volume if power is lost while a critical operationis performed.

The Windows CE database provides general–purpose, structured storage of data, but it is nota full–fledged database. In particular, Windows CE databases have only one level of hierar-chy. Records cannot contain other records, nor can they be shared between databases.

The Graphics, Windowing, and Event Subsystem

The Graphics Windowing and Events Subsystem (GWES) is the graphical user interface ofthe Windows CE operating system. User input is handled by translating keystrokes, stylusmovements, and control selections into messages that convey information to applicationsand the operating system. The output to the user is either created in windows, graphics, ortext that are displayed on display devices and printers.

GWES is supporting all the windows, dialog boxes, controls, menus, and resources that makeup the Windows CE user interface. This interface allows users to control applications bychoosing menu commands, pushing buttons, checking and un-checking boxes, and manipu-lating a variety of other controls. The user is also provided with information by the GWESin the form of bitmaps, carets, cursors, text, and icons.

Even Windows CE–based platforms that lack a graphical user interface use GWES’ basicwindowing and messaging capabilities. These provide the means for communication be-tween the user, the application, and the operating system. As part of GWES, Windows CE

6 Other Handheld Operating Systems 161

provides support for active power management to extend the limited lifetime of battery–op-erated devices. The operating system automatically determines a power consumption levelto match the state of operation of the device.

Programming Tools and Languages

Windows CE ”PocketPC” applications can be written in Basic or C++/C using the MicrosofteMbedded Visual Tools 3.0 ([MCE00]), which are used to develop, compile, and debug theapplications.A Java Virtual Machine from Microsoft does not yet exist. Right now only other companiesprovide a Java Virtual Machine (JVM) for Windows CE. Sun for example provides a Person-alJava Application Environment, NSIcom has its CrEme, an augmented Java Virtual Ma-chine (cf. Appendix ’Internet Links’).

6 Other Handheld Operating Systems

This section provides a brief overview of some other operating systems, which are not yetpopular in Europe or the US, but have for example a significant market share in Japan. How-ever, this does not imply that these operating systems are less interesting. References to In-ternet pages can be found in the Appendix ’Internet Links’.

JBlend

JBlend, developed by the Aplix Corporations, is an operating system that adheres from theJTRON architecture specification. JTRON, announced by the TRON Project, is a real–timeoperating system architecture based on ITRON, a high performance real–time operating sys-tem specification, and the Java runtime environment ([JBLEND]). JBlend has been imple-mented on several systems such as car navigation system, panel computers, and PersonalDigital Assistance (PDA) devices.

CPUCPUCPU

PALPALPAL

Processor dependent portion(thread, monitor, interruption)

Processor dependent portionProcessor dependent portion(thread, monitor, interruption)(thread, monitor, interruption)

Task manipulation, system calls,Semaphore manipulation

Task manipulation, system calls,Task manipulation, system calls,Semaphore manipulationSemaphore manipulation

JavaOSJavaOS

ITRONITRONspecificationspecificationkernelkernel

CPUCPUCPU

PALPALPAL

Processor dependent portion(thread, monitor, interruption)

Processor dependent portionProcessor dependent portion(thread, monitor, interruption)(thread, monitor, interruption)

Task manipulation, system calls,Semaphore manipulation

Task manipulation, system calls,Task manipulation, system calls,Semaphore manipulationSemaphore manipulation

JavaOSJavaOS

ITRONITRONspecificationspecificationkernelkernel

Figure 6.1: Architecture of the JBlend Operating System

6. Other Handheld Operating Systems162

To merge Java and ITRON Aplix decided to allow both to coexist in JBlend, to minimize theloss of performance. To harmonize the interaction between both parts an intermediary layercalled Processor Abstraction Layer (PAL) has been introduced, as shown in figure 6.1.

Neutrino

QNX Neutrino 2.0 is a scalable — from a tiny, resource–constrained system up to high–enddistributed computing environments —, event–driven, real–time operating system built fol-lowing the POSIX application programming interface. The main part of Neutrino is a truemicro kernel design that provides multitasking, threads, priority–driven preemptive schedul-ing, and fast context switching. The micro kernel can be extended by a pool of dynamicallyplugged in and out operating system modules, such as process manager, different file man-agers for DOS, QNX, CD–ROM, NFS, etc. file systems, TCP/IP manager, character manag-er, network manager, and Photon GUI manager [QNX99], [QNX01].

VTech OS

VTech’s VT–OS Version 1.1 is an open source operating system, which has mainly been de-signed for the Helio PDA. The operating system consists of three layers, the device driver,kernel and user interface. The device driver supports pen, display, sound, I/O keys, serialport, interrupt, and hardware module functions. The Kernel includes a memory, database,and power management and besides a queue, a scheduler, and a timer. The user interface hasfunctions for strings, alarms, resources, a clipboard, and a display.

VT–OS contains a simple single process kernel that provides basic process management.Any application is generally a single–threaded and event–driven program. The communica-tion between the three layers is through a message– and event queue ([VT99]).

Zaurus

Zaurus, developed by Sharp, is a very popular operating system in Japan. It is very hard tofind any information about the structure of this operating system, because unfortunately mostinformation is only available in Japanese (cf. Appendix ’Internet Links’). Nevertheless thisoperating system should be mentioned here.

Summary

There is no ultimate operating system that can fit every demand, like hardware platform flex-ibility, easy customer usage, customer acceptance, big variety of development tools and plat-forms, and clear and flexible programming APIs. Every operating system has a different wayto achieve most of these targets, but the future will show which operating system will suc-ceed.

7 Platform Invariant Design of Applications 163

7 Platform Invariant Design of Applications

Platform invariant design is an old and for a long time known problem, but nowadays it isgetting a new orientation and dynamic. Reasons for this developmnent are the myrades ofhandheld devices with their diversity of operating systems, which differ more than any twodesktop PC operating systems. The high diversity and the different and new constraints askfor new solutions for an application design. This section describes how to successfully de-velop multi–platform applications for PDAs using the IBM satellite database system DB2Everyplace as an example.

DB2 Everyplace is a relational database management system developed by IBM for hand-held devices running Palm OS, Windows CE, EPOC, embedded Linux, or QNX Neutrino.The database system is less then 150 kBytes and allows a synchronization of relational datafrom other data sources such as DB2 Universal Database for UNIX, OS/2 and Windows NT,DB2 for OS/390, and DB2 for AS/400. DB2 Everyplace Version 7.1 supports a subset of theSQL 99 standard:

• CREATE TABLEwith up to eight columns in a primary key, referential and check con-straints. Only the data types INTEGER, INT, SMALLINT, DECIMAL, CHAR, CHAR-ACTER, VARCHAR, BLOB, DATE, and TIME are supported.

• CREATE INDEX with up to eight columns for the index key.

• DELETE one or more rows from a table.

• DROP tables or indexes.

• INSERT a single row into a table.

• SELECT statement supporting DISTINCT, GROUP BY, ORDER BY, and LIMIT.(no support of nested statements)

• UPDATE the values of specified columns in rows of a table.

DB2 Everyplace also supports a subset of three interfaces: DB2 Call Level Interface, OpenDatabase Connectivity (ODBC), and Java Database Connectivity (JDBC).

The following subsections discuss the design of the first version of IBM’s database manage-ment system for handheld devices named DB2 Everywhere. This discussion is followed bya presentation of problems of porting this first database management system to the EPOCplatform. Problems encountered there led to the design turnaround and reimplementation ofthe new DBMS. With these major changes and the marketing requirement of an registeredtrademark comes a new, in functionality only slightly changed database system, named DB2Everyplace Version 7.1. Therefore, the two different product names are used explicitly to dis-tinguish both versions.

7. Platform Invariant Design of Applications164

7.1 General Design of a DBMS for Handheld Devices

Due to the limited size of resources on these handheld devices a general textbook six layersapproach is dammed to fail, because of the big overhead created by the different design lay-ers. The best will be to reduce as many layers as possible to make the database managementsystem very compact. Fitting the special requirements of handheld devices asks for a reducedarchitecture ([HäRa99]) as shown in figure7.1.

The data management layer deals with the translation and optimization of requests. Themanagement of physical records and access paths is done in the access management tier.Buffer and memory management is supported by the memory management layer. The trans-actions layer is ensuring consistent data. The meta-data management stores and handles allinternal information about system tables, indexes, user tables, columns and records. Usingthis reduced design makes it possible to fit a full database management system within onlyfew kilobytes.

7.2 Design of DB2 Everywhere Version 1.x

DB2 Everywhere is designed as a small footprint [Footnote: Small footprint means minimalmemory consumption for storage and during runtime.] relational database, which should of-fer the users the functionality they know from DB2 or any other database management sys-tem on the back–end server or on their desktop PC. Aiming at a small library code size (ca.100 kB), nobody is able to provide the whole functionality of a mainframe or desktop data-base system. To achieve the small footprint, DB2 Everywhere has been designed with a lim-ited functionality, which is reduced to a core of necessary supported functions (cf. [DB2e99],Appendix A and B). The Call Level Interface (CLI) or the Open DataBase Connectivity(ODBC) are supported interfaces for DB2 Everywhere. In the next version a JDBC interfacefor certain platforms will also be available.

Data managementData management

Access managementAccess managementMetaMeta--datadata

Memory managementMemory management

Trans-Trans-actionsactions

Figure 7.1: The Architecture of a DBMS for handheld devices

7.2 Design of DB2 Everywhere Version 1.x 165

The limitation of the CLI/ODBC interfacefunctionality and the implementation of only asubset of SQL make it possible to perform asmall footprint database system. The follow-ing picture shows the internal design of DB2Everywhere version 1.x with its six mainparts: CLI/ODBC, Runtime, Compiler, Cata-log, Data Management Services, and Operat-ing System Services.

The CLI/ODBC interface is the topmost layerof any database management system and pro-vides the users a standardized interface withthe whole functionality to the database sys-tem.

After passing the CLI layer any command,which has not already been executed, willreach the Runtime part, which consists of therelational data service and the interpreter. Therelational data services (RDS) works as a dispatcher for all database commands. In this mod-ule it will be decided whether the compiler needs to be called or the command can be passeddirectly to the interpreter. The interpreter will execute the SQL commands and will interpretany aggregated functions and predicates.

The Compiler, like in any other database system, consists of a parser, a semantic analyzer andan optimizer. It will be called if it is necessary to parse, check and optimize an SQL state-ment. The parser is responsible splitting up any entered SQL statement in its tokens andcheck whether the SQL statement is grammatically correct. After the syntax check the se-mantic analyzer will test the query for it’s semantical correctness by checking for examplewhether the table– and column names are correct. If the statement has passed these two stepsand it has been granted as a correct statement the optimizer will improve the statement toachieve the best performance for execution.

All information about all databases and tables are saved in the catalog. DB2 Everywheredoes not support different databases, so the catalog will only store meta information abouttables, it’s columns, their data types and indexes.

The Data Management Services (DMS) are responsible for the direct database access on ta-ble, record, or column level. To speed up prototyping in DB2 Everywhere Version 1.x, thislayer has been designed as an interface to the native database functions in each operating sys-tem. The DB2 Everywhere internal data representation has been mapped to the databases ofPalm OS or Windows CE.

CatalogCatalog

Operating System Services (OSS)Operating System Services (OSS)

Palm OSPalm OSOperating SystemOperating System

Windows CEWindows CEOperating SystemOperating System

Data Management Services (DMS)Data Management Services (DMS)

Palm OSPalm OS Windows CEWindows CE


Palm OSPalm OS Windows CEWindows CE

CompilerCompiler RuntimeRuntime

ParserParser

SemanticSemantic

OptimizerOptimizer

RDSRDS

InterpreterInterpreter

CLI / ODBCCLI / ODBC

DB

2Eve

ryw

her

eV

ersion

1.x

OS

Figure 7.2: Architecture ofDB2 Everywhere Version 1.x.


The lowest layer is the Operating System Services (OSS) layer, which takes care of any op-erating system platform dependencies to hide them to any layer on its top. Normal interfacessupported are memory access, character or string manipulation, file system access and otherfunctionalities. In the case of porting DB2 Everywhere to another hard– and software plat-form only the OSS layer should have to be customized and afterwards the engine should runon the new operating system immediately.

The statement from above is only partially correct. Looking inside DB2 Everywhere one willdiscover a lot of platform dependent implementation in any other layer than the DMS or theOSS layer. But why are there so many platform dependent implementations in any other lev-els than the DMS and the operating system services layer?

Platform dependent implementations above the DMS layer are caused by the design of theDMS layer. The decision to use the native database management systems (NDBMS) of PalmOS or Windows CE, helped to speed up the development process but caused a lot of problemsin the implementation of DB2 Everywhere. As you already shown, the Palm OS and the Win-dows CE platform are totally different in their structure. Not only the operating system is dif-ferent but also the implementation of the NDBMS are not compatible. Windows CE is usingits object store to implement the database system; the Palm OS is using ”records” or ”data-bases” for the file system.

Implementing the data management services on base of two so different operating systemsbrings all their differences with it. There are, for example, the problems of big and little en-dian formats for numeric operations, or sorting differences of character strings, etc. On theother hand there are the dissimilar implementations of the NDBMS. For example WindowsCE is storing its records after a sequential insertion into a table in the opposite order thanPalm OS does it. This example is only one problem which is caused by the different designof the NDBMS on both platforms, but there are still other problems like the incompatibleNDBMS interfaces and the constraints you have in both NDBMS, like maximum table size,number of records, size of keys, limitation in size of data types, etc.

These various behaviors of the NDBMSs cause as well a major customization of the Com-piler and the Runtime part of DB2 Everywhere. Porting this version of DB2 Everywhere tothe EPOC platforms will add more specialized implementations in all these parts. Havingmore and more specialized implementations will increase the problems of porting DB2 Ev-erywhere to other platforms. The next platform will again increase the complexity of thecode and then rise more porting problems. The only way out of this vicious circle is to im-plement an own database management service, which is no longer based on the native data-bases of each platform; instead it is only based on the file system. But even that will causeproblems, because the Palm OS does not have a file system like any other operating system.Therefore a Palm OS customized solution would always be needed.

7.3 Porting to EPOC 167

7.3 Porting to EPOC

This section explains the way to port DB2 Everywhere Version 1.x to the EPOC platform. Itwill focus not only on the already mentioned problems, but also about typical and character-istic problems for the EPOC platform.

DB2 Everywhere in Version 1.x has been designed to use the NDBMS of the Palm and theWindows CE operating system. The first focus was to realize the same approach for theEPOC platform. But before starting to port the database system engine to the EPOC platform,it is important to understand the development environment and especially those parts that areused in the engine. The main parts to know about are memory handling, string manipulationand of course EPOC’s native database system.

First it is necessary to discuss one of the major differences between the EPOC platform com-pared to Palm OS and Windows CE. As already mentioned, EPOC is a truly object–orientedoperating system and therefore mostly written in C++. This fact creates conflicts with theDB2 Everywhere engine written in C, because any needed C++ method must have a wrapperto C. That especially means every C++ NDBMS access function requires a C wrapper, whichwill increase the code size without increasing the functionality.

After taking a look at the NDBMS of EPOC it was already obvious that there are some re-strictions, which will limit DB2 Everywhere in its future and present functionality. For ex-ample, the native database only supports a maximum record size of 8200 bytes and thereforethe maximum number of columns is limited by this record size. Each table can only have 32indexes, which are supporting multi column keys, but the key size must not exceed 244 bytes.

Trying to implement the DMS interface we faced a lot of problems, which where very hardto solve. We produced a lot of system crashes, which we were not able to understand. TheEPOC documentation was not helpful in these cases at all. But overall the biggest strugglewe fought was against the interface and the way of calling the NDBMS, because its imple-mentation was not at all compliant with the DB2 Everywhere logic. Because no fast solutionwas possible, IBM decided to drop the idea of using the NDBMS. This started the implemen-tation of an own data management structure, based on the file system.


7.4 The New DB2 Everyplace Version 7.1

The decision not to use the functionalities ofthe NDBMS anymore marks the starting pointof DB2 Everyplace Version 7.1. This versionmainly changed the DMS layer, which is nowfully platform independent. The biggest goalwhich has been achieved by introducing thenew DMS layer is, making it possible to isolateany platform dependencies in the OSS or in thefile system layer. This is a major improvementin the sense of portability and made it mucheasier to port DB2 Everywhere to the EPOCplatform.

For this version of DB2 Everyplace it was notnecessary anymore to deal with the NDBMS,but instead of that you have to work with thefile system. Implementing the new DMS layeris easier, because EPOC Development environ-ment includes a C standard library, which isproviding all functions needed for the databasesystem, e.g. memory management, string manipulation and file access.

With this library it seems that all problems that came up are solved, but this approach raisedsome new problems, such as internal memory handling of the C standard library and writablestatic data in a dynamic link library. No support of writable static data (global variables) is avery specific problem of EPOC applications ([TAD+00]). While programming C++ this con-straint does not really hurt, but for C code global variables are sometimes necessary and can-not be avoided. The only solution for that problem is, collecting all global variables in a glo-bal structure. At the start of the engine memory will be allocated for this structure and thevalues will be initialized. Thereafter a pointer to this memory will be stored in the thread lo-cal storage, which can be accessed from any file of the engine. Closing the engine will releasethe memory of the global structure. But within the addition, that memory used inside the Cstandard library has to be released explicitly by using an EPOC system call.

After solving all these problems mentioned above, the porting effort to EPOC and the timespent was much smaller, than it would have been with the approach used in DB2 Everywhere1.x.

CatalogCatalog

Operating System Services (OSS)Operating System Services (OSS)

EPOCEPOCOperatingOperatingSystemSystem


CompilerCompiler RuntimeRuntime

ParserParser

SemanticSemantic

OptimizerOptimizer

RDSRDS

InterpreterInterpreter

CLI / ODBCCLI / ODBC

File SystemFile System

Palm OSPalm OSOperatingOperatingSystemSystem

Windows CEWindows CEOperatingOperatingSystemSystem

DB

2Eve

rypla

ceV

ersion

7.1

OS

Figure 7.3: Internal Structure ofDB2 Everyplace Version 7.1.

7.5 Porting Remarks 169

7.5 Porting Remarks

After the introduction of the new data management services layer, it was and will be a fairlyeasy and quick task to port DB2 Everyplace Version 7.1 to Embedded Linux, Neutrino, andany other operating system. Being independent from platform dependent database manage-ment implementations highly improved the portability of the code. Now only the operatingsystem services layer and the file system support is platform dependent. Supporting the samefile system behavior across all platforms is still not an easy task, because for example PalmOS does not have a real file system, which makes a custom solution necessary. But theseproblems are still minor compared to using the NDBMS.

Due to the fact that only the OSS layer and the file system are platform dependent, only theselayers may cause some more trouble because of the different file system behavior (e.g. EPOCcan have 32 files maximum open at a time). But reducing and keeping the platform depen-dent code as small as possible will definitely pay off in future.

8 Summary and Conclusion

As seen in the introduction the handheld market has definitely a big potential, so that a lot ofsoftware companies are now developing software for this market. Most of the time thesecompanies start with a prototype only developed for one or maybe two platforms (e.g. PalmOS, and Windows CE). Later when they see that there is a market requirement, they will adddifferent other platforms. If then the first application design is not already well structured theaddition of other platforms requires to rewrite the application partially. Developers may min-imize or even avoid the additional work by pursuing platform invariant application develop-ment.

The first section of this paper was introducing the handheld device market from a marketingaspect. Afterwards differences between PDAs and desktop computers were described to givean introduction into the handheld device world. This world has been build by many devicesand operating systems, which were shown in more detail in chapter two. After that generalintroduction the paper is concentrating on the business–case of DB2 Everyplace and thehandheld application design guidelines and implementation rules.

Finally this paper has given any reader the necessary knowledge to help him to understandthe PDA world in the past, present, and future. The past was Apple’s Newton, the present isdominated by Palm with its devices and operating system, and the future might be any oper-ating system and device running Java.

What ever will happen in future, every application that should run on various operating sys-tem platforms has to be properly designed for this multi–platform use. Only with a goodmulti–platform design, which will minimize the porting effort, time consumption, and costs,a company will be able to react fast and successful to the recent market trends.

8. Summary and Conclusion170

References

Internet Links

IBM99 IBM Corporation, Administration and Application Programming Guide, DB2 Everywhere forWindows CE and Palm OS Software, Version 1.1, August, 1999, Publication No. SC26-9675-00

Symb99a Symbian Ltd., EPOC Release 5 Software Development Kit for C++, SDK documentation, 1999

Symb99b Symbian Ltd., EPOC Developers Course, 1999

Symb99c Symbian Ltd., EPOC Technical Paper: EPOC Overview: Summary June, 1999http://www.symbian.com/technology/papers/e5oall.html

Task99 Martin Tasker, EPOC Technical Paper: EPOC Overview: Core June, 1999http://www.symbian.com/technology/papers/e5ocore.html

HäRa99 Theo Härder, Erhard Rahm, Datenbanksysteme: Konzepte und Techniken der Implementierung,Springer Verlag, Berlin, Heidelberg, New York, 1999

IDC00 Jill House, Market Mayhem: The Smart Handheld Devices Market Analysis and Forecast, 1999–2004, IDC Report #W22430, June 2000; http://www.idc.com

JBLEND Aplix Corporation, JBlend operating system online documentation; http://www.jblend.com/en/

MCE00 Microsoft eMbedded Visual Tools 3.0, Online documentation for the SDK, 2000http://www.microsoft.com/pocketpc/developer.asp

PPC99 Palm Computing Platform, Palm OS Software Development Kit: Palm OS Programmer’sCompanion, 9/1999; http://www.palm.com/devzone/docs.html

TAD+00 Martin Tasker, Jonathan Allin, Jonathan Dixon, John Forrest, Mark Heath, Tim Richardson, MarkShackman, Professional Symbian Programming — Mobile Solutions on the EPOC Platform, WroxPress Ltd. & Symbian Ltd., 2000.

QNX99 QNX Software Systems Ltd., QNX System Architecture, Online Documentation, 1999http://www.qnx.com/literature/qnx_sysarch/index.html

QNX01 QNX Software Systems Ltd., Handheld Computers for Mission Critical Applications – A WinCEAlternative is "In Hand"; http://www.qnx.com/literature/whitepapers/handheld.html

RhMc99 Neil Rhodes, Julie McKeehan, Palm Programming: The Developer’s Guide, O’Reilly (and)Associates, Inc., 1. Edition, January 1999, USA

VT99 VT–OS V1.1 Overview, (Included in the SDK document); http://www.pdabuzz.com/vtech/

Apple Newton Message–Padhttp://www.pdastreet.com/newton.html

JTRON specification overviewhttp://www.jblend.com/en/jtron/3-e.html

EPOC — Symbian developer networkhttp://www.symbiandevnet.com/

JTRON specificationhttp://tron.um.u-tokyo.ac.jp/TRON/ITRON/SPEC/FILE/jtron-200e.pdf

EPOC — Symbian technical papershttp://www.symbian.com/technology/papers/papers.html

Microsoft Windows CE ”PocketPC”http://www.microsoft.com/pocketpc/default1.asp

Helio — devicehttp://www.myhelio.com/cgi-bin/vtechhelio.storefront

Palm OShttp://www.palm.com/

Helio — VT–OShttp://www.pdabuzz.com/vtech/

Palm OS developer networkhttp://www.palmos.com/dev/

JBlendhttp://www.jblend.com/en/

TRON Projecthttp://tron.um.u-tokyo.ac.jp/TRON/

Documents

PLATFORM INVARIANT DATABASE DESIGN FOR … Series 7 SP ARM710T RISC, 32-bit ... Ericsson Mobile Companion MC218 EPOC Release 5 CPU Speed RAM ROM Flash ... and execute commands. The