Betriebssysteme

HTBLVA FÜR EDV UND ORGANISATION SPENGERGASSE Betriebssysteme Operating Systems Bernhard Friedreich, 4AHDVK 23.11.2008 Dieses Dokument beschreibt den Grundaufbau von Betriebssystemen und vergleicht, anhand vielfacher Aspekte, die wichtigsten Betriebssysteme miteinander. Fachbegriffe, die aus dem Englischen kommen, werden im Original verwendet, um der Eindeutschung von Fachbegriffen entgegen zu wirken. Inhaltsverzeichnis 1. Einführung ............................................................................................................................... 4 1.1. Grundlagen ...................................................................................................................... 4 1.1.1. Was ist ein Betriebssystem? ........................................................................................ 4 1.1.2. Grundlegende Aufgaben ............................................................................................. 4 1.1.3. Geschichte ................................................................................................................... 5 1.1.4. Häufig genutzte Betriebssysteme ................................................................................ 6 1.1.5. Sonstige Betriebssysteme............................................................................................ 7 2. Kernel ...................................................................................................................................... 8 2.1. Grundlagen ...................................................................................................................... 8 2.2. Architekturen................................................................................................................... 8 2.2.1. Microkernel ................................................................................................................. 9 2.2.2. Monolithic kernel ........................................................................................................ 9 2.2.3. Hybrid Kernel ............................................................................................................. 10 2.2.4. Monolithic vs. Micro vs. Hybrid ................................................................................. 10 2.2.5. Exokernel ................................................................................................................... 10 2.3. Inter‐Process Communication (IPC) .............................................................................. 11 2.4. Sicherheit und Design .................................................................................................... 11 2.4.1. Virtual Memory/Paging ............................................................................................. 12 2.5. Scheduler ....................................................................................................................... 12 2.5.1. Auswahl an Strategien/Scheduler ............................................................................. 13 2.6. Treiber ........................................................................................................................... 13 2.7. Hardware Abstraction Layer (HAL) ................................................................................ 13 2.8. Dateisysteme ................................................................................................................. 14 2.8.1. Arten .......................................................................................................................... 14 3. 2.9. Interrupts ....................................................................................................................... 15 2.10. Windows NT .................................................................................................................. 16 2.11. Linux .............................................................................................................................. 16 2.12. Mac OS X ........................................................................................................................ 17 2.13. GNU Hurd ...................................................................................................................... 17 Startup ................................................................................................................................... 18 3.1. Grundlagen .................................................................................................................... 18 3.2. Bootloader ..................................................................................................................... 18 3.2.1. Multistage Boot‐Loader ............................................................................................. 18 3.2.2. Chain‐Loader ............................................................................................................. 18 Seite 2 von 28 4. 3.3. Linux .............................................................................................................................. 19 3.4. Mac OS X ........................................................................................................................ 20 3.5. Frühere Windows Versionen ......................................................................................... 20 3.6. Windows Vista ............................................................................................................... 20 Graphische Oberfläche .......................................................................................................... 21 4.1. Graphische Subsystems ................................................................................................. 21 4.1.1. Linux (X Server) .......................................................................................................... 21 4.1.2. Mac OS X (Quartz) ..................................................................................................... 22 4.2. Linux Desktop Environments ......................................................................................... 22 4.2.1. Gnome ....................................................................................................................... 23 4.2.2. KDE 3 .......................................................................................................................... 24 4.2.3. KDE 4 .......................................................................................................................... 25 4.3. Window Manager .......................................................................................................... 26 4.3.1. Grundlagen ................................................................................................................ 26 5. Quellen .................................................................................................................................. 28 Seite 3 von 28 1. Einführung 1.1.
Grundlagen 1.1.1.
Was ist ein Betriebssystem? Ein Betriebssystem ist eine Software, welche die Verwendung eines PCs ermöglicht, indem sie eine Schnittstelle zur Hardware darstellt, sie verwaltet, und andere Aufgaben durchführt, ohne denen es nicht möglich wäre die PC‐ Hardware zu verwenden. Weiters zählt zu den Aufgaben eines Betriebssystems die Verwaltung von Ein‐ und Ausgabegeräte, die korrekte Zuteilung von Speicherbereichen und die Ausführung von Programmen. 1.1.1.1.
Begriffserklärung Für den Begriff Betriebssystem existiert keine eindeutige Definition und er kann sehr weitläufig verwendet werden. Der englische Stammbegriff hatte eine spezielle Bedeutung, auf die später näher eingegangen wird. Der Kernel ist die einzige Komponente, die in allen Definitionen des Wortes Betriebssystems enthalten ist. Im engeren Sinne ist der Kernel das Betriebssystem. Daher würde man, wenn man von Linux spricht eigentlich korrekterweise vom Kernel sprechen. Meist ist damit jedoch das ganze System gemeint. Wenn man vom kompletten System spricht, so sollte man es als Distribution (Zusammenstellung von Tools und Komponenten) bezeichnen. Diese klare Trennung ist jedoch bei proprietären System nicht möglich, weshalb der Begriff Betriebssystem sich nicht klar definieren lässt. Weitere Komponenten, die in einigen Definitionen enthalten sind, umfassen folgende Themen: • Hardware Verwaltung • Treiber • Schnittstelle für Systemfunktionen • Teile einer Grafischen Oberfläche • System‐ Dienste, ‐Programme • Interprocess Communication (IPC) • Dateisysteme • Datentransfer über Netzwerke • Skriptsprache für das System • Bootloader • Programmbibliotheken 1.1.2.
Grundlegende Aufgaben Ein Betriebssystem hat vielerlei Aufgabengebiete. An vorderster Stelle ermöglicht es uns die Arbeit mit einem Computer. Weitere Aufgabengebiete sind: • Verwaltung der Prozessorzeit • Verwaltung des Speicherplatzes für Anwendungen • Verwaltung der (angeschlossenen) Geräte • Laden und Unterbrechen von Programmen • Bereitstellung von Schnittstellen für Programme Seite 4 von 28 1.1.3.
Geschichte Betriebssysteme in der Form, wie wir sie nun kennen existieren vergleichsweise kurz, zu den Systemen, die es früher gab. Es waren keine Systeme, wie Windows oder Linux, wie wir sie derzeit kennen mit einem Terminal oder einer Grafischen Oberfläche sondern Systeme, die man per Hand bedienen musste. Eines davon waren die Lochkartensysteme. 1.1.3.1.
Lochkartensysteme Beim Einsatz von Lochkartensystemen brauchte man eine Person dazu, das System mit Lochkarten zu „füttern“. Dies war der sogenannte „Operator“, wovon auch der Begriff „Operating System“ kommt, was auf Deutsch übersetzt soviel wie „Betriebssystem“ bedeutet. Die Aufgabe der Programmierer war es damals die Lochkarten zu fertigen (zu programmieren) und den Kartenstapel an die Operatoren weiterzugeben. Dieser ließ die Karten von der Maschine einlesen und händigte dem Programmierer anschließend die Ergebnisse in ausgedruckter Form aus. Diese Lochkartensysteme besaßen kein Betriebssystem in der Form wie wir es derzeit kennen. Stattdessen hatten diese Systeme einen sogenannten „resident monitor“ im Speicher, welcher für die Kontrolle des derzeit ausgeführten Programmes sorgte. Der „resident monitor“ wurde später durch das BIOS und den Betriebssystem Kernel ersetzt. 1.1.3.2.
Multiprogrammed Batch System Die Weiterentwicklung der Lochkartensysteme waren die Multiprogrammed Batch Systeme (deutsch: Stapelverarbeitung). Diese konnten mehrere Programme und Daten im Speicher verhalten, was eine schnellere Abarbeitung der Kartenstapel ermöglichte. Diese waren auch erstmals autonom und benötigten keine interaktive Bearbeitung der Aufgaben mehr. Dabei war ein eigenes Programm nötig welches Ein‐ und Ausgabe Geräte, den Speicher und vor allem die CPU Zeit (Scheduling) verwaltete. Dies waren die Beginne der allerersten wirklichen Betriebssysteme. Da es verschiedenste Anwendungsbereiche für solche Systeme gab, entstanden jede Menge Abspaltungen, die man zum Teil auch heute noch antrifft: • Parallele Systeme • Verteilte Systeme • PC‐Systeme • Time‐Sharing‐Systeme • Real‐Time‐Systeme • Handheld‐Systeme Batch Processing (Stapelverarbeitung) ist auch heute noch ein nicht zu vernachlässigender Aspekt in Betriebssystemen. Auf UNIX/Linux System besonders weit verbreitet, hat es aber auch unter Windows mit der cmd.exe, dem Windows Script Host und der recht neuen Windows PowerShell nach wie vor eine wichtige Bedeutung, speziell im Bereich der Systemadministration und Abarbeitung immer wiederkehrender Tätigkeiten (z.B. automatisierte Backups). Seite 5 von 28 1.1.4.
Häufig genutzte Betriebssysteme 1.1.4.1.
Heimanwender Das derzeit weit verbreitetste System für den normalen Heimanwender ist Microsoft Windows. Es liegt mit einem Marktanteil von stolzen 92% (Stand: Oktober 2008) vor allen anderen. Durch den weitläufigen Einsatz von Windows führte dies dazu, dass Microsoft eine Monopolstellung bekam, und damit den ganzen Betriebssystemmarkt bestimmen kann. Zu dieser Situation kam es, da Microsoft eine gute Marketing Strategie hatte, und zur richtigen Zeit am rechten Ort war. Anderen Systemen gelingt es nur sehr schwer Fuß zu fassen, da es jede Menge Probleme mit fehlender Software und Treibern gibt, welche von Herstellern oftmals nur für Windows zur Verfügung gestellt werden. Doch natürlich gibt es auch für die anderen Systeme einen Verwendungszweck. So ist Apples Mac OS vor allem bei Computerneulingen und Multimediaanwendungen oft im Einsatz. Der Anteil von Linux Systemen beschränkt sich nach wie vor auf ein Minimum, meist im Einsatz bei Servern oder bei Endanwendern mit umfangreicheren EDV Kenntnissen. Ebenso gibt es auch Anwender, die sich nicht nur auf ein System beschränken, sondern für jede Aufgabe das System verwenden, welches die Aufgabe für sie am besten löst. Der tatsächliche Marktanteil von Betriebssystemen lässt sich nur sehr schwer bis gar nicht ermitteln, da es keine Möglichkeit gibt herauszufinden, welche Systeme eingesetzt werden. Die Browseridentifikation gibt keinen eindeutigen Aufschluss darüber, welches System eingesetzt wird, da man sie fälschen kann, was oftmals für einige Webservices nötig ist. Die Verkaufszahlen entsprechen nicht den tatsächlichen Nutzungszahlen, da es erstens Mehrplatzlizenzen gibt, und zweitens, sehr viele Raubkopien von Windows Systemen im Umlauf sind, was ein weiterer Grund für die weite Verbreitung von Windows ist. Den Anteil von GNU Linux und anderen freien Betriebssystemen kann man noch weniger genau feststellen, da es hier nur in den seltensten Fällen zu Verkaufszahlen kommt, aufgrund dessen, dass die meisten Linux Distributionen gratis herunter zu laden sind. Marktanteil Heimanwender – ungefähre Aufteilung (lt. Wikipedia) Seite 6 von 28 1.1.4.2.
Serverbereich Im Serverbereich sieht die Sache nicht so klar aus. Es gibt jede Menge Evangelisten, die der Meinung sind, dass Linux/Unix das einzig Wahre im Serverbereich ist, und dass nur die Command Line ein effektives Mittel zur Administration ist. Auf der anderen Seite sind diejenigen, die meinen, dass es deutlich besser ist ein System per Grafischer Oberfläche zu konfigurieren. Sowohl von Windows, Linux als auch Mac OS gibt es eigene Server Varianten. Diese zeichnen sich in der Regel durch eine höhere Stabilität, längeren Support und einer schlankeren Basisinstallation aus. Weitere Mitspieler in diesem Bereich sind auch zahlreiche andere Unix Systeme und Novell NetWare. Vor allem im Bereich der verteilten Systeme (Cluster) sind Linux Systeme sehr verbreitet, da man sie bis zum Letzten an seine eigenen Bedürfnisse umschreiben/konfigurieren kann. 1.1.5.
Sonstige Betriebssysteme Abgesehen von normalen Heimanwender und Server Betriebssystemen gibt es natürlich auch noch Betriebssysteme für die verschiedensten anderen Zwecke (z.B. embedded Systeme, „distributed computing“ Systeme, …), doch all diese hier aufzuzählen würde den Rahmen dieses Dokumentes sprengen. Ein weiteres Heimbenutzersystem, welches einer Nennung wert ist, heißt ReactOS. 1.1.5.1.
ReactOS ReactOS ist ein Open‐Source‐Betriebssystem, welches es sich zum Ziel gesetzt hat ein komplett Windows NT kompatibles System zu erstellen. Sobald es fertig ist, sollte es komplett kompatibel zu sämtlichen Windows Anwendungen und Treibern sein. Derzeit befindet es sich noch im Alpha Stadium, doch laut Roadmap soll es diesen 2009 verlassen. Link: http://www.reactos.org/de/index.html Seite 7 von 28 2. Kernel 2.1.
Grundlagen Der Kernel ist die zentrale Komponente eines Betriebssystems. Zu seinen Aufgaben zählen die Verwaltung der verfügbaren Ressourcen (Speicher, Prozessor, Input/Output Geräte). Durch Inter Process Communication (IPC) und Systemaufrufe werden diese Fähigkeiten an höher liegende Schichten weitergegeben (z.B. Prozesse). Wie diese Aufgaben geregelt sind je nach Aufbau und Implementation des Kernels (siehe Architekturen) unterschiedlich. Ein Betriebssystem besteht aus vielen Abstraktionsschichten, wovon der Kernel als niedrigste Schicht, die in Software implementiert ist, gilt (mit Ausnahme des HAL). Der Startvorgang des Kernels beginnt damit, dass er durch einen Bootloader geladen wird, welcher im privilegierten CPU Mode (x86) läuft. Ab dieser Stelle fängt der Kernel an sich selbst und die angeschlossene Hardware zu initialisieren. Sobald er damit fertig ist, startet er den ersten Prozess. Unter Linux und Unix ähnlichen Systemen ist dies der Init Prozess. Sobald diese Phase abgeschlossen ist, wartet der Kernel auf weitere Systems Calls (Software) oder Interrupts (Hardware). Solange der Kernel nichts zu tun hat, befindet er sich üblicherweise in der „idle loop“. Zur Funktionalität, die ein Kernel zur Verfügung stellen sollte, zählen Funktionen um Prozessen Prioritäten zuweisen zu können, IPC, Prozess Synchronisation, Context Switching, Interrupt Handling und Prozess Verwaltung (Erzeugen, Beenden, Pausieren, …). Ein wichtiger Punkt beim Ressourcen Management ist die Definition von „execution domains“, welche zur Absicherung des Kernel Adressraums benötigt wird, ansonsten hätten Programme die Möglichkeit Kernel Speicherbereiche zu überschreiben, was zwangsläufig zu einem Absturz führen würde. 2.2.
Architekturen Um die vielen Aufgaben, die ein Kernel hat, möglichst effizient zu bewältigen entstanden verschiedene Kernel Architekturen, die alle für spezielle Fähigkeiten ausgelegt sind. So ist zum Beispiel der Monolithic Kernel darauf ausgelegt möglichst viel Programmcode im selben Adressraum wie der Kernel auszuführen/zu beinhalten, was zu einer höheren Performance führt, aber schlechter wartbar ist. Microkernel sind so angelegt, dass die meisten Services im User Space ausgeführt werden, was zu einer besseren Wartbarkeit und Modularität des Kernels führt, aber zu einer schlechteren Performance. Die Verwaltung der Zugriffsrechte (kann eine höhere Abstraktinosschicht auf die Speicherverwaltung zugreifen), liegt ebenfalls im Bereich der Kernelarchitektur. Hier gilt auch wieder, dass beim Monolithic Kernel wenig Freiraum gewährt wird (es ist bereits alles im Kernel implementiert), wogegen beim Microkernel vieles in den höheren Abstraktionsschichten implementiert werden kann/muss. Dieser Trennung der Abstraktionsschichten und Zugriffsrechte wird als „Separation of mechanism and policy“ bezeichnet. Dies führt zur Kernel/User Mode Architektur, die eine Möglichkeit darstellt mit Hilfe der „hierachical protection domains“ (Ring) den Betriebssystem Kern vor ungewolltem Zugriff aus Seite 8 von 28 höheren Layern zu schützen. Daher werden sämtliche Kernel Module, die Schutz benötigen direkt in den Kernel integriert (Kernel mode – Monolithic Kernel). Die meisten Kernel passen jedoch nicht in dieses Schema, sondern fallen eher in die Kategorie Hybrid Kernel. 2.2.1.
Microkernel Ein Microkernel stellt nur eine simple Abstraktion über die Hardware da, die einfache System Aufrufe implementiert, um Speicherverwaltung, Multitasking und IPC zu ermöglichen. Andere Funktionalität wie zum Beispiel Netzwerk, wird dabei nicht im Kernel integriert, sondern läuft als so genannter „Server“ als User‐Space Programm. Microkernel sind leichter zu pflegen (programmiertechnisch), da sie modularer aufgebaut sind, jedoch können die Unmengen an Systemaufrufen und „Context switches“, der CPU, zu einem deutlich langsameren System führen, als bei einem Monolithic Kernel. Durch das Prinzip der Microkernel wird es auch möglich Teile des Betriebssystems in einer High Level Programmiersprache, als normale Anwendungen, zu schreiben. Ein Beispiel für einen Microkernel ist der nicht sehr weit verbreitete Mach Kernel. Er diente vor allem als Experimentierkernel, welcher für den Einsatz in „Parallel Computing Systems“ und in der „Distributed Computation“ gedacht war. Jedoch befinden sich einige Mach ähnliche Kernel im Einsatz. Der wohl bekannteste davon ist Mac OS X Kernel (Darwin). Weiters setzen auch einige BSD Derivate auf einen Mach ähnlichen Kernel (z.B.: FreeBSD). 2.2.2.
Monolithic kernel In einem Monolithic Kernel befinden sich alle Services im selben Speicherbereich wie der Kernel. Dies führt zu einer höheren Performance, da einige Context Switches wegfallen. Nach Meinung mancher Entwickler, z.B. UNIX Entwickler Ken Thompson, ist es einfacher einen Monolithic Kernel zu entwerfen und zu implementieren, als einen Microkernel. Der Hauptnachteil von Monolithic Kernels ist die Abhängigkeit zwischen den Systemkomponenten. Sobald eine Komponente (z.B. ein Treiber) instabil ist, ist das ganze System vor Abstürzen nicht gefeit. Linux besitzt einen Monolithic Kernel, was bereits zu einigen hitzigen Diskussionen geführt hat, und auch zu lauten Rufen nach einem neuen Kernel für die Open Source Welt. Für diesen Zweck wäre HURD, ein Microkernel, prinzipiell geeignet, jedoch befindet sich dieser bereits seit sehr langer Zeit in Entwicklung und es ist nach wie vor kein Ende in Sicht. Seite 9 von 28 2.2.3.
Hybrid Kernel Hybrid Kernel stellen einen Kompromiss zwischen dem Monolithic und dem Microkernel dar. Das bedeutet, dass einige Services im Kernel Space (z.B. Netzwerk) und einige im User Space laufen (z.B.: Geräte Treiber). Windows hat einen Hybrid Kernel (NT Kernel), was sich auch dadurch bemerkbar macht, dass eine der häufigsten Ursachen für Blue Screens ein Treiber Probleme sind (vor allem Grafikkarten Treiber). Einen Begriff den Microsoft selbst für seinen Kernel verwendet ist „Macro Kernel“ Andere Beispiele für Hybrid Kernels sind der NetWare Kernel, der ReactOS Kernel und einige BSD Kernel. 2.2.4.
Monolithic vs. Micro vs. Hybrid 2.2.5.
Exokernel Exokernel werden als „vertikal strukturierte Betriebssysteme“ bezeichnet. Seine Hauptfunktion besteht darin, Ressourcenkonflikte zu verhindern und Zugriffsrechte zu prüfen. Im Gegensatz zu den anderen Kernel Architekturen beschränkt sich der Exokernel auf möglichst wenig Abstraktion. Das bedeutet, dass sie den Programmen direkten Zugriff auf Speicherblöcke und Festplattenbereiche ermöglichen. Die Aufgabe des Exokernels ist es dabei, festzustellen, ob ein Ressourcenkonflikt vorliegt, und ob die Ressource auch benutzt werden darf. 2.2.5.1.
Hypervisor/Paravirtualisierung Ein Begriff, der hier erwähnenswert wäre, ist die Paravirtualisierung. Das bedeutet, dass man ein Betriebssystem teilvirtualisiert auf seinem aktuellen laufen lassen kann. Hierfür muss jedoch das zu Host System angepasst werden (der Kernel), um dem System Zugriff auf den Ring 0 der x86 Architektur zu gewähren. Dabei greift das GastSystem auf den Hypervisor des Hostsystems zurück. Ein Beispiel für einen paravirtualisierten Hypervisor stellt XEN dar. Seite 10 von 28 Der Hypervisor befindet sich nun im Ring 0, und verwaltet einen oder mehrere Kernel, welche sich dann im Ring 1 befinden. Dies kann jedoch auch für schädliche Anwendungen benutzt werden (Virtual Machine Based Rootkit). 2.3.
Inter‐Process Communication (IPC) IPC stellt eine Reihe von Techniken zum Austausch von Daten innerhalb mehrerer Threads oder Prozesse dar. IPC umfasst die Weitergabe von Nachrichten (message passing), Synchronisation (synchronization), Gemeinsamer Speicher (shared memory) und Remote Procedure Calls (RPC). Eine wichtige Implementation von IPC stellt D‐Bus dar, das vor allem in der Opensource Welt eine wichtige Rolle darstellt (Gnome/KDE). Von Microsoft wäre hier COM(+), OLE, DCOM und die Windows Communication Foundation zu nennen. POSIX stellt ebenfalls Richtlinien zur IPC bereit. 2.4.
Sicherheit und Design Ein wichtiger Aspekt beim Design eines Kernels besteht darin ihn Fehler tolerant zu entwickeln, und vor schädlichem Verhalten zu schützen. Die Ring (Domain) Darstellung der CPU stellt dabei ein Sicherheitsstufenmodell eines Prozesses dar. Dieses schränkt den Prozess auf die Nutzung eines bestimmten Speicherbereichs und Befehlssatzes ein. Dies ist vor allem dazu sinnvoll, um Prozesse voneinander abzuschotten und die Hardware zu abstrahieren (HAL Layer). Der Befehlssatz wird für unprivilegierte Prozesse derart eingeschränkt, dass sie keinen direkt Zugriffauf die Hardware haben. Der Zugriff auf den Speicherbereich anderer Prozesse wird durch Speichervirtualisierung (Virtual Memory) verhindert. Somit wird gewährleistet, dass Prozesse von Ring 3 keinen Zugriff auf Prozesse in Ring 0 oder andere Prozesse aus anderen Ringen haben. Da die unprivilegierten Prozesse nicht auf Hardware direkt zugreifen können, existieren „Gates“ als Zugangs‐Tore im Speicher auf den darunterliegenden Ring, um auf die Programmierschnittstelle des Betriebssystemkerns zugreifen zu können. Ring 0 Prozesse laufen im „kernel mode“, alle anderen im „user mode“. Jeder Wechsel von einem Ring zu einem anderen erfordert in der CPU einen „Context Switch“, der einige Rechenzeit in Anspruch nimmt und daher Performance kritisch ist. Solche Ringe sind eine verbreitete Implementierung einer “Hierachical protection domain”, um ein gewisses Maß an Fehlertoleranz zu gewährleisten. Damit das Virtual Memory Konzept funktioniert muss die CPU muss über eine „Memory Management Unit“ (MMU) verfügen, welche dafür sorgt, dass zwischen virtuellen und physikalischen Speicheradressen vermittelt werden kann. Seite 11 von 28 2.4.1.
Virtual Memory/Paging Ein Problem, das bei dieser Adressraum Zuteilung auftritt, ist die externe Fragmentierung. Darunter versteht man, dass jedem Prozess vom Betriebssystem ein Adressraum zugeordnet wird, was dazu führt, dass mit der Zeit Lücken zwischen den Prozessen entstehen. Um dem entgegen zu wirken wird „Paging“ verwendet. Beim Paging wird zwischen Logischem und physikalischem Speicher unterschieden. Der logische Speicher ist in gleich große Stücke unterteilt, die man als „pages“ bezeichnet. Der physikalische Speicher wird in „frames“ unterteilt. Eine page und der zugehörige frame haben dabei die gleiche Größe. Um pages und frames einander zuordnen zu können verwendet man eine „page table“ für jeden Prozess. Zwar ist der logische Speicher weiterhin zusammenhängend, im physischen Speicher können die benachbarten Seiten jedoch in weit von einander entfernt liegenden frames abgelegt werden. 2.5.
Scheduler Ein Scheduler ist grob gesagt ein Programm, welches die zeitliche Ausführung mehrerer Prozesse steuert. Es gibt unter anderen folgenden Kategorien: • unterbrechende (preemptive) • nicht unterbrechende (non preemptive – kooperativ) Kooperative Scheduler lassen einen Prozess, nachdem ihm die CPU einmal zugeteilt wurde, solange laufen, bis dieser diese von sich aus wieder freigibt oder bis er blockiert. Preemptive Scheduler teilen die CPU von vornherein nur für eine bestimmte Zeitspanne zu und entziehen dem Prozess diese daraufhin wieder. Es gibt unterschiedliche Scheduler für unterschiedliche Aufgaben. So kann man zum Beispiel ein Augenmerk auf Fairness (Prozessorzeit ungefähr gleich verteilen), Balance (andere Ressourcen wie Festplatten und Netzwerk haben ebenfalls eine Priorität), Reaktionszeit und viele andere Faktoren legen. Seite 12 von 28 2.5.1.
•
•
•
•
•
•
•
Auswahl an Strategien/Scheduler First‐Come First‐Served (FIFO Verfahren): Prozesse werden komplett, in der Reihenfolge ihres Eingangs bearbeitet Shortest‐Remaining‐Time Round Robin (Zeitscheibenverfahren): alle Prozesse bekommen nacheinander Zugriff auf die Ressourcen, jedoch immer nur für einen kurzen Zeitschlitz Prioritätsscheduling Multilevel Feedback queue O(1) scheduler Completely Fair Scheduler (CFS): Linux Scheduler seit 2.6.23 2.6.
Treiber Ein Treiber ist ein Programm, welches es normalen Programmen ermöglicht mit einer Hardware zu interagieren. Treiber sind Gerät und Betriebssystem spezifisch. Unter Linux können Treiber entweder direkt in den Kernel kompiliert werden, oder als separates Kernel Modul geladen werden. Diese werden als *.ko (Kernel Object) Dateien gekennzeichnet. Unter Mac OS X werden diese als *.kext Dateien und unter Windows als *.sys Dateien bezeichnet. 2.7.
Hardware Abstraction Layer (HAL) HAL ist eine Abstraktionsschicht, die dafür sorgt, dass höher liegende Schichten sich nicht darum sorgen müssen, auf was für einer Hardware sie laufen. Seine Grundfunktion ist es die Unterschiede in der Hardware vor dem Betriebssystem Kernel zu verbergen, was dafür sorgt, dass der meiste Kernel‐Mode Code nicht geändert werden muss, um das System auf einer anderen Hardware laufen lassen zu können. So werden auf unterschiedlicher Hardware (z.B. anderes Mainboard) unterschiedliche HAL Komponenten installiert, und der darüber liegende Kernel bemerkt nichts davon, dass er auf einer anderen Hardware läuft. Wenn sich die darunter liegende Hardware ändert, muss einfach der HAL angepasst werden, und das System läuft auf der neuen Hardware. Natürlich gibt es auch hier Ausnahmen, so greift der Kernel auch zeitweise am HAL vorbei direkt auf die Hardware zu, was jedoch die Portabilität des Kernels verschlechtert. Zur Verwirrung gibt es auch im Unix Bereich eine gleichnamige Software, die es Anwendungen ermöglicht Informationen über die Hardware abzurufen. Auf längere Sicht gesehen wird jedoch HAL durch seinen Nachfolger DeviceKit ersetzt werden, der eine bessere Programmstruktur aufweist, und damit zukunftssicherer sein soll. Seite 13 von 28 2.8.
Dateisysteme Das Dateisystem stellt eine Schicht des Betriebssystems dar, über welche alle Anwendungen Dateien abstrakt über deren Klartext‐Namen zugreifen können. Im Dateisystem selbst werden diese abstrakten Angaben umgesetzt in physische Adressen (Blocknummer, Spur, Sektor, …) auf dem Speichermedium. Auf der Kernel Ebene kommuniziert das Dateisystem dazu mit dem jeweiligen Gerätetreiber und der Firmware des Speichersystems, wodurch letztendlich die Speicherung/Organisation der Daten geschieht. Je nach Medium und Betriebssystem gibt es unterschiedliche, an die Begebenheiten angepasste Dateisysteme. Natürlich bieten auch alle Dateisysteme unterschiedliche Eigenschaften und eigenen sich damit für unterschiedliche Anwendungszwecke. So sind einige auf Datensicherheit, andere auf Performance und wiederum andere auf All‐Zweck Systeme ausgelegt. 2.8.1.
2.8.1.1.
Arten Lineare Dateisysteme Lineare Dateisysteme waren die ersten Systeme zur Verwaltung von Daten. Sie waren im Einsatz bei Lochbändern oder Lochkarten. Weiters werden sie auch heute noch für die Sicherung von Daten bei Magnetbandsystemen eingesetzt. 2.8.1.2.
Hierarchische Dateisysteme Hierarchische Dateisysteme bestehen aus einer Verzeichnisstruktur. Alle aktuellen Betriebssysteme setzen auf hierarchische Dateisysteme. Hier gilt es noch zu unterteilen in Journaling und Nicht‐Journaling Dateisysteme. Virtuelle Dateisysteme: Linux: proc, sysfs, usbfs, devpts FUSE: Filesystem in Userspace NTFS Treiber für Linux: ntfs‐3g Netzwerkdateisysteme: WebDAV: Zugriff auf entfernt liegende Dateien via HTTP SMB (Server Message Block) NFS (Network File System) OCFS2 (Oracle Cluster File System 2) – Cluster Dateisystem Flash Dateisysteme: JFFS(2) YAFFS CD‐ROM Dateisysteme: ISO9660 Joliet Windows: FAT VFAT NTFS Seite 14 von 28 Linux: btrfs: Next Generation Dateisystem ext,2,3,4 JFS XFS ReiserFS, Reiser4 Tux3: versionierendes Dateisystem Mac OS: HFS, HFS+ SUN: ZFS: hochperformantes Dateisystem mit Metainformationen und Checksummen 2.9.
Interrupts Ein Interrupt ist ein Signal, welches eine kurzfristige Unterbrechung eines Programms auslöst, um eine andere zeitkritische Verarbeitung durchführen zu können. In der Regel werden Interrupts nur von Hardware (z.B.: Tastatur, Maus, …) ausgelöst. Jedoch gibt es auch Software Interrupts, welche vor allem für System Aufrufe verwendet werden. Das Signal wird als IRQ (Interrupt Request) bezeichnet und löst eine „Interrupt Service Routine“ (ISR) aus. Sobald sie fertig ist, wird die Ausführung des Programmes an der ursprünglichen Stelle fortgesetzt. Ohne Interrupts wäre „Preemptive Scheduling“ nicht möglich, da Programme nicht mehr unterbrochen werden könnten und damit Input/Output Geräte nicht mehr bedien bar wären. Seite 15 von 28 2.10. Windows NT 2.11. Linux Der Linux Kernel ist in C geschrieben und umfasst zum derzeitigen Zeitpunkt 9709868 Zeilen Code. (Stand: 9. Oktober 2008) Zum Vergleich: Linux 0.01 wurde im September 1991 fertig gestellt und besaß 10239 Zeilen. Linux fand so großen Zuspruch zu Beginn, da es das einzige Quelloffene Betriebssystem war, dem man das Potential zuschrieb, dass man damit die kommerziellen UNIX Systeme ersetzen könnte. Linux steht unter der GNU General Public License version 2 (GPLv2). Obwohl Linux ursprünglich nicht dazu gedacht war portierbar auf andere Plattformen zu sein, ist es nun das am weitest portierte System. Vom iPAQ bis zum IBM Blue Gene Supercomputer ist alles vertreten. Im Bereich der Supercomputer hat es einen Anteil von mehr als 85%. Linux Kernel, die von Linus Torvalds freigegeben werden, und keine speziellen distributionsspezifischen Patches enthalten werden als „Vanilla“ Kernel bezeichnet. Linux Kernel Grundaufbau: http://www.makelinux.net/kernel_map Seite 16 von 28 2.12. Mac OS X Der Kernel von Mac OS heißt Darwin und steht unter der „Apple Public Source License“. Darwin ist ein Hybrid Kernel basierend auf dem XNU (X ist Not Unix) und anderen Open Source Projekten. So ist zum Beispiel der Netzwerk Stack und das VFS auf BSD Komponenten aufgebaut, während der Kernel, an sich, auf dem Mach 3 Microkernel basiert. 2.13. GNU Hurd Hurd ist ein rekursives Akronym: „HIRD of Unix‐Replacing Daemons“ Æ „HURD of Interfaces Representing Depth“ Das Grundprinzip des GNU Hurd ist, dass Betriebssystem Komponenten als eigene Prozesse (Server) laufen. Hurd an sich ist eigentlich nicht der Kernel, sondern die Sammlung von Servern, die auf einem GNU Mach Microkernel aufsetzen. Das führt dazu, dass die meisten Betriebssystem Aktionen keinerlei Privilegien mehr benötigen. Erreicht wird dies durch die Herausnahme der Gerätetreiber, Dateisysteme, Netzwerkprotokolle und ähnlichem aus dem privilegierten Adressraum. Stattdessen laufen sie als normale Benutzerprozesse. GNU Hurd ist zwar bereits seit 1990 in Entwicklung, ist aber noch keineswegs nahe einem Produktivsystem. Für diejenigen, die Duke Nukem Forever kennen, und die Situation, in der es sich befindet… GNU Hurd kommt sicher noch später ;‐) Seite 17 von 28 3. Startup 3.1.
Grundlagen Nach dem Durchlaufen des BIOS startet der Bootloader. Dieser befindet sich standardmäßig im Master Boot Record (MBR). Der Bootloader lädt anschließend den Kernel des Betriebssystems. 3.2.
Bootloader 3.2.1.
Multistage Boot‐Loader Sollte der Code des Bootloaders zu groß für den Boot Sektor sein, so wird der Bootloader in mehrere Stages eingeteilt. In diesem Fall befindet sich nur der Code für die erste Stage (Stufe) im Boot‐Sektor. Weitere Stufen werden von der ersten Stufe aus geladen und sind damit nicht an Größenvorgaben oder sonstige Beschränkungen gebunden. Ein Beispiel für so einen Aufbau wäre, dass die zweite Stufe mit dem Dateisystem umgehen kann, und von eben diesem die dritte Stage lädt. 3.2.2.
Chain‐Loader Durch Einträge in einem Bootloader können auch andere Bootloader aufgerufen werden. Diesen Vorgang bezeichnet man als Chain‐Loading. Ein typischer Anwendungszweck für Chain Loading ist die Installation eines Dual Boot Systems. Weiters werden Chainloader auch bei Installations Medien für Betriebssysteme verwendet, welche nur das Setup starten, wenn man eine Taste drückt, und andernfalls das installierte System starten. Seite 18 von 28 3.3.
Linux Nachdem der Kernel durch den Bootloader (üblicherweise LILO/GRUB) gestartet wurde, ruft der Kernel unter Linux und Unix ähnlichen Systemen den ersten Prozess, das Init auf. Inits verwalten Runlevel und den Start und das Beenden von Prozessen beim Computer Start und Herunterfahren. Das traditionell verwendete Init System ist SysVInit. Es wird nach wie vor überwiegend eingesetzt, jedoch gibt es einige Versuche SysVInit durch ein Alternatives Init zu ersetzen, da SysVInit sehr langsam zu Werke geht. Dies ist der Fall weil es seriell arbeitet und immer abwartet bis der vorherige Prozess gestartet ist, bis es den nächsten startet. Alternative Inits wie zum Beispiel Upstart (Ubuntu Linux) oder eInit (Gentoo) verfolgen hier den Ansatz Daemons („Linux Services“ parallel zu starten, was jedoch dazu führt, dass sämtliche Init Skripts geändert werden müssen, um Abhängigkeiten zwischen den Skripten zu regeln, was ein sehr zeitaufwendiger Prozess ist. Das ist der Grund dafür, dass die meisten alternativen Init Systeme eine Art Kompatiblitätslayer eingebaut haben, der alte Init Skripte unterstützt. Seite 19 von 28 3.4.
Mac OS X BootX, der Apple Bootloader für Mac OS X und Linux, lädt den Darwin Kernel, welcher anschließend launchd startet. Launchd ist ein Opensource Init Ersatz, der ein wenig Intelligenz ins Spiel bringt, indem er nicht unbedingt notwendige Daemons erst startet, wenn auf den jeweiligen Ports Aktivität festgestellt wird. 3.5.
Frühere Windows Versionen NTLDR (NT Loader) ist der Bootloader von Windows (bis Windows XP). NTLDR liest aus der „boot.ini“ die benötige Konfiguration aus. 3.6.
Windows Vista Seit Windows XP hat sich der Bootvorgang grundlegend geändert. 1. BIOS 2. Master Boot Record 3. Boot Sector 4. Windows Boot Manager 5. Konfiguration aus BCD (Boot Configuration Data) auslesen 6. Nach “hiberfile.sys” (Ruhezustand) Datei suchen 7. winload.exe 8. ntoskrnl.exe 9. smss.exe 10. winlogon.exe 11. services und Login BCD: Boot Configuration Data, ersetzt boot.ini winload.exe: Bootloader, lädt Kernel (ntoskrnl.exe) and Gerätetreiber – Äquivalent zu NTLDR Seite 20 von 28 4. Graphische Oberfläche 4.1.
Graphische Subsystems 4.1.1.
Linux (X Server) Das X Window System (X11 oder auch X) ist ein Fenstersystem (GUI System), welches das X Anzeige Protokoll implementiert. X stellt einige Basisframeworks zur Verfügung um Grafische Umgebungen entwickeln zu können. Zu seinen Aufgaben zählt das Zeichnen und Verschieben von Fenstern und das Interagieren mit Maus und Tastatur. X stellt dabei keine Benutzeroberfläche bereit, sondern überlässt es, ganz nach dem Server/Client Prinzip, den Clients die Implementierung der GUI. Das ist auch der Grund dafür, dass unterschiedliche Frameworks (z.B. Qt/Gtk+/Motif) alle für unterschiedliches Look & Feel sorgen. X ist damit nur ein weiterer Anwendungs‐Layer oberhalb des Kernels, welcher eigene Clients (Anwendungen) laufen hat. Allgemein gesagt ist X ist ein Minimalsystem, bei dem zum Zeichnen lediglich Primitive wie Linien, Muster, ... bereitgestellt werden. Aufgrund dessen, dass X mit dem Server/Client Prinzip konzipiert wurde, ist es auch dafür konzipiert worden über Netzwerke hinweg genutzt zu werden. X ist für die Steuerung von Input/Output Geräten zuständig. Dafür kommuniziert es mit dem Kernel, jedoch gibt es einige Ausnahmen, wo es direkt mit der Hardware kommuniziert, was jedoch weitere Problemfaktoren aufwirft. Es führt dazu, dass das System schwerer zu warten und fehleranfälliger wird. Jedoch besitzt X seit einigen Versionen einen modularen Aufbau, welcher die Wartung erleichtern soll. Einer der Fälle, wo der Kernel umgangen wird, ist die 3D Beschleunigung. Um schnelle 3D‐
Beschleunigung zu ermöglichen, stellt das X‐Window‐System die Schnittstelle Direct Rendering Infrastructure (DRI) bereit, über die Programme direkt auf die 3D‐Hardware zugreifen können. Bei freien Treibern passiert dies durch die OpenGL‐Implementierung Mesa3D, im Fall von proprietären Treibern durch jeweils proprietäre Implementierungen von OpenGL. NVIDIA war hier sehr „mutig“ und hat gar ganze Teile des X Servers umgangen und im eigenen Treiber neu implementiert. Dieser Ansatz ist sehr umstritten und stößt in der Open Source Community auf wenig Gegenliebe. Weiters gibt es generell viel Kritik an proprietären Treibern, da diese in der Regeln nicht auf die sich schnell ändernden Architekturen reagieren können, und in manchen Fällen in der Vergangenheit von minderer Qualität, im Vergleich zu den Windows Treibern, waren. Es gibt derzeit einige Kritik am Design von X, aufgrund dessen, dass es niemals dazu designed wurde 3D Beschleunigung anzubieten. Jedoch wäre der Aufwand den X Server neu zu konzipieren viel zu groß, was der Grund dafür ist, dass nur inkrementell versucht wird das Chaos zu beseitigen (es wurde in den vergangenen Jahren alles Stück für Stück an allen Ecken und Enden angebaut). Seite 21 von 28 4.1.2.
Mac OS X (Quartz) Quartz ist eine Ansammlung von Frameworks zur Darstellung von Fenstern und Grafiken. Es stellt das Mac OS Äquivalent zum Linux X‐Server dar. • Quartz Compositor o Quartz Extreme (Erweiterung des Quartz Compositor um Hardware Beschleunigung) • QuickDraw • Core OpenGL • Quartz 2D • Core Image • Core Animation • Core Video • Core Graphics • QuickTime Aqua ist ein einheitliches GUI Design für Mac OS X. Es beinhaltet Widgets, Farben, Schriftarten und die Dateidialoge, was für eine einheitliche Oberfläche sorgt. 4.2.
Linux Desktop Environments Ein Desktop Environment besteht üblicherweise aus einem Window Manager, einigen Themes, Programmen und Libraries, die es gemeinsam erleichtern mit einem PC zu arbeiten. Die wichtigsten sind Gnome und KDE, jedoch gibt es noch andere kleinere, die auch alle ihre eigenen Anhänger haben. Weitere bekannte Desktop Environments sind Blackbox, Openbox, Fluxbox, Enlightenment, Xfce, Window Maker, CDE und LXDE. Seite 22 von 28 4.2.1.
Gnome Gnome basiert auf dem Gtk+ (Gimp Toolkit) Toolkit, welches in C geschrieben ist. Es ist bekannt dafür einen klaren, auf Unternehmen ausgelegten, schnörkellosen Desktop anzubieten, der sich an der Windows Oberfläche orientiert, um Umsteigern den Einstieg zu erleichtern. Die nächste größere Version ist 3.0, welche für 2009 geplant ist, jedoch soll sie hauptsächlich Altlasten entfernen, und erst nach und nach für neue Features Tür und Tor öffnen. Updates finden bei Gnome in der Regel nur inkrementell statt, um eine möglichst hohe Kompatibilität zu wahren. Gnome hat den Ruf, dass es mehr Wert auf Usability als Funktionalität legt. Seite 23 von 28 4.2.2.
KDE 3 KDE3 basiert auf dem Qt3 Toolkit und ist bereits etwas in die Jahre gekommen. Es gibt bereits einen Nachfolger, der allerdings noch etwas in den Kinderschuhen steckt. Dieser bietet einige interessante Ansätze, die eine rosige Zukunft versprechen. KDE3 selbst eignet sich noch ausgezeichnet zum Arbeiten jedoch bietet KDE dafür keinerlei offiziellen Support mehr dafür an, da der Fokus auf KDE4 liegt. Weiters ist KDE auch sehr bekannt für seine hochqualitativen Programme. Hier ist zum Beispiel Amarok (Musik Player) zu nennen, das für viele Windows Anwender einen Grund darstellt, auf Linux umzusteigen. Seite 24 von 28 4.2.3.
KDE 4 KDE4 ist die neue Generation von KDE, welche auf dem Qt4 Toolkit basiert, was KDE viele neue Möglichkeiten eröffnet. So werden derzeit Schritte unternommen, um es über alle Plattformen verfügbar zu machen. Es existieren bereits Portierungen einiger Programme für Windows und Mac OS X. Es wird daran gearbeitet KDE4 auf mobile Geräte zu portieren. KDE4 bietet viele neue Frameworks, die für die Zukunft viele noch nie gesehene Funktionen versprechen. Erwähnenswert wären hier der revolutionäre neue Desktop (Plasma) und die Desktop Effekte bereitgestellt von KWin (Window Manager). Seite 25 von 28 4.3.
Window Manager 4.3.1.
Grundlagen Ein Window Manager sorgt dafür, dass man mit Fenstern interagieren kann. Das bedeutet, dass man ohne einen Window Manager weder zwischen Fenstern wechseln, noch sie verschieben oder sonst mit ihnen interagieren kann. Manche Window Manager unterstützen alle möglichen (und unmöglichen) Arten von Effekten. Es hängt jedoch sehr vom Grafikkarten Treiber ab, ob diese mit einer brauchbaren Geschwindigkeit funktionieren, was speziell unter Linux ein Problem darstellt. Aufgrund der unterschiedlichen Funktionalität lassen sich diese in verschiedene Kategorien unterteilen. 4.3.1.1.
Compositing Window Managers Ein Compositing Window Manager unterstützt viele Arten von Möglichkeiten Fenster darzustellen, sowohl in 2D als auch Schein‐ 3D. Das erste Betriebssystem, das auf so einen Compositing Window Manager setzte war Mac OS X mit dem Quartz Compositor. Unter Linux gibt es ähnliche Ansätze, so zum Beispiel Compiz. In den Beginnen von Compiz benötigte es noch einen speziellen X Server (XGL), jedoch mittlerweile unterstützt X die nötigen Erweiterungen. Auch Windows Vista bietet einen Compositing Window Manager. Dort heißt dieser allerdings „Desktop Window Manager“ und ist Voraussetzung für die Aero Oberfläche. Ein etwas unbekannterer Compositing Window Manager ist Metisse (Mandriva). Dieser kam jedoch nie über das Konzept Stadium hinaus, und scheint derzeit nicht mehr weiter entwickelt zu werden. Er bietet interessante neue Bedienkonzepte (Fenster im Raum). Seite 26 von 28 4.3.1.2.
Stacking window managers Alle Window Manager, die überlappende Fenster darstellen können und kein Compositing verwenden, sind Stacking window managers. Fenster, die sich im Hintergrund befinden werden zuerst gezeichnet, sodass, wenn man ein Fenster in den Vordergrund zurückholt, nur ein Fenster neu gezeichnet werden muss. Sobald man Fenster verschiebt, muss man zwangsläufig (fast) alle Fenster neu zeichnen. Ein Beispiel für so einen Stacking window manager ist der Window Manager von Windows XP. 4.3.1.3.
Tiling window manager Früher gab es auch noch Tiling window manager, jedoch sind diese heutzutage kaum noch von Relevanz. Sie ordnen Fenster so an, dass kein Fenster ein anderes verdeckt. Seite 27 von 28 5. Quellen http://de.wikipedia.org http://en.wikipedia.org http://kde.org http://www.gtk.org http://marketshare.hitslink.com http://www.w3schools.com/browsers/browsers_os.asp Seite 28 von 28