20,99 €
Sie finden das Thema "Betriebssysteme" trocken und schwierig? Dieses Buch vermittelt Ihnen die wesentlichen Aspekte der Konstruktion und Analyse von Betriebssystemen in unterhaltsamer Form. Verfolgen Sie Prozesse im System, erleben Sie die Planung von Aktivitäten mit und beobachten Sie die Verwaltung von Ressourcen. Erlernen Sie, wie Prozesse miteinander kooperieren und dabei Daten austauschen. Das Thema "Sicherheit" kommt natürlich nicht zu kurz. Kleine Programmieraufgaben ermuntern Sie, das Verhalten eines Betriebssystems selbst zu erforschen.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 522
Veröffentlichungsjahr: 2023
Betriebssysteme für Dummies
ls [muster]Verzeichnisanzeige (list)
cd [verz]Verzeichniswechsel (change dir)
cp 〈quelle〉 〈ziel〉Kopieren von Dateien/Verzeichnissen (copy)
mv 〈quelle〉 〈ziel〉Bewegen von Dateien/Verzeichnissen (move)
rm 〈datei〉Löschen von Dateien/Verzeichnissen (remove)
mkdir 〈verz〉Verzeichnis anlegen (make dir)
rmdir 〈verz〉Verzeichnis löschen (remove dir)
chmod 〈recht〉 〈datei〉Rechte einer Datei ändern (change mode)
less 〈datei〉seitenweise Anzeige von Dateien
cat 〈datei〉Dateien verbinden und anzeigen (concatenate)
wzeigt an, wer eingeloggt ist (und was er tut)
ps [ax]Anzeige existierender Prozesse
xZeichen unter dem Cursor löschen
ddaktuelle Zeile löschen
〈num〉GCursor zur Zeile num bewegen
:!〈cmd〉Shellkommando cmd ausführen
uletzten Befehl revertieren
oZeile unter der aktuellen Zeile einfügen
OZeile über der aktuellen Zeile einfügen
/〈str〉Suche vorwärts ab Cursor nach stryyaktuelle Zeile zwischenspeichern
pgelöschten oder zwischengespeicherten Text hinter Cursor einfügen
Pgelöschten Text vor Cursor einfügen
Jzwei Zeilen zusammenfügen
%s/str1/str2/gglobal alle str1 durch str2 ersetzen
:syntax onSyntaxhighlighting einschalten
int close(int fd);Schließen des Deskriptors fd, Resultat: Erfolg (0) oder Fehler (-1)
int execvp(const char *file, char *const argv[]);Überlagerung des aktuellen mit dem Prozessabbild filevoid exit(int status);Beenden des Prozesses mit Status statuspid_t fork(void);Neuen Prozess erzeugen, Resultat: PID des Sohnes im Vater, 0 im Sohn
int kill(pid_t pid, int sig);Versenden des Signals sig an Prozess mit pid, Resultat: Erfolg (0) oder Fehler (-1)
off_t lseek(int fd, off_t offset, int whence);Verstellen des Dateipositionszeigers des Dateideskriptors fd um offset Bytes relativ zu whence, Resultat: neue Position
int lstat(const char *pathname, struct stat *statbuf);Ermittlung der Attribute der Datei pathname, Resultat: Attribute in statbuf
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);Einblenden von length Bytes der Datei mit Deskriptor fd (überspringe offset Bytes der Datei) in den Adressraum des Prozesses ab addr, Resultat: Zeiger auf Anfang des Mappings
int open(const char *pathname, int flags, mode_t mode);Datei pathname eröffnen, Resultat: Dateideskriptor
int pipe(int pipefd[2]);Pipe erzeugen, Resultat: Lesedeskriptor in pipefd[0], Schreibdeskriptor in pipefd[1]ssize_t read(int fd, void *buf, size_t count);Lesen von count Bytes aus Dateideskriptor fd in Puffer buf, Resultat: Anzahl gelesener Bytes
ssize_t write(int fd, const void *buf, size_t count);Schreiben von count Bytes in Dateideskriptor fd aus Puffer buf, Resultat: Anzahl geschriebener Bytes
Betriebssysteme für Dummies
Bibliografische Informationder Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
1. Auflage 2024
© 2024 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, Germany
All rights reserved including the right of reproduction in whole or in part in any form. This book published by arrangement with John Wiley and Sons, Inc.
Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Dieses Buch wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.
Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.
Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.
Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.
Coverfoto: RedlineVector – stock.adobe.comKorrektur: Birgit Volk
Print ISBN: 978-3-527-71813-9ePub ISBN: 978-3-527-82987-3
Robert Baumgartl studierte von 1990 bis 1995 Informatik an der TU Dresden. Tätigkeiten als Graduiertenstudent und wissenschaftlicher Mitarbeiter führten schließlich zur Promotion, in der er sich mit der Eignung Digitaler Signalprozessoren (DSP) als universeller Beschleunigerhardware und deren Integration in sogenannte Mikrokernel befasste.
Von 2003 bis 2008 war er Juniorprofessor für Echtzeitsysteme an der TU Chemnitz. Seit 2008 ist er Professor für Betriebssysteme an der Hochschule für Technik und Wirtschaft (HTW) Dresden. Außer Betriebssystemen lehrt er verschiedene Aspekte echtzeitfähiger Systeme sowie Informationssicherheit.
In der Freizeit fährt er Rad oder versucht sich in Bau und Nutzung elektronischer Musikinstrumente.
Cover
Titelblatt
Impressum
Über den Autor
Inhaltsverzeichnis
Einleitung
Über dieses Buch
Konventionen in diesem Buch
Symbole in diesem Buch
Törichte Annahmen über den Leser
Wie dieses Buch aufgebaut ist
Wie Sie dieses Buch lesen sollten
Teil I: Grundlagen
Kapitel 1: Ein bisschen Einführung
Was ist ein Betriebssystem?
Eine (ganz) kurze Geschichte der Betriebssysteme
Aufgaben eines Betriebssystems
Perspektiven auf Betriebssysteme
Klassifizierung von Betriebssystemen
Lizenzierungsaspekte
Kapitel 2: Bedienung, bitte: Wie man mit Linux umgeht
Wie sag ich's meinem Betriebssystem?
Interaktion an der Kommandozeile
Editor
Compiler und Interpreter
Das eingebaute Handbuch
Lesevorschläge
Übungsaufgaben
Kapitel 3: C
Warum C?
Aller Anfang ist schwer
Konstrukte zur Steuerung der Abarbeitung
Funktionen
Zeiger
Dynamische Speicherverwaltung
Was fehlt jetzt noch zum C-Profi?
Lesevorschläge
Übungsaufgaben
Teil II: Aktivitäten im Betriebssystem
Kapitel 4: Grundlegende Begriffe und Abstraktionen
Architekturen
Kernel Mode und User Mode
Interrupts
Aktivitäten und Ressourcen
Übungsaufgaben
Kapitel 5: Action! Aktivitäten, Prozesse und all das
Prozesse und Threads
Lesevorschläge
Übungsaufgaben
Kapitel 6: Planen von Aktivitäten (Scheduling)
Wozu benötigt man einen Scheduler?
Offline-Planung
Einfache Online-Verfahren für Jobsysteme
Verfahren für Universalbetriebssysteme
Übungsaufgaben
Teil III: Interaktion zwischen Aktivitäten
Kapitel 7: Synchronisation: Warten auf Godot
Zeitabhängige Fehler und wie man ihnen beikommt
Dezentrale Steuerung kritischer Abschnitte
Zentrale Steuerung
Das Leser-Schreiber-Problem
Lesevorschläge
Übungsaufgaben
Kapitel 8: Kommunikation
Wozu kommunizieren?
Begriffe
We are laying a pipeline
Prozesse, hört die Signale
Vom Senden und Empfangen: Nachrichtenaustausch
Teilen macht froh: Shared Memory
Was es sonst noch zum Kommunizieren gibt
Lesevorschläge
Übungsaufgaben
Teil IV: Speicher
Kapitel 9: Hauptspeicher (RAM)
Verwaltung des Freispeichers
Virtueller Speicher
Wichtige UNIX-Dienste für den Speicher
Lesevorschläge
Übungsaufgaben
Kapitel 10: Persistenter Speicher
Grundlegende Abstraktionen
Systemrufe fürs Dateisystem
Implementation von Dateisystemen
Optimierung von Massenspeicherzugriffen
Lesevorschläge
Übungsaufgaben
Teil V: Sicherheit
Kapitel 11: Betriebssystem-Sicherheit
Grundbegriffe
Schadcode
Stack Overflow
Gegenmaßnahmen
Andere Angriffe
Authentifizierung
Zusammenfassung
Lesevorschläge
Übungsaufgaben
Teil VI: Top-Ten-Teil
Kapitel 12: Zehn Personen, ohne die Betriebssysteme nicht denkbar sind
Edsger W. Dijkstra (1930–2002)
Bill Gates (* 1955)
Steve Jobs (1955–2011)
Leslie Lamport (* 1941)
Jochen Liedtke (1953–2001)
Dennis Ritchie (1941–2011)
Richard Stallman (* 1953)
Andrew S. Tanenbaum (* 1944)
Ken Thompson (* 1943)
Linus Torvalds (* 1969)
Anhang: Lösungen der Aufgaben
Kapitel 1
Kapitel 2
Kapitel 3
Kapitel 4
Kapitel 5
Kapitel 6
Kapitel 7
Kapitel 8
Kapitel 9
Kapitel 10
Kapitel 11
Literatur
Abbildungsverzeichnis
Stichwortverzeichnis
End User License Agreement
Kapitel 3
Tabelle 3.1: Die wichtigsten Grunddatentypen in C
Tabelle 3.2: Beispiele einiger wichtiger Zeichenkonstanten
Tabelle 3.3: Arithmetische (links) und Vergleichsoperatoren (rechts)
Tabelle 3.4: Logische Verknüpfungen in C
Tabelle 3.5: Bitoperatoren in C
Tabelle 3.6: Präzedenz der wichtigsten Operatoren in C
Tabelle 3.7: Platzhalter im
formatstring
von
printf()
Kapitel 4
Tabelle 4.1: Klassifikation von Ressourcen
Kapitel 6
Tabelle 6.1: Schedulingzeitpunkte und Bereitmengen für zwei Prozessoren
Tabelle 6.2: Beispielprozessmenge für SRT und HRRN
Tabelle 6.3: Entwicklung der Prioritäten bei HRRN für die Prozesse der Beispielmenge
Kapitel 7
Tabelle 7.1: Wichtige Funktionen der POSIX-API für (benannte) Semaphore
Kapitel 8
Tabelle 8.1: Die wichtigsten Signale unter UNIX
Kapitel 9
Tabelle 9.1: Statusbits im Seitentabelleneintrag
Tabelle 9.2: Klassifizierung von Seiten anhand der Statusbits bei NRU
Tabelle 9.3: Beispiel für das Aging-Verfahren
Tabelle 9.4: Folge der Speicherreferenzen für Aufgabe 7
Kapitel 10
Tabelle 10.1: Beispiel einer Zugriffsmatrix
Tabelle 10.2: Permissions im AFS
Kapitel 11
Tabelle 11.1: Unsichere C-Funktionen und ihre sicheren Pendants
Tabelle 11.2: Erlaubte Operationen für Prozesssegmente
Tabelle 11.3: Einige gebräuchliche Hashverfahren
Kapitel 1
Abbildung 1.1: Einfache Schichtenarchitektur eines Rechensystems
Kapitel 2
Abbildung 2.1: Typischer Anmeldebildschirm in Linux
Abbildung 2.2: Typische GUI-basierte Arbeitsoberfläche (Fenstermanager Gnome)
Abbildung 2.3: Kommandobasierte Interaktion mit einem Textterminal
Abbildung 2.4: Mehrere Terminals parallel im grafischen Fenstermanager i3
Abbildung 2.5: Ein kleiner Verzeichnisbaum
Abbildung 2.6: Ausschnitt aus einem typischen UNIX-Verzeichnisbaum
Abbildung 2.7: Zustände von
vi
Abbildung 2.8: Vom Quellcode zum Programmcode (Binärabbild)
Abbildung 2.9: Abarbeitung mittels Interpreter
Abbildung 2.10: Auszug aus der Manual-Seite für den Zeichenkettenvergleich unter ...
Kapitel 3
Abbildung 3.1: Die Schlüsselwörter von C
Abbildung 3.2: Die Zeichenkette
msg
im Speicher
Kapitel 4
Abbildung 4.1: Beispiel einer einfachen Schichtenarchitektur
Abbildung 4.2: Schichtenarchitektur bei MS-DOS
Abbildung 4.3: Client-Server-Beziehung
Abbildung 4.4: Prinzip eines Systemrufs
Abbildung 4.5: Ein Interrupt und seine Behandlung
Abbildung 4.6: Transformation von Ressourcen
Kapitel 5
Abbildung 5.1: Zustandsdiagramm eines Prozesses
Abbildung 5.2: Prozesserzeugung mittels
fork()
Abbildung 5.3: Drei Prozesse (links) vs. ein Adressraum mit drei Threads und ein ...
Kapitel 6
Abbildung 6.1: Prinzip der Zeitsteuerung
Abbildung 6.2: Resultierender Plan nach RMS für einen Prozessor und , und
Abbildung 6.3: Präzedenzgraph für die Beispielprozessmenge
Abbildung 6.4: Offline generierter Plan für einen Prozessor
Abbildung 6.5: Offline generierter Plan für zwei Prozessoren
Abbildung 6.6: Resultierende Pläne für FCFS und SJN
Abbildung 6.7: Resultierender Plan nach SRT für die Prozesse aus Tabelle 6.2
Abbildung 6.8: Resultierender Plan nach HRRN für die Prozesse aus Tabelle 6.2
Abbildung 6.9: Parameter bei Round Robin
Abbildung 6.10: Prioritätsstufen in Windows
Abbildung 6.11: Acht rechenbeschränkte Prozesse auf Vier-Kern-Syst...
Abbildung 6.12: Acht rechenbeschränkte Prozesse auf Vier-Kern-Syst...
Abbildung 6.13: Acht rechenbeschränkte Prozesse auf Vier-Kern-Syst...
Kapitel 7
Abbildung 7.1: (Möglicher) zeitlicher Ablauf beim Zugriff auf gemeinsames Konto
Abbildung 7.2: Funktionalität der den kritischen Abschnitt klammernden Funktionen...
Abbildung 7.3: Lösungsversuch 1 für dezentrales Management des kritischen Abschni...
Abbildung 7.4: Lösungsversuch 2 für dezentrales Management des kritischen Abschni...
Abbildung 7.5: Lösungsversuch 3 für dezentrales Management des kritischen Abschni...
Abbildung 7.6: Lösungsversuch 4 für dezentrales Management des kritischen Abschni...
Abbildung 7.7: Der Peterson-Algorithmus
Abbildung 7.8: Die Zeichenkette
msg
im Speicher
Kapitel 8
Abbildung 8.1: Der Lebenszyklus einer unbenannten UNIX-Pipe
Abbildung 8.2: Synchrones Senden beim Message Passing
Abbildung 8.3: Asynchrones Senden beim Message Passing
Abbildung 8.4: Datenübertragung via POSIX Message Queues
Abbildung 8.5: Prinzip des
Shared Memory
Kapitel 9
Abbildung 9.1: Speicherbelegung eines Prozesses im UNIX
Abbildung 9.2: Beispiel zur externen Fragmentierung
Abbildung 9.3: Speicherverwaltung mittels Bitmap
Abbildung 9.4: Freispeicherliste für Situation aus Abbildung 9.3
Abbildung 9.5: Blöcke mit integrierten Headern
Abbildung 9.6: Beispiel für Boundary Tags
Abbildung 9.7: Zusätzliche Verkettung freier Segmente
Abbildung 9.8: Beispiel zur Teilung größerer Segmente beim Buddy-Verfahren
Abbildung 9.9: Grundprinzip des virtuellen Speichers
Abbildung 9.10: Adressierung mittels Seitentabelle
Abbildung 9.11: Virtuelles Speichermodell der Intel-IA32-Architektur
Abbildung 9.12: Ablauf der Umsetzung einer virtuellen in eine physische Adresse
Abbildung 9.13: Beispiel zum Uhralgorithmus (Second Chance)
Abbildung 9.14: Aktualisierung eines Zählers beim Aging
Abbildung 9.15: Prinzip der Abbildung einer Datei im Hauptspeicher mittels
mmap()
Kapitel 10
Abbildung 10.1: Beziehung zwischen Verzeichniseintrag, Inode und Nutzdaten
Abbildung 10.2: Zwei Verzeichniseinträge für ein und dieselbe Datei
Abbildung 10.3: Prinzip einer Symbolischen Verknüpfung
Abbildung 10.4: Festplatte in Draufsicht (vereinfacht)
Abbildung 10.5: Physische und logische Blocknummern des Massenspeichers und ihre ...
Abbildung 10.6: Kontinuierliche Allokation von Blöcken
Abbildung 10.7: Datenblöcke einer Datei als Liste
Abbildung 10.8: Datei als verkettete Liste
Abbildung 10.9: Datei als verkettete Liste mit Zuordnungstabelle
Abbildung 10.10: Speicherung mit variablen Indexblöcken
Abbildung 10.11: Eine Datei im UNIX-Dateisystem
Abbildung 10.12: Beispiel für die Speicherung einer Datei mittels zweier Extents
Abbildung 10.13: Ein einfaches Beispiel zum Journaling
Kapitel 11
Abbildung 11.1: Stack Frames für jeden Funktionsaufruf
Abbildung 11.2: Stack-Layout während der Ausführung von
bo
Abbildung 11.3: Stack-Layout nach Kopieroperation mit zu langem Argument
Abbildung 11.4: Schutz der Rücksprungadresse durch Canary Word
Abbildung 11.5: Überschreiben der Rücksprungadresse mittels
Stack Overflow
Abbildung 11.6: Naive Implementierung der Authentifizierung
Abbildung 11.7: Authentifizierung mittels Passworthash
Abbildung 11.8: Authentifizierung mittels Challenge-Response
Abbildung 11.9: Prinzip des Wörterbuchangriffs
Anhang
Abbildung A.1: Der Verzeichnisbaum zur taxonomischen Einordnung vo...
Abbildung A.2: Ausschnitt der Ausgabe von
pstree
bei der Abarbeitu...
Abbildung A.3: Offline generierter Plan für die Taskmenge unter »O...
Abbildung A.4: Offline generierter Plan für die Taskmenge unter »O...
Abbildung A.5: Speicherabbild nach vier Forderungen
Cover
Titelblatt
Impressum
Über den Autor
Inhaltsverzeichnis
Einleitung
Fangen Sie an zu lesen
Anhang: Lösungen der Aufgaben
Literatur
Abbildungsverzeichnis
Stichwortverzeichnis
End User License Agreement
1
2
5
6
7
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
381
382
383
384
385
389
390
391
392
In diesem Buch geht es um Betriebssysteme. Betriebssysteme sind aus vielerlei Gründen eine faszinierende Form von Software. Sie sind ausgesprochen vielgestaltig, sie müssen äußerst zuverlässig arbeiten, und die in ihnen verankerten Algorithmen sind teilweise höllisch komplex. Keine Software muss so optimal auf die Hardwarearchitektur abgestimmt sein, wie das Betriebssystem.
Wo viel Licht ist, ist natürlich auch viel Schatten. Wenn ein Betriebssystem seine Aufgaben gut erledigt, dann merkt man von seiner Anwesenheit so gut wie nichts. Es handelt sich sozusagen um mehr oder minder »unsichtbare« Software. Während Computergrafiker oder Experten für Künstliche Intelligenz in der Öffentlichkeit meist spektakuläre Ergebnisse vorweisen können, stehen Fachleute für Betriebssysteme selten im Mittelpunkt. Gegenstand der Berichterstattung sind sie zumeist nur, wenn ein Rechensystem versagt hat (wobei es meist nicht am Betriebssystem liegt), wenn wieder eine Klinik oder eine Hochschule mittels eines verschlüsselnden Trojaners erpresst wird.
Sie sind also gewarnt! Falls Sie nach der Lektüre dieses Buches den Wunsch verspüren, sich weiter in die Geheimnisse der Betriebssysteme zu vertiefen, dann werden Sie mit hoher Wahrscheinlichkeit keine Person des öffentlichen Interesses sein. Ausgeschlossen ist es natürlich nicht, Sie könnten beispielsweise mit Hilfe von Betriebssystemen erfolgreiche Firmen gründen, denken Sie an Apple oder Microsoft. Aber auch ohne diese Superlative sind Betriebssysteme ein interessantes Spezialisierungsgebiet; allzu viele Fachleute gibt es nämlich nicht.
Betriebssysteme sind übrigens fast auf jedem Rechner unabdingbar. Sie gestatten es dem Nutzer des Systems oder dem Anwendungsprogrammierer, sich auf die Probleme ihrer Domäne zu konzentrieren. Der Nutzer, der ein Programm starten möchte, klickt auf ein grafisches Symbol, oder (wenn es sich um einen fortgeschrittenen Nutzer handelt) er gibt den Namen des Programms an einer Kommandozeile ein. Wenige Augenblicke später öffnet sich das oder die Fenster des Applikationsprogramms. Der Nutzer muss keinen Gedanken daran verschwenden, wo sich das Binärabbild des Programms auf dem Massenspeicher befindet, und ihm ist auch egal, an welche Adressen im Hauptspeicher dieses geladen wird. Darum kümmert sich stillschweigend das Betriebssystem. Startet der Nutzer gleich mehrere Programme, oder arbeiten mehrere Nutzer am selben System, dann sorgt das Betriebssystem dafür, dass sich diese nicht gegenseitig ins Gehege kommen und dass auch alle gestarteten Prozesse die Hardwareausstattung des Rechners (der Betriebssystemler spricht von »Ressourcen«) gleichberechtigt nutzen dürfen.
Wie bereits erwähnt kann man heutzutage auch eine missbräuchliche Verwendung von Rechensystemen nicht mehr ignorieren. So werden aus den unterschiedlichsten Gründen Rechner angegriffen, Zugänge unberechtigt erschlichen, Daten ausspioniert und manipuliert und ganze Rechnerverbünde auch lahmgelegt. Das Betriebssystem bildet in diesem Kontext die wichtigste Verteidigungslinie. Man könnte möglicherweise sogar postulieren, dass dies die wichtigste Funktion des Betriebssystems ist.
Kursiv gedruckte Begriffe sollen sowohl in ihrer Wichtigkeit betont werden als auch bei erster Benutzung hervorgehoben werden. Begriffe, die eine präzise Definition erfordern, sind im Allgemeinen in einen extra Kasten gesetzt. Alle programmiersprachlichen Konstrukte im Fließtext, wie Systemrufe, Bezeichner und Schlüsselworte, sowie alle Kommandos sind in Schreibmaschinenschrift gesetzt. Um Ihnen die weiterführende Lektüre zu erleichtern, sind alle wichtigen Begriffe sowohl in Deutsch als auch in Englisch angegeben (manchmal sind die deutschen Begriffe sehr ungebräuchlich; niemand sagt »Planer« zum Scheduler). Am Ende der einzelnen Kapitel gibt es einige Vorschläge zur vertiefenden Lektüre.
Alle längeren Codebeispiele sind zeilennumeriert, um im Text Bezug nehmen zu können. Schlüsselworte der Programmiersprache C sind der Übersichtlichkeit halber fett gedruckt.
Diese Abschnitte enthalten tiefergehende Erläuterungen, die bei der ersten Lektüre übersprungen werden können.
Dieses Symbol weist auf Stolperstellen, potenzielle Fehler und allgemein auf Probleme hin.
An dieser Stelle werden für das Gesamtverständnis wichtige Begriffe definiert.
Abschnitte dieser Art enthalten illustrierende Beispiele. Diese sollten besonders sorgfältig studiert und nachvollzogen werden.
Dieses Symbol kennzeichnet anekdotische Begebenheiten sowie geschichtliches Hintergrundwissen, mit dem Sie auf jeder Informatikerparty brillieren können.
Hier finden Sie wichtige Aussagen oder Erkenntnisse, die eine besondere Hervorhebung erfordern.
Idealerweise interessieren Sie sich für den Aufbau und die Funktionsweise von Betriebssystemen. Ob die Motivation zur Lektüre intrinsisch ist oder durch einen näher rückenden Klausurtermin extern befeuert wird, ist zunächst egal. Möglicherweise ist Ihnen auch die Lektüre alternativer Publikationen zum Diskursbereich schwergefallen, oder die Vorlesung fand stets freitags um 17 Uhr statt.
Natürlich sind Studenten der Informatik und angrenzender Bereiche eine wichtige Zielgruppe dieses Buches. Es ist aber bewusst so verfasst, dass es prinzipiell auch für Nichtakademiker geeignet ist. Sie müssen nicht programmieren können (es schadet natürlich auch nicht), ein kleiner abgeschlossener Kurs, der Sie in die Anfangsgründe von C einführt, ist enthalten. Allenfalls grundlegende Kenntnisse über Rechentechnik werden vorausgesetzt (Sie sollten wissen, was ein Byte oder eine Festplatte sind).
Viel wichtiger als alle akademische Bildung und Vorbildung ist einfach das Interesse, ein komplexes Softwaresystem, um das es sich bei Betriebssystemen in aller Regel handelt, so gut wie möglich verstehen und gedanklich durchdringen zu wollen. Nützlich ist fürderhin eine gewisse Experimentierfreude. Sie finden im Buch häufig die Aufforderung, unklare Sachverhalte einfach auszuprobieren. Da es sich bei Betriebssystemen um Software handelt, können Sie nämlich nichts kaputt machen (na gut, sagen wir, fast nichts, denn eine ordentlich programmierte Fork-Bombe kann schon einmal einen Neustart des Rechners erfordern).
Höchstwahrscheinlich nicht auf Ihre Kosten kommen Sie, wenn Sie Anleitungen zum Installieren von Betriebssystemen suchen oder wenn Sie theoretische Aspekte von Betriebssystemen studieren wollen. Für diese Zwecke wird auf die reichlich vorhandene Spezialliteratur verwiesen.
In diesem Büchlein lernen Sie Betriebssysteme von zwei Seiten kennen. Sie schauen zum einen von außen auf typische Betriebssysteme und lernen, welche Funktionen und Dienste diese für die Programmierung von Anwendungen anbieten. Dabei stützen wir uns häufig auf die POSIX-API (keine Sorge; diese und ähnliche Begriffe verlieren ihre Mystik schon in den ersten Kapiteln) des Linux-Kernels. Sie lernen gewissermaßen, das Betriebssystem als Dienstleister zu verstehen.
Zum anderen sollen Sie aber auch solide Kenntnisse erwerben, wie diese Dienste durch das Betriebssystem erbracht werden. Es soll also nicht als Black Box aufgefasst werden, sondern wir wollen den einen oder anderen Blick in die »Innereien« von Betriebssystemen werfen. Aber keine Sorge: Es geht weniger darum, neue Betriebssysteme zu programmieren (schließlich gibt es schon eine ganze Menge bewährte), sondern mehr um ein grundlegendes Verständnis der Arbeitsweise der einzelnen Komponenten.
Zu diesem Zweck gliedert sich Betriebssysteme für Dummies in sechs grundlegende Teile.
Im Teil I erlernen Sie alles, was Sie für das Verständnis des restlichen Textes benötigen; das ist zum einen eine knappe Einführung, wie Sie mit einem Linux-System arbeiten, und zum anderen einen (nicht ganz so knappe) Einführung in die Programmiersprache C. Letztere ist notwendig, denn die allermeisten Betriebssysteme sind in C programmiert, und auch die systemnahe Programmierung erfolgt meist in C. Beiden Kapiteln vorangestellt ist die Einführung zum Thema, in der Sie etwas über die geschichtliche Entwicklung der Betriebssysteme erfahren und darüber, was man nun konkret unter einem Betriebssystem versteht.
Teil II des Buches ist den sogenannten Aktivitäten gewidmet. Darunter versteht man, grob gesagt, die ausgeführten Programme. Kapitel 4 »Grundlegende Begriffe undAbstraktionen« erläutert weitere wichtige Begriffe, Kapitel 5 »Action! Aktivitäten,Prozesse und all das« ist der Blick von außen. Sie erlernen, wie Sie programmtechnisch neue Prozesse und Threads in das System aufnehmen (und aus diesem wieder entfernen). Der Blick in die »Innereien« des Betriebssystems, die mit Aktivitäten zu tun haben, erfolgt in Kapitel 6 »Planen von Aktivitäten (Scheduling)«. Sie lernen, wie der sogenannte Scheduler arbeitet und nach welchen Kriterien dieser die einzelnen Aktivitäten in eine konkrete Abarbeitungsreihenfolge bringt. An dieser Stelle kann ein Hauch Mathematik nicht vermieden werden, aber Sie brauchen keine Angst zu haben, es ist wirklich nur ein Hauch.
Die Aktivitäten eines Systems arbeiten sehr häufig miteinander und müssen sich zu diesem Zweck zeitlich abstimmen (man sagt »synchronisieren«) und Daten miteinander austauschen (kommunizieren). Diese beiden Aspekte sind Gegenstand von Teil III. Jeweils ein Kapitel ist der Synchronisation sowie der Kommunikation von Aktivitäten gewidmet. Beide Aspekte zusammen genommen bilden die sogenannte »Inter Process Communication«, abgekürzt IPC.
Im Teil IV geht es um Speicher: zum einen um den flüchtigen (RAM) im Kapitel 9 »Hauptspeicher (RAM)« und zum anderen um den nicht flüchtigen oder persistenten, also den Massenspeicher, in Kapitel 10 »Persistenter Speicher«. Wie schon im vorangehenden Teil sind auch hier der Blick von außen und die »inneren Werte« in jedem Kapitel verankert. Sie lernen wichtige Verfahren kennen, beide Formen des Speichers zu verwalten. Zwei wichtige Begriffe sind »Allokatoren«, das sind die Komponenten, bei denen sich die Nutzerprogramme Hauptspeicherblöcke besorgen, und »Dateisystem«. Von Letzterem haben Sie bestimmt schon eine ungefähre Vorstellung.
Der letzte inhaltliche Teil V nimmt ein bisschen eine Sonderstellung ein. Er umfasst nur ein einziges Kapitel »Betriebssystem-Sicherheit«, dieses fällt aber verhältnismäßig umfangreich aus. Es ist auch ein klitzekleines bisschen schwieriger zu verstehen, sodass Sie nicht gerade mit ihm beginnen sollten. Wenn Sie aber die ersten zehn Kapitel gemeistert haben, dann haben Sie genügend Wissen erworben, um dieses letzte anspruchsvolle Kapitel zu absolvieren. Lassen Sie sich nicht entmutigen: Es sind besonders viele Referenzen angegeben, die Ihnen im Zweifelsfalle weiterhelfen.
Der allerletzte Teil ist (subjektiv) zehn wichtigen Persönlichkeiten gewidmet, die unsere heutige Welt der Betriebssysteme entscheidend geprägt haben. Lassen Sie sich von ihnen inspirieren, diese Welt zu entdecken!
Unabhängig von Ihrer Motivation, sich mit Betriebssystemen tiefer auseinanderzusetzen, ist es sicherlich günstig, mit Kapitel 1 zu beginnen. Besitzen Sie Grundkenntnisse in der Nutzung von Linux und/oder der Programmiersprache C, dann dürfen Sie die Kapitel 2 und/oder 3 getrost überspringen. Beide sind verhältnismäßig kurze Abhandlungen, die Sie noch nicht zum Profi machen, sondern es Ihnen ermöglichen, die Kommando- und Codebeispiele in den folgenden Kapiteln zu verstehen.
Von da ab ist eine Lektüre in der Reihenfolge der Kapitel am sinnvollsten, wobei es ohne Weiteres möglich ist, Kapitel 7 mit Kapitel 8 und Kapitel 9 mit Kapitel 10 zu tauschen, wenn das Ihren Interessen entgegenkommt.
Sollten Sie (schlimmstenfalls in Form einer Pflichtveranstaltung) einer akademischen Vorlesung »Betriebssysteme« lauschen, dann kann es günstiger sein, die Kapitel in der Reihenfolge der Veranstaltungen zu zu lesen. Kapitel 5 »Aktivitäten« sollte relativ früh verstanden sein; dies werden aber ohnehin wohl alle Dozenten so handhaben. Am besten ist es natürlich, Sie hören »Betriebssysteme« als angehende Informatiker oder Medieninformatik an der HTW Dresden; dann können Sie einfach das Buch in einem Rutsch durchlesen. Es kommt alles zur Prüfung dran.
Wenn Sie mehr erfahren wollen, dann folgen Sie bitte den an verschiedenen Stellen eingefügten Lesevorschlägen; immerhin handelt es sich bei diesem Büchlein um eine Einführung in das Themengebiet und nicht um eine Enzyklopädie. Des Weiteren gibt es eine moderate Menge an Übungsaufgaben, die zumeist mit überschaubarem Aufwand lösbar sind.
Zögern Sie nicht, mit dem Autor Kontakt aufzunehmen, falls Sie Fehler oder Unklarheiten entdecken. Im Gegensatz zu Donald E. Knuth kann ich keinen Scheck über einen hexadezimalen Dollar für jeden gefundenen Fehler ausloben, sondern bestenfalls ein herzliches »Dankeschön!«.
Und nun wünsche ich viel Spaß und hoffentlich tiefe Erkenntnisse bei der Lektüre!
St. Egidien im Juni 2023
Robert Baumgartl
Teil I
IN DIESEM TEIL…
lernen Sie zunächst, was ein Betriebssystem ist und wozu man es benötigt.
Im zweiten Kapitel werfen wir einen Blick auf das Betriebssystem Linux.
Das dritte Kapitel schließlich ist ein Crashkurs für die Programmiersprache C.
Alle diese Kenntnisse sind für das Verständnis der folgenden Kapitel ziemlich wichtig, denn Sie wollen doch spielerisch-experimentell die »Innereien« von Betriebssystemen kennenlernen.
Kapitel 1
IN DIESEM KAPITEL
lernen Sie, was ein Betriebssystem ist und wozu man es benötigt,können Sie sich einen historischen Überblick über die Entwicklung der Betriebssysteme verschaffen,erhalten Sie einen Eindruck von der Vielfalt von Betriebssystemen für die unterschiedlichsten Einsatzzwecke.Bevor Sie in den späteren Kapiteln die »Innereien« von Betriebssystemen wie das Dateisystem oder den Scheduler näher kennenlernen, ist es hilfreich, zunächst eine Außensicht auf diese Form von Software zu entwickeln. Dazu muss das Betriebssystem von anderer Software abgegrenzt werden, und seine Aufgaben müssen definiert werden. Wie immer bei komplizierten technischen Systemen entstehen diese nicht ad hoc, sondern unterliegen einer Evolution. Daher geht es in diesem Kapitel auch um die Entwicklung dieser Softwarekategorie von den ersten Schedulern bis zur heutigen Vielfalt von Universal- und Spezialbetriebssystemen.
In diesem Buch geht es um Betriebssysteme, und somit ist es sicherlich sinnvoll, zunächst einmal zu klären, was das überhaupt ist, ein Betriebssystem.
Ingenieure nutzen gern Normen, und interessanterweise gibt es eine DIN, die den Begriff Betriebssystem direkt definiert:
»Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechensystems bilden und insbesondere die Abwicklung von Programmen steuern und überwachen.« [15]
Nun, das klingt ein bisschen antiquiert (kein Wunder, die Norm stammt aus dem Jahr 1988), trifft aber den Kern der Sache recht gut. Offenbar handelt es sich bei Betriebssystemen um Software, und zwar um die, die für den eigentlichen Betrieb des Rechensystems notwendig ist. Microsoft Word oder der Firefox-Browser sind zum Betrieb nicht unbedingt nötig (man könnte ja ganz ohne ihr Zutun beispielsweise ein Spielchen laden), aber die darunterliegende Softwareschicht, die bei einem normalen PC häufig Windows heißt und die beispielsweise das Laden des Spielchens oder einer anderen Applikation übernimmt, die ist essenziell. Das ist das Betriebssystem, um das es in diesem Buch geht.
Das war jetzt möglicherweise ein bisschen viel Fachjargon für den Anfang. Wieso gibt es Schichten von Software, die offenbar auch noch eine Art Stapel bilden, und was ist mit »Applikation« gemeint? Die Beantwortung der ersten Frage soll noch etwas verschoben werden. Fakt ist, dass auf heutigen Rechensystemen sehr viele verschiedene Softwarekomponenten existieren, und damit man den Überblick behält, muss man diesen Wust an Software strukturieren. Eine Möglichkeit dafür ist das Schichtenmodell, das Sie im Kapitel 4 »Grundlegende Begriffe und Abstraktionen« genauer kennenlernen werden. Die zweite Frage ist deutlich einfacher zu beantworten: Unter »Applikationen« versteht man die Gesamtheit der Programme, die dem Nutzer eines Systems zur Verfügung stehen und die nicht zum Betriebssystem gehören.
Seit dem Siegeszug der Smartphones hat sich für »Applikation« der Kurzbegriff App etabliert. Im Deutschen gibt es auch noch den Begriff »Anwendungsprogramm«.
Charakteristisch ist des Weiteren, dass der Nutzer von der Arbeit des Betriebssystems verhältnismäßig wenig mitbekommt. Den größten Anteil am Code eines Betriebssystems nehmen Funktionen ein, die audiovisuell nicht in Erscheinung treten, sondern gewissermaßen »unter der Haube« still und zuverlässig ihre Arbeit verrichten. Ihre Existenz wird häufig erst durch den Nutzer wahrgenommen, wenn einmal etwas schiefgeht, beispielsweise der Zugriff auf die abgelegten Daten unmöglich ist oder die Netzverbindung nicht zustande kommt.
Das Betriebssystem ist sozusagen ein mehr oder minder unsichtbares Helferlein, das Ihnen gestattet, auf einfache Weise mit dem System zu kommunizieren und dessen Ressourcen bestmöglich auszuschöpfen. Die »Abarbeitung von Programmen« spielt dabei eine große Rolle.
Zu einem Betriebssystem gehört in der Regel nicht nur der im Hauptspeicher abgelegte Kern (im Englischen häufig Kernel genannt), sondern eine große Anzahl von Hilfsprogrammen, die es überhaupt gestatten, effizient mit dem System zu arbeiten, es zu überwachen und zu diagnostizieren. Im Kontext sogenannter eingebetteter Systeme (das sind Rechensysteme, die Teil eines größeren Apparats oder einer Maschine sind, beispielsweise eines Fernsehers oder eines Computertomografen) wird das Betriebssystem häufig auch Firmware genannt.
Die Abgrenzung beider Begriffe voneinander ist nicht ganz einfach.
Von »Betriebssystem« spricht man, wenn es um »universelle« Computer geht, die potenziell alle mögliche Software abarbeiten können. Der Nutzer kann zur Laufzeit des Systems entscheiden, welches konkrete Programm abgearbeitet werden soll. Insbesondere ist es möglich, mit Hilfe von Entwicklungswerkzeugen neue Software für das System herzustellen, die dann ebenfalls abgearbeitet werden kann. Es gibt also (mindestens) zwei Softwareebenen: das Betriebssystem und die mit dessen Hilfe abgearbeiteten Programme.
Der Begriff »Firmware« wird stattdessen verwendet, wenn die Software im Kontext eines eingebetteten Systems eingesetzt wird. Die Auswahl und das Abarbeiten von wie auch immer gearteten Applikationsprogrammen ist dabei normalerweise nicht vorgesehen. Die angebotene Funktionalität steht im Allgemeinen fest (das englische firm bedeutet »fest«). Eine Teilung in mehrere Ebenen ist somit unmöglich; die Firmware bildet einen monolithischen Block.
Es gibt natürlich viele weitere Definitionen des Begriffs »Betriebssystem«; jeder Autor eines entsprechenden Lehrbuches formuliert natürlich eine eigene. Stellvertretend sei Andrew S. Tanenbaum zitiert, der zwei verschiedene Rollen eines Betriebssystems unterscheidet: ([27]):
das Betriebssystem als Verwalter der Systemressourcen und
das Betriebssystem als Erweiterung des Systems, die deutlich einfacher zu programmieren ist als die reine Hardware.
Es muss betont werden, dass der Begriff »Betriebssystem« gar nicht so einfach zu definieren ist und im Regelfall ein gewisser Interpretationsfreiraum besteht.
Im Abschnitt »Aufgaben eines Betriebssystems« dieses Kapitels erfahren Sie genauer, welche Aufgaben ein Betriebssystem zu erfüllen hat (und was besser durch Applikationen realisiert wird). Zuvor wollen wir aber einen kurzen historischen Exkurs die Entwicklung von Betriebssystemen betreffend unternehmen.
Komplexe technische Systeme unterliegen einem historischen Entwicklungsprozess; Betriebssysteme bilden dabei keine Ausnahme. Viele zugrunde liegende Konzepte, Algorithmen und Mechanismen wurden über längere Zeiträume hinweg immer wieder verbessert, adaptiert und optimiert. Um die Komplexität heutiger Systeme zu verstehen, ist es daher durchaus hilfreich, sich einen kurzen Überblick über wesentliche Entwicklungsetappen der Betriebssysteme zu verschaffen.
Nicht weiter überraschend ist, dass die Geschichte der Betriebssysteme sehr eng an die Geschichte der Rechentechnik, genauer: der Hardware, gekoppelt ist.
In der Anfangsphase der Computer, die von 1941 bis etwa Anfang der 1960er-Jahre dauerte, gab es typischerweise kein Betriebssystem. Man war gewissermaßen froh, dass diese überaus komplexen Maschinen überhaupt funktionierten und plausible Ergebnisse lieferten. Das Rechensystem wurde mit einem Programm »gefüttert«, arbeitete dieses ab und lieferte Ergebnisse zunächst mittels Lampenfeldern, später über Lochkartendrucker. Die allerersten Rechner hatten Namen wie »ENIAC« und »EDVAC« und wurden infolge ihrer immensen Kosten zunächst durch durch Militär und Geheimdienste genutzt, beispielsweise zur Berechnung ballistischer Tabellen für die Artillerie oder der Objektive von Spionagekameras. Sehr bald kamen jedoch auch zivile wissenschaftliche und, ein bisschen später, auch wirtschaftsorientierte Anwendungsgebiete hinzu.
Mitte der 1950er-Jahre etablierten sich die ersten Unternehmen, die kommerziell Rechensysteme anboten, nämlich in Gestalt einer neuen Gattung Hardware, der sogenannten Großrechner oder Mainframes. Die Software für diese Systeme war mittlerweile so komplex, dass man diese in zwei »Schichten« strukturierte. Direkt auf der Hardware setzte eine Softwareschicht auf, die von der »nackten« Hardware abstrahierte und gewisse Basisdienste anbot. Diese Schicht nannte man Operation System oder Operating System – das Betriebssystem war geboren. Oberhalb dieser Schicht residierte das Applikationsprogramm (zunächst immer nur eines!), das die Basisdienste des Betriebssystems benutzte und die vom Nutzer gewünschte Funktionalität erbrachte (Abbildung 1.1).
Abbildung 1.1: Einfache Schichtenarchitektur eines Rechensystems
Weite Verbreitung fanden Mainframes des Typs »IBM System/360«, die mit dem Betriebssystem OS/360 ausgerüstet waren. Über viele Entwicklungsetappen wurde dieses zur heute existierenden Mainframe-Architektur z Systems und dem dazugehörigen Betriebssystem z/OS weiterentwickelt. Innerhalb der Klasse der Mainframes ist Kompatibilität, also die Übertragbarkeit von Programmen zwischen verschiedenen Generationen, ausgesprochen wichtig. Infolge der hohen Anschaffungs- und Betriebskosten bilden Mainframes für sich eine verhältnismäßig abgeschlossene Welt.
Die fortschreitende Miniaturisierung führte etwa ab 1970 zu einer neuen Klasse von Rechnern, die etwas weniger leistungsfähig, dafür jedoch deutlich weniger kostenintensiv als Mainframes waren. Bezugnehmend auf ihre geringere Größe wurden sie Minicomputer genannt. Nach heutigen Maßstäben ist die Bezeichnung grob irreführend; sie spielt darauf an, dass der Rechner nicht mehr einen ganzen Raum einnahm, sondern etwa die Größe eines halbhohen Schrankes hatte.
Ein wichtiger Hersteller dieser Systeme war die Digital Equipment Corporation (DEC), deren PDP-Serie und insbesondere die VAX genannten Rechner sehr populär in Industrie und Forschung waren. Betriebssystemseitig wurden sie zum einen durch die proprietäre Eigenentwicklung VMS betrieben (VMS bedeutet Virtual Memory System und weist auf das hier erstmals verwirklichte Konzept des virtuellen Speichers hin, das Sie im Kapitel 9 ziemlich genau kennenlernen werden). Zum anderen wurden Minicomputer mit UNIX betrieben, einem damals brandneuen, in den Bell Laboratories von Ken Thompson und Dennis Ritchie entwickelten Betriebssystem, das zusammen mit der Programmiersprache C entworfen wurde. Während VMS heute nur noch ein Nischendasein führt, wurde UNIX zum Stammvater für eine ganze Betriebssystem-Familie, von denen Ihnen einige in diesem Buch noch viele Male begegnen werden.
Minicomputer als Geräteklasse wurden in den 1980er-Jahren zunächst von den wiederum preiswerteren Workstations verdrängt, die zumeist ebenfalls unter UNIX genutzt wurden und ihrerseits Mitte der 1990er-Jahre durch leistungsstarke PCs ersetzt wurden.
Hardwaretechnisch gesehen entstand die nächste Geräteklasse, die der Mikrocomputer, gegen Ende der 1970er-Jahre. Sie zeichneten sich durch die erstmals verwendeten Mikroprozessoren aus, die im Vergleich zu Minicomputern wiederum bedeutende Kosten- und Größenreduktionen erlaubten. Nun wurde es möglich, dass einzelne Personen Computer für sich allein beanspruchten, sowohl in der Form von Heimcomputern als auch professionell als Personal Computer.
In dieser Gerätekategorie kann man drei Subkategorien unterscheiden:
Diese Systeme wurden mit preiswerten 8- oder 16-Bit-CPUs gebaut und waren als Hobbygeräte sowohl zum Spielen als auch für einfache »ernsthafte« Verarbeitungsaufgaben gedacht. Systeme wie Commodore 64 und Amiga, Sinclair ZX81 und Spectrum oder Atari ST wurden in ungeheuren Stückzahlen gebaut und verkauft. Die Betriebssysteme bestanden zunächst häufig aus einer Sammlung wichtiger Routinen, die im ROM des Rechners abgelegt waren. Später entwickelte man auch für diese kleine Geräteklasse »richtige« Betriebssysteme wie CP/M von Digital Research oder AmigaOS des Commodore Amiga, das bereits eine grafische Oberfläche anbot sowie Multitasking beherrschte.
Die ungeheure Vielfalt an Herstellern und zueinander inkompatiblen Geräten und Betriebssystemen (das bedeutet, man konnte die Software eines Systems im Normalfall nicht auf einem anderen Gerät betreiben) sowie die zögerlich erfolgende Weiterentwicklung der Hardware sorgte für das weitgehende Aussterben dieser Rechnerkategorie in den 1990er-Jahren.
Nachdem die 1976 gegründete Firma Apple Inc. zunächst einen sehr erfolgreichen Heimcomputer, den Apple II, entwickelt hatte, konzentrierte man sich mit der Macintosh-Familie alsbald auf höherwertige Rechner, die in der Folge besonders von Kreativen geschätzt wurden. Apple gebührt der Verdienst, mit macOS als Erster eine grafische Nutzerschnittstelle (Graphical User Interface, GUI) für ein kommerzielles System etabliert zu haben. Dieses Betriebssystem, mittlerweile OS X genannt, wird bis heute entwickelt und ausschließlich für die Mac-Reihe von Apple genutzt.
Im Jahr 1981 entwickelte die Firma IBM auf der Basis des Intel-Prozessors 8086 einen preiswerten Computer für Büroanwendungen, dessen Architektur bewusst offen dokumentiert wurde, den sogenannten IBM-PC. In den folgenden Jahren etablierte sich diese Architektur als Quasistandard für Bürocomputer, wobei die in rascher Folge erscheinenden Prozessoren der Firma Intel (80286, 80386, Intel Pentium …) sowie dazu kompatible CPUs von weiteren Herstellern wie AMD als CPU Verwendung fanden. Die offene und modulare Architektur motivierte zahllose Mitbewerber, zum original IBM PC kompatible Rechner zu entwickeln. Zum ursprünglichen Desktop-Format kamen alsbald auch transportable Modelle hinzu; mittlerweile sind die Mehrzahl der verkauften Systeme Notebooks. Der enorme Wettbewerb und Kostendruck ließ IBM bereits Mitte der 1990er-Jahre aus diesem Markt aussteigen. Die Plattform wird regelmäßig weiterentwickelt, und die genutzten Bussysteme und Prozessoren werden aktualisiert. Die meisten verkauften »Computer für den persönlichen Bedarf« gehören zu dieser Kategorie – trotz modernerer Systeme wie Tablets.
Als Betriebssystem des IBM PC und kompatibler Systeme kam zunächst MS-DOS des damals völlig unbekannten Herstellers Microsoft zum Einsatz. Die Legenden, wie es zu dieser ungewöhnlichen Entscheidung kam, sind zahlreich. Angeblich soll Gary Kildall, der Entwickler des für 8-Bit-Computer häufig eingesetzten Betriebssystems CP/M, die verantwortlichen IBM-Manager brüskiert haben, sodass diese eher notgedrungen mit dem 26-jährigen Bill Gates über die Lieferung eines Betriebssystems verhandelten, das dieser über einen Subunternehmer innerhalb kurzer Zeit zur Verfügung stellen konnte.
Nachdem die grafische Oberfläche des Apple Macintosh ziemliches Aufsehen erregte, begann man auch bei Microsoft, eine grafische Oberfläche unter dem Namen Windows zu entwickeln. Diese wurde zunächst als »Aufsatz« für MS-DOS konzipiert; die Version 1.0 erblickte 1985 das Licht der Welt. Weitere Versionen folgten rasch. Gleichzeitig entwickelte Microsoft eine neue Betriebssystemarchitektur unter dem Namen Windows NT, die 1993 vorgestellt wurde. Es ist gewissermaßen der Urvater des gegenwärtig aktuellen Windows 11. MS-DOS erwies sich schon in den 1990er-Jahren als nicht mehr zeitgemäß, es endete 1994 mit der Version 6.22. Die auf MS-DOS basierende Windows-Entwicklungslinie endete 2006 mit Windows ME.
Darüber hinaus gibt es für den PC ein weiteres wichtiges Betriebssystem, das 1991 als Hobbyprojekt des finnischen Informatikstudenten Linux Torvalds entstand: Linux. Im Prinzip handelt es sich um eine Neuimplementierung von UNIX, das als Gemeinschaftsprojekt von über den gesamten Erdball verteilten Freiwilligen, aber auch durch Beiträge aus der Industrie entstand und noch entsteht. Im Gegensatz zu den bislang erwähnten proprietären Betriebssystemen, deren Quellcode im Allgemeinen den Herstellern gehört und geheim ist, steht der Quellcode von Linux unter einer sogenannten Open-Source-Lizenz, er kann von jedem eingesehen und nach Gutdünken verändert werden. Linux wurde ursprünglich für die PC-Architektur auf Basis des 80386-Prozessors entwickelt, mittlerweile gibt es jedoch Portierungen auf viele andere Architekturen.
Es gibt sogar noch eine weitere quelloffene, UNIX-basierte Betriebssystemfamilie für den PC (und nicht nur ihn): das Trio FreeBSD, OpenBSD und NetBSD. Das Akronym BSD steht hierbei für Berkeley Software Distribution, ein Begriff aus der Historie von UNIX. In vielen Aspekten ähneln diese Betriebssysteme Linux. An dieser Stelle soll nicht näher auf sie eingegangen werden.
Die PC-Architektur dominierte den Markt persönlicher Computer für lange Zeit. Dies änderte sich mit der Entwicklung mobiler Rechner, die mit dem Mobiltelefon ihren Anfang nahm. Betriebssystemtechnisch gab es dabei bemerkenswerte Dualitäten zur Entwicklung von »stationären« Computern.
Die erste Generation von Mobiltelefonen besaß wiederum kein Betriebssystem. Der eingebaute Mikroprozessor übernahm die Kommunikation mit dem Nutzer sowie die Codierung und Dekodierung der Sprachdaten. Die Software war in Form einer Firmware realisiert. Jeder Hersteller kochte hierbei sein eigenes Süppchen.
Bald kam man auf die Idee, wenn nun schon einmal eine CPU im Gerät verbaut war, diese auch für weitere »konventionelle« Datenverwaltungsaufgaben, wie die persönliche Termin- und Kontaktverwaltung, die Erfassung von Notizen und die Aufzeichnung und Wiedergabe von Audio- und Videoinformationen, zu nutzen: Das Smartphone entstand. Der resultierende deutlich höhere Entwicklungsaufwand für die Software rechtfertigte wiederum die Abstraktion eines Betriebssystems. Etwa ab 1997 erschienen in rascher Folge Geräte, die auf dem Betriebssystem Symbian OS und Prozessoren der ARM-Architektur basierten. Symbian OS besitzt eine wechselvolle Geschichte. Die mit Symbian ausgestatteten Geräte litten an verschiedenen »Kinderkrankheiten«, nicht zuletzt war die Nutzung mobiler Daten durch das Nichtvorhandensein entsprechender Dienste und Tarife sehr teuer.
Dies änderte sich mit der Einführung des AppleiPhone 2007, das auf dem Betriebssystem iOS basiert und seinerseits eine modifizierte UNIX-Implementierung, den sogenannte XNU-Kernel, nutzt. Kurze Zeit danach stellte Google mit Android eine zweite Betriebssystembasis für mobile Geräte vor. Android wiederum basiert auf dem bereits erwähnten Linux. Beide Betriebssysteme, iOS und Android, sind mittlerweile für weitere mobile Geräte, wie die etwa ab 2010 entwickelten Tablet-Computer, verfügbar.
Damit ist der kurze Rundgang über 60 Jahre Betriebssystem-Entwicklung zunächst komplett. Er ist stark subjektiv gefärbt und erhebt natürlich auch keinen Anspruch auf Vollständigkeit. Insbesondere haben wir den Bereich der eingebetteten Systeme bislang ausgeblendet.
Kurz gefasst stellt sich die gegenwärtige Situation folgendermaßen dar: Desktop-PCs oder Notebooks mit Intel- (oder kompatiblem) Prozessor werden abgesehen von einer Minderheit, die eine BSD-Variante oder Linux nutzen, mit einer Version von Windows betrieben. Rechner der Firma Apple bilden eine eigenen Kosmos: Mobile Geräte nutzen iOS, die Notebooks und Desktop-Geräte laufen unter OS X. Rechner, die Daten als Server im Inter- oder Intranet zur Verfügung stellen, nutzen sehr häufig Linux oder BSD, seltener Windows Server. Mobile Geräte, die nicht von Apple stammen, setzen fast ausschließlich Android (und damit Linux) ein.
Falls Sie den Abschnitt über die Historie der Betriebssysteme nicht übersprungen haben, wissen Sie bereits, dass ein Betriebssystem gewissermaßen als Mittler zwischen der Hardware und den Applikationsprogrammen fungiert. Im Folgenden soll diese recht allgemeine Aussage genauer ausgeführt werden. Dabei werden Sie erfahren, warum ein Betriebssystem für den Betrieb eines Rechensystems essenziell ist.
Ein Computer benötigt aus Hardwaresicht mindestens zwei Komponenten: ein »Gehirn« in Form eines Mikroprozessors (Central Processing Unit, CPU), der seinerseits Befehle über ihm zur Verfügung gestellten Daten ausführt. Zur kurzfristigen Speicherung dieser Daten benötigt das System den Hauptspeicher (Random Access Memory, RAM). Will man die Daten längerfristig aufbewahren, dann wird ein Massenspeicher wie die Festplatte notwendig.
Darüber hinaus sind sogenannte Peripheriegeräte nötig, damit der Nutzer oder andere Computer mit dem Computer selbst in Verbindung treten können, also Bildschirm, Tastatur, Maus, Drucker, Netzwerkgeräte und so weiter.
Die Kommunikation mit und zwischen diesen Geräten ist sehr einfach und trotzdem sehr mühsam, denn alle Beteiligten verstehen nur zwei Zustände: 0 und 1 (davon aber ungeheure Massen). Alles, was in die CPU oder in die Festplatte hinein- oder aus ihr herauskommt, sind sehr lange Ströme von Nullen und Einsen. Ein JPEG-Bild, wie es Kameras zu Tausenden liefern, besteht aus einem endlichen, aber sehr langen Bitstrom aus Nullen und Einsen.
Damit wir Menschen mit Rechensystemen interagieren und kommunizieren können, benötigen wir Abstraktionen, die diese Bitströme in etwas für unseren Verstand Fassbares verwandeln. Das gerade angesprochene JPEG-Bild ist eine solche Abstraktion, allerdings eine anwendungsorientierte.
Stellen Sie sich vor, Sie wollen als Nutzer ein Bild vom Massen- in den Hauptspeicher transferieren, um es beispielsweise zu bearbeiten. Haben Sie kein Betriebssystem mit geeigneten Abstraktionen zur Verfügung, dann müssen Sie ungefähr das Folgende tun:
Sie müssen zunächst eine Liste mit einigen Hunderttausend (oder Millionen) Einträgen konsultieren, in der vermerkt ist, welche Blöcke der Festplatte das Bild enthalten. Danach müssten Sie eine Reihe sogenannter SATA-Kommandos an die Festplatte schicken, die diese anweisen, die entsprechenden Blöcke bereitzustellen. Danach müssten Sie in einer weiteren riesigen Liste nachsehen, ob es im Hauptspeicher einen Bereich geeigneter Größe gibt, und diesen für das Bild reservieren (also der Liste einen entsprechenden Eintrag hinzufügen). Schließlich, das ist sicherlich der einfachste Teil, müssten Sie die Daten aus dem Speicher der Festplatte in den Hauptspeicher kopieren. Umständlich, nicht wahr?
Interessanterweise sind die gerade angesprochenen SATA-Kommandos ebenfalls Abstraktionen, deren Funktionalität zu früheren Zeiten durch das Betriebssystem hätten erbracht werden müssen, die aber mittlerweile durch die Festplatte selbst bereitgestellt werden, die ihrerseits wiederum ein spezielles Rechensystem, (mit eigenem Prozessor, Speicher, Programm) konstituiert.
Ein Betriebssystem nimmt Ihnen den allergrößten Teil dieser Arbeit ab, indem es die Abstraktion »Datei« zur Verfügung stellt.
Es gibt natürlich viele weitere Abstraktionen, die Sie bei der Lektüre des Buches kennenlernen werden. Manche sind Ihnen intuitiv längst vertraut, wie die bereits angesprochene Datei oder das »Verzeichnis«, von manchen haben Sie vielleicht schon einmal gehört, etwa vom »Prozess« oder von einem »Thread«, und von manchen lesen Sie vielleicht zum ersten Mal: »Semaphore« oder »Spinlock«.
Natürlich nützen Ihnen Abstraktionen allein gar nichts. Sie müssen mit ihnen hantieren, arbeiten können. Dafür wiederum stellt ein Betriebssystem Dienste in Form von sogenannten Systemrufen zur Verfügung. Für die oben angesprochene Aufgabe, ein Bild in einen Hauptspeicherbereich zu laden, bietet Ihnen das Betriebssystem UNIX die Dienste open(), read() und mmap() an.
In Rechensystemen geschieht sehr viel gleichzeitig. Dies betrifft sowohl den Kontext der Applikationsprogramme als auch das Betriebssystem selbst. Beim Mehrnutzerbetrieb leuchtet dies unmittelbar ein. Ist die Aussage jedoch auch haltbar für ein Einprozessorsystem, das vielleicht gar keinen interaktiven Nutzerbetrieb kennt, sagen wir für eine mikroprozessorgesteuerte Waschmaschine?
Nun, es ist sicherlich ein Unterschied, ob das System 24 oder eine CPU besitzt und ob einige Dutzend oder gar kein einziger Nutzer mit dem System arbeiten. Nichtsdestotrotz gibt es selbst bei den klitzekleinsten Rechnern Gleichzeitigkeit in Form von externen Ereignissen. Prozessoren besitzen sogenannte Interrupteingänge, die externe Geräte zur Signalisierung nutzen, indem sie einen kurzen elektrischen Impuls senden. Beispielsweise könnte es möglich sein, dass die Bedienelemente der Kaffeemaschine jeweils an einem Interrupteingang angeschlossen sind. Damit kann es wieder Gleichzeitigkeit geben: Die CPU führt Code aus, sie könnte zum Beispiel gerade eine Statusmeldung auf dem Display ausgeben. Der Nutzer drückt eine Taste, und nun muss die Kaffeemaschine mit dieser Form der Gleichzeitigkeit (Bedienhandlung und Meldungsausgabe) klarkommen. Soll sie zunächst die Ausgabe der Meldung fortsetzen oder lieber sofort auf die gedrückte Taste reagieren? Was ist, wenn der Nutzer zwei Tasten gleichzeitig drückt und somit zwei Interrupts generiert werden?
Zugegebenermaßen ist das Beispiel hinreichend simpel, und der Systemdesigner wird sicher für alle möglichen Formen der Parallelität eine für die Maschine und den Menschen akzeptable Lösung finden. Es soll aber nur die Aussage untersetzen, dass in Rechensystemen viele Dinge gleichzeitig geschehen und es im Allgemeinen Aufgabe des Betriebssystems ist, diese Gleichzeitigkeit zu koordinieren. In Kapitel 7 erlernen Sie dafür geeignete Techniken und Algorithmen.
Aus Sicht des Nutzers eines Rechensystems besteht dieses eigentlich aus Aktivitäten und Ressourcen. Sie werden im Kapitel 5 »Action! Aktivitäten, Prozesse und all das« genauer erfahren, was es mit diesen beiden Kategorien auf sich hat. An dieser Stelle soll es reichen, sich Aktivitäten als »Programme in Ausführung« vorzustellen. Sehr häufig findet man in der Literatur auch den Begriff Prozess.
Der Speicher, egal, ob temporär oder permanent, die CPUs, sämtliche Peripheriegeräte, jedoch auch viele sogenannte logische Abstraktionen (das sind Dinge im Rechner, die keine physische Repräsentation haben, die Sie also weder betrachten noch anfassen können), wie Dateien, Verzeichnisse oder ein (digital abgelegter) Film, werden als Ressourcen bezeichnet, die durch die Aktivitäten benutzt werden können. Damit sich die Aktivitäten nicht ins Gehege kommen, also sich gegenseitig Ressourcen streitig machen, verweigern oder sich ungerechtfertigte Vorteile bei der Ressourcenzuteilung verschaffen, sorgt das Betriebssystem für die Verwaltung der Ressourcen. Dazu gehört auch, die Nutzung aller Ressourcen ordentlich zu protokollieren, um Fairness zu gewährleisten oder Informationen für den Fall einer Überlastung zu sammeln.
Last but not least muss das Betriebssystem dem Nutzer Mechanismen zur Absicherung des Rechensystems bieten. Besondere Bedeutung kommt dabei dem sogenannten virtuellen Speicher zu, den Sie im Kapitel 9 gründlich kennenlernen werden. Ebenso zählen dazu die Verwirklichung eines Mehrnutzerkonzepts, die sichere Ablage von Passworthashes, ein sicherer Bootprozess und vieles andere mehr. Diese Funktionalität ist klassischer Bestandteil des Betriebssystems, denn es hat sich gezeigt, dass die Implementation von Sicherheitsmechanismen in der Applikationsschicht ohne solide Basis im Betriebssystem keinen zuverlässigen Schutz bieten kann.
Fassen wir zusammen: Betriebssysteme haben die folgenden vier Aufgaben:
Verwirklichung von Abstraktionen und Diensten für die Arbeit mit dem System
Koordination aller parallelen Abläufe
Verwaltung aller Ressourcen eines Systems
Realisierung einer Basis für die Systemsicherheit
Um den Fokus auf Betriebssysteme noch ein bisschen zu weiten, sollen im Folgenden kurz einige Perspektiven auf Betriebssysteme skizziert werden. Wer interessiert sich für Betriebssysteme und aus welchem Grund?
Nun, beginnen wir diesen Rundgang mit dem gewöhnlichen Anwender oder Nutzer. Jeder, der mit Rechensystemen arbeitet, kommt auf die ein oder andere Weise mit dem Betriebssystem in Berührung, sei es durch die normale Interaktion, egal, ob text- oder grafikorientiert (oder beides!), sei es bei der Installation des Systems. Entscheidend für den Nutzer ist daher häufig die Benutzeroberfläche (User Interface, UI), während die »inneren Werte« zunächst weniger von Interesse sind, solange alles einigermaßen funktioniert.
Während der private Nutzer meist das System selbst aufspielt, konfiguriert und wartet, erfolgt diese Tätigkeit im professionellen Umfeld meist über Administratoren, also Spezialisten, die für den Betrieb größerer IT-Infrastrukturen ausgebildet und angestellt sind. Ihre Perspektive unterscheidet sich von der des gewöhnlichen Nutzers; im Vordergrund stehen Aspekte wie effiziente Interaktionsmöglichkeiten, die Stabilität der Systeme, die Automatisierbarkeit von sich wiederholenden Bedienoperationen oder die Verfügbarkeit von Werkzeugen zur Überwachung und Wartung größerer Rechnerbestände.
Bei den Softwareentwicklern kann man grob zwei Kategorien unterscheiden. Entwickeln sie Dienstprogramme (Applikationen, im Jargon mobiler Systeme meist Apps genannt) für ein bestimmtes Betriebssystem, dann müssen sie Kenntnisse über dessen Dienste besitzen und darüber, wie eine bestimmte Funktionalität mit den Diensten eines (oder mehrerer) Betriebssysteme effizient erbracht werden kann. Entsteht eine Komponente für ein Betriebssystem, beispielsweise ein Treiber (eine Komponente, die es dem Betriebssystem ermöglicht, mit einem bestimmten Hardwaregerät zu kommunizieren), dann sind zusätzliche umfangreiche Kenntnisse über die Interna des jeweiligen Systems notwendig. Diese sind oftmals sehr komplex!
Ein Angreifer, landläufig auch gern fälschlich als »Hacker« bezeichnet, wiederum benötigt diese exzellenten Kenntnisse über Interna von Betriebssystemen ebenso. Ihn interessiert meist, welche Komponenten eines Betriebssystems Schwachstellen aufweisen, um diese auszunutzen und sich beispielsweise unberechtigt Zugang zum System zu verschaffen. Jedoch ist nicht jeder Angreifer potenziell ein Feind: Sogenannte Penetration Tester tun genau das Gleiche, bieten es jedoch als Dienstleistung an, um die Widerstandsfähigkeit der Systeme ihrer Kunden gegen Angriffe zu erhöhen.
IT-Forensiker wiederum sind bestrebt, die nach einem erfolgreichen Angriff vorhandenen Spuren innerhalb des Systems, ob im Haupt- oder auf dem Massenspeicher, auszuwerten, und dem Angreifer auf die Schliche zu kommen, die Systeme zu säubern und mögliche Verletzungen der Datenintegrität zu beheben. Dies tun sie auch bei der Suche nach Beweismitteln auf den Rechnern Tatverdächtiger. Daher kennen sie sich besonders mit den Eigenarten der zahlreichen Dateisysteme und den Möglichkeiten der Wiederherstellung absichtlich und versehentlich gelöschter Daten aus, was im Übrigen sogenannte Datenretter ebenfalls als Dienstleistung anbieten.
Der Blick von Betriebssystem-Wissenschaftlern ist wiederum verschieden zu den bislang aufgeführten Kategorien. Diese versuchen, ganz unterschiedliche Aspekte von Betriebssystemen zu optimieren. So gibt es Informatiker, die über bessere Nutzerschnittstellen nachdenken, genauso wie andere versuchen, neue Abstraktionen zu finden oder die Leistung oder die Sicherheit bestehender Systeme und zugehöriger Werkzeuge zu verbessern. Sie stehen häufig in direkter Konkurrenz zu den bereits erwähnten Angreifern.
Nicht vergessen werden sollten Computerarchäologen. Ihr Interesse gilt insbesondere der Analyse und allgemein dem Betrieb historischer Rechensysteme, die natürlich historische Betriebssysteme benutzen. Zwei Anwendungsbeispiele sind die Restauration alter Datenbestände und das Zugänglichmachen von historischer Software, die als erhaltenswertes Kulturgut angesehen wird (Computerspiele!). Sie bedienen sich dabei Techniken der Virtualisierung und der Emulation, da die Verfügbarkeit der originalen Rechensysteme durch Verschleiß und Ausfall von Hardwarekomponenten kontinuierlich abnimmt.
Zu guter Letzt soll noch die spezifische Perspektive des Lehrers erwähnt sein. Sein Fokus (und auch der dieses Buches) liegt auf der Vermittlung von Prinzipien, Verfahren und Algorithmen, die bei Entwurf, Konstruktion, Analyse und Optimierung von Betriebssystemen angewandt werden. Dazu benötigt er (Lehr-)Betriebssysteme, die die enorme Komplexität »richtiger« Betriebssysteme vereinfachen und die insbesondere einen niedrigschwelligen Zugang zu den »Innereien« des Systems erlauben. Das Betriebssystem MINIX [25] des Informatikers Andrew S. Tanenbaum ist ein Beispiel dafür. Sie werden diesem Namen im Laufe der Lektüre noch einige Male begegnen.
Nachdem Sie verschiedene Sichtweisen auf Betriebssysteme kennengelernt haben, ist es nun an der Zeit, einmal einen Blick auf die Fülle an existierenden Betriebssystemen zu werfen. Eine einfache Auflistung, die keinen Anspruch auf Vollständigkeit erhebt, finden Sie beispielsweise in der Wikipedia unter dem URL https://de.wikipedia.org/wiki/Liste_von_Betriebssystemen.
Um einen besseren Überblick über die schier unübersehbare Menge von Betrachtungsgegenständen (hier: Betriebssystemen) zu erhalten, ist es nützlich, diese zu klassifizieren, also nach bestimmten Kriterien in Kategorien einzuteilen. Dies soll im folgenden Abschnitt geschehen.
Ein unmittelbar einleuchtendes Kriterium ist die Frage, welches Problem oder welche Problemklasse mittels des betrachteten Rechensystems gelöst werden soll. In erster Näherung kann man hier Universal- von Spezialbetriebssystemen unterscheiden. Universalbetriebssysteme sind, wie der Name nahelegt, für eine große Menge verschiedener Problemkreise oder Rechensysteme geeignet, während Spezialbetriebssysteme üblicherweise sehr genau für einen einzigen Einsatzzweck optimiert wurden.
Etwas klarer wird die Klassifizierung, wenn konkretere Kategorien genutzt werden.
Desktop-Betriebssysteme, also Betriebssysteme, die auf Rechensystemen für die Büroarbeit laufen, sind beispielsweise viele Windows-Varianten, MacOS für Systeme der Firma Apple sowie Linux und die historischen Vertreter MS-DOS und CP/M.
Typische Betriebssysteme, die für Server jeglicher Art genutzt werden, sind Linux, die BSD-Varianten, viele weitere UNIX-Derivate sowie Windows Server.
Eine besonders große und heterogene Kategorie sind sogenannte eingebettete Systeme, also Rechner, die Teil eines größeren Gesamtsystems und als typische Computer häufig gar nicht zu erkennen sind. Darunter fallen industrielle Steuerungen, Rechner in Autos, Flugzeugen und Schiffen (der sogenannte Automotive-Bereich), aber auch Consumer Electronics, wie Fernseher, Haushaltgeräte und Ähnliches. Exemplarisch sollen die Betriebssysteme Linux, FreeRTOS, OSEK und VxWorks genannt sein; es gibt sehr viele weitere Vertreter.
Eng mit dieser Kategorie verwandt sind die sogenannten Echtzeitbetriebssysteme. Diese Systeme zeichnen sich dadurch aus, dass sie die Dauer bestimmter Operationen, beispielsweise Reaktionszeiten auf externe Ereignisse, garantieren können. Dies erfordert im Vergleich zu universellen Vertretern des Genres umfangreiche Modifikationen. Die bereits erwähnten FreeRTOS, OSEK und VxWorks sind ebenso Vertreter dieser Kategorie.
Wie bereits im historischen Abriss erwähnt wurde, bildeten und bilden die Mainframe-Computer eine eigene Welt, was die hier genutzten Betriebssysteme unterstreichen. Systeme von IBM nutzten das bereits erwähnte OS/360, später OS/390 und nun z/OS; jedoch begegnet uns erneut das bereits häufig referenzierte Linux. Andere Hersteller wie Unisys oder Fujitsu nutzen ebenfalls eigene Betriebssysteme.
Man kann also also resümieren, dass es auf der einen Seite Betriebssysteme gibt, die für spezielle Einsatzzwecke konzipiert sind. Andererseits gibt es universell einsetzbare Betriebssysteme, die man in mehreren Systemkategorien finden kann.
Es gibt viele weitere Kriterien, nach denen sich Betriebssysteme einteilen lassen. Dazu zählen:
Unterstützte Hardwareplattform.
Manche Betriebssysteme sind für verhältnismäßig viele verschiedene Prozessorarchitekturen verfügbar. Meist wurde das Betriebssystem zunächst für eine einzige Plattform entwickelt und später auf andere übertragen (
portiert
). Als Beispiel für diese Art Betriebssystem kann wiederum Linux dienen. Andere Betriebssysteme sind nur für eine einzige Architektur verfügbar. MS-DOS ist beispielsweise nur für die Intel-Prozessorarchitektur verfügbar, allerdings wiederum für mehrere konkrete Prozessortypen ab dem Intel 8086.
Möglichkeit, Nutzer zu unterscheiden.
Gibt es die Abstraktion
Nutzer
(
User
), so können verschiedene Benutzer mit dem System arbeiten. Dies muss nicht notwendigerweise gleichzeitig erfolgen. Sind mehrere Nutzer möglich, dann spricht man vom
Mehrnutzerbetriebssystem
(
Multi-User Operating System
) andernfalls vom
Einnutzerbetriebssystem
(
Single-User Operating System
). Das Betriebssystem Android beispielsweise wurde ab Version 4.2 mit der Mehrnutzerfähigkeit ausgestattet, bis dahin konnte es pro Gerät nur einen einzigen Nutzer geben. MS-DOS ist klassisch nur für einen einzigen Nutzer, alle modernen Desktop- und Server-Betriebssysteme sind für mehrere Nutzer ausgelegt.
Anzahl gleichzeitig möglicher unabhängiger Aktivitäten. Betriebssysteme, die nur eine einzige Aktivität zu einem Zeitpunkt abarbeiten können, werden Singletasking-Betriebssysteme genannt (hier gibt es keine adäquate deutsche Bezeichnung). Kann der Nutzer mehrere Aktivitäten gleichzeitig etablieren (also beispielsweise die Textverarbeitung, ein Spiel und den Videoplayer hintereinander starten), ohne die anderen Aktivitäten jeweils zuvor beenden zu müssen, dann spricht man von einem Multitasking-Betriebssystem.
Bitte beachten Sie, dass ein System, das nur einen einzigen Prozessor oder Core aufweist, prinzipiell zu einem Zeitpunkt nur eine Aktivität ausführen kann, da nur ein einziger Registersatz zur Verfügung steht. Ein Multitasking-Betriebssystem erlaubt es trotzdem, mehrere Aktivitäten zu etablieren; die Illusion der Gleichzeitigkeit kommt durch die enorme Arbeitsgeschwindigkeit und das schnelle Umschalten zwischen den Aktivitäten zustande. Diesen Vorgang werden Sie im Kapitel 6 »Planen von Aktivitäten (Scheduling)« näher kennenlernen. Multi-User-Systeme bedingen nicht unbedingt Multitasking, denn es kommt darauf an, ob mehrere Nutzer hintereinander oder gleichzeitig arbeiten können.
Kommunikation mit der Umwelt. Systeme, mit denen die Nutzer in einen Dialog treten können, werden interaktive Systeme genannt. Es gibt jedoch auch Systeme, bei denen diese Arbeitsweise nicht im Vordergrund steht, beispielsweise Clusterrechner, die aus vielen Tausenden Einzelrechnern bestehen. Die Anschaffung und der Betrieb solcher Systeme sind extrem teuer, sodass man es sich nicht leisten kann, wertvolle Rechenzeit durch (aus Sicht des Rechners) extrem langsame interaktive Kommunikation mit dem Nutzer zu verschwenden.
Typische interaktive Systeme, wie das Notebook, auf dem der Autor dieses Buch schreibt, tun genau das: Sie warten fast ihre gesamte Betriebszeit auf die Eingaben des Nutzers. Sehr schnelle Schreiber schaffen ungefähr 500 Anschläge pro Minute. Das benutzte Notebook besitzt eine Taktfrequenz von 3.6 GHz und verfügt über vier Rechenkerne. In einer Minute könnte es ungefähr
