PalmOS on x86: threads

Unlike original PalmOS, the x86 port allows multiple programs to run concurrently on the same screen. Each program runs on a separate thread and there is a system thread responsible for updating the display and managing input events, like mouse cursor movements, button clicks and key pressing. If one of these events occur, the system thread forwards the event to the active program thread. When an application uses Window Manager functions (WinDrawChar, etc) , pixels are written to a private in memory bitmap. From time to time, the system thread accesses these bitmaps and draw them on the global screen using SDL2. The system thread is the only one that actually draw on the screen. Shared resources, like the  private bitmap used by each thread, are protected by a mutex. PalmOS storage databases are also protected by a mutex: a database created by one application is visible to other applications, but access is controlled so that two different threads do not overlap by other. Besides the storage database, another way for application threads to communicate with each other is through the clipboard, using ClipboardAddItem and ClipboardGetItem.

Threads and mutexes are implemented using pthreads, a set of standard functions and structures available on many systems, including Linux and Windows. The picture below illustrates some of these concepts.

Multiple threads running on PalmOS

The green box inside each thread represents a PalmOS application compiled from source. The yellow box labeled PalmOS API is the library mentioned in the previous article. The img box is an image drawing library. Red arrows represent screen updates and blue arrows system events.

On PalmOS, the starting point of an application is the PilotMain function. On the x86 port, the thread main routine performs some initialization and then calls PilotMain. The application never “knows” it is running outside of PalmOS. From its perspective, it is just like a native PalmOS program, calling standard API functions and receiving standard events via EvtGetEvent. The action of dragging an application window on the screen is handled by the system thread (labeled PalmOS thread on the picture). In this case, pen movement events are handled internally and not forwarded to the application being dragged. When a special key is pressed, the system thread forwards an appStopEvent to the active application. This event is the standard way to terminate a program on PalmOS.

The launcher window is just another application thread (not shown in the picture), also coded using PalmOS API calls. The only difference from a regular launcher is that instead of calling SysUIAppSwitch to start an application, it calls a newly created function SysUIAppSpawn. This function tells the system thread that a new program must be launched on a separate thread, instead of replacing the current program with the new one.

Be default, all applications have a 320×320 screen set to the standard coordinate system, that is, 160×160, just like in PalmOS 5 devices. Double density API calls are available, so an application can make use of double density bitmaps and fonts. There is also a mechanism for applications to request a bigger screen. The launcher uses this feature, as you can see in the picture.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s