PumpkinOS: a PalmOS re-implementation that needs no PalmOS ROM

An operating system re-implemented, not an emulator

PumpkinOS is a re-implementation of PalmOS that runs on modern architectures such as x86 and ARM. The distinction it draws in its own documentation is the important one: it is not an average PalmOS emulator, it does not require a PalmOS ROM, but it can run m68K PalmOS applications.

That distinction changes what the project is. An emulator of the kind most people picture reproduces the original hardware in software and needs the original firmware as the starting point for the guest system. PumpkinOS reimplements the operating system itself, so there is no ROM to supply, and the applications that run on it are the ordinary PalmOS binaries that were distributed for the platform.

The primary language is C, and the licence is GPL v3. The repository carries a licenses directory that the documentation describes as holding information on the specific licences of the various components used in PumpkinOS, with an invitation to report anything missing or incorrect.

For the intended audience, think of the developer or hobbyist who has PalmOS software that runs but no hardware to run it on, or who wants to look at how a handheld operating system was structured. The project also points to a series of articles describing various aspects of PumpkinOS, hosted on a personal blog under the palmos category, which is the place to go for the design reasoning this repository does not spell out.

A Launcher, a shell, and four missing PIM applications

Three pieces of the user interface are described, and one of them is a gap rather than a feature.

The Launcher is the first application that runs when PumpkinOS starts. It shows a panel from which other applications can be started, which makes it the equivalent of the home screen of the original device. Preferences is described as something that will eventually contain all the preference options for configuring PumpkinOS, so it is present in outline rather than finished.

Command is a command shell, and the documentation calls it still experimental. It is the piece to try first if you want to poke at the system from the keyboard, and it is also the piece most likely to disappoint.

The significant absence is the PIM suite. This release does not contain the four classic PIM applications from PalmOS, which in a typical Palm install are the address book, the date book, the todo list and the memo pad. They can still be compiled from source, so the capability is not lost, but it is work the user has to do.

The launchers of the day had those four applications as the reason people used the device. A PumpkinOS installation today gives you a launcher, a settings shell in progress and a way to start PRC files you supply yourself. That is a hobbyist operating system, and the documentation is refreshingly open about that.

Compiling with gcc, make and SDL2 headers

There is no installer and no binary distribution described in the documentation. You build PumpkinOS from source, and no IDE is required because it builds from the command line.

The dependency list is short. On a 64-bit Linux system such as Debian or Ubuntu you need gcc, binutils, make and git, plus the SDL2 development package, which is the package that contains the libraries and the headers:

sudo apt install gcc binutils make git libsdl2-dev

On 64-bit Windows the documented route is MSYS2, with the installer followed by the MINGW64 terminal, and the additional packages installed with:

pacman -S gcc binutils make git

There is a third option for Windows. On Windows 11 and recent releases of Windows 10 it is also possible to build on WSL2, the Windows Subsystem for Linux version 2, and the documentation says the instructions from there on are the same as for Linux.

The build itself is a clone and a make:

git clone https://github.com/migueletto/PumpkinOS.git
cd PumpkinOS/src
make

If it goes well you get a pumpkin executable in the root directory, some dynamic libraries in the bin directory, and some PRC files in the vfs/app_install directory. That last artifact is the application mechanism, and the next section explains what happens to it at run time.

The repository root also holds the platform launch scripts, pumpkin.bat for 64-bit Windows, pumpkin.sh for Linux and WSL2, a pumpkin32.bat, a pumpkin.vbs, a pumpkin.wine, a pumpkin_rpi.sh, and separate lib and lib32 directories, which is consistent with a project that has to build and run on several architectures and hosts.

Every launch unpacks the virtual file system

The runtime behaviour of the application directory is unusual and worth understanding before you install anything.

According to the documentation, when you run PumpkinOS, all PRCs inside vfs/app_install are removed and expanded into folders inside vfs/app_storage. So the install directory is not a durable storage location. It is a staging area that the system consumes on start up, and the installed applications live in the storage directory as expanded folders.

Two consequences follow. Anything you put in app_install is processed at the next launch, and anything you edit there directly will be lost, because the files are moved out of it. And if an application is not behaving, the place to look is the expanded folder in app_storage rather than the PRC you copied in.

The vfs directory is the name for the whole of this, and the project uses it for the application tree, so the virtual file system is where the executable content of the system lives.

The alternative route to the same place is drag and drop. The documentation states that PumpkinOS supports it: you can drag a PalmOS PRC file over its window and it will be installed and will show up in the Launcher. You can also manually copy PRCs to the vfs/app_install directory and restart PumpkinOS, which is the path to take when the drag and drop is not convenient, for instance over a remote desktop.

Debugging with gdb and reading pumpkin.log

The project expects you to expect problems, and it gives you the tools to look at them.

The documentation says to keep in mind that everything is pretty much experimental at this stage, so expect a few issues here and there. On debug compilations, after either a successful or an unsuccessful run, you find a pumpkin.log file in the root directory, and if something goes wrong the instruction is to look for lines marked with an E in the third column of that file. The author invites you to send the log file along with any question.

For deeper work there is gdb, on Windows, Linux and WSL2. The debugging invocation is documented for each platform, and the Linux and WSL2 form is:

gdb --args ./pumpkin -d 1 -f pumpkin.log -s libscriptlua ./script/pumpkin.lua

The Windows variant is the same command with the Windows executable and a backslash path to the Lua script. To use it you edit the last line of pumpkin.bat or pumpkin.sh accordingly.

Two things in that command line are informative. The -d 1 flag turns on debug level one, and the -s libscriptlua argument points at the Lua scripting library with the script/pumpkin.lua file, which tells you that the system's startup behaviour is driven by a Lua script rather than only by compiled C code. The script directory in the repository root is where that lives.

So the debugging story is coherent even at version 0.0.2: run it, read the log, and if that is not enough, attach gdb to the process with the Lua script visible in the arguments.

Version 0.0.2 and a licence directory for components

The release history is short. There are two tagged versions, v0.0.1 from 2025-11-06 and v0.0.2 from 2026-02-28, and the last push to the repository was on 2026-10-20. Nothing here suggests a monthly release cadence, and the 0.0.x numbering says plainly that the project considers itself early.

For a project at this stage, what you get from the repository is more valuable than what you get from the release tags, because the code moves between them without new tags. If you clone the master branch you get the current state of the work, including whatever fixes have landed since v0.0.2.

The licensing needs a paragraph of its own. PumpkinOS is licensed under the GPL v3, and the licence directory contains information on the specific licences of the various components used in PumpkinOS. The documentation explicitly invites corrections if something looks missing or wrong, which is an unusually open way to handle a component licence inventory.

Why this matters is that a re-implementation of an operating system is assembled from other people's code: windowing and audio code, compression, scripting libraries, and so on. A single GPL v3 file at the root tells you how the project as a whole is licensed, and the directory tells you what the borrowed pieces are licensed under. If you intend to redistribute a build, that directory is the document to read, and your counsel should confirm the position rather than infer it from the root licence alone.

Editorial conclusion

PumpkinOS suits an engineer or retro computing hobbyist who wants to run PalmOS applications on a modern machine without hunting for a ROM image, and who is comfortable compiling a C project with make, gcc and SDL2 development headers. It is the wrong choice for anyone who wants the PalmOS experience as it shipped, because the four classic PIM applications are not in the release and the shell is described as experimental, and it is the wrong choice for a casual user, since there is no installer and no package for any platform. Verify three things before you start: that the applications you care about are either included as PRC files or compilable from source, that your platform has the SDL2 development package available, and that the version you clone is the one you want, since the project is at 0.0.2 and still expects a few issues.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. migueletto/PumpkinOS on GitHub
4. README
5. Releases