|
Palm Database Programming The Electronic Version
Chapter 2: What You Need To Know About Palm Devices
This material was published in 1999. See the free
Palm OS Programming
online course I developed for
CodeWarriorU for some updated material.
Prev Chapter |
Prev Section |
Next Section |
Next Chapter |
Contents
Operating System
The Palm operating system (Palm OS) provides the environment for
your applications to run in and consists of two parts, the kernel and
the managers.
The Kernel
The kernel is the core of Palm operating system (Palm OS).
It provides the interface between the hardware (such as trapping
interrupts when the user strokes the screen with the pen) and the rest
of the operating system and also manages multiple threads of
execution. The kernel in current use is licensed from Kadak Products
Ltd. (www.kadak.com).
Although Palm OS uses several threads internally, applications
cannot create or use any threads other than the one they're running
on. You can only write single-threaded applications, which
means that you'll have to perform long operations in small chunks to
avoid the appearance of hanging the device. We discuss this further in
Chapter 4 when we deal with event processing.
Although applications are single-threaded and only one application
ever appears active to the user, a second copy of the active
application sometimes runs on another thread but in a more limited
environment. This is also covered in Chapter 4 when we discuss
application launching.
The Managers
Apart from the kernel, Palm OS consists of a series of managers,
which are collections of APIs grouped by function. Your applications
use the managers to obtain system resources and interact with the
user. The managers can be grouped as follows:
- The UI managers handle all interaction with the user. This
includes general functions for drawing on the screen as well as
functions related to specific user interface elements such as
fields and lists.
- The system managers handle non-UI interaction with the device,
including access to the timers and the system event queue.
- The memory managers handle memory allocation and management of
Palm OS databases and resources, discussed later in
this chapter.
- The communication managers handle communications between the
Palm device and the external world, using the serial port or the
infrared port.
We discuss most of the managers as we explore Palm programming.
Palm OS Versions
As the Palm devices have evolved, Palm Computing has released new
versions of the operating system. Palm OS 3.2 is the most recent
version of the operating system at the time this book was written and
is available on the Palm VII. The Palm IIIx and Palm V run Palm OS
3.1, while the Palm III runs Palm OS 3.0. The original Pilot 1000 and
Pilot 5000 machines run Palm OS 1.0. The PalmPilot Personal and
PalmPilot Professional models run Palm OS 2.0. All Palm models prior
to the Palm III can be upgraded to run the latest operating system by
ordering a new memory card from Palm Computing. The upgrade also
provides more RAM (random-access memory) and adds some new
capabilities such as infrared beaming that are missing in those
models. More recent models such as the Palm III can be upgraded simply
by downloading the new operating system into the device's flash
memory.
To detect which version of Palm OS is installed, an application
calls the FtrGet function, part of the Feature Manager:
// Get ROM version
DWord romVersion;
FtrGet( sysFtrCreator, sysFtrNumROMVersion, &romVersion ); |
The OS version number is returned as a four-byte value, whose
format is documented in the Palm OS header file <System/SystemMgr.h>
(see the next chapter for information about the Palm OS header files)
as follows: 0xMMmfsbbb, where MM is the major version, m
is the minor version, f is a bug fix number, s is the
code stage (0 for internal development, 1 for an alpha release, 2 for
a beta release, 3 for a final release), and bbb is the build
number for the releases that are not final. In general, all you check
are the major and minor build numbers:
if( romVersion < 0x02000000 ){
// Palm OS 1.x
}
if( romVersion >= 0x03100000 ){
// Palm OS 3.1 or higher
} |
The version number is often checked when the application starts to
ensure that the correct version of Palm OS is being used, as you'll
see in Chapter 4.
Palm Computing has done its best to make each version of Palm OS
upwardly compatible. Applications written for Palm OS 1.0 devices will
work equally well on Palm OS 2.0 or 3.0 devices. Palm OS 2.0
applications will work on Palm OS 3.0 devices but may not work on Palm
OS 1.0 devices. In some cases, an application written for an older
operating system will not work correctly on a newer OS because it
relied on an OS bug that the newer OS fixed. Apart from these bugs, if
your application is developed using a newer OS but doesn't actually
use any features specific to that version of the OS, then it will also
run on older operating systems.
How can you tell if you're using a feature specific to Palm OS 2.0
or 3.0? The surest way to tell is to try running your application on a
Palm OS 1.0 or 2.0 device (or using the Palm OS Emulator, which we'll
discuss in the next chapter, with an older ROM image). Or you can try
compiling your application using an older version of the Palm OS
software development kit (SDK). The problem with both these approaches
is that it is increasingly harder to get older versions of the device
or the SDKs. Your best bet is to know what features were added to the
OS. Since this book does not discuss Palm OS 1.0, here is a summary of
what's new in Palm OS 3.0 in comparison to Palm OS 2.0:
- More dynamic memory (96K instead of 64K). See the discussion about
the dynamic heap in the next section.
- New functions for supporting the infrared beaming capability new to
the Palm III device.
- Support for MIDI sound files.
- The ability to dynamically create user interface objects at run
time as opposed to only loading them from static definitions.
- A simple file-streaming API for dealing with large blocks of data.
- A Progress Manager for displaying progress dialogs during lengthy
operations.
Full details of these and other changes can be found in Appendix B
of Palm OS SDK Reference. Note that besides adding new
routines, some Palm OS 2.0 routines were modified in Palm OS 3.0 to
take extra parameters. The original routines are still available but
with a V20 appended to their name. For example, Palm OS 3.0 supports
both the CategoryEdit and the CategoryEditV20 routines. If you want
your program to work on a Palm OS 2.0 device, you must call the V20
version of the routine, otherwise your program will crash when it
tries to call the new version. There are a few Palm OS 1.0 routines
that were similarly changed when 2.0 was released. The V10 suffix is
used for the original version of the routine.
All applications in this book will work with Palm OS 2.0 and up
unless otherwise mentioned.
Sidebar: How V10 and V20 Functions Work
For a library developer, the promise of upward compatibility can be
a hard one to keep. It's often only after you make a piece of code
public that you discover one of your routines could have used an extra
parameter or two, or that changing the order of the parameters would
make the routine easier to understand. How can you make these changes
without requiring the recompilation of existing applications?
When you call a Palm OS routine, your compiler doesn't generate a
call directly to the routine in ROM, but rather to an entry in a
dispatch table instead. A dispatch table is an array of
pointers or offsets. In C++, for example, the virtual functions of a
class are stored in a dispatch table called the vtable and all
calls to the virtual functions are done through the vtable entries.
This allows derived classes to easily override a function by simply
writing a new address for the function in the vtable.
On the Palm, the dispatch table entries — called system
traps — are initialized by the operating system.
Whenever a routine is added to Palm OS, the developers add a new
system trap to the end of the table. Once added, a system trap's index
in the dispatch table is forever fixed.
How does the compiler know which system trap to use for a
particular routine? In the header files that come with the Palm OS SDK
you'll see that there is a mapping for each Palm OS routine to a
particular system trap. These mappings provide the link from the
symbolic name — the name you use in your code —
to the actual routine in ROM. When you call a Palm OS routine, the
compiler uses the mapping in the header file to generate a call into
the dispatch table. Change the mapping and you change which ROM
routine gets called. As long as the old system trap is still valid
then code compiled using the original mapping will continue to work
unchanged. Only when the code is compiled using a newer SDK will
changes be required, at which point the generated code will use the
new mapping and hence the new system trap.
Take, for example, the CategoryEdit routine. In Palm OS 3.0 there
are actually three versions of this routine: CategoryEdit,
CategoryEditV20, and CategoryEditV10. In Palm OS 1.0 there was only a
single CategoryEdit routine, and it took two parameters. The SDK
defined a mapping from the CategoryEdit name to a system trap. Palm OS
2.0 added a three-parameter version of the routine and hence a new
system trap. The new SDK remapped CategoryEdit to the new (second)
system trap and mapped the "new" routine CategoryEditV10 to
the old (first) system trap. Palm OS 3.0 added a four-parameter
version of the routine and another new system trap. The 3.0 SDK
remapped CategoryEdit to the third trap and mapped the new routine
CategoryEditV20 to the second trap. Thus, calling CategoryEdit using
the 1.0 SDK is equivalent to calling CategoryEditV10 when using the
2.0 or 3.0 SDKs.
|
Prev Chapter |
Prev Section |
Next Section |
Next Chapter |
Contents
Copyright ©1999 by Eric Giguere. All rights reserved.
From Palm Database Programming: The Complete Developer's Guide.
Reprinted here with permission from the publisher. Please see the
copyright
and disclaimer notices for more details.
If you find the material useful, consider buying one of
my books,
linking to this site from your own site or in your weblog,
or sending me a note.
|