Wer Windows bis ins letzte Detail an seine eigenen Vorlieben anpassen oder sich - wie in anderen Artikeln in diesem Heft beschrieben - komfortables Werkzeug dazu gar selbst herstellen will, kommt unweigerlich mit der Windows-Registry in Berührung. Ein wenig Know-how über deren inneren Aufbau kann dabei nicht schaden.
Die Möglichkeiten, einem Windows-System lästige Macken abzugewöhnen, es den persönlichen Vorlieben anzupassen oder hier und da noch ein Quäntchen Performance herauszuquetschen, sind nahezu unüberschaubar: Allein in der Systemsteuerung finden sich je nach installierten Optionen bis zu 30 Symbole und mehr; viele der dahinter versteckten Dialoge sind zudem in mehrere Unterfenster unterteilt. Dazu kommen noch einmal eine Hand voll Programme, die sich im Startmenü unter `Programme/Zubehör/Systemprogramme´ oder - bei Windows 2000 und XP - im Untermenü `Verwaltung´ finden. Beinahe jede Anwendung birgt darüber hinaus im Extras- oder Optionen-Menü noch einmal einen oder mehrere Dialoge zum Einstellen spezifischer Optionen.
Trotz dieser Vielfalt an `offiziellen´ Konfigurationsmöglichkeiten liest man in Tipp-Sammlungen immer wieder davon, dass sich bestimmte Änderungen am Systemverhalten nur dadurch erreichen lassen, dass man direkt in der so genannten Registry Manipulationen vornimmt. Der bequemere Weg führt über den Policy-Editor und spezielle ADM-Dateien (siehe Artikel auf Seite 106 und 116 in diesem Heft). Besonders komfortabel wirds, wenn man sie den eigenen Bedürfnissen auf den Leib schneidert. So verlockend diese Aussicht ist: Ganz ohne Kenntnisse über die Struktur und den Inhalt der Registry kommt man dabei denn doch nicht aus.
Die Registry ist eine Erfindung von Microsoft, die seit der Einführung von Windows 95 eine elementare Rolle spielt. Es handelt sich um eine Art zentrale Datenbank, in der das Betriebssystem selbst, aber auch jede Anwendung beliebige Informationen speichern und wiederfinden kann. Microsoft empfiehlt Entwicklern, die Registry als Speicher für sämtliche Daten zu verwenden, die nicht in den eigentlich bearbeiteten Dokumenten beziehungsweise Dateien Platz finden.
In grauer Windows-3.x-Vorzeit dienten für diesen Zweck die immer noch nicht ganz verschwundenen .ini-Dateien. Mit der Einführung einer zentralen Konfigurationsdatenbank wollte Microsoft im Wesentlichen zwei Ziele erreichen: Zum einen sollte sie gegenüber den zahlreichen, in diversen Verzeichnissen verstreuten .ini-Dateien für mehr Übersichtlichkeit sorgen. Zum anderen löst sie ein Problem, das bei Windows 95 überhaupt zum ersten Mal auftauchte, denn dies war das erste mehrbenutzerfähige Betriebssystem aus dem Hause Microsoft. Konfigurationsdaten lassen sich grob in zwei Kategorien unterteilen: Eine typische Anwendung benötigt einerseits Informationen über die Installation insgesamt, etwa Pfade zu Komponenten, eine Seriennummer oder das Datum des letzten Update. Andererseits muss sie aber auch benutzerspezifische Daten ablegen wie die zuletzt verwendeten Dateien, Fensterposition und -größe oder Vorgaben hinsichtlich Farben, Schriften und so weiter. Eine Möglichkeit, solche Daten getrennt nach Anwendern zu speichern, sehen .ini-Dateien nicht vor.
Ein weiterer Vorteil einer in einem speziellen Format vorliegenden Konfigurationsdatenbank gegenüber verstreuten Textdateien ist, dass das System auf bestimmte Einträge wesentlich schneller zugreifen kann: .ini-Dateien haben teilweise eine recht beachtliche Größe angenommen, die Einträge waren aber normalerweise nicht sortiert. Deswegen musste ein Programm oft mehrere KByte Text durch einen Parser schleusen, bevor ein bestimmter Wert gefunden war. In der Registry verwendet Windows dagegen spezielle Indizes, um den Zugriff zu beschleunigen. Auch die Tatsache, dass Windows seine Konfiguration durch zentral im Netz gespeicherte Systemrichtlinien-Dateien zusammenstückeln kann, basiert letztlich auf der Verwendung eines datenbankähnlichen Dateiformats.
Ein Nachteil der Abkehr von Textdateien ist jedoch, dass ein Administrator nicht `mal eben´ mit einem Editor wie Notepad Einstellungen überprüfen oder gar ändern kann. Glücklicherweise hat Microsoft das von Anfang an erkannt und seinen Systemen spezielle Werkzeuge zum Bearbeiten der Registry mitgegeben: Alle Windows-Versionen seit Windows 95 enthalten für diesen Zweck ein Programm namens Regedit, bei Windows NT und 2000 gibt es zusätzlich noch den Regedt32, der erweiterte Funktionen zur Verfügung stellt (dazu später mehr). Bei Windows XP hat Microsoft diese Funktionen in das Programm Regedit integriert, sodass es hier nur noch einen Registry-Editor gibt.
Die Daten in der Registry sind hierarchisch in so genannten Schlüsseln gespeichert. Jeder Schlüssel kann neben den eigentlichen Einträgen weitere Unterschlüssel enthalten. Diese Struktur spiegelt sich in der Bedienoberfläche des Programms Regedit wider: Er sieht auf den ersten Blick wie ein Windows-Explorer aus, der statt Ordnern die Schlüssel und statt Dateien die Einträge anzeigt.
Jeder Eintrag besitzt neben seinem Namen und seinem Wert auch einen Typ. Zur Verfügung stehen:
%VARIABLE% enthält, und ersetzt ihn gegebenenfalls durch deren Inhalt.
Die letzten beiden Typen gibt es nur unter Windows NT, 2000 und XP; will man solche Einträge anlegen oder bearbeiten, muss man unter NT und 2000 das Programm Regedt32 verwenden.
Die Suche nach einem Registry-Eintrag beginnt immer bei einem der - je nach Windows-Version - fünf bis sechs vordefinierten Wurzelschlüssel. Um zu beurteilen, welche Auswirkungen eine eventuelle Änderung an einem Eintrag auf das System haben kann, ist ein grober Überblick hilfreich, welche Art von Daten sich unter welchem Schlüssel verbirgt.
Unter HKEY_CLASSES_ROOT (oder kurz HKCR) speichert Windows alles, was mit Dateiklassen und ihren Zuordnungen zu Anwendungen zu tun hat. Außerdem verewigen sich hier sämtliche COM- und ActiveX-Komponenten. Darunter fallen unter anderem Programme, die Programmierern eine Schnittstelle zum Fernsteuern bieten oder deren Dokumente sich in andere Dateien einbinden lassen. Auf unbedachte Änderungen in diesem Bereich der Registry reagiert Windows sehr allergisch; wer weiß, was er tut, kann hier aber beispielsweise die Kontextmenüs von Dateien im Explorer den eigenen Vorlieben anpassen [1].
HKEY_CURRENT_USER (HKCU) ist die Basis für sämtliche Einstellungen, die nur den gerade angemeldeten Benutzer betreffen. Die meisten derartigen Konfigurationsdaten von Windows selbst finden sich unter HKCU\Software\Microsoft\Windows\CurrentVersion; bei Windows NT, 2000 und XP ist zusätzlich noch der Schlüssel HKCU\Software\Microsoft\Windows NT\CurrentVersion samt Unterschlüsseln interessant. Benutzerspezifische Einstellungen für Anwendungen finden sich in der Regel unter einem Schlüssel nach dem Muster HKCU\Software\<Hersteller>\<Programmname>.
Ganz ähnlich sind die Daten des Schlüssels `Software´ unter HKEY_LOCAL_MACHINE (HKLM) strukturiert, nur dass hier eben Daten liegen, die für alle Anwender gleich sind beziehungsweise die ein Programm sonst noch benötigt, etwa um Dateien wiederzufinden, für die das Installationsprogramm die Möglichkeit zur Auswahl eines Verzeichnisses bietet. Alle anderen Unterschlüssel von HKLM betreffen die Konfiguration der Hardware samt installierter Treiber sowie lokaler Dienste. Wer sich nicht absolut sicher ist, was er tut, sollte von Manipulationen mit Regedit in diesem Bereich unbedingt die Finger lassen.
Der Inhalt des Schlüssels HKEY_USERS unterscheidet sich deutlich je nach Windows-Version: Unter Windows 9x und ME enthält er normalerweise nur einen Unterschlüssel namens .DEFAULT (der Eintrag `Software´, den man in manchen Installationen findet, ist vermutlich auf die Schlamperei eines Microsoft-Entwicklers zurückzuführen - zu suchen hat er hier eigentlich nichts). Der ist nichts anderes als der `wahre´ Ort der Daten unter HKCU. Anders gesagt: HKCU ist eine Abkürzung auf HKEY_USERS\.DEFAULT. Diese Zuordnung ändert sich unter Windows 9x/ME, wenn man dort mehr als einen Benutzer anlegt: Dann bildet HKCU den Schlüssel HKEY_USERS\<Benutzername> ab, und HKEY_USERS\.DEFAULT enthält eine Vorlage, die beim Anlegen weiterer Benutzer in deren HKCU-Ast kopiert wird.
Letzteres passiert auch unter Windows NT und seinen Nachkommen. Der Zweig für den aktuellen Benutzer trägt hier aber nicht dessen Anmeldenamen, sondern eine kryptische Bezeichnung, die beim Anlegen des Benutzerkontos erzeugt wird und weltweit einmalig ist. Bei Windows XP finden sich unter HKEY_USERS noch weitere Schlüssel, die zu vordefinierten Benutzerkonten wie `LocalService´ oder `System´ gehören.
Der letzte in jeder Registry vorhandene Wurzelschlüssel heißt HKEY_CURRENT_CONFIG. Er ist wieder eine Abkürzung, und zwar unter Windows 9x und ME auf HKLM\Config\0001 und unter NT, 2000 und XP auf HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current. Für seine Inhalte gilt das bei HKLM Erwähnte.
Schließlich zeigt Regedit unter Windows 9x und Millennium noch einen Schlüssel namens HKEY_DYN_DATA an, dessen Inhalte jedoch nicht wirklich Konfigurationsdaten sind. Vielmehr können sich entsprechende Anwendungen hier Informationen über den Systemzustand abholen, etwa die dynamische Zuordnung von Ressourcen zu Plug&Play-Hardware oder die Speicherauslastung. Änderungsversuche blockt Regedit von vornherein ab.
Nicht unerwähnt bleiben sollte, dass auch die Wurzel HKCR nur eine Abkürzung ist, und zwar auf HKLM\Software\Classes. In Wirklichkeit gibt es also nur zwei echte Registry-Wurzeln, nämlich HKEY_LOCAL_MACHINE und HKEY_USERS.
Diese Erkenntnis ist bei der Beantwortung der Frage wichtig, in welchen Dateien denn Windows eigentlich die Registry speichert. Und das sollte man wissen, um zum Beispiel vor eigenen, potenziell gefährlichen Experimenten eine Sicherheitskopie der Registrierdatenbank anlegen zu können. Leider ist weder die Frage nach dem Speicherort noch die nach einer geeigneten Backup-Methode trivial.
Windows 95, 98 und ME speichern den HKLM-Ast der Registry in der Datei system.dat im Windows-Verzeichnis. Dort liegt bei einem System, auf dem es nicht mehrere Benutzerkonten gibt, auch die Datei user.dat, die die Daten unter HKCU enthält. Beide Dateien sind normalerweise versteckt; um sie im Explorer zu sehen, muss man ihn also anweisen, alle Dateien anzuzeigen. Konfiguriert man Windows 9x/ME für den Mehrbenutzerbetrieb, so erhält jeder Anwender seine eigene Kopie der Datei user.dat; sie liegt jeweils in seinem Profil-Ordner unter \Windows\Profiles\<Benutzername>. Beim Anmelden blendet Windows jeweils die zu dem Benutzer gehörende Datei in die Registrierdatenbank ein; im Zweig HKEY_USERS sieht man nur diesen Ast sowie den Eintrag .DEFAULT. Dabei handelt es sich um die Daten des ursprünglichen Anwenders, der das System installiert hat. Diese Daten nimmt Windows jeweils beim Einrichten eines weiteren Kontos als Kopiervorlage.
Sowohl die Datei system.dat als auch sämtliche Kopien von user.dat lassen sich im laufenden Betrieb kopieren oder durch eine ältere, gespeicherte Version ersetzen. Von solchen Aktionen ist allerdings dringend abzuraten: Wenn ein Programm Daten in der Registry ablegt, hält Windows sie zunächst in einem Zwischenspeicher und schreibt sie erst später wirklich auf die Festplatte. Tauscht man in einem solchen Zustand eine Registry-Datei aus, kann es zu unvorhersehbaren Effekten bis hin zur Unbrauchbarkeit des Systems kommen. Besser ist es, zum Anlegen eines Registry-Backups oder zum Zurückspielen den Rechner in eine reine DOS-Eingabeaufforderung zu starten - bei Millennium zur Not mit einer Startdiskette - und die Kopieraktionen dort von Hand mit copy oder xcopy vorzunehmen. Vorher muss man bei den beteiligten Dateien mit dem Befehl attrib - h -s -r die Versteckt-, System- und Schreibschutz-Attribute entfernen.
Unter Windows 98 und ME legt das System übrigens von sich aus einmal täglich eine Kopie der Registry an, wenn es erfolgreich gestartet wurde. Um ein solches Backup zurückzuspielen, steht der Befehl scanreg /restore zur Verfügung. Unter Windows 98 muss man ihn auf der Kommandozeile eingeben, nachdem man den Rechner im MS-DOS-Modus gestartet hat. Millennium kennt keinen solchen Modus; hier kann man den Befehl über `Start/Ausführen´ erreichen. Wer sich auf ScanReg verlässt, sollte das Programm für den Fall der Fälle auf einer selbst erstellten Start-CD bereithalten [2].
Auch Windows NT, 2000 und XP speichern die Registrierung getrennt nach System- und Benutzerbereichen. Der Systemteil besteht aus den Dateien unter \WinNT\System32\Config auf der Systempartition (außer den *.evt-Dateien - in ihnen speichert das System die Daten der Ereignisanzeige). Die benutzerspezifischen Abschnitte lagern in Dateien namens ntuser.* im jeweiligen Profilverzeichnis, also normalerweise bei Windows NT unter \WinNT\Profiles\<Benutzername> und bei Windows 2000 und XP unter \Dokumente und Einstellungen\<Benutzername>.
Im laufenden Betrieb unterbindet das System jeden direkten Zugriff auf die systemweiten Dateien und die des aktuellen Benutzers, selbst zum Lesen beziehungsweise Kopieren. Die ntuser.*-Dateien kann man trotzdem recht einfach sichern und wiederherstellen, indem man sich unter einem anderen Benutzernamen anmeldet. Um auf alle Dateien Zugriff zu haben, leistet ein zweites Konto mit Administratorrechten gute Dienste. Zum Sichern und Zurückspielen der systemweiten Registry-Dateien benötigt man ein zweites System, das Zugriff auf diese Dateien hat: Ist die Systempartition mit FAT32 formatiert, genügt eine Windows-9x-Startdiskette, bei einer NTFS-Partition ist eine Parallelinstallation derselben Windows-Version erforderlich. Wo die aus Platzgründen unmöglich ist, kann bei Windows 2000 und XP als Notbehelf auch die - in der Bedienung etwas gewöhnungsbedürftige - Wiederherstellungskonsole dienen [3].
Bei Windows XP kann man sich solche Klimmzüge meist sparen: Hier ist man relativ sicher, wenn man vor möglicherweise riskanten Experimenten einen so genannten Wiederherstellungspunkt anlegt (Programme/Zubehör/Systemprogramme/Systemwiederherstellung) - der hilft allerdings nichts, wenn die Manipulationen an der Registry so weit gehen, dass sie einen Neustart unmöglich machen.
Ein Komplett-Backup der Registry ist häufig die sprichwörtliche Kanone, mit der man auf Spatzen schießt: Vor Registry-Experimenten, die nur einen Schlüssel betreffen, bietet es sich an, den einzeln zu speichern. Dazu enthalten sämtliche Versionen von Regedit den Befehl `Datei/Exportieren´. Er speichert den gerade ausgewählten Schlüssel samt seiner Unterschlüssel in einer .reg-Datei. Solche Dateien sind in der Regel nicht nur kleiner als eine Komplettsicherung, sondern lassen sich zur Not auch mit einem Editor wie Notepad nachbearbeiten, da es sich um reine Textdateien handelt. Unter Windows 9x gibt es sogar eine Möglichkeit, sie nach dem Booten in den MS-DOS-Modus wieder in die Registry zu importieren [4].
Windows NT und seine Nachfahren verhindern manche Registry-Fummelei dadurch, dass die Registrierdatenbank hier über eine Rechteverwaltung verfügt: An die wirklich kritischen Bereiche lassen sie normalerweise nur Administratoren heran. Die können dann allerdings - ähnlich wie bei Dateien auf NTFS-Partitionen - solche Rechte auch anderen Anwendern zuteilen oder wieder entziehen. Unter Windows NT und 2000 beherrscht dieses Kunststück nur das Programm Regedt32 (über den Befehl `Sicherheit/Berechtigungen´), bei XP sind die entsprechenden Funktionen in Regedit integriert und über das Menü `Bearbeiten´ oder einen Rechtsklick auf einen Schlüssel erreichbar.
Eine andere weithin unbekannte Spezialität von Regedt32 und dem XP-Regedit verbirgt sich hinter dem Befehl `Struktur laden´ aus dem `Registrierung´- beziehungsweise `Datei´-Menü: Damit lässt sich die Registry einer anderen Installation auf demselben Rechner bearbeiten oder ein Blick in die Einstellungen eines gerade nicht angemeldeten Benutzers werfen. Der Befehl steht nur zur Verfügung, wenn im Schlüsselbaum HKLM oder HKEY_USERS ausgewählt ist. Mit dieser Methode kann man unter Umständen ein Windows wieder zum Leben erwecken, das aufgrund unbedachter Registry-Spielereien den Start verweigert.
Die Methode eignet sich außerdem dazu, direkte Änderungen an einer .POL-Datei (siehe Artikel ab S. 106) vorzunehmen: Deren Dateiformat ist mit dem von Registry-Dateien identisch. Nach getaner Arbeit sollte man aber auf keinen Fall vergessen, sie über den Befehl `Struktur entfernen´ wieder freizugeben - sonst verhindert Windows ähnlich wie bei den eigentlichen Registry-Dateien jeglichen direkten Dateizugriff. (hos)
[1] Hajo Schulz, Verteile und herrsche, Windows-Dateitypen im Griff, c't 2/02, S. 186
[2] Axel Vahldiek, Herbert Schmid, Silberner Retter, Notfall-CD für Windows im Eigenbau, c't 26/01, S. 108
[3] Lars Bremer, Klempner an Bord, Registry sichern und reparieren unter Windows 2000 und XP, c't 22/01, S. 146
[4] Hajo Schulz, Ingo Pakalski, Wenn Windows wurmt, Hilfe zur Selbsthilfe bei Systemproblemen, c't 26/99, S. 102