Bayern digital souverän
  1. Aktuelle Seite:  
  2. Startseite

Home

Die Geschichte von POSIX

Details
Geschrieben von: Dr. Torsten Thurow
Kategorie: Uncategorised
Veröffentlicht: 22. November 2025

Wo soll man die „Urzelle“ der IT sehen?

Ich persönlich finde, dies trifft auf den Z4 in erweiterter Form (1950) und den EDSAC (1949) zu.

Angestoßen wurden ihre Entwicklungen u.a. durch die Vorarbeiten von Konrad Zuse.

Konrad Zuse (1992), Von Wolfgang Hunscher, Dortmund - Eigenes Werk, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=620905

Dieser Tausendsassa baute zunächst 1937 den Z1, einen rein mechanischen Rechner, angetrieben von einem Staubsaugermotor, mit Laubsäge etc. unterstützt von seinen Freunden, seinem Vater, ja sogar seiner Theatergruppe. 1939 folgte der Z2 auf Relay-Basis, 1941 der Z3 und zwischen 1942 und 1945 der Z4.

Nachbau der Z1 im Deutschen Technikmuseum in Berlin, Von ComputerGeek - de.wikipedia.org: 22:33, 27. Dez 2005, ComputerGeek (Diskussion), CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=735841
Nachbau der Zuse Z3 im Deutschen Museum in München, Von Venusianer, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=3632073
Die Z4 im Deutschen Museum (München), Clemens PFEIFFER, CC BY 2.5

Am 14. Februar 1946 ging dann auch der ENIAC des US-Militärs an den Start.

ENIAC auf einem Bild der US-Armee, im Vordergrund Betty Holberton, im Hintergrund Glen Beck, Autor/-in unbekannt - U.S. Army Photo

Entgegen manchen Schilderungen / Behauptungen erfüllten diese Rechner aber noch nicht vollständig die Merkmale eines universell programmierbaren Rechners, also Turing-Vollständig. Was ihnen dazu noch fehlte: bedingte Sprünge und Speicher-Instruktionen. Dafür hatten die Rechner von Konrad Zuse vom Z1 an bereits Gleitkommazahl-Arithmetik!

Mit dem EDSAC in Cambridge kam aber 1949 endlich dieser Sprung, den man in der Biologie mit dem Übergang zum Leben bezeichnen könnte. Echt Turing-Vollständig. 1950 zog ein alter Z4 nach gründlicher Überholung und, das ist der entscheidende Punkt, Erweiterung für die ETH Zürich nach. In den 1950er Jahren setzte die Produktion kommerzieller (Serien-)Computer ein.

Foto der EDSAC-Schaltschränke, Copyright Computer Laboratory, University of Cambridge, CC BY 2.0

So stehen die „Dinosaurier“ der IT-Urzeit, Hallen füllende Großrechner auf Basis von Röhren, Relais, Lochkarten, Magnetbändern und Trommelspeichern vor uns, welche sich nur wenige Firmen und Universitäten leisten konnten. Aus dieser Zeit stammen heute alltägliche Begriffe wie der Bug.

Zwischenzeitlich erblickte 1947 der erste funktionstüchtige Bipolartransistor das Licht der Welt und auf seiner Grundlage entwickelte Texas Instruments 1958 den ersten integrierten Schaltkreis, die Grundlagen der Hardware-Weiterentwicklung in der IT.

Von ihnen sind dann die 1960er geprägt, DEC erscheint mit u.a. seinem PDP-1 (Programmed Data Processor 1). Und der wurde als erster „Minicomputer“ bezeichnet, da er „nur“ so groß wie zwei Kühlschränke war und von einer Person hochgefahren werden konnte. Auf diesen kommen wir gleich zurück.

PDP-1, Matthew Hutchinson, CC BY 2.0

Bei den Großrechnern der 50ger war jeder Programmlauf eine komplette Hardware-Neukonfiguration. 

Ende der 50ger änderte sich das. Nicht mehr der Mensch steuert die Maschine, sondern ein kleines Verwaltungsprogramm. Lochkarten wurden als Stapel (Batch) abgearbeitet. Job-Controller, die Vorläufer von Betriebssystemen, luden nacheinander Programme, übernahmen Ein- und Ausgabe. Fehlermeldungen wurden standardisiert. Dabei bildeten sich die Vorläufer unserer Geräte-Treiber, rudimentäre I/O-Routinen.

Genau nach diesen Prinzipien kam 1956 das GM-NAA Ein-/Ausgabesystem von General Motors und North American Aviation. Viele sehen in ihm das erste Betriebssystem der Welt.

In den 60gern kam darauf aufbauend der nächste Durchbruch. Rechenzeit war extrem teuer, also sollte ein Großrechner auch nie stillstehen. Bisher wurden Jobs nacheinander abgearbeitet, aber nun wurden mehrere Programme im Speicher gehalten und zwischen ihnen umgeschaltet. Richtig, der erste Herzschlag der Betriebssysteme, die Zeitscheibe war geboren, welche wir bis heute in fast allen Betriebssystemen haben, und mit ihr die Vorläufer der Scheduler.

Durch die parallele Abarbeitung der Programme entstanden aber nun auch als funktionale Folge:

  • Speicheraufteilung
  • CPU-Zuteilung
  • Pufferung von I/O
  • Spooling (Drucker und Ein-/Ausgabe wurden zwischengespeichert)

Und so kommen wir zu IBM OS/360 und … MULTICS

Ein IBM-System 360/20 (OS: OS/360) im Deutschen Museum, München, Ben Franske, CC BY 2.5

 

… und zur logischen Fortsetzung der Entwicklungskette: wenn wir schon mehrere Programme parallel laufen lassen, warum dann nicht auch deren „Besitzer“ gleich scheinbar parallel arbeiten lassen?

Wenn die Zeitscheibe nur schnell genug wechselt, erhält jeder Benutzer die „Illusion“ einen eigenen Computer, in Wahrheit teilen sie sich die Rechenzeit desselben Großrechners. Wir kommen zu den ... Terminals.
Sperry-UNIVAC UNISCOPE 200 für koaxialen Anschluss (1974), Von Adamantios - Eigenes Werk, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4778222
Damit verschärft sich aber ein Grundproblem parallel arbeitender Programme:

sie können sich gegenseitig stören, ja sogar „herunterreißen“.

Und wir reden hier von sehr teurer Rechenzeit! Daher wird es nun erforderlich, die Programme sozusagen „einzusperren“.

So, als gäbe man Hotelgästen je ein Zimmer. Was der Gast in seinem Zimmer macht, ist seine Sache. Aber das andere Zimmer ist tabu.

Hier beim Betriebssystem heißt das:

- Prozessisolation für die „Zimmer“
- Benutzerkonten, wem welches Zimmer „gehört“

Aber die Gäste wollen auch versorgt werden, mit Speisen und Getränken. Die werden ihnen auch geliefert, ...

... aber die Küche etc. ist für sie tabu. Kein Eintritt!

Und so kommen wir zur Geburt von Unix, dessen Grundlagen heute jedes moderne Betriebssystem für Server und Desktopbereich prägen.
 
Hier eine kurze Unterbrechung:

> Und so kommen wir zur Geburt von Unix, dessen Grundlagen heute jedes moderne Betriebssystem
*** für Server und Desktopbereich prägen. ***

Dieser Einschub ist sehr wichtig. Es gibt Betriebssysteme für ganz andere Einsatzzwecke, sie haben teils erheblich andere Ansätze. Diese lasse ich hier alle aus, da sie für unser Thema. Cloud, keine Rolle spielen.
 
Wir sprachen von dem Hotel. Jeder Gast hat sein Zimmer. Und dieses Zimmer ist begrenzt durch seine Wände.

Dann haben wir die Küche, wo die Speisen und Getränke für alle Gäste zubereitet werden. Und da hat kein Gast etwas verloren.

Auch hier haben wir Wände. Und zwischen den Wänden haben wir Türen.

Übertragen heißt das:

Damit ein Programm kein anderes stören kann, darf es nur in seinem ihm zugewiesenem Speicher arbeiten.

Es hat auch nichts „in der Küche zu suchen“, übertragen, es darf nur bestimmte Instruktionen ausführen.

Nun gibt es gewisse „Naturgesetze“ in der IT. Dazu gehört, was in einer tieferliegende Schicht verbrochen wurde, kann in einer höheren Schicht kaum noch korrigiert werden.

Auf unsere Punkte bezogen heißt das, Speichertrennung und Einschränkungen der Instruktionen ganz tief, in der Hardware selbst.
 
Zunächst zum Speicher. Wie will ich verhindern, dass ein Programm den Speicher eines anderen überschreibt?

Die geniale Lösung ist die Einführung virtuellen Speichers. Arbeitet die CPU mit echten physischen Hardwareadressen, kann jede Anwendung den Speicher von Kernel wie auch anderen Anwendungen überschreiben.

Nun wird aber eine MMU eingeführt, die Memory Management Unit, zunächst als extra Baustein, heute fest in der CPU integriert.

Die Anwendung arbeitet nicht mehr mit physischen Adressen, sondern virtuellen, und die MMU ist dafür zuständig, zwischen physischen und virtuellen Adressen zu übersetzen.

Durch diese Zwischenschicht kann nun eine Anwendung nur noch abgeschottet in ihrem ihr zugeordneten Arbeitsspeicher werkeln,

... und der muss nicht mal real im Arbeitsspeicher liegen, der virtuelle Speicher kann ausgelagert werden (Swap) … was wir hier aus Zeitgründen wieder nicht weiter vertiefen ...
 
 
Nun kommen wir zur Küche. Kein Gast darf hier herein. Die Küche allein hat Zugriff auf das Lager, bereitet die Speisen zu und die Kellner bringen es den Gästen.

Übertragen ist dies der Zugriff auf die reale Hardware, wie Laufwerke, Schnittstellen etc. Zugriffe auf die Hardware werden je nach Design der CPU über Speichereinblendung (Memory-mapped) oder Ports (eigener Bus, Port-mapped) gesteuert.

Nun kommt die Einführung von User- und Kernelland. Die meisten Programme laufen im Userland, sie sind wie die Gäste des Hotels. Kein Zugang zur Küche … zur Hardware.

Dagegen haben wir das Personal. Das ist der Kern des Betriebssystems, hart abgeschottet. Er greift auf die Hardware zu, verwaltet diese. Wir sind im Kernelland.

Um User- und Kernelinstruktionen in den Rechten zu trennen, muss eine CPU mindestens zwei „Modis“ besitzen, den User Mode für Anwendungen, den Kernel Mode für den Kern des Betriebssystems. Real wird dies noch feingranularer durch sogenannte Privilege Rings gesteuert. Auch das lassen wir hier wieder der Zeit geschuldet aus …
 
 
Da nun User Land und Kernel Land voneinander abgeschottet sind, selbst hinsichtlich der Speicheradressen, brauchen wir Türen: es muss eine Schnittstelle zwischen diesen beiden Welten her.

Schnittstellen zu entwickeln ist harte Arbeit. Man sieht einer Schnittstelle an, ob sie unter Zeitdruck oder nach sauberer Konzeption entstand! Gerade saubere Schnittstellen sind das Ergebnis von Gremien in vielen Iterationen und Beispielimplementationen. Aber dazu in späteren Beiträgen mehr.
An dieser Stelle: wir sind endlich bei POSIX (https://de.wikipedia.org/wiki/POSIX).

POSIX ist ein Standard, der auf API-Ebene beschreibt, wie User- und Kernelland miteinander „sprechen“. POSIX wird heute von vielen Betriebssystemen unterstützt, entweder nativ oder als Kompatibilitätslayer, und macht auch mein Leben als Entwickler so viel einfacher.

Dank POSIX kann ich Code schreiben, den ich auf unterschiedlichsten Plattformen ohne Änderung (oder fast ohne Änderungen, Danke mal wieder an WinzigWeich!!!) nutzen kann.
 

 

 

 

 

 

 

 

 

Main Menu

  • Home
  • Impressum

Login Form

  • Passwort vergessen?
  • Benutzername vergessen?