Betriebssysteme für Dummies - Robert Baumgartl - E-Book

Betriebssysteme für Dummies E-Book

Robert Baumgartl

0,0
20,99 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.

Mehr erfahren.
Beschreibung

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:

Android
iOS
von Legimi
zertifizierten E-Readern

Seitenzahl: 522

Veröffentlichungsjahr: 2023

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Betriebssysteme für Dummies

Schummelseite

WICHTIGE UNIX-KOMMANDOS

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

WICHTIGE VI-KOMMANDOS

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

DIE WICHTIGSTEN UNIX-SYSTEMRUFE

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

Über den Autor

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.

Inhaltsverzeichnis

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

Tabellenverzeichnis

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

Illustrationsverzeichnis

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

Orientierungspunkte

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

Seitenliste

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

Einleitung

Über dieses Buch

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.

Konventionen in diesem Buch

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.

Symbole in diesem Buch

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.

Törichte Annahmen über den Leser

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.

Wie dieses Buch aufgebaut ist

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.

Teil I: Grundlagen

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: Aktivitäten im Betriebssystem

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.

Teil III: Interaktion zwischen Aktivitäten

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.

Teil IV: Speicher

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.

Teil V: Sicherheit

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.

Teil VI: Top-Ten-Teil

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!

Wie Sie dieses Buch lesen sollten

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

Grundlagen

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

Ein bisschen Einführung

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.

Was ist ein Betriebssystem?

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.

Betriebssystem oder Firmware?

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.

Eine (ganz) kurze Geschichte der Betriebssysteme

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.

Im Anfang war das Nichts

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.

Großrechner (Mainframes)

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.

Minicomputer

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.

Mikrocomputer

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:

Heimcomputer

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.

Apple-Computer

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.

Der IBM-PC und seine Nachfahren

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.

Mobile Rechner

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.

Aufgaben eines Betriebssystems

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.

Bereitstellung von Abstraktionen und Diensten

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.

Koordinierung paralleler Abläufe

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.

Ressourcenverwaltung inklusive Protokollierung

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.

Basis für Schutz und Sicherheit

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

Perspektiven auf Betriebssysteme

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.

Klassifizierung von Betriebssystemen

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.

Klassifizierung nach Einsatzzweck

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.

Andere Klassifikationskriterien

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