1984: Das X Window System braucht Cursor

Die Geschichte von XBM beginnt am Massachusetts Institute of Technology (MIT). 1984 arbeitete eine Forschungsgruppe um Robert Scheifler und Jim Gettys am X Window System — einer netzwerkfähigen Fenster-Verwaltung für Unix-Maschinen, die Anwendungen auf einem zentralen Server laufen lassen und auf verschiedenen Workstation-Bildschirmen anzeigen konnte. X wurde später zum De-facto-Standard für Unix-GUIs und ist bis heute (über X11 und Wayland) die Grundlage von Linux-Desktops.

X brauchte ein Bildformat für Cursor und kleine UI-Symbole. Die Anforderungen waren ungewöhnlich:

  • Plattform-unabhängig. X lief auf Sun, DEC, IBM, HP und vielen anderen Workstations mit unterschiedlichen Byte-Reihenfolgen. Ein binäres Format mit Endianness-Problemen kam nicht in Frage.
  • In C-Quelltext einbettbar. Cursor-Daten sollten direkt in X-Anwendungs-Code als statische Arrays eingebunden werden können.
  • Einfach zu editieren. Per Text-Editor änderbar, ohne spezielle Bildverarbeitungs-Software.

XBM: 1-Bit-Cursor als C-Code

Das Resultat war X BitMap (XBM). Eine XBM-Datei ist tatsächlich C-Quelltext. Beispiel: ein 16×16-Cursor sieht so aus:

#define cursor_width 16
#define cursor_height 16
static unsigned char cursor_bits[] = {
  0x00, 0x00, 0x18, 0x00, 0x3c, 0x00, 0x7e, 0x00,
  0xff, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x00,
  0x18, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x00,
  0x18, 0x00, 0x18, 0x00, 0x18, 0x00, 0x00, 0x00 };

Das war elegant: das XBM ist gleichzeitig eine Bild-Datei und ein einkompilierbares C-Header-File. Ein X-Programmierer konnte ein Cursor-Bild mit einem Mal-Programm erstellen, als XBM speichern und es direkt per #include in den Source-Code des Programms einbinden. Kein separater Decoder, keine Datei-IO zur Laufzeit — die Cursor-Daten landeten direkt im Binär.

1989: XPM kommt für mehr Farbe

XBM war auf 1 Bit pro Pixel beschränkt — schwarz oder weiß, kein Grau, kein Farbton. Für die ersten X-Cursor war das ausreichend, aber als Bildschirme komplexer wurden (4-Bit-Grau, 8-Bit-Farbe, später 24-Bit-Truecolor), brauchte X ein erweitertes Format.

1989 entwickelten Daniel Dardailler und Colas Nahaboobei Bull Research das X PixMap (XPM)-Format. XPM behält die textbasierte C-Source-Code-Architektur von XBM, erweitert sie aber um Farbpaletten und mehrere Color-Modes (monochrom, Grayscale, Color, Symbolic).

Eine XPM-Datei für ein kleines 4-Farb-Icon sieht zum Beispiel so aus:

/* XPM */
static char *icon[] = {
  "8 8 4 1",
  " 	c None",
  ".	c #000000",
  "+	c #FF0000",
  "@	c #FFFFFF",
  "..++++..",
  ".++@@++.",
  "+@@@@@@+",
  "+@@..@@+",
  "+@@..@@+",
  "+@@@@@@+",
  ".++@@++.",
  "..++++.." };

Jeder Pixel wird durch ein ASCII-Zeichen repräsentiert, die Farbzuordnung steht im Header. Das Format ist wie eine textuelle Pixel-Art-Notation — direkt im Texteditor editierbar, ohne dass man Hex-Werte umrechnen muss.

Unix-Adoption und Linux-Distributionen

XBM und XPM wurden zur De-facto-Standardformaten in Unix-Anwendungen. Tausende von X-Apps speicherten ihre Icons als XPM-Dateien: xeyes, xclock, xterm, viele Window-Manager (twm, fvwm, WindowMaker) und die ersten Desktop-Environments (CDE, später GNOME 1.0 und KDE 1.0).

Linux-Distributionen erbten diese Tradition. Eine Tour durch /usr/share/icons/auf einer alten Slackware- oder Debian-Installation zeigt unzählige XPM-Dateien. Anwendungen wie xfig (Vektor-Zeichen-Software für Unix) hatten umfangreiche XPM-Bibliotheken.

1990er: Erste Webbrowser unterstützen XBM

Eine bemerkenswerte Episode: die ersten Web-Browser (NCSA Mosaic, Netscape Navigator 1.0) unterstützten XBM als eines der Bildformate. Web-Designer in der Anfangszeit des Webs konnten kleine schwarz-weiße Icons als XBM einbetten — und der Browser zeigte sie an. Diese Unterstützung verschwand mit dem Aufstieg von GIF (siehe unsere GIF-Geschichte) und später JPG.

Aktuelle Browser unterstützen XBM nicht mehr. Firefox war einer der letzten Browser, der XBM rendern konnte; in modernen Firefox-Versionen ist die Unterstützung entfernt.

2000er: PNG verdrängt XPM

Mit dem Aufkommen von PNG (siehe unsere PNG-Geschichte) verlor XPM auch in der Unix-Welt seine Position. PNG bot bessere Komprimierung, 24-Bit-True-Color, echten Alpha-Kanal und war binär — also kleiner und schneller zu dekodieren. Moderne Linux-Desktop-Umgebungen (GNOME 2.0 ab 2002, KDE 4.0 ab 2008) wechselten zu PNG für Icons; SVG kam später für skalierbare Variants dazu.

XPM überlebt aber in spezifischen Nischen. Einige Open-Source-Programme nutzen XPM weiter, weil die Migration zu PNG keinen technischen Vorteil bringt: das Programm startet, hat ein einzelnes 32×32-Icon, und ein XPM-Header reicht. Auch Bitmap-Editor-Lehrwerkzeuge für Computer-Science-Kurse nutzen XBM/XPM, weil das textbasierte Format Konzepte wie Pixel-Daten und Komprimierung anschaulich macht.

XBM/XPM 2026: lebendiges Legacy

Die Formate sind 2026 in einer interessanten Position: nicht mehr aktiv genutzt für neue Inhalte, aber auch nicht aus der Welt. Eine Linux-Distribution wie Debian enthält immer noch tausende XPM-Dateien, weil viele alte Anwendungen sie nutzen und niemand die Migration durchführt. GIMP, ImageMagick, GTK+ und Qt unterstützen XBM und XPM weiterhin — Migrieren ist eine kontinuierliche Wartungs-Aufgabe, kein Notfall.

Für moderne Web- oder Foto-Anwendungen sind XBM und XPM irrelevant. Wer eine XBM/XPM-Datei vorfindet, kann sie mit GIMP oder ImageMagick zu PNG konvertieren — was 5 Sekunden dauert und das Asset web-tauglich macht.

Was wir von XBM/XPM lernen

  • Plattform-Unabhängigkeit ist mächtig. Ein textbasiertes Format funktioniert auf jeder Maschine, jeder Byte-Reihenfolge, mit jedem Texteditor. XBM hat 40 Jahre überlebt.
  • Source-Code-Einbettung war revolutionär. Die direkte Integration in C-Programme erlaubte eine elegante Asset-Pipeline, die heute mit JavaScript-Asset-Bundlern wieder relevant ist.
  • Einfache Formate haben lange Lebensdauer. Der gesamte XBM-Decoder ist 50 Zeilen C-Code. Solche Formate werden nicht obsolet.

Wann XBM/XPM die richtige Wahl ist

  • Embedded C/C++-Projekte. Direkte Einbettung von kleinen Cursor- oder Icon-Bildern als statische Arrays.
  • Lehr-Beispiele für Bildformate. Textbasierte Architektur macht Konzepte verständlich.
  • Linux-Legacy-Anwendungen. Wenn die Software XPM erwartet, bleibt es die Wahl.
  • Pixel-Art als Source-Code-Asset. Manche Indie-Game-Entwickler nutzen XPM-ähnliche Notationen für kleine Pixel-Art-Sprites.

Wann XBM/XPM nicht ideal ist: Web-Auslieferung (kein Browser-Support), moderne Anwendungen mit Alpha-Transparenz, Foto-Inhalte (XPM ist auf wenige Farben beschränkt), alles, was nicht spezifisch Unix-Legacy oder didaktisch ist.

Quellen

Wikipedia — X BitMap · Wikipedia — X PixMap · X.Org Foundation · FileFormat.Info — XBM · FileFormat.Info — XPM · ImageMagick — Format Support für XBM/XPM · Scheifler, R. & Gettys, J., „X Window System: The Complete Reference to Xlib", Digital Press 1992.