Dennis Ritchie: Wie C Unix portabel machte

Am 9. September 2026 jährt sich Dennis Ritchies Geburtstag zum 85. Mal. Seine Arbeit an C und Unix veränderte, wie Software zwischen Rechnern wechseln konnte. Portabler Code bedeutete dabei nie, dass überall dieselbe Datei läuft.

Stell dir vor, du gibst jemandem eine Diskette mit deinem Programm. Der andere Rechner hat einen anderen Prozessor, ein anderes Betriebssystem und andere Regeln für Dateien. Was hast du weitergegeben: ein startfähiges Programm, einen brauchbaren Bauplan oder den Beginn einer aufwendigen Neuentwicklung? An dieser Frage lässt sich Dennis Ritchies Leistung besser verstehen als an einer langen Liste berühmter Geräte.

Das Heidelberg Laureate Forum nennt den 9. September 1941 als seinen Geburtstag. Heute liegt dieser Tag 85 Jahre zurück. Auch der Nerd-Kalender erinnert an den Anlass. Uns interessiert dabei, welcher Teil der Arbeit erhalten bleibt, wenn der ursprüngliche Computer verschwindet.

C und Unix übernehmen verschiedene Aufgaben

C ist eine Programmiersprache. Mit ihr beschreibt man Abläufe, die ein Compiler übersetzen kann. Unix ist ein Betriebssystem: Es verwaltet Ressourcen und stellt Programmen Dienste bereit. Wer beides gleichsetzt, übersieht gerade das Interessante an der Verbindung. Eine Berechnung braucht den Typ des Festplattenlaufwerks nicht zu kennen. Ein Betriebssystem kann Dateizugriffe ermöglichen und dabei viele technische Einzelheiten verbergen.

Das Computer History Museum würdigt Ritchie als Entwickler von C und gemeinsamen Schöpfer von Unix mit Ken Thompson. Es verortet diese Arbeit in den frühen 1970er-Jahren bei Bell Labs. Die Geschichte handelt von Zusammenarbeit an einem System, nicht von einem Einzelnen, der sämtliche Computerschichten erfand.

Ein Programm verbindet mindestens drei Entscheidungen: Was soll berechnet werden? Wie werden Dienste angefordert? Welche Maschinenbefehle führen die Arbeit aus? Diese Entscheidungen können so eng zusammenhängen, dass jede Änderung alles berührt. Man kann sie aber auch so weit trennen, dass beim Austausch einer Ebene ein großer Teil der übrigen Arbeit bestehen bleibt.

Die Neufassung von 1973 war kein Zauberschalter

Ritchie und Thompson datieren die Neufassung in C in ihrem Unix-Fachartikel auf den Sommer 1973. Die archivierte Fassung ist die Überarbeitung von 1978 des Artikels von 1974. Sie beschreibt ein verständlicheres und leichter veränderbares System, das dafür mehr Platz benötigte.

Schreibt man einen Betriebssystemkern in einer höheren Sprache, verschiebt sich die Arbeit. Assemblersprache folgt eng den Befehlen eines Prozessors. In C lassen sich Funktionen, Daten und Kontrollfluss beschreiben; viele Entscheidungen über einzelne Maschinenbefehle übernimmt der Compiler. Der Rechner bleibt relevant. Seine Routinedetails müssen nur seltener unmittelbar im eigentlichen Programmtext stehen.

Portabilität war dabei nicht von Anfang an der große Plan. Ritchie erklärt in seiner Geschichte der Sprache C, dass dieses Interesse später entstand. C entwickelte sich aus B; die kreativste Phase lag 1972. Aus einer besseren Arbeitsumgebung wurde etwas, das sich weitertragen ließ.

Portabler Quellcode ist keine universelle Programmdatei

Zurück zur Diskette. Darauf kann Quellcode liegen, also ein lesbarer Text in C. Oder eine ausführbare Datei, die bereits für eine bestimmte Zielumgebung übersetzt wurde. Das ist ein erheblicher Unterschied. Ein passender Compiler kann aus geeignetem Quellcode andere Maschinenbefehle erzeugen. Das bloße Kopieren der fertigen Datei erledigt diese Übersetzung nicht.

Nehmen wir ein kleines Programm, das Temperaturen einliest und den niedrigsten Wert bestimmt. Seine Vergleichslogik muss nichts über eine Grafikkarte wissen. Nutzen Ein- und Ausgabe Funktionen, die in beiden Umgebungen verfügbar sind, lässt sich derselbe Quelltext möglicherweise für beide übersetzen. Kommt ein Fenster aus einer plattformspezifischen Grafikbibliothek hinzu, entsteht eine weitere Abhängigkeit.

Eine erfolgreiche Übersetzung ist außerdem nur eine Zwischenstation. Bibliotheken, Eingabeformate und erwartetes Verhalten müssen ebenfalls passen. Eine Datei lässt sich vielleicht öffnen, enthält ihre Zahlen aber in einem ungeeigneten Format. Zwei Programme können beide starten und die Daten trotzdem unterschiedlich interpretieren. Deshalb gehört zur Portabilität immer die Prüfung des Ergebnisses.

Wo sich der alte Rechner im Programm versteckt

Um ein Programm zu beurteilen, hilft die Suche nach seinen Annahmen über die Umgebung. Drei Stellen sind besonders aufschlussreich:

• Darstellung der Daten. Wird eine bestimmte Ganzzahlgröße vorausgesetzt? Speichert das Programm eine Struktur als rohe Speicherkopie? Ein festgelegtes Austauschformat ist etwas anderes als die Anordnung im Arbeitsspeicher.
• Dienste des Betriebssystems. Woher kommen Dateien, Uhrzeit, Eingaben und andere Ressourcen? Eine überschaubare Schnittstelle lässt sich leichter anpassen als verteilte Plattformaufrufe in jeder Funktion.
• Direkter Hardwarezugriff. Wer unmittelbar mit einem Gerät spricht, muss dieses Gerät verstehen. Eine klare Grenze bündelt die Anpassungen, sie lässt sie nicht verschwinden.

Das ist unsere praktische Lesebrille für Programmcode, keine Behauptung über sämtliche historischen C-Programme. Eine Sprache eröffnet Möglichkeiten zur Trennung. Nutzen müssen sie die Entwickler. Sehr kurzer Code kann voller stiller Voraussetzungen stecken. Etwas längerer Code kann seine Erwartungen dagegen so deutlich formulieren, dass andere Menschen sie prüfen können.

Der eigentliche Gewinn: menschliche Arbeit bewahren

Stephen C. Johnson und Ritchie dokumentieren in ihrer Portabilitätsstudie von 1978 den Wechsel auf die Interdata 8/32. Ihr Maßstab ist die eingesparte Arbeit gegenüber einer Neuentwicklung. Große Teile des Quellcodes blieben gemeinsam nutzbar; technische Anpassungen gehörten weiterhin dazu.

Genau dieser Maßstab macht das Thema greifbar. Entscheidend ist nicht, dass überhaupt nichts mehr angepasst werden muss. Entscheidend ist, dass bereits erarbeitete Lösungen erhalten bleiben: Algorithmen, Entscheidungen und das Wissen darüber, wie ein Problem sinnvoll zerlegt wird. Ein neuer Rechner sollte nicht automatisch bedeuten, dieselbe Frage noch einmal von Grund auf beantworten zu müssen.

Daneben lohnt sich unser Beitrag über Steve Wozniaks Computerentwürfe. Die beiden Geschichten öffnen unterschiedliche Designfragen: Wie wird ein Rechner zugänglich? Und wie verhindert man, dass brauchbare Software dauerhaft an genau diesen Rechner gebunden bleibt?

Diesen Beitrag in anderen Sprachen lesen: Englisch · Spanisch · Französisch.

Eine kleine Aufgabe zum Geburtstag

Für ein eigenes Experiment brauchst du kein Betriebssystem zu portieren. Nimm ein kleines Programm, das du verstehst. Notiere die erwarteten Ein- und Ausgaben und suche eine Annahme über seine Umgebung. Das kann ein Verzeichnispfad sein, eine Zeichencodierung oder eine bestimmte Bildschirmbibliothek.

Ziehe diese Annahme an eine klar benannte Stelle. Falls eine zweite Umgebung verfügbar ist, übersetze das Programm dort und vergleiche die Ergebnisse anhand derselben Beispiele. Andernfalls halte fest, was beim Wechsel geprüft werden müsste. Damit ist noch keine universelle Portabilität bewiesen. Aus einem unbestimmten Wunsch wird aber eine konkrete, überprüfbare Aufgabe.

Zum 85. Geburtstag Dennis Ritchies ist das eine passende Würdigung: ein Stück Wissen leichter weitergeben können. C und Unix haben die Unterschiede zwischen Computern nicht abgeschafft. Ihre Geschichte zeigt, welchen Wert es hat, die Kosten dieser Unterschiede zu senken.