Programar Palm OS en 2026: aún compila

0:00 / 24:06 1×

Más formatos

1. Un archivo de Palm OS que llevaba 25 años en un cajón

En octubre de 2026, el desarrollador sueco Aaron Ardiri publicó en GitHub dev-palmos, un archivo de más de un gigabyte con lo que acumuló mientras programaba para Palm OS: kits de desarrollo, manuales, transparencias de conferencias, utilidades y hasta una parte del código fuente del sistema que Palm distribuyó a los desarrolladores a finales de los noventa.

No lo hizo por nostalgia. Lo hizo porque alguien le abrió un pull request en el repositorio donde tenía el código de su clon de Lemmings para Palm OS. El parche añadía soporte para la pantalla HiRes+ del Tungsten T3, un dispositivo de 2003. Ardiri llevaba dos décadas convencido de que aquello era arqueología y resultó que había gente jugando y mejorando sus juegos en hardware de hace veinte años.

Ese detalle resume el post: una plataforma que murió comercialmente en 2011 y que sigue teniendo comunidad, emuladores y desarrollo nuevo en 2026. Y un archivo de herramientas que, sin él, se habría quedado en una copia sin destino.

Cuando vi el repositorio me acordé de mi propia etapa: yo no programé Palm OS en C con CodeWarrior, sino con CASL, un entorno de desarrollo visual con el que hice un sistema de reservas de hotel. De eso también va esto: de lo que había dentro de un Palm, de por qué se programaba así y de por qué una plataforma que llegó a dominar el bolsillo desapareció.

2. SDK, manuales y código fuente: lo que trae el archivo

El repositorio no es una colección curada con criterio de museo: es un volcado sin adornos de carpetas de trabajo, con duplicados, versiones intermedias y material que solo tiene sentido en su contexto original. Eso, que en un archivo oficial sería un defecto, aquí es el valor: se ve cómo trabajaba un desarrollador de verdad.

2.1 Mapa de las siete carpetas

Composición del repositorio por carpetas, contada sobre el tree de Git: 1.408 entradas, de las que 1.311 son ficheros. Los SDK y la documentación son el 71 % del total.

Los SDK de fabricante son la parte que más se pasa por alto y la que mejor explica la época: Tapwave Zodiac (consola portátil con Palm OS), Garmin iQue 3600 (GPS), Handspring Treo 600, AlphaSmart Dana (un portátil de bajo consumo para aulas), el malogrado Palm Foleo y la ALP Sandgate VP de ACCESS. Cada uno traía sus extensiones propietarias, y un desarrollador que quisiera vender en todos esos dispositivos tenía que probar en todos.

También hay material de certificación, que hoy suena entrañable: Palm tenía un programa de certificación para desarrolladores, con examen y temario, como si fuera un fabricante de sistemas operativos con ecosistema serio. Lo era.

2.2 Lo que no está, y por qué importa

El README detalla las ausencias: no hay imágenes de ROM, ni firmware, ni binarios de emuladores, ni aplicaciones comerciales. Es una decisión deliberada para no distribuir propiedad ajena, y es la razón por la que el archivo se puede publicar sin que GitHub reciba una reclamación el primer día.

Tampoco hay licencia. El repositorio no es open source: cada fichero conserva los derechos de su autor original y las condiciones con las que se distribuyó en su momento. Que esté en GitHub no convierte un SDK de 1999 en software libre. Si vas a usar algo de ahí para un proyecto, mira qué es y de dónde viene.

Antes de reutilizar código del archivo: los SDK, las cabeceras y parte del código fuente se distribuyeron con licencias de desarrollo, no como dominio público. El propio repositorio avisa de que la inclusión no concede derechos de redistribución ni de explotación comercial. Para estudiar, investigar o emular tu propio dispositivo, adelante; para publicar un derivado, lee primero el fichero que acompaña al material.

GitHub calcula 1,13 GB de repositorio, contando el historial comprimido. Si descomprimes los ZIP, los ficheros suman alrededor de 1,8 GB. La diferencia entre las dos cifras es una buena lección sobre cómo se mide el tamaño de un archivo: lo que ocupa en disco no es lo que ocupa en la red.

3. ¿Qué era Palm OS? Un sistema para encender, usar y apagar

Palm OS fue el sistema operativo de los asistentes personales que popularizaron la informática de bolsillo entre 1996 y 2005. No era un Windows pequeño ni un UNIX recortado: era un sistema escrito desde cero para un dispositivo que se enciende, hace una cosa y se apaga. Esa restricción autoimpuesta es la clave de su éxito y, años después, de su caída.

3.1 Un ordenador de bolsillo con 16 MHz y dos pilas AAA

El primer Pilot salió en marzo de 1996, fabricado por Palm Computing, entonces filial de U.S. Robotics. Llevaba un Motorola 68328 DragonBall a 16 MHz —un primo hermano del 68000 del Mac—, 128 KB de RAM en el modelo 1000 y 512 KB en el 5000, una pantalla táctil monocroma de 160×160 píxeles y dos pilas AAA que duraban semanas.

La ficha técnica parece una broma comparada con cualquier móvil actual, y sin embargo esos números explican todo el diseño del sistema:

• 160×160 píxeles obligaban a decidir qué información era imprescindible. No cabía una barra de herramientas, ni un menú de diez opciones, ni un formulario con veinte campos a la vez.
• La memoria era un recurso escaso y explícito. No había malloc y free al uso: se pedían bloques con MemHandleNew, se bloqueaban para usarlos y se liberaban a mano. Cada byte tenía dueño.
• El almacenamiento era una base de datos de registros, no un sistema de ficheros. Una aplicación era un .prc con recursos; sus datos, un .pdb con registros. Esto permitía arrancar rápido y sincronizar por diferencias.
• La pantalla se apagaba, la CPU entraba en reposo y el usuario no esperaba. Una operación de más de medio segundo se notaba. El sistema estaba diseñado para responder, no para hacer varias cosas a la vez.

Ese contexto también explica por qué el software de Palm OS solía ser pequeño y directo. Si vienes del mundo actual, donde un framework pesa más que todo el Palm OS, el contraste es brutal. Es la misma disciplina que cuento en Goose, el lenguaje sin heap: sin asignación dinámica, el diseño cambia de sitio.

3.2 La línea temporal: del Pilot a webOS

Quince años de plataforma: el crecimiento (1996–2000), la fragmentación (2001–2005) y la caída (2006–2011).

Los hitos que importan para entender el resto:

• 1996. Pilot 1000 y 5000 con Palm OS 1.0. En la campaña de Navidad de ese año ya tenían más del 70 % del mercado estadounidense de ordenadores de bolsillo.
• 1997–1999. PalmPilot Personal y Professional con Palm OS 2.0 y pantalla retroiluminada; Palm III con Palm OS 3.0 e infrarrojos; Palm V, el modelo delgado con batería recargable. La plataforma se licencia a terceros: Handspring, IBM (WorkPad), Sony (CLIE), Qualcomm.
• 2000. Palm controla en torno al 65 % de un mercado de 11,2 millones de unidades. Parecía imbatible.
• 2001–2002. Palm OS 4.0 llega a la serie m500. En enero de 2002 se anuncia PalmSource, la filial que se queda con el sistema operativo y lo licencia. Palm OS 5 (Garnet) salta a ARM, estrena el kernel MCK, sube a 320×320 y resuelve la compatibilidad con PACE, una capa que emula el 68k dentro del ARM.
• 2003. PalmSource se separa del todo y Palm se convierte en palmOne tras comprar Handspring. Sony abandona los CLIE. Tapwave lanza la Zodiac.
• 2004–2005. PalmSource anuncia Cobalt (Palm OS 6), que nunca llega a un dispositivo. ACCESS compra PalmSource en 2005. palmOne recupera el nombre Palm.
• 2006–2007. Los Treo con Windows Mobile conviven con los Palm OS. El iPhone se presenta en enero de 2007 y redefine la pregunta: ya no era «¿qué PDA compro?», sino «¿qué móvil me deja instalar cosas?».
• 2009–2011. webOS y el Pre llegan tarde y con un solo operador en Estados Unidos. HP compra Palm en 2010, mata el hardware en 2011 y vende webOS a LG en 2013. ACCESS cancela la Access Linux Platform en 2010.

3.3 Recursos, no ficheros

Merece la pena detenerse en el modelo de ejecución porque es lo que hace que el archivo siga siendo útil. En Palm OS, una aplicación es una base de datos de recursos con un tipo y un creador de cuatro caracteres. Los recursos tienen nombre de cuatro letras e identificador numérico: code, data, tFRM (formulario), tSTR (cadena), Tbmp (bitmap), tAIB (icono), MBAR (barra de menú), tver (versión).

Cuando instalas un .prc, el sistema no copia un ejecutable y lo lanza con un cargador. Convierte la imagen plana en una base de datos en RAM y ejecuta el recurso code 0. El código está partido en segmentos porque el 68k direcciona con 16 bits: cada recurso de código no podía pasar de 64 KB, y el enlazador repartía las funciones entre code 0, code 1, code 2… Ese límite condicionó la arquitectura de las aplicaciones durante años.

Y había un detalle que hoy sería impensable: la aplicación no tenía un heap del sistema operativo a su disposición. Tenía una pila pequeña, un heap dinámico de tamaño fijo y bases de datos. Si te pasabas, el dispositivo se reiniciaba.

4. CodeWarrior, GCC o CASL: tres formas de compilar para Palm OS

Alrededor de ese modelo de recursos creció un ecosistema de herramientas muy variado. El archivo de Ardiri lo documenta casi entero, y verlo junto ayuda a entender que «programar para Palm OS» no significaba una sola cosa.

Tres caminos al mismo .prc: el comercial, el libre y el RAD. Los tres acaban en un fichero con recursos y código 68k.

4.1 CodeWarrior y Constructor

La vía oficial era CodeWarrior for Palm OS, de Metrowerks, disponible para Mac y Windows. Era el mismo IDE y el mismo compilador que CodeWarrior Pro, con un añadido: un posenlazador llamado PilotRez que convertía la salida del enlazador en el formato de aplicación de Palm.

Al lado iba Constructor, un editor visual de recursos donde se dibujaban formularios, botones, listas, menús y alertas. Constructor generaba un fichero de cabecera con constantes para cada recurso, de modo que el código C podía referirse a un botón por su nombre simbólico y no por un número. Era el equivalente Palm de un editor de diálogos de Windows, y para mucha gente fue la razón de elegir CodeWarrior: se veía la pantalla antes de escribir una línea.

4.2 GCC, prc-tools y pilrc

La vía libre era el GNU PalmPilot SDK, que en la práctica era un GCC cruzado a m68k con una colección de utilidades. El flujo tenía más piezas y más oportunidades de equivocarse, pero funcionaba en Linux y en Windows con Cygwin, y no costaba dinero.

Un ciclo típico: m68k-palmos-gcc compilaba el C, pilrc convertía un fichero de recursos de texto en recursos binarios, obj-res partía el ejecutable en recursos code y data, y build-prc lo empaquetaba todo en el .prc final. Cada paso generaba ficheros intermedios con nombres crípticos, y el Makefile de ejemplo era el documento más leído de la comunidad.

4.3 CASL: la vía rápida (y mi sistema de reservas)

Yo llegué a Palm OS por una tercera puerta: CASL, Compact Application Solution Language, de CASLsoft. Su primer IDE salió en 1996 —el mismo año que el Pilot— y venía de un prototipo para PDAs con GEOS, así que no era un experimento: era un producto pensado para gente que quería hacer aplicaciones de negocio sin aprender C.

La propuesta era un entorno visual con editor de formularios, un lenguaje de alto nivel parecido a Pascal o Visual Basic con orientación a objetos, y dos modos de ejecución: p-code interpretado por un runtime pequeño, o CASLpro, que traducía el programa a C y lo compilaba con prc-tools y GCC para producir una aplicación nativa. Lo bueno: el mismo código fuente compilaba para Palm OS, Windows y, desde 2003, Pocket PC. Eso de «escribe una vez, ejecuta en todas partes» que ahora suena a marketing barato, entonces era la diferencia entre un proyecto viable y tres proyectos.

Con CASL desarrollé un sistema de reservas de hotel. Pantallas de alta de reserva, calendario de ocupación, ficha de cliente y consultas de disponibilidad. En el ordenador de recepción corría la versión de Windows; en la mano, un Palm con la aplicación. El puente era un conduit de HotSync: las reservas se sincronizaban entre la base de datos del dispositivo y la del escritorio cada vez que alguien ponía el PDA en la base.

Lo que recuerdo de aquellos años no es el lenguaje, sino las restricciones. El calendario de ocupación era el problema difícil: un mes entero en 160×160 píxeles, con el dedo o el lápiz, sin scroll infinito y sin poder permitirte un botón de más. Aprendí que en Palm OS se diseñaba la pantalla antes que el modelo de datos, porque la pantalla mandaba. Y aprendí a probar en el emulador antes de tocar el dispositivo, porque cada instalación fallida costaba un HotSync completo.

CASLsoft dejó de dar soporte en 2005 y publicó la versión 4.2 como freeware; después el producto pasó por otras manos y siguió vendiéndose para Android y Windows CE. Su web sigue en pie. Si te pica la curiosidad, CASL tiene artículo propio en Wikipedia y la documentación del fabricante todavía se puede descargar.

5. Anatomía de un .prc

Si el archivo de Ardiri sirve para algo práctico, es para esto: abrir un .prc y entender qué hay dentro. No hace falta un emulador ni un SDK; con un editor hexadecimal y veinte líneas de Python se ve la estructura completa.

5.1 La cabecera, campo a campo

Un .prc es una cabecera, una tabla de diez bytes por recurso y los datos. Nada más: por eso se puede leer con un script y por eso el formato sobrevivió veinte años.

La cabecera ocupa 78 bytes y empieza por el nombre, en 32 bytes terminados en cero. Después vienen los campos que de verdad importan:

Dos cosas sorprenden al mirarlo por primera vez. La primera: las fechas se cuentan desde el 1 de enero de 1904, herencia de la época de Macintosh. La segunda: el creador es un código de cuatro caracteres, como en Mac OS, que servía para que el sistema supiera qué aplicación abría un .pdb. Un fichero de contactos con creador addr lo abría la agenda; uno con jvAC, la aplicación de su autor.

5.2 Un lector de PRC en 30 líneas

Este script lee la cabecera y lista los recursos con su tamaño. Funciona con cualquier .prc o .pdb de la época, incluidos los del archivo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import datetime, struct, sys

EPOCH = datetime.datetime(1904, 1, 1, 0, 0, 0)

def stamp(seconds):
    return (EPOCH + datetime.timedelta(seconds=seconds)).strftime("%Y-%m-%d %H:%M")

data = open(sys.argv[1], "rb").read()
name = data[:32].split(b"\0")[0].decode("latin-1")
flags, version = struct.unpack(">HH", data[0x20:0x24])
created, modified, _backup = struct.unpack(">III", data[0x24:0x30])
kind = data[0x3C:0x40].decode("latin-1")
creator = data[0x40:0x44].decode("latin-1")
count, = struct.unpack(">H", data[0x4C:0x4E])

print(f"nombre     {name}")
print(f"versión    {version}   flags {flags:#06x}")
print(f"creado     {stamp(created)}")
print(f"modificado {stamp(modified)}")
print(f"tipo       {kind}   creador {creator}")
print(f"recursos   {count}")

records = []
for i in range(count):
    off = 0x4E + i * 10
    rname = data[off:off + 4].decode("latin-1")
    rid, roff = struct.unpack(">HI", data[off + 4:off + 10])
    records.append((rname, rid, roff))

ends = [r[2] for r in records[1:]] + [len(data)]
print("\n  tipo   id   bytes")
for (rname, rid, roff), end in zip(records, ends):
    print(f"  {rname:<6} {rid:>4} {end - roff:>7}")

Si se ejecuta sobre una de las utilidades del archivo, una tabla ASCII de 2000:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

nombre     AsciiChart
versión    203   flags 0x0001
creado     2000-06-25 15:08
modificado 2000-06-25 15:08
tipo       appl   creador jvAC
recursos   18

  tipo   id   bytes
  code      1    7780
  tFRM   1000    1440
  Tbmp   1000     640
  tAIB   1000     488
  ...
  data      0      51
  code      0      24
  tver   1000       6

Ahí está todo: el recurso code 1 con el código, los tFRM con los formularios, los Tbmp con los bitmaps, el data 0 con las variables globales y el tver con la versión. Dieciocho recursos, 13 KB, una aplicación completa de 2000.

Grabación real: descarga de un .prc del archivo y lectura de su cabecera con el script anterior. Los 78 bytes de cabecera explican por qué estas aplicaciones siguen siendo legibles sin herramientas especiales.

6. Cómo mirar el archivo sin descargar 1,8 GB

El repositorio completo pesa demasiado para un clon de cortesía. Git permite traerse el tree sin los ficheros y descargar solo la carpeta que te interese:

1
2
3
4
5

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/ardiri/dev-palmos.git
cd dev-palmos
git sparse-checkout set palmos-programming_recipies
du -sh palmos-programming_recipies

En esta máquina, el clon parcial ocupa 1,8 MB y la carpeta de recetas 916 KB con 32 ficheros. Frente a los 1,13 GB del repositorio completo, la diferencia es la de mirar el catálogo en vez de vaciar el almacén.

Para ver la estructura sin descargar nada:

1

git ls-tree -d --name-only HEAD

Y para inspeccionar un ZIP de SDK sin extraerlo:

1

unzip -l palmos-sdk/win32-palmos-sdk-4_0.zip | head -30

Grabación real: clon parcial del repositorio, listado de las siete carpetas y descarga de una sola. El objetivo es poder hojear el archivo sin esperar un gigabyte.

7. Emulador de Palm OS en el navegador: CloudpilotEmu

Lo mejor es que no necesitas el hardware. CloudpilotEmu emula dispositivos Palm OS en el navegador, como aplicación web instalable y también como app móvil. Para los modelos con DragonBall (Palm OS 1 a 4) se apoya en el histórico POSE; para Palm OS 5 usa uARM, el emulador de ARM de Dmitry Grinberg, y permite arrancar un Tungsten E2.

Los pasos, sin misterio:

1. Descarga una ROM compatible desde PalmDB, que mantiene una biblioteca de ROMs y de software para la plataforma.
2. Abre CloudpilotEmu, elige el modelo y arranca. La primera vez pide calibrar la pantalla, como el dispositivo real.
3. Instala un .prc arrastrándolo sobre la ventana del emulador, o desde el menú de almacenamiento.
4. Si el programa es antiguo y la pantalla es de 320×320 o 480×320, prueba a activar el modo HiRes o HiRes+; es exactamente el tipo de parche que alguien envió al Lemmings de Ardiri.

Lo que se ve no es un vídeo: es el sistema operativo ejecutándose, con su Graffiti, sus menús y su velocidad original. Y no es solo arqueología: en 2025 se publicó StarGrid, un juego nuevo para Palm OS escrito desde cero, y hay parches de alta resolución para aplicaciones de los noventa.

Si tienes un Palm físico, puedes extraer su ROM con herramientas como palmrom o volcarla desde el propio dispositivo, y usar esa imagen en el emulador. Es la forma más limpia de conservar tu unidad: la ROM sale de tu hardware, no de un sitio de descargas.

8. Programar Palm OS en 2026: una app de 1.174 bytes

Encontrar el archivo está bien. Comprobar que la cadena de herramientas sigue viva es otra cosa. Así que escribí una versión mínima de lo que fue mi sistema de reservas: una habitación, un campo para el cliente, un botón y un contador. Todo cabe en 160×160 y en 1.174 bytes.

8.1 Un toolchain de 2026 para un sistema de 1996

No hace falta CodeWarrior ni un Mac de los noventa. La cadena que uso es la que documentó Palm2000 y que cabe en una imagen de contenedor: un GCC 9.1 cruzado a m68k preparado por Dmitry Grinberg, las cabeceras del SDK 5r3 y PilRC 3.2 para los recursos.

1
2
3
4
5

podman run --rm \
  -v "$PWD/app:/palm/Src:Z" \
  -v "$PWD/artifacts:/artifacts:Z" \
  -e PRC_NAME=Reservas -e PRC_CREATOR=CPal \
  docker.io/knickish/palm_docker:latest

La imagen compila, pero no empaqueta el código: su Makefile llama a pilrc -ro y el .prc sale con los formularios y sin el binario. Escribí un empaquetador de sesenta líneas que arma la cabecera de 78 bytes, la tabla de recursos y los datos:

1
2
3
4
5
6
7
8

header = (
    name.encode("latin-1")[:31].ljust(32, b"\0")
    + struct.pack(">HHIII", 1, 1, now, now, 0)
    + struct.pack(">III", 0, 0, 0)
    + b"appl"
    + creator.encode("latin-1")[:4].ljust(4, b"\0")
    + struct.pack(">II H", 0, 0, len(resources))
)

Es la misma cabecera que lee el script de la sección 5, escrita al revés. El resultado pesa 1.174 bytes y lleva cuatro recursos: code, tFRM, tAIB y tAIN.

8.2 La pantalla y la lógica

El formulario se describe en un .rcp de PilRC, el equivalente a los recursos que CodeWarrior editaba con Constructor:

1
2
3
4
5
6
7
8
9
10
11
12

FORM ID 1000 AT (0 0 160 160)
  USABLE
BEGIN
  TITLE "Reservas"
  LABEL "Hotel Palau" AUTOID AT (CENTER 20) FONT 1
  LABEL "101 libre" ID 1002 AT (CENTER 42) FONT 1
  LABEL "Cliente:" AUTOID AT (12 62)
  FIELD ID 1001 AT (12 74 136 18) MAXCHARS 24 UNDERLINED SINGLELINE
  BUTTON "Reservar" ID 1003 AT (CENTER 104 80 20)
  LABEL "Reservas: 0 de 3" ID 1004 AT (CENTER 134)
  GRAFFITISTATEINDICATOR AT (140 22)
END

La lógica es un manejador de eventos como el de cualquier aplicación Palm: se abre el formulario, se dibuja, se atiende el botón y se actualizan las etiquetas.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

static void BookRoom(void)
{
	FormPtr frm = FrmGetActiveForm();
	FieldPtr fld;
	Char *guest;
	UInt16 booked = GetBooked();

	if (booked >= kMaxBookings) {
		SetLabel(LblStatusID, "No quedan plazas");
		return;
	}

	fld = (FieldPtr)FrmGetObjectPtr(frm, FrmGetObjectIndex(frm, FldGuestID));
	guest = FldGetTextPtr(fld);

	if (guest == NULL || guest[0] == '\0') {
		SetLabel(LblStatusID, "Falta el cliente");
		return;
	}

	booked++;
	SetBooked(booked);
	UpdateLabels(booked);
}

Dos detalles que resumen cómo era programar aquí:

• El enlazador no podía direccionar una variable global. Con -mpcrel, el acceso a .bss no cabe en un desplazamiento de 16 bits y el enlace falla con R_68K_PC16 against .bss. En vez de pelear con el script de enlazado, guardé el contador en un feature de Palm OS (FtrSet y FtrGet), un entero de 32 bits asociado a un creador. Sobrevive al cierre de la aplicación, como una preferencia.
• Hace falta un __Startup__ explícito en la sección .vectors que llame a SysAppStartup, ejecute PilotMain y llame a SysAppExit. Sin él, el .prc se instala y no arranca: el sistema no muestra ni un error.

8.3 El resultado

Grabación real del emulador, sin montaje: CloudpilotEmu con una ROM de Palm III, el .prc instalado por arrastre y la aplicación ejecutándose. Se ve el error de validación, la escritura con el teclado y dos reservas.

La aplicación aparece en el lanzador con su icono, como cualquier otra:

El lanzador del Palm III reconoce la aplicación nueva. El icono es una cama dibujada en 22×22 píxeles y un bit por píxel.

La validación se hace en el dispositivo, sin conexión: si el campo está vacío, la reserva no se crea. Es la misma lógica que tenía el sistema de hotel, solo que entonces la pantalla la dibujaba CASL.

9. Por qué desapareció Palm: un negocio partido en dos

La respuesta fácil es «el iPhone», y es una respuesta incompleta. Palm no murió por un producto, sino por una estructura de negocio que dejó de funcionar cuando el mercado cambió de pregunta. Se puede reconstruir en tres actos.

9.1 El negocio partido en dos

En 2002, Palm separó el sistema operativo del hardware: PalmSource se quedó con Palm OS y lo licenció a fabricantes; Palm (luego palmOne) se quedó con los dispositivos. La idea era imitar a Microsoft: cobrar por licencia a todo el mundo y dejar que otros compitieran por el hardware.

Sobre el papel, era razonable. En la práctica, creó dos empresas con incentivos distintos y ninguna con el control completo de la experiencia. PalmSource tenía que contentar a muchos fabricantes; palmOne tenía que competir con esos mismos fabricantes. Cuando llegó el momento de invertir en una plataforma nueva, ninguna de las dos tenía el tamaño ni la libertad para hacerlo sola.

Mientras tanto, el mercado se llenó de alternativas: Pocket PC con Windows Mobile, los BlackBerry de RIM para correo, Symbian en Europa. Palm OS seguía siendo excelente para gestionar una agenda, pero se quedaba corto en color, multimedia, navegador y, sobre todo, en telefonía.

9.2 Cobalt no llegó y el iPhone cambió la pregunta

Palm OS 6, Cobalt, se anunció en enero de 2004 con tecnologías que PalmSource había comprado a los restos de BeOS. Nunca salió en un dispositivo. Los fabricantes no lo adoptaron, Palm siguió vendiendo Garnet, y el sucesor basado en Linux —Access Linux Platform— se canceló en 2010 sin haber llegado a nada relevante.

Cuando Apple presentó el iPhone en 2007, la comparación dejó de ser entre PDAs. El iPhone no tenía Graffiti, ni stylus, ni HotSync: tenía un navegador de verdad, multitáctil y una tienda de aplicaciones que llegó en 2008. Palm respondió con webOS en 2009, un sistema técnicamente muy interesante —multitarea por tarjetas, notificaciones, Synergy— que llegó tarde, con un solo operador en Estados Unidos y sin el ecosistema de aplicaciones que ya tenía la competencia.

HP compró Palm en 2010 por 1.200 millones de dólares, presentó una tableta con webOS y mató el hardware un año después. LG se quedó con webOS en 2013 y lo recicló para sus televisores. Para entonces, la marca Palm ya era historia.

9.3 Lo que quedó

Quedó un sistema operativo que durante quince años hizo algo muy difícil: ejecutar aplicaciones de 1996 en hardware de 2005 sin recompilarlas. PACE, la capa de compatibilidad de Palm OS 5, emulaba el 68k dentro del ARM y dejaba que el código antiguo llamara a un sistema operativo nativo. La mayoría de las aplicaciones 68k no necesitaban reescribirse.

Eso explica por qué el archivo de Ardiri sigue siendo ejecutable: los .prc que hay dentro no son fósiles, son binarios que un emulador puede cargar hoy. Y explica también por qué la comunidad sigue viva: hay un formato estable, unas herramientas conocidas y un montón de software que nadie volvió a tocar.

10. Tres lecciones de Palm OS que siguen valiendo

Hay tres lecciones que se pueden aplicar sin nostalgia.

La restricción es una herramienta de diseño. Un calendario de reservas en 160×160 obliga a decidir qué es importante. En un móvil de 2026, con 6,7 pulgadas y 120 Hz, seguimos discutiendo lo mismo: qué se ve primero y qué se esconde. Palm tenía la respuesta porque no tenía elección.

La compatibilidad hacia atrás da tiempo, no futuro. PACE permitió a Palm vender durante años sin romper su catálogo. También le permitió posponer la decisión de reescribir la plataforma, y esa decisión llegó igual, tarde. Si tu sistema depende de que el código de hace una década siga funcionando, tienes un activo y una deuda al mismo tiempo.

La preservación es ingeniería, no coleccionismo. Un SDK sin documentación es un ZIP; una documentación sin SDK es un PDF. El valor está en el conjunto: herramientas, manuales, ejemplos y código que se puedan reconstruir. El archivo de Ardiri funciona porque incluye las cuatro cosas, incluidas las transparencias de conferencias donde se explicaba cómo se usaban.

Es la misma idea que aparece al mirar los compiladores de BASIC que siguen vivos: las plataformas no mueren cuando se apaga el último servidor, mueren cuando se pierde la cadena que permite volver a compilar.

11. Si tienes un disco de los noventa

El post empezó con un backup de hace 25 años. Si tú también tienes uno, este es el orden que funciona:

1. Identifica qué es. Nombre, plataforma, año, si es herramienta o aplicación. Un ZIP llamado palm no le sirve a nadie.
2. No lo limpies antes de copiarlo. Conserva el original tal cual: discos, imágenes, correos, notas. La limpieza viene después, sobre una copia.
3. Documenta cómo se usaba. Un Makefile con rutas absolutas y un README de dos líneas valen más que el código.
4. Publica las herramientas, no las ROMs. El material propio y el que se distribuyó públicamente, sí; el firmware y las aplicaciones comerciales, no.
5. Dilo. Un repositorio sin anuncio no existe. La comunidad de Palm OS se enteró del de Ardiri porque él lo contó.

12. Enlaces y vídeos de interés

12.1 Artículos

• Palm OS and the devices that ran it — la retrospectiva más completa que he encontrado, con el detalle técnico y el contexto de negocio.
• prc-tools — el toolchain libre que usaba CASL por debajo y que sigue siendo la vía para compilar C para 68k.
• Palm Programming: The Developer’s Guide — el libro de Rhodes y McKeehan en Internet Archive, con el CD de herramientas.
• Dmitry Grinberg — el desarrollador que recibió más de 50 dispositivos de Ardiri y que ha llevado Palm OS a hardware moderno.
• StarGrid — un juego nuevo para Palm OS en 2025, con su proceso de desarrollo contado.

12.2 Vídeos

Charla del Computer History Museum con Jeff Hawkins, Donna Dubinsky y Ed Colligan: cómo nació el Pilot y por qué la industria del bolsillo fracasó antes de acertar.

Demostración de CloudpilotEmu en el navegador: arranque de un Palm OS 68k, instalación de un .prc y uso real del sistema.