08.10.2026 · Signal Titans Editorial
Dennis Ritchie entwickelte C, damit Unix leichter portierbar wurde
Anfang der 1970er Jahre versuchte Dennis Ritchie nicht, eine universelle Programmiersprache für die gesamte Softwarebranche zu erfinden. Bei Bell Labs arbeitete er an einem konkreteren Problem: Wie lässt sich ein Betriebssystem weiterentwickeln, ohne jede wichtige Idee an genau einen Maschinentyp zu binden?
Die Antwort wurde C. Seine Bedeutung wird oft damit erklärt, dass viele spätere Sprachen von C beeinflusst wurden und Unix in C neu geschrieben wurde. Beides stimmt. Die tiefere Geschichte handelt jedoch von Portabilität. Eine Systemsprache erlaubte es, immer größere Teile eines Betriebssystems aus maschinenspezifischem Assembler herauszulösen.
Ritchie beschrieb C später als eine Sprache, die zwischen 1969 und 1973 parallel zum jungen Unix entstand. Sie wurde nicht an einem Tag fertig entworfen. Sie entwickelte sich aus BCPL und B, aus den Grenzen der verfügbaren Hardware und aus den praktischen Anforderungen eines Teams, das eine angenehme Arbeitsumgebung bauen wollte.
Bell Labs nach Multics
Bell Labs war an Multics beteiligt gewesen, einem ambitionierten Timesharing-Projekt. Ende der 1960er Jahre zog sich das Unternehmen zurück, weil Kosten und Fortschritt nicht mehr zu den Erwartungen passten. Ken Thompson und andere Forscher wollten dennoch ein interaktives System nach ihren eigenen Vorstellungen.
Sie experimentierten zunächst auf einer ungenutzten PDP-7. Das frühe Unix entstand unter starken Einschränkungen. Speicher war knapp und die Hardware sehr spezifisch. Assembler bot direkten Zugriff auf die Maschine, band den Code aber eng an den Prozessor.
Mit dem Wechsel auf die PDP-11 entstand die Gelegenheit, diese Abhängigkeit neu zu betrachten. Eine höhere Sprache konnte die Systementwicklung vereinfachen, wenn sie trotzdem genügend Kontrolle für Betriebssystemcode zuließ.
Von B zu C
Thompson hatte B entwickelt, beeinflusst von BCPL. Die Sprache war klein und praktisch, doch die PDP-11 und Unix stellten neue Anforderungen. Ritchie ergänzte Typen und weitere Eigenschaften, damit die Sprache reale Maschinendaten besser darstellen konnte. Besonders 1972 veränderte sich das Design schnell.
C war kein theoretisches Projekt, das auf maximale Eleganz zielte. Es war eine technische Antwort auf eine konkrete Umgebung. Die Sprache blieb hardwarenah genug für Systems Programming, war aber abstrakt genug, damit ein Compiler denselben Quellcode für andere Prozessoren übersetzen konnte.
Diese Balance erwies sich als erstaunlich langlebig. Pointer, direkter Speicherzugriff und vorhersehbare Datenrepräsentationen standen neben Funktionen, strukturiertem Kontrollfluss und einer portableren Programmierebene.
Warum die Unix-Neuschreibung so wichtig war
Ein Betriebssystem, das fast vollständig in Assembler geschrieben ist, muss für eine neue Architektur weitgehend überarbeitet werden. Als große Teile von Unix in C ausgedrückt wurden, schrumpfte der maschinenabhängige Anteil.
Unix wurde dadurch nicht automatisch überall lauffähig. Für jede Plattform waren weiterhin Compiler nötig, Hardwareunterschiede blieben bestehen und manche Teile mussten angepasst werden. Aber der Aufwand eines Ports veränderte sich grundlegend. Unix konnte realistischer auf neue Systeme übertragen werden und verbreitete sich dadurch leichter in Universitäten, Forschung und später im kommerziellen Umfeld.
C und Unix verstärkten einander. Unix war für C ein anspruchsvoller Praxistest. C gab Unix einen Weg zu neuer Hardware.
Eine Sprache aus Randbedingungen
Aus heutiger Sicht wirkt C manchmal gefährlich offen. Die Sprache gibt Programmierern viel Kontrolle und nur wenige Sicherheitsgeländer. Im ursprünglichen Kontext ist das verständlicher. Die Entwickler bauten Systemsoftware auf Rechnern, bei denen Speicher, Geschwindigkeit und einfache Compiler entscheidend waren.
Sie optimierten nicht für Einsteiger, Managed Runtimes oder Internet-Anwendungen. Sie wollten maschinennahe Programmierung weniger an eine bestimmte Maschine binden, ohne die Maschine selbst zu verstecken.
Darum bedeutet die Übernahme der C-Syntax noch lange nicht die Übernahme ihres Zwecks. Viele spätere Sprachen verwendeten ähnliche Klammern und Operatoren, trafen aber völlig andere Entscheidungen bei Speicherverwaltung, Typen und Sicherheit.
Von Praxis zur Standardisierung
Mit der Verbreitung von C entstanden unterschiedliche Compiler und Dialekte. Das 1978 veröffentlichte Buch The C Programming Language von Brian Kernighan und Dennis Ritchie wurde zur weithin verwendeten Beschreibung. Die formale ANSI-Standardisierung folgte erst in den 1980er Jahren.
Diese Reihenfolge ist bemerkenswert: C bewährte sich zunächst im echten Betriebssystem und bei echten Anwendern. Der Standard kam nach der Verbreitung. Praktische Nutzung formte die Sprache, bevor ein Komitee die Schnittstelle stabilisierte.
Ritchies bleibender Einfluss
Ritchie erhielt 1983 gemeinsam mit Ken Thompson den ACM Turing Award für Arbeiten zu Betriebssystemen und Unix. Der Einfluss von C reicht jedoch weiter. Betriebssystem-Kernel, eingebettete Systeme, Datenbanken, Compiler und zahllose Bibliotheken basieren weiterhin auf C oder auf Schnittstellen, die aus der C-Welt stammen.
Die wichtigste Lehre ist nicht nur, dass „C überall ist“. Eine sinnvoll gewählte Abstraktionsebene kann bestimmen, ob Software ihre ursprüngliche Hardware überlebt. Code sollte nicht stärker als nötig an eine Maschine gebunden sein, aber auch nicht so weit von ihr entfernt, dass die eigentliche Aufgabe unmöglich wird.
Ritchie wollte keine Sprache für jeden zukünftigen Computer bauen. Er half, eine Sprache zu schaffen, mit der ein wichtiges System seine erste Maschine verlassen konnte. Das war genug, um die Branche zu verändern.
SIGNAL TITANS