art 1 of this series began a discussion of the differences between PalmOS and Symbian OS. Despite their superficial similarities, programming in Symbian isn’t just like programming a Palm PDA. Part 2 takes this discussion even further, covering the areas where these two operating systems really go in different directions.

Memory
If you’re thinking about moving to Symbian OS from PalmOS, one of the biggest differences is how Symbian OS handles memory. While both have main memory and permanent storage memory, they use them differently.

Palm OS uses RAM for both main memory, the dynamic area, and permanent storage, the storage area. As you might guess from the names, the dynamic area runs programs while the storage area stores programs and data just as a hard drive would on a PC.

	Figure 1: Palm OS Memory Map

While Palm OS handhelds also use flash memory, a removable expansion card such as a Secure Digital card, MultiMediaCard (MMC), or Memory Stick for permanent storage, they must use some of their RAM for permanent storage of the operating system. The exact amount of RAM used for this purpose depends on which version of Palm OS is in use. Currently, Palm OS accesses only up to 16MBs of RAM. But Version 5.2 brings support for up to 128MBs of RAM.

Figure 1 shows a typical Palm OS device with removable expansion memory and flash memory.

	Figure 2: Symbian OS Memory Map

Symbian OS Memory
Symbian OS devices use RAM just as it is used on a PC?with all the main memory available for the operating system and applications. Permanent storage is kept in flash memory and expansion cards like the Nokia 9200 Series’ MMC.

As you can see in Figure 2, the, the way RAM is allocated allows you more active, main, memory for your Symbian OS applications than you would have for your Palm OS programs. In addition, Symbian uses all hardware supported RAM to a theatrical maximum of 2GBs.

Memory Usage
Both Symbian OS and Palm OS use execute-in-place for efficient memory usage. With execute-in-place, your code can run without being copied into main memory.

Symbian OS, however, provides a more stable memory environment for applications than Palm OS. In Symbian OS, the kernel runs within its own protected address space. Because of this, a programs memory leak or stack over-run can’t overwrite the kernel’s stack or heap which would cause a system crash. When programs need to dynamically exchange data, it’s done by using the Symbian OS’ internal client-server architecture, with its minimal resources, message-passing system.

In addition, every program process has its own protected address space. Thus, it’s difficult, although not impossible, to write an application that will overwrite another’s program’s address space?again, causing an application crash.

Palm OS also restricts the amount of memory used by an application’s stack and heap. This means you must keep an applications stack size small and not allocate large objects on the heap. The situation is quite different in Symbian OS.

While there is a 2GB RAM limit, for all practical purposes the sky is the limit for an application’s heap size. Hardware, not the Symbian OS, limits the amount of available memory. In real world development, this makes writing applications that require dynamic memory allocation much easier. On a smartphone, of course, the most popular use will be allocating dynamic memory in the form of buffers for communications application.

Palm OS does not support virtual memory and has no per-process memory protection. This means badly written applications can overwrite other program’s memory segments, also leading to crashes. With Symbian OS, the programming framework makes it much more difficult to make this kind of mistake.

A Symbian OS application that allocates dynamic memory on the heap but doesn’t release it can lead to poor memory management especially with multiple open applications.

In short, Symbian makes it harder, but not impossible to leak memory

Code Reusability and Shared Libraries
To save memory and effort, Symbian OS is designed so that code can be reused as often as possible.

This is done in two ways. The first is by making low-level services available to applications via the layered components of the operating system. The second is by enabling the reuse of DLLs.

As you can see from Figure 3, a great deal of functionality is already available from the operating system so you don’t need to reinvent even high level constructions like a WAP browser.

	Figure 3: Symbian OS Functionality

Applications access this functionality via the appropriate API calls.

In Palm OS, on the other hand, you must build your own higher level functions or look to pre-existing third-party plug-ins.

In Symbian OS, you can also use system DLLs, normally located in permanent storage, to be executed in place thus saving main memory space. You must load DLLs stored in expanded memory storage into into main memory.

When Symbian OS loads a program, it also loads all the DLLs it calls. If the DLL is already in permanent storage or has already been loaded by another process, the process’ threads share the resident copy rather than loading an additional copy. This cuts down the code loaded into main memory to a bare minimum.

Connectivity
One advantage Palm OS has over Symbian OS is that the Palm Conduit Development Kit (CDK) makes it much easier to write conduits for its HotSync Manager application for PC/PDA data synchronization. With Symbian OS, you write your own data synchronization applications using the Connectivity SDK, 2.5.

Despite this advantage, Symbian OS was designed from the ground up for Smartphones, so it has a much richer set of networking and messaging APIs.

Symbian’s extensive set of messaging APIs can be used to connect applications with both external communications services, like SMS or e-mail, and interapplication communications (IAC) calls, such as calling for information from the Contacts database or using the Global Find API to search for text strings in saved files. Instead of writing a routine to perform such functions, you use relatively simple API calls.

While both operating systems have TCP/IP networking and enable the use of sockets, Symbian OS offers easier access to networking protocols via API calls. In particular, Symbian OS enables the use of sockets with a variety of different transport layer protocols. So, besides TCP/IP, where one expects to find sockets, you can also use sockets with IrDA and SMS.

Using sockets is done at a high level during the application’s network initialization phase, eliminating the need to write any protocol specific code. Simply use the socket API without regard to the protocol’s demands.

The Biggest Difference: Programming Styles
The biggest change you will face in moving to Symbian OS is becoming an object-oriented programmer. In Palm OS, even developers who use C++, can program as if they were in a C environment. That is simply not possible in Symbian OS.

For example, most Palm OS applications use multiple ‘.h’ and ‘. c’ source files, and a resource file that describes user interface resources. Usually the source files are organized by functionality?one file contains application logic, database functionality, and so on. In short, Palm OS uses standard C programming conventions.

Symbian OS applications, on the other hand, use the object-oriented, Model-View-Controller (MVC) model. In MVC, there’s a clear division between application logic and the user interface. A typical Symbian OS program is made up of C++ header and source files that define the application’s classes. For example, consider a typical Palm OS program on the left compared to a Symbian OS on the right.

	Figure 4: Palm OS vs. Symbian OS

As shown in Figure 4, Symbian OS takes a very different approach. In Symbian OS, any application must use three different classes: the application class; the document, which may include a data model, class; and a user interface class. If you’re using UIQ, you must include at least one View class, which is the equivalent of onr of Palm OS’ Forms.

In Symbian OS, applications are made up of an application class. You use this to create the document/data model and the UI. Interprocess communication is done by event handlers within the User Interface Class, which work with the underlying operating system.

The Application’s Entry Point
The Entry Point is simply a C++ file that calls the minimum required application entry points functions, NewApplication and E32Dll, by using an instance of the Application Class.

The Application Class is derived from the UIQ Application base class, C@ikApplication. This class bootstraps the application, returns its system unique application ID and creates the document object.

Regardless of whether you use UIQ, the Document Class (which derives from the UIQ Document base class, CqikDocument), both creates the application’s UI and well as stores and restores data. In addition, the Document Class also contains and initializes the application’s data model. The ways by which the application will save data and close down are arranged in the Document Class.

The User Interface Class does exactly what its name indicates. It creates the application’s user interface controls, views, and handles UI commands. Even if the application doesn’t use UIQ, it must use the UIQ User Interface base class, CQikAppUi. The User Interface Class provides the foundation for the UI, but does not actually implement the UI.

That job is done by the View Class. The View Class determines what the user actually sees and works with. This, in turn, springs from the Control framework base class, CCoeControl and from the view architecture class, MCoeView. Typically, UIQ is used.

Resource files are handled in approximately the same way they are in Palm OS. Symbian Resource files usually use the same names as their applications, with the extension .rss.

When an application starts, it reads in the resource file. While you could dynamically create UI objects, as you can in Palm OS, it’s much more efficient to use the resource file to create all your applications UI objects.

Processing Approach
Both operating systems are event-driven operating system. With Palm OS, an application implements an event loop and event handlers and talks to the operating system via the event manager

Symbian OS also takes an event-based approach, but its object-oriented approach combined with its prioritized pre-emptive multitasking makes multiple running applications not only possible, but makes even single applications more responsive to user input.

From Palm OS to Symbian OS
While you might think that if you know C++?the most powerful language option available on both operating systems?you’ll be able to program on Symbian OS, that is not the case. Not only does Symbian offer more full access to the operating systemstet APIs, and the underlying hardware, its object-oriented approach is fundamentally different from Palm’s approach.

Writing code for Symbian OS means more than just picking up a few new programming idioms. It means adapting to an entirely different approach to programming. Since that’s the case, even an extremely experienced Palm OS developer should spend considerable time learning how to program on Symbian OS before attempting to port a major Palm OS application to Symbian OS or creating a new Symbian OS program from scratch. For more on that, see the resources on the left hand of the page.

In the end, it will be worth it. By gaining access to Symbian OS, you will learn not just how to use a fundamentally more sophisticated and powerful operating system, you’ll also open up the world of Smartphones for your applications.