1.2 Aufgaben eines Betriebssystems 
Zusammengefasst verwaltet ein Betriebssystem also die Betriebsmittel eines Computers – also Rechenzeit, Speicher oder I/O-Geräte – und ermöglicht dem Benutzer das Ausführen von Programmen. Zwei weitere, jedoch eher indirekte Aufgaben, die wir bisher noch nicht extra benannt haben, sind die Abstraktion und die Virtualisierung.
1.2.1 Abstraktion 
Die Abstraktion haben wir von Anfang an als selbstverständlich betrachtet. Niemand möchte Maschinencode schreiben oder sich direkt mit dem Prozessor auseinandersetzen. Man möchte viel lieber auf ein hübsches Symbol auf dem Desktop klicken, um ein bestimmtes Programm zu starten. So weit, so gut.
Ein weiteres gutes Beispiel sind die bereits vorgestellten Syscalls. Sie abstrahieren die komplexen Fähigkeiten des Betriebssystems in wenige, konkret gegebene Funktionsaufrufe. Eine ebenfalls sofort einsichtige Anwendung des Abstraktionsprinzips gibt es beim Dateisystem. Eine Festplatte wird schließlich über ihre geometrischen Eigenschaften adressiert, also über ihre Zylinder, Köpfe und Sektoren. <Teilweise wird aber auch schon vom Controller davon abstrahiert, sodass das Betriebssystem nur noch mit abstrakten Blocknummern zu tun hat.> Für den Benutzer werden diese unhandlichen Eigenschaften jedoch auf Dateien und Verzeichnisse abgebildet und diese sogar mit diversen Rechten und anderen Eigenschaften versehen. Die Syscalls dienen nun dazu, diese abstrahierte Funktionalität aus Programmen heraus nutzen zu können.
Geräte als Dateien
Unter Unix-Systemen wie zum Beispiel Linux und BSD werden verwaltete Geräte auf spezielle Dateien im /dev-Verzeichnis abgebildet. Das hat den Vorteil, dass man auch für die Benutzung von I/O-Geräten Rechte vergeben kann und sich die Handhabung nicht groß von der des restlichen Systems unterscheidet.
1.2.2 Virtualisierung
Die Virtualisierung ist eine weitere wichtige Aufgabe des Betriebssystems. Der Begriff bezeichnet in der Informatik eine Ressourcenteilung möglichst ohne ungünstige Nebenwirkung für die Benutzer.
Für den Benutzer beziehungsweise sein Programm sieht es nämlich so aus, als stünde die Ressource ausschließlich ihm zur Verfügung.
Virtuelle Prozessoren
Das erste Beispiel kennen wir bereits: die Virtualisierung des Prozessors. Das bereits erwähnte preemptive Multitasking ermöglicht das quasiparallele Ausführen von mehreren Programmen.
Dazu wird, wie wir bereits festgestellt haben, die verfügbare Prozessorzeit in viele gleich große Zeitscheiben unterteilt, die vom Betriebssystem nun einzelnen Programmen zugewiesen werden. Im Folgenden kann dann jedes Programm rechnen, als hätte es den gesamten Prozessor für sich allein. Es merkt nichts von den Unterbrechungen und von anderen parallel laufenden Programmen.
Virtueller Speicher
Wie schon allein der Name dieses ebenfalls bereits erwähnten Prinzips sagt, handelt es sich hier um eine Virtualisierung des Speichers. Jedes Programm hat den Eindruck, dass ihm der gesamte Hauptspeicher zur Verfügung steht. Alle Adressen können benutzt werden, ohne dass das Programm von anderen, zur selben Zeit laufenden Programmen etwas merken würde. Die anderen Programme haben natürlich ebenfalls ihren eigenen virtuellen Speicher.
Greift ein Programm auf eine (virtuelle) Adresse zu, wird diese von der MMU in die entsprechende reale Adresse im Hauptspeicher übersetzt. Das Setup, also die Verwaltung der MMU und des Hauptspeichers, übernimmt dabei wieder das Betriebssystem. Dieses wird auch durch einen Interrupt informiert, falls mal ein Speicherbereich, auf den ein Programm gern zugreifen möchte, auf die Festplatte ausgelagert worden ist. In der Behandlungsroutine des Interrupts kann das Betriebssystem diesen Speicherblock nun wieder in den Hauptspeicher kopieren und die fehlgeschlagene Anweisung des unterbrochenen Programms noch einmal wiederholen – diesmal ist die betreffende virtuelle Adresse im Hauptspeicher eingelagert, und die Adressübersetzung der MMU schlägt nicht mehr fehl.
Speicher anfordern
Diese vom Betriebssystem zu erledigende Verwaltungsarbeit für den virtuellen Speicher zeigt auch die Relevanz eines Syscalls auf, der für ein Programm neuen Speicher anfordert. Der meist malloc() genannte Funktionsaufruf sorgt nun dafür, dass die Memory Management Unit entsprechend initialisiert wird. Dann kann dem Programm die virtuelle Adresse zurückgegeben werden, unter der der angeforderte Speicherbereich angesprochen werden kann.
Würde ein Programm auf eine virtuelle Adresse zugreifen, die noch nicht initialisiert wäre, würde die MMU natürlich wieder das Betriebssystem über einen Interrupt informieren. Das Betriebssystem würde nun nachsehen, ob der betreffende Speicherbereich vielleicht ausgelagert wäre – aber das ist er nicht.
Es liegt also ein klassischer Speicherzugriffsfehler vor, bei dem ein Programm normalerweise beendet wird. Falls so ein Fehler auftritt, liegt meist ein etwas komplizierterer Programmierfehler vor.
#include <stdlib.h>
int main()
{
char* puffer; // Variable deklarieren
puffer = malloc(4096); // 4 KB = 4096 Bytes
// anfordern
// Nun kann der Speicherbereich benutzt werden
free(puffer); // Speicherbereich
// wieder freigeben
// Jeder Zugriff, der nach dem Freigeben auf den
// Speicherbereich der Variable 'puffer'
// erfolgt, führt zu einem Speicherzugriffsfehler
return 0; // Programm beenden
}Listing 1.6 Anfordern von Hauptspeicher mit malloc()
Das obige Beispiel in der Programmiersprache C zeigt sehr deutlich, wie sich der Programmierer bei dieser Sprache selbst um die Verwaltung des Speichers kümmern kann. Der Speicher wird nicht nur per malloc() angefordert, sondern muss auch mit einem Aufruf von free() wieder freigegeben werden – natürlich ist das ebenfalls ein Syscall.
Andere Programmiersprachen
Andere Programmiersprachen verstecken teilweise diese Syscalls vor dem Programmierer. Damit ist das Programmieren zwar einfacher, aber nicht unbedingt flexibler. In Java zum Beispiel sieht die Anforderung von neuem Speicher ganz anders aus, auch wenn intern natürlich dieselben Syscalls genutzt werden.
Neue Objekte werden dort mit einem Aufruf von new angelegt. Natürlich reserviert dieser Aufruf auch den für das Objekt nötigen Speicherplatz, ohne dass sich der Programmierer näher damit auseinandersetzen muss, wie viel das ist. Einen free()-ähnlichen Aufruf sucht man dagegen vergeblich. Nicht mehr benutzter Speicher wird nämlich von der das Java-Programm ausführenden virtuellen Maschine, also dem Programm, das den maschinenunabhängigen Bytecode interpretiert, durch eine Garbage Collection wieder freigegeben: Diese »Müllsammlung« scannt den gesamten Speicherbereich der Applikation nach nicht mehr genutzten Referenzen und löscht diese schließlich. Diese Garbage Collection war früher auf etwas langsameren Systemen auch der Grund, wieso bei etwas umfangreicheren Java-Programmen das System in regelmäßigen Abständen stehen blieb. Mittlerweile sind die Systeme aber so leistungsfähig, dass dieser Performance-Nachteil nicht mehr ins Gewicht fällt.
1.2.3 Ressourcenverwaltung
Betrachtet man die letzten Beispiele, so leuchtet auch die Aufgabe der Ressourcenverwaltung ein.
Ressourcen werden dabei im weitesten Sinne verstanden, der Prozessor zählt nämlich genauso als Ressource wie die durch ihn realisierte Rechenzeit. Zu den verwalteten Ressourcen gehören also weiterhin:
- Prozessor
- Rechenleistung
- Speicher
- Timer
- Festplatte
- Maus
- Bildschirm
- Drucker
- Netzwerkkarten
Spooling
Warum und inwiefern eine solche Verwaltung nötig ist, zeigt das klassische Druckerbeispiel: Stellen Sie sich vor, zwei Programme würden parallel zu drucken versuchen. Hätten beide direkten Zugriff auf den Drucker, wären ziemlich wahrscheinlich beide Ausgaben auf einem Ausdruck gemischt – so ziemlich das genaue Gegenteil von dem, was erreicht werden sollte. Stattdessen wird das Betriebssystem (oder wie im Falle von Linux und BSD) ein spezieller Dienst die Druckwünsche entgegennehmen und erst einmal auf der Festplatte zwischenspeichern. Dieser Dienst könnte dann exklusiv auf den Drucker zugreifen und einen Auftrag nach dem anderen abarbeiten, ohne dass es zu Problemen und Konflikten kommt.
