Architektur und Schlüsselkomponenten von Windows

Transkript

1 Architektur und Schlüsselkomponenten von Windows von Stefan Lietsch Steffen Sommer Agenda I. Geschichte II. Architektur I. Hardware Abstraction Layer (HAL) III. IV. Kernel Executive Objekte in Windows Win32-API II. III. V. Teilsysteme für andere Systeme VI. ( Registry ) VII. VIII. Quellen Fragen I. Geschichte I. Geschichte (1985) erste graf. Oberfläche für MS-DOS (Windows 1.0) (1990) kommerzielle Erfolge mit Windows 3.0 / 3.1 / 3.11 Auf MS-DOS aufgesetzt DOS hatte noch immer Kontrolle über Maschine und Dateisystem Alle Programme liefen im selben Adressraum und ein Fehler in irgendeinen Programm konnte das gesamte System zum Absturz bringen. (1995) Windows 95 Merkmale eines kompletten Betriebsystems (u.a. virtueller Speicher, Prozessmanagement, Multiprogramming) Hatte noch große Teile des 16-Bit-Assembler-Codes von DOS (mit einigen 32-Bit-Erweiterungen) Benutzte MS-DOS-Dateisystem (1998) Windows 98 bzw. später Windows ME Keine großen Veränderungen zu Windows 95 Kerndatenstrukturen im Benutzerraum Jedes Programm konnte also diese Kerndatenstrukturen überschreiben und so das ganze System zum Absturz bringen. (1993) Windows NT 3.1 (New Technologie) komplett neues 32-Bit-BS Ziele bei Entwicklung: Sicherheit und hohe Zuverlässigkeit Multiprocessing und Multiuser lediglich Anhänger im Servermarkt (1996) Windows NT 4.0 graf. Benutzeroberfläche, wie Win 95 (2000) Windows NT 5.0 bzw. Windows 2000 Zusammenführung der zwei Windowsstränge echtes 32-Bit-System mit Trennung von Kern- und Benutzermodus Unterstützung für Plug-and-Play / USB / FireWire / IrDa / PowerManagement u.v.m.

2 II. Architektur Ursprünglich auf Betrieb von mehreren verschiedenen Teilsystemen ausgelegt, die Ausführung von Programmen verschiedener BS (z.b. Unix, OS/2, Windows) ermöglicht So konzipiert, dass Absturz eines Teilsystems nicht zu Absturz anderer Teilsysteme oder des Ganzen BS führt (bzw. führen soll) Aufgliederung in Schichten: Hardwareabstraktionsschicht (HAL) Zentraler Zuweisungsmechanismus = Kernel Executive (Gerätetreiber) Schichten bieten die Möglichkeit durch Abstraktion mit einfachen Systemaufrufen komplexere Befehle zur Verfügung zu stellen Windows 2000 hat eine modulare Struktur mit relativ kleinem Kern Windows 2000 ist Pseudo-Objektorientiert II.I Hardwareabstaraktionsschicht (HAL) Ziel: BS soll portierbar sein Problem: untere Ebene des BS arbeitet mit Geräteregistern, Interrupts und anderen Hardwaremerkmalen, die sich von Maschine zu Maschine grundlegend unterscheiden Abstrahierte Sicht auf Hardware durch HAL Die HAL stellt Dienste zur Verfügung, die darüber liegende Schichten nutzen können um mit der Hardware zu kommunizieren/interagieren (z.b. Zugriff auf Geräteregister, busnahe Geräteadressierung, Multiprozessorsynchronisation etc.)

3 II.I Hardwareabstraktionsschicht (HAL) Gerätespezifische Adressen, Interrupts etc. werden in systemweite, logische Adressen, Interrupts etc. umgewadelt um ein eindeutiges ansprechen der Geräte zu ermöglichen Informationen über im System vorhandene Geräte, Busse etc. bekommt die HAL beim Hochfahren direkt vom BIOS/CMOS Erweiterung der HAL durch z.b. DirectX möglich, dadurch können zusätzliche, spezialisierte Prozeduren für z.b. Multimediaanwendungen implementiert werden II.II Kern II.II Kern (Objekte) Kein Mikrokern, da von Anfang an Dienste wie Speicherverwaltung und andere Systemkomponenten im Kern integriert waren Der Kern soll den Rest des BS vollständig von der Hardware unabhängig und somit hochgradig portierbar machen Kern benutzt einfache Prozeduren der HAL um höhere Abstraktionsstufen zu erreichen Der Kern ist für das Scheduling der Threads und Prozesse zuständig und führt z.b. bei abgelaufener Zeitscheibe oder E/A- Unterbrechung notwendig gewordene Kontextwechsel durch ohne das darüber liegende Schichten sich darum kümmern müssen Der Kern verwaltet die internen Objekte: Kontrollobjekte (steuern das System): Einfache Prozessobjekte, Unterbrechungsobjekte Defferred Procedure Call (DPC) Objekte: trennen zeitlich kritischen Teil einer Unterbrechungsroutine von zeitlich unkritischem und ordnet dann die Teile in der DPC-Warteschlange zur Bearbeitung Asynchronous Procedure Call (APC) Objekte: wie DPC, werden aber im Kontext eines bestimmten Prozesses ausgeführt Dispatcherobjekte Semaphore, Mutexe, Ereignisse, Stoppuhren und andee Objekte auf die Threads warten können Sind in den Kern eingelagert, weil sie eng mit Thread/Prozess-Scheduling zusammenarbeiten

4 II.III Executive Besteht aus 10 Komponenten, wobei jede eine Sammlungvon Prozeduren darstellt um bestimmte Ziele zu erreichen: Object Manager: Verwaltet alle Objekte, die dem BS bekannt sind (z.b. Threads, Prozesse, Dateien, Verzeichnisse, Semaphore, E/A-Geräte etc.) E/A Manager Verwaltet E/A-Geräte und stellt E/A-Dienste zur Verfügung Heimat der Gerätetreiber Auch Dateisysteme (NTFS, FAT) sind technisch gesehen Gerätetreiber und werden deshalb im E/A Manager verwaltet Process Manager Behandelt Prozesse und Threads (Erstellung und Vernichtung) Schlüssel zur Multiprogrammierung Virtual Memory Manager Verwaltet virtuellen Speicher (Einlagerung, Überwachung) Behandelt Systemaufrufe, die virtuellen Speicher betreffen II.III Executive II.III Executive Security Reference Monitor Garantiert das Sicherheitsstandards nach Orange Book eingehalten werden Z.B. authentifizierende Anmeldung, Zugriffskontrolle etc. File System Cache Beschleunigt Speicherzugriff indem zuletzt oder häufig verwendete Speicherblöcke im Speicher behalten werden Arbeitet für alle Dateisysteme und eng mit Virtual Memory Mgr zusammen Plug and Play Manger Überprüft beim Hochfahren und im Betrieb (z.b. bei USB) ob neue Geräte angeschlossen wurden und leitet Treibersuche/-installation ein Power Manager Herrscher über Energieverwaltung Configuration Manager Verwaltet die Registry Local Procedure Call Manager Interprozesskommunikation zw. Prozessen und Subsystemen Effizienz sehr wichtig weil für Systemaufrufe benötigt Graphics Device Interface (GDI) Ursprünglich im Benutzerraum, seit NT 4.0 zur Leistungssteigerung im Kernraum Behandelt Bilddaten für Monitor und Drucker Verwaltet Grafiktreiber und Window Manager Systemdienste Eigenständige, dünne Schicht über der Executive Dient als Schnittstelle zur Executive Akzeptiert echte Windows 2000 Systemaufrufe und ruft Teile der Executive zur Ausführung auf

5 II.IV Gerätetreiber III. Objekte in Windows 2000 Jeder Treiber kann ein oder mehrere E/A-Geräte steuern aber auch z.b. Datenstrom verschlüsseln oder Zugang zu den Datenstrukturen des Kerns verschaffen Kein Bestandteil des Kerns (im Gegensatz zu UNIX) Vorteil: Kern ist für (fast) jede Hardwarekonstellation gleich, die Treiber werden dynamisch beim Start geladen und ermöglichen so trotzdem eine individuelle Konfiguration III. Objekte in Windows 2000 IV. API allgemein Einheitliche und konsistente Schnittstelle zu den Systemressourcen und Datenstrukturen (Prozesse, Threads, offene Dateien etc.) Alle Objekte werden auf gleiche Art benannt und können über sog. Objekt-Handles angesprochen werden Alle Objekte laufen über den Objektmanager, dadurch wird eine zentrale Sicherheitskontrolle ermöglicht und nicht mehr benutzte Objekte können schnell ermittelt und gelöscht werden Jedes Objekt hat einen Bestimmten Typ, der durch eine Zeiger auf ein Typobjekt festgelegt wird, diese Typobjekte haben Standardoperationen um die jeweiligen Objekte aufzurufen, zu schließen und zu löschen Jedes Objekt hat seine eigenen Adressraum, da sie dynamisch erzeugt werden Win32-API bietet Methoden um Objekte zu erschaffen oder zu öffnen API = Anwendungsprogrammierschnittstelle (Application Programming Interface) Eine API besteht aus einem Satz von Funktionen, die von Programmierern benutzt werden, um festzulegen, wie Programme interagieren. Bsp. CryptoAPI von MS: Wen ein Programm eine Verschlüsselung vornehmen muss, kann es dafür diese CryptoAPI von MS aufrufen. Diese enthält Standardfunktionen für die Verschlüsselung. Das Programm selbst muss nicht wissen, wie die Verschlüsselung funktioniert. Wenn MS eine neue Verschlüsselungfkt. entwickelt, kann diese problemlos in die API integriert werden. Solange sich die Schnittstellen nicht ändert, können die Programme unverändert auf diese API zugreifen.

6 IV. Win32-API IV. Win32-API Dokumentierte Bibliothek mit Funktionen Systemaufrufe oder Arbeit direkt im Benutzerraum Jedes BS besitzt Systemaufrufe. Allerdings hat MS diese nie öffentlich bekannt gegeben. Und MS ändert die Systemaufrufe von Ausgabe zu Ausgabe Win32-Aufrufe ändern sich nicht (es kommen nur neue hinzu) Demzufolge abwärtskompatibel bis Win95, wenn man grundlegende Änderungen beachtet. (z. Bsp.: Sicherheitsaufrufe ) Win32-Aufrufe erzeugen Betriebssystemkernobjekte, wie Dateien, Prozesse, Threads, Pipes usw. Ergebnis = Handle, welches das Objekt referenziert Handles gehören zu dem Prozess der das Objekt erzeugt hat. Handles referenzieren das Objekt. Bsp.: Beim Laden eines Gerätetreibers wird ein Objekt erzeugt, das alle Eigenschaften und Zeiger auf all seine Funktionen enthält. Innerhalb des BS wird der Treiber nur über dieses Objekt referenziert. Kontrollierte Zugriff auf Objekte mittels Sicherheitsdeskriptor Sicherherheitsdeskriptor legt genau fest, wer welche Operationen auf dem Objekt ausführen darf und wer nicht. Win32-Aufrufe decken alle Operationen ab, die eine Windows- Anwendung bei der Ausführung benötigt Speicherverwaltung Dateiein- und Ausgabe über 60 Aufrufe zum Erzeugen, Löschen, Schließen, Lesen, Schreiben von Dateien, sowie Auslesen und Setzen von Dateiattributen Sicherheit, Jeder Prozess besitzt eine ID, die ihn eindeutig identifiziert. Jedes Objekt besitzt eine Zugriffskontrolle, die festlegt, welcher Benutzer welche Operatione ausführen darf. graf. Schnittstelle Es gibt hunderte von Aufrufen zum Erzeugen, Zerstören, Verwalten, Benutzen von Fenstern, Menüs, Toolbars, Statusanzeigen, Rollbalken, Dialogboxen, Symbolen und vieles mehr. Ein- und Ausabegeräte V. Weitere Teilsysteme (MS-DOS-VM / WOW) Teilsysteme agieren mit dem Win32-Teilsystem, das als Einziges direkt mit der Ausführungsschicht interagiert. MS-DOS-Teilsystem NTVDM (NT Virtual DOS Machine) führt alle DOS-Anwendungen aus, indem die MS-DOS-5.0 Umgebung emuliert wird. Jede DOS-Anwendung läuft in ihrer eigenen NTVDM und in ihrem eigenen Adressraum. Es wird ein vollständiger Netzwerk-Redirector sowie Unterstützung für Maus und CD-ROM-Laufwerken bereitgestellt. 16-Bit-Windows-Teilsystem WOW (Windows on Windows) für Windows 3.1 / Anwendungen Mittels Prozess Thunking werden 16-Bit-Aufrufe in entsprechende 32-Bit- Aufrufe der Win32-API umgewandelt V. Weitere Teilsysteme (POSIX und OS/2) POSIX-Teilsystem (Portable Operating System Interface for Unix) Während der Entwurfsphase von Windows NT, war die POSIX-Kompatibilität eine Anforderung an BS, das von der US-Bundesregierung gekauft wurde. Es gibt drei Posix-Ebenen. Windows 2000 unterstützt die unterste: POSIX.1. Minimale Unterstützung für UNIX-Anwendungen allerdings keine Threads, kein Fenstersystem und kein Netzwerk Wandelt C-Aufrufe in Win32-API-Aufrufe um Demzufolge vom Win32-Teilsystem abhängig. Das Posix-Teilsystem kann nur das was auch das Win32-Teilsystem kann. Und nicht mal das. Es steht nicht die gesamte Win32-Schnittstelle zur Verfügung. OS/2-Teilsystem für OS/2 1.x Zeichenmodusanwendungen konvertiert ebenfalls OS/2-API-Aufrufe in Win32-API-Aufrufe Sehr beschränkt. Kann keine graf. Anwendungen oder OS/2 2.x Programme oder höher ausführen. Enthält nur Kern-API von OS/2 1.x und einige grundlegende Netzwerkaufrufe- Aufrufe. Womit es den POSIX-Teilsystem einen Schritt voraus ist.

7 VI. Registry VI. Registry Alle Boot- und Konfigurationsinformationen, sowie aktuelle Benutzeranpassung in einer großen zentralen Datenbank Verzeichnis = Key / Verzeichniseintrag = value (Name, Typ, Daten) HKEY_LOCAL_MACHINE Hardware (alle Informationen über Hardware, Treiber) Wir beim Systemstart vom Plug-and-Play-Manager aufgebaut und nicht auf der Festplatte gespeichert. SAM = Security Account Manager (Benutzernamen, Gruppen, Passwörter usw. ) Security (Systemweite Sicherheitsrichtlinien) Mindestlänge der Passwörter, geduldete Anzahl falscher Anmeldeversuche. Software (Informationen von Programmen externer Hersteller) System (Informationen zum Systemstart) Liste der Treiber, die geladen werden müssen, und eine Liste der Dieste, die nach dem Hochfahren gestartet werden müssen. HKEY_USERS alle benutzerspezifischen Einstellungen (Sounds, Grafikeinstellungen usw.) Generell alles was man mit der Systemsteuerung einstellen kann HKEY_PERFORMANCE_DATA (Systemleistung über perfmon ) Hunderte von internen Zählern, die die Systemleistung beobachten. HKEY_CLASSES_ROOT ( Link auf COM-Objekte = Dateiendungen HKEY_CURRENT_CONFIG Link zum aktuellen Hardwareprofil HKEY_CURRENT_USER Link zum aktuellen Benutzerprofil Wenn das System heruntergefahren wird, wird das meiste der Registry auf der Festplatte gespeichert, und zwar in Dateien, die Hives genannt werden. Hardware-Informationen werden nicht abgespeichert. VII. Quellen Andrew S. Tanenbaum, Moderne Betriebssysteme, Kapitel 11 David A. Solomon, Inside MS Windows Edition, Kapitel 2 Fragen? Brown, Miller, Windows 2000 Server Kompendium, Kapitel 2 Vielen Dank für Eure Aufmerksamkeit!