Converting a 68K-based Palm OS application to a native ARM application running on Palm OS Cobalt can usually be done in two steps:
- Perform a basic port, keeping the new code as close to the original as possible. This results in a running application that looks and feels—and is—nearly identical to the original.
- Change sections of the application to take advantage of the new capabilities of Palm OS Cobalt. Depending upon your application, you might modify it so that it uses schema databases, or you might re-architect it so that portions of the application run in one or more separate threads.
This book is intended to help you with step 1; this chapter outlines a basic process for doing a straight port and discusses some of the more commonly-encountered problem areas. There isn't a general procedure for performing step 2. Depending upon which Palm OS Cobalt features you want to take advantage of, consult the appropriate books in the Exploring Palm OS series to learn more about how you would write software that can take advantage of those features.
The Basic Porting Procedure
The following are a series of steps one can take to convert a basic 68K-based Palm OS application to a native ARM application. Note that the order of these steps is not critical. As well, depending on your application some of these steps may not apply, and additional steps may well be necessary.
- Before you begin, verify that your project builds and runs cleanly on the Palm OS Garnet version 5.3 simulator. Enable all debugging checks, and fix any errors or warnings that arise.
- Convert all resources.
Previously, Palm OS application resources were stored in an encoded format in
.rsrc
files if you used CodeWarrior, or in.rcp
or.ro
files otherwise. In Palm OS Cobalt resources are stored using an XML format in one or more.xrd
files. Accordingly, each resource must be converted to the new format. Among the tools that make up the Palm OS Cobalt development suite is the "Generate XRD Wizard." This tool lets you- convert all resources from an existing PRC, or
- convert
.rsrc
filesNote that you must pass to the Wizard the files inside the
Resource.frk
folder, if on Windows. Developers on Mac OS must convert their resource files to Window format (with all data in the data fork, not in the resource fork), while PilRC users can create a PRC and pass that to the Wizard.
- Create a new empty Palm OS project of the appropriate type. Exactly how you do this depends upon your development environment.
- Add copies of your 68K-based project's files to the empty project. This includes source files, header files, and the converted resource files that were created in step 2.
- Open your C source files and comment out #includes for specific Palm OS header files. Instead, make sure that your C source files include
PalmOS.h
. - Unless you are trying to maintain a single set of source files that can be compiled for either ARM or 68K—something that can be tricky to do and would prevent you from taking advantage of the many new capabilities of Palm OS Cobalt—change declarations of variables of type
Err
tostatus_t
. Note that in Palm OS Cobaltstatus_t
is a signed 32-bit integer, whileErr
was defined in the 68K-based SDKs to be an unsigned 16-bit integer. Error values are all less than zero. Some functions may now return "status" codes that aren't errors; these values are greater than zero. Because of this, you should rewrite any code that looks like this:if (err) { // handle errors here. This is WRONG in Palm OS Cobalt }
Ideally, you should check for specific error codes. To check for a no-error condition, compare the returned value against
errNone
.While you are at it—and because it is little more than another set of search-and-replace operations—you may want to change how other variables are declared to better conform with the data types used by the Palm OS Cobalt APIs. For instance, change variables of type
UInt16
touint16_t
. Table 2.1 lists the basic data types used in the Palm OS Garnet headers and their corresponding Palm OS Cobalt data types.
Table 2.1 Palm OS Cobalt basic data types
|
The header file PalmTypesCompatibility.h
maps these data types for you using a series of typedefs. Although it is indirectly included in PalmOS.h
—SslLib.h
includes it—don't count on it being part of PalmOS.h
in future SDK releases. Either change your data types as outlined above, or specifically #include
this header file in each of your source files in order to get these mappings. PalmTypesCompatibility.h
is most useful when you are trying to create a single set of source files that can be compiled using either the Palm OS Garnet or Palm OS Cobalt SDKs. See "Compatibility Headers" for more information on the compatibility header files.
NOTE: If your application included
PalmCompatibility.h
to allow it to use older-style data types—such as Int
, Short
, and DWord
—you will have to change your declarations to use the new data types. PalmCompatibility.h
is not among the Palm OS Cobalt header files.
- Remove the call to the
RomVersionCompatible()
function, or at least update the function so that it checks for version 6.0 as a minimum version number. Note that theAppLaunchWithCommand()
function, commonly called from withinRomVersionCompatible()
, is not part of the Palm OS Cobalt ARM-native API set.If you leave the
RomVersionCompatible()
function in place, be sure to remove the check for Palm OS 1.0; it isn't needed since by design ARM-native Palm OS Cobalt applications won't launch on devices running an earlier version of Palm OS (5.x or earlier). - Build your project, and deal with the errors that arise. These errors are the result of differences between the 68K APIs and the Palm OS Cobalt ARM-native APIs. The following are differences that result in many of the errors you'll see:
- As discussed under "Missing UNIX Header Files," the
Core/System/UNIX
directory is not part of the Palm OS Cobalt ARM-native API set. - APIs that access a resource file and used to depend on the resource search chain now need to be pointed to the resource file that contains the resource. Until you make the needed changes, the compiler will complain that some of your function calls don't pass enough parameters (and the missing parameter is a
DmOpenRef
). See "No Resource Search Chain" for tips on dealing with these errors. - Functions that formerly took a
cardNo
parameter no longer do so. See "The cardNo Parameter" for the list of affected functions, and some tips on handling this change. Note that the "V50" versions of these functions still take acardNo
parameter, but be aware that the V50 functions work with Classic, not Extended, databases. - Calls to Palm OS Glue functions need to be replaced by calls to the function underlying each Palm OS Glue function. See "No Palm OS Glue" for more details on dealing with these missing functions.
- Code that directly accessed system structures that are now private, or have undergone significant change, will be flagged. Update the code to use the appropriate accessor function(s) as discussed under "Changes in System Structures."
- Most functions that were previously deprecated—as indicated by an operating system version number on the end of the function name (
CategoryEditV20()
, for example)—are not included in the Palm OS Cobalt ARM-native APIs. If your application uses one or more of these functions, see the appropriate chapters in Part II of this book for the corresponding function to call. - Per "Renamed Functions," a number of functions have new names in Palm OS Cobalt, meaning that your compiler will flag any attempts to call the function by its old name.
- The way in which
DmGetNextDatabaseByTypeCreator()
is used has changed significantly. See "DmGetNextDatabaseByTypeCreator() Changes." - In Palm OS Cobalt applications no longer use the Net Library in order to connect to, and transfer data to and from, other machines using the standard TCP/IP protocols. Instead, you'll have to change your application to use the standard Berkeley sockets APIs declared in
sys/sockets.h
. - There are now 1000 ticks per second, and this value is true on real devices, on emulators, and on the Simulator. Also, tick values are stored in unsigned 64-bit integers. Pay close attention to functions that take a tick value parameter, particularly if you pass a non-zero constant value. See "Changes in the Number of Ticks Per Second."
- You'll likely need to do some casting in order to make the compiler happy; a number of function parameters and return types have changed sizes. In some cases you may need to re-declare variables to avoid a loss of precision.
- There is little left of the Graffiti Manager. In Palm OS Cobalt you typically use the Pen Input Manager instead. One of the more common operations was to set the shift state using
GrfSetState()
. In Palm OS Cobalt to set the input area to "shifted" mode, use:PINSetInputMode(pinInputModeShift);
For more on the Pen Input Manager and user input in general, see Exploring Palm OS: Input Services.
A discussion on how you might deal with many of the above issues can be found in one of the sections under "Common Compile-Time Errors." For details on the differences between the API sets, see Part II of this book.
- As discussed under "Missing UNIX Header Files," the
- Test your application, and deal with the errors that you see. See "Common Run-Time Errors" for some of the more common run-time errors you may encounter, and tips on how to deal with them.
Compatibility Headers
The Palm OS Cobalt ARM-native API set includes a number of "compatibility" header files. These revert some of the API name changes, and accommodate some of the simpler function parameter list modifications that were made due to the lack of a resource search chain and the elimination of the concept of internal memory cards.
These compatibility headers are not included by default; you must include the appropriate compatibility headers in each of your application source files as necessary. Note that because they simply allow you to put off a set of rather simple changes, you should consider dispensing with these header files and simply altering your application's source to directly deal with the changes.
The following are the compatibility header files defined by the Palm OS Cobalt ARM-native SDK:
- DataMgrCompatibility.h
- Redirects a number of functions to their "V50" (deprecated) counterparts, and accounts for a number of APIs that have been renamed.
- ExgMgrCompatibility.h
- Declares three deprecated functions.
- FloatMgrCompatibility.h
- Declares a number of constants, structures, and macros formerly used in conjunction with the Float Manager.
- IrLibCompatibility.h
- Declares a number of APIs that allow applications to directly interact with the IR Library.
- LocaleMgrCompatibility.h
- Declares a set of
NumberFormatType
values. Rather than use these values, however, applications should be rewritten to use the format preference selected by the user (prefNumberFormat
). If you need a locale-specific format, passlmChoiceNumberFormat
toLmGetLocaleSetting()
. - MemoryMgrCompatibility.h
- Declares a number of functions that take a
cardNo
parameter. This allows your application to continue to work with card number values. Note, however, that the card number you pass must always be 0, and returned card number values are always 0. - ModemMgrCompatibility.h
- Declares a number of APIs that allow applications to directly control a modem.
- PalmTypesCompatibility.h
- Allows your application to continue to employ the basic data types used in the Palm OS Garnet SDK. Also declares the
min()
,max()
, andOffsetOf()
macros. - SysEventCompatibility.h
- Declares an enum and a struct using their Palm OS Garnet names; applications should use the new enum and structure declared in Palm OS Cobalt. See Chapter 112, "SysEvent.h," for details.
- WindowCompatibility.h
- Declares a single function that was part of the Palm OS Garnet PINS API and used to set window constraints. In Palm OS Cobalt this function does nothing.
Common Compile-Time Errors
The following sections go into some detail about a few of the more common errors you may encounter after compiling your ported application for the first time. These sections are presented in no particular order.
Missing UNIX Header Files
The header files mentioned in step 5. are not the only header files that are not present. The Core/System/UNIX
directory is also not part of the Palm OS Cobalt ARM-native API set. Use the header files declared in the posix
and streams
directories instead. So, for instance, instead of this:
#include <unix_string.h>
#include <posix/string.h>
Note that there is not a direct mapping between the header files in Core/System/UNIX
and those in the posix
and streams
directories. As well, differences between the UNIX and POSIX APIs may require you to modify or even rewrite those portions of your application that employ these APIs.
No Resource Search Chain
Prior to Palm OS Cobalt, Palm OS had the concept of a "resource search chain." This was a list of all open resource databases that would be searched by certain APIs. For compatibility purposes (mainly to support PACE) Palm OS Cobalt declares a number of "V50" APIs—such as DmGetResourceV50()
—that continue to operate on the resource search chain. This functionality is only for backwards compatibility, however, and shouldn't be relied on going forward. Instead, your application should wherever possible explicitly identify the resource database that contains the resource in question.
Table 2.2 lists the affected APIs. These APIs now take an additional parameter, a DmOpenRef
that indicates the open resource database that contains the resource.
Table 2.2 Functions that have an added DmOpenRef parameter
Because all of the resources explicitly accessed by most Palm OS applications reside within the application PRC itself, you can usually accommodate this change by doing the following:
- Declare a global variable of type
DmOpenRef
. - Early on in the execution of your program—in
StartApplication()
, perhaps—initialize this variable so that it contains a reference to your application's PRC. The loader contains two functions that make retrieving this very easy:SysGetModuleDatabase()
andSysGetRefNum()
.status_t error; if((error = SysGetModuleDatabase(SysGetRefNum(), NULL, &g_AppDB)) < errNone) return error;
Note that
SysGetModuleDatabase()
performs an IPC, and thus is a bit slow. Because of this, you may not want to call this function for every launch code, but instead only for those where the global referencing your application's PRC is needed. - Pass the global variable you declared in step 1 to each function that now needs an exploit reference to your application's resource database.
System Resources
Because the resource search chain is no longer supported, you cannot rely upon it to help you locate system resources. If your application employs system resources, you'll have to modify it to access those resources directly. Note that some system resources may have different resource IDs from their Palm OS Garnet counterparts, and some no longer exist at all.
The standard Edit menu continues to exist; its resource ID is 10000. As well, the alert icon bitmaps remain and can be used by applications. See UIResources.h
for the set of system resources that can be used by Palm OS Cobalt applications.
The cardNo Parameter
Palm Powered handhelds were originally designed to have ROM and RAM located on one or more memory modules that were known as cards. (These cards were a logical construct used by the operating system and are in no way connected with the removable memory cards supported by the Expansion Manager.) In the 68K API set a number of functions take or return a cardNo
(card number) parameter to identify on which card the memory being referenced is located. Because almost all Palm Powered devices only had one memory card, many Palm OS applications assume that the cardNo
parameter is always 0. PACE requires that this parameter be set to 0.
In Palm OS Cobalt this memory module concept is no longer supported, so the cardNo
parameter is no longer needed. Table 2.3 lists those functions that are affected. When porting 68K code to the ARM-native environment, everywhere you have a call to one of these functions you'll have to remove the cardNo
parameter.
Table 2.3 Functions that no longer take a cardNo
parameter
No Palm OS Glue
The primary purpose of the Palm OS Glue libraries and macros was to allow developers to write code that would continue to work across the widest range of Palm OS devices, even as the APIs changed from one Palm OS release to another. Because Palm OS Cobalt, version 6.0 exposes the first—and currently only—set of ARM-native Palm OS APIs, "glue" functions and macros are not necessary.
In most cases, where your application used to call a glue function or use a glue macro it should use the underlying operating system function instead. This is usually a function with the same name as the glue function or macro, with the word "Glue" removed. So, for instance, instead of calling WinGlueDrawChar()
your application should be updated to call WinDrawChar()
instead.
For a complete list of the Palm OS Glue functions exposed by the latest 68K-based SDK, and the corresponding ARM-native functions you should use in your ported application, see Chapter 79, "PalmOSGlue."
Changes in System Structures
The Palm OS defines a number of data structures for use by the operating system. To aid in the debugging process many of these structures were declared in the public APIs, and notes in both the header files and the documentation warned developers not to access the contents of these structures directly.
In Palm OS Cobalt the internals of many of these structures are no longer publicly declared. For instance, in the latest Palm OS Garnet SDK the FormType
structure is declared as follows:
typedef struct FormType #ifdef ALLOW_ACCESS_TO_INTERNALS_OF_FORMS // These fields... { WindowType window; UInt16 formId; FormAttrType attr; WinHandle bitsBehindForm; FormEventHandlerType *handler; UInt16 focus; UInt16 defaultButton; UInt16 helpRscId; UInt16 menuRscId; UInt16 numObjects; FormObjListType *objects; } #endif FormType;
In Palm OS Cobalt, the FormType
structure is declared as follows:
typedef struct FormType FormType
If, prior to porting your application to Palm OS Cobalt, you had successfully built your application with all debug checks enabled, the change in how these structures are defined should have no effect. If your application was directly accessing the contents of one of these structures, however, you'll have to rewrite those portions to use the appropriate accessor functions.
To determine the proper way to access the contents of one of these system structures, see the description of that structure in the reference documentation that is shipped with the Palm OS Garnet SDK: the Palm OS Programmer's API Reference.
Redefined System Structures
Some system structures continue to be declared in such a way as to make their contents directly accessible. However, the structure's contents may have changed. For instance, in the Palm OS Garnet SDK the BitmapType
structure is defined as follows:
typedef struct BitmapType #ifdef ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS // These ... { Int16 width; Int16 height; UInt16 rowBytes; BitmapFlagsType flags; UInt8 pixelSize; UInt8 version; } #endif BitmapType;
In Palm OS Cobalt this structure is declared like this, with the fields renamed to show the endianness changes:
typedef struct BitmapType { int16_t widthBE16; int16_t heightBE16; uint16_t rowBytesBE16; uint16_t flagsBE16; uint8_t pixelSize; uint8_t version; } BitmapType
Although your application could be modified to access this structure's fields directly, wherever possible use accessor functions instead. So, for example, if your application was determining the dimensions of a bitmap by accessing the BitmapType
structure's width and height fields directly, it should instead be rewritten to call BmpGetDimensions()
.
Renamed Functions
For various reasons a number of APIs in the Palm OS Cobalt API set were brought forward from the Palm OS Garnet API set with new names. Often this was done to make the purpose of a function more immediately apparent, or to bring the name of a function more in line with similar functions that use a different naming pattern. For instance, the Palm OS Garnet function BmpBitsSize()
is named BmpGetSizes()
in the ARM-native API set. If the compiler informs you that a particular API is not declared, check the appropriate chapter in Part II, "68K vs ARM-Native APIs," to see if it has been renamed.
Table 2.4, below, lists some of the commonly-used APIs that were renamed for Palm OS Cobalt.
Table 2.4 New names of some commonly-used APIs
Memory Manager Functions
Although the functions provided by the Memory Manager continue to work as documented, many of them simply call the standard POSIX memory management functions. You are encouraged to call these functions directly, rather than using the Memory Manager functions. So for instance, instead of MemMove()
you could call memmove()
. Refer to posix/stdlib.h
for malloc()
and related functions, and posix/string.h
for functions such as memmove()
, memset()
, and so on.
IMPORTANT: When changing a function call from, for instance,
MemMove()
to memmove()
, carefully examine the parameters to make sure that they correspond exactly. In particular, pay attention to parameter ordering; some of the Palm OS functions do not use the same parameter ordering as their POSIX counterparts.
String Functions
As with the Memory Manager functions, you can use the POSIX string functions in place of many of the Palm OS Str...
string functions. The POSIX functions are typically faster than their Palm OS counterparts. Note, however, that the POSIX functions don't necessarily respect the device's locale and don't necessarily work with multi-byte characters as the Palm OS versions do. So, while you can safely call strlen()
in place of StrLen()
, and strcmp()
in place of StrCompareAscii()
, other functions aren't directly interchangeable. For example:
-
StrCompare()
performs a localized string comparison. -
StrToLower()
andStrToUpper()
respect the current locale. -
StrChr()
andStrStr()
properly deal with multibyte characters. -
StrNCopy()
andStrNCat()
won't truncate the string in the middle of a multibyte character.
DmGetNextDatabaseByTypeCreator() Changes
DmGetNextDatabaseByTypeCreator()
must now be used in conjunction with the new DmOpenIteratorByTypeCreator()
function; you indicate what you are searching for when calling the latter function. DmGetNextDatabaseByTypeCreator()
now optionally returns information about the found database in addition to its database ID.
If you just want to locate a single database, and not iterate through all databases that match the given criteria, consider calling DmFindDatabaseByTypeCreator()
instead.
Changes in the Number of Ticks Per Second
In Palm OS Cobalt, version 6.0 there are 1000 ticks per second (but code should use the SysTicksPerSecond()
macro instead of relying on a constant value). Because of this, variables that hold tick counts should be declared as uint64_t
; this is what is returned from functions such as TimGetTicks()
.
The number of ticks per second should not be counted upon to remain unchanged. Palm OS Cobalt defines a number of macros that allow you to work with time values and intervals using more natural units, such as seconds or milliseconds. The various SysTimeIn...
macros, such as SysTimeInMilliSecs()
, allow you to convert a system time value (a time interval, in ticks) to more conventional units. To convert from such units back to a system time value, use one of the SysTimeTo...
macros, such as SysTimeToMilliSecs()
. Consider rewriting your applications to avoid working directly with ticks; this will insulate your applications from any future changes in the number of ticks per second.
Although the TimGetTicks()
function could be used in a loop to implement a delay, applications should be rewritten to use the SysTaskDelay()
function instead. The SysTaskDelay()
function automatically puts the unit into low-power mode during the delay. Using TimGetTicks()
in a loop consumes much more current.
ERROR_CHECK_LEVEL Not Defined
In Palm OS Cobalt the ERROR_CHECK_LEVEL
#define has been replaced by BUILD_TYPE
. In 68K-based SDKs, ERROR_CHECK_LEVEL
could either be set to ERROR_CHECK_NONE
, ERROR_CHECK_PARTIAL
, or ERROR_CHECK_FULL
. BUILD_TYPE
, on the other hand, is either set to BUILD_TYPE_DEBUG
or BUILD_TYPE_RELEASE
, depending on whether you are building your project for debugging or for release.
The ErrDisplay...
, ErrFatalDisplay...
, and ErrNonFatalDisplay...
macros have been adjusted accordingly. Note, however, that these macros are only provided for compatibility purposes; applications should now use ErrFatalError...
and DbgOnlyFatalError...
instead. Also note that Palm OS Cobalt supports the POSIX assert()
macro (defined in posix/assert.h
).
For more on the use of these #defines and macros, see "Displaying Development Errors" of Exploring Palm OS: System Management.
Common Run-Time Errors
The following sections describe some of the errors you may encounter when running your application. Errors of this type won't be caught by the compiler. These sections are presented in no particular order.
The "Save Behind" Bit
Versions of Palm OS prior to Palm OS Cobalt saved and restored the area of the screen obscured by a form if Save Behind was selected in the form's resource. For ARM-native applications Palm OS Cobalt doesn't honor the Save Behind setting; in a debug build it will warn you of this fact when a form is displayed that has Save Behind set.
To deal with this, you need to:
- Turn off Save Behind. You can do this by opening each form in "Palm OS Resource Editor" (double-click it). Select the form, and un-check "Save Behind" if it has been checked. Alternatively, you can just open the XRD file in a text editor and change "SAVE_BEHIND" to "FALSE". The line you need to change in the XRD file looks like this:
<SAVE_BEHIND> TRUE </SAVE_BEHIND>
- Make sure that your application correctly responds to updates. That is, make sure that it draws when it receives a
frmUpdateEvent
(and only when it receives afrmUpdateEvent
).
For more on dealing with forms, see Chapter 2, "Working with Forms and Dialogs," of Exploring Palm OS: User Interface.
Restrictions on Callbacks
There is no guarantee that your code will still be loaded, or that it will be loaded at the same location in memory after an application switch. Therefore, the use of callbacks to communicate between executable modules, while technically allowed in certain rare cases, is no longer encouraged. Instead, use custom launch codes to communicate between executable modules. This applies to notifications, the Attention Manager, and the like.
Also note that data structures passed along with launch codes—SysNotifyParamType
structures that accompany notifications, for example—should not contain embedded pointers.
Note that callbacks within an executable module—to form event handlers, list drawing routines, and such—are fine.
Streaming Sound Callbacks
Don't use the streaming sound callbacks to cause sounds to play after an application has quit. Instead, create a background thread and play the sounds from within that thread.
Custom Drawing
As explained under "Drawing or Updating a Form" of Exploring Palm OS: User Interface, custom drawing in update-based windows should only be done in response to a frmUpdateEvent
. If you use legacy or transitional windows you can draw whenever you like. However, if you do any custom drawing you must handle frmUpdateEvent
. To trigger a frmUpdateEvent
, call WinInvalidateRect()
or WinInvalidateWindow()
.
Many of the window drawing operations (documented under "WinDrawOperation" of Exploring Palm OS: User Interface) are deprecated in the Palm OS Cobalt ARM-native APIs. Pay particular attention to winInvert
and winSwap
; these do not work when drawing text, drawing unfilled rectangles, or drawing to update-based windows. When you try to use them in these instances, nothing is drawn to the screen.
PIM Database Access
The PIM applications have been rewritten to use schema databases. Applications that directly access the PIM databases will quickly discover that the classic databases used by the 68K-based versions of the PIM applications are either not present or are empty. Such applications will have to be rewritten1. See Exploring Palm OS: Memory, Databases, and Files for information on reading and writing schema databases. Exploring Palm OS: Palm OS File Formats describes the schema of the PIM application databases.
Differences in Endianness
68K applications live in a big-endian world. Palm OS Cobalt, on the other hand, uses the ARM processor in little-endian mode. Because of this, to allow the exchange of data between a handheld running Palm OS Cobalt and one running Palm OS Garnet or an earlier Palm OS version, you'll need to develop a "wire format"—a processor-independent format—for the data being exchanged. The PIM applications do this by adopting standard exchange formats such as vCalendar.
Note that byte ordering can affect your application's conduits as well. If your application uses a conduit you can add byte-swapping routines to your conduit as needed.
Application Process Tear-down
Applications run in a dedicated process. When the application quits, the application is torn down. Because of this, you no longer use MemPtrSetOwner()
to share a block of memory between applications.
NOTE: Palm OS Cobalt maintains a "legacy heap" largely for use by PACE. All "legacy" memory (memory allocated from 68K code) resides in this heap. The legacy heap is persistent across invocations of PACE and native ARM applications. It is limited in size, and is size-checked at application shut-down. The legacy heap respects all of the behavior of the heap model used in Palm OS versions prior to Palm OS Cobalt, including the behavior related to owner IDs.
The fact that the application process is torn down when your application quits also means that:
- You can't use callback notifications. There is no guarantee that your code will be loaded, or that it will be loaded at the same location after an application switch.
- You can't use embedded pointers in the
SysNotifyParamType
structures that accompany your notifications.
Beyond the Basic Port
Once your application is up and running natively on Palm OS Cobalt, you may want to take advantage of the many new features of the Palm OS Cobalt operating system. Features such as schema databases, multithreading, and the new multimedia subsystem can be used to greatly enhance a Palm OS application, making it richer and more powerful.
Even if you don't want to take advantage of these major new features, however, note that some of the programming techniques you had to employ in a 68k-based Palm OS application were "defensive" in nature—they were to work around limitations in the operating system. Palm OS Cobalt lifts many of these restrictions, so although the old code will continue to work, you may wish to simplify your application by removing any code that exists to work around these limitations. In particular, note that:
- Using handles is rarely beneficial in Palm OS Cobalt, so use pointers for simplicity.
- Global variables are now available for all launch codes and for shared libraries.
- Memory chunks are no longer limited to a maximum of 64 KB. Extended database records can exceed 64 KB as well (but note that Classic databases retain this restriction).
- Code segmentation of large applications is no longer necessary.
- Applications can now be multi-threaded.
- All applications are now shared libraries, exporting
PilotMain()
. Applications can also export other functions. Shared libraries are much easier to write in Palm OS Cobalt: there are no trap dispatch tables, and you can use global variables. To use a shared library, simply link against the library's stub file. - MathLib has been ported to ARM. Note that in Palm OS Cobalt version 6.0 MathLib is not in ROM, however. It may well be in ROM in later releases of Palm OS Cobalt.
1. 68K-based applications that run courtesy of PACE continue to work, however; see "Accessing the PIM Application Databases" on page 13 for specifics.