Registrierungsdatenbank

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Systemregistrierung)
Wechseln zu: Navigation, Suche
Moderne Interpretation des Symbols

Die Windows-Registrierungsdatenbank (manchmal auch Registrierdatenbank oder Registrierung und meist nur Registry genannt) ist seit der ersten Version von Windows NT die zentrale hierarchische Konfigurationsdatenbank des Betriebssystems Microsoft Windows. Hier werden sowohl Informationen zu Windows selbst als auch Informationen zu Programmen gespeichert. Mit Microsoft Windows 3.1 wurde die Windows-Registry 1992 auch im Bereich der Consumerbetriebssysteme eingeführt. Während unter den frühen Windowssystemen hauptsächlich Dateierweiterungen gespeichert wurden, handelt es sich bei der Registry seit Windows 95 und Windows NT 4.0 um eine umfassende Datenbank für die Verwaltung des Systems und aller integrierten Systemdienste und -prozesse. Das Symbol der Registrierungsdatenbank ist ein aus vielen kleineren Würfeln zusammengesetzter großer Würfel mit drei freischwebenden Teilwürfeln.

Motivation und Entwicklungsgeschichte[Bearbeiten | Quelltext bearbeiten]

Bevor sich in Windows das Konzept der Registry durchgesetzt hatte, wurden Einstellungen in Konfigurationsdateien (z. B. INI-Dateien) separat für jedes einzelne Programm in dessen Verzeichnis gespeichert. Dies bringt jedoch einige Nachteile mit sich: So werden die Einträge in einem Textformat gespeichert und ausgewertet, wodurch diese zwar einfach mit einem Texteditor bearbeitet werden können, für die Weiterverwendung in Programmen aber erst in ein Binärformat umgewandelt werden müssen. Dies bringt Performancenachteile mit sich. Ferner können Berechtigungen nur auf Dateiebene, nicht auf Eintragsebene gesetzt werden[1]; verschieden Berechtigungsstufen für einzelne Einträge ließen sich sonst – wo nötig – nur durch verschiedene Konfigurationsdateien abbilden.

Die Registrierungsdatenbank hat diese Nachteile nicht: Sie wird in einem binären Format gespeichert, sodass ihre Inhalte direkt und ohne Konvertierung weiterverarbeitet werden können. Informationen, die in einer Konfigurationsdatei als langer Text vorliegen, werden in der Registrierungsdatenbank „zerstückelt“ und in einzelnen Einträgen gespeichert. Dadurch können nicht nur Berechtigungen auf Eintragsebene gesetzt werden,[1] sondern eine Blockade durch gleichzeitigen Schreibzugriff zweier Programme wird vermieden, wenn diese unterschiedliche Einträge bearbeiten. In einer Konfigurationsdatei müssten beide dieselbe Datei öffnen und editieren, in der Registrierung sind beide Wertepaare nur logisch durch Listen-Zellen verbunden. Um durch die „Zerstückelung“ keinen physikalischen Nachteil bei Zugriff auf die Daten zu haben, sorgt das System seit Windows XP von selbst für eine Defragmentierung.[2]

Vorteile bringt die Registry auch im Netzwerkverbund unter Verwendung des Verzeichnisdienstes Active Directory. Über Gruppenrichtlinien können mehrere Arbeitsplatzrechner zentral und auf einmal gesteuert werden.[3] Denn auf die Daten der Registry kann auch über ein Netzwerk zugegriffen werden, da die Pfade zu den Werten standardisiert sind: Ein Programm muss nicht wissen wo eine bestimmte Datei liegt, sie spricht nur die Standard-API an, welche den Registrywert in dem Schlüssel ausliest oder schreibt.

Seit der Einführung der Registrierungsdatenbank wurden von Microsoft eine Reihe von Verbesserungen durchgeführt. Bis zur Version NT 5.2 (Microsoft Windows Server 2003) konnte der Startvorgang des Rechners scheitern, wenn Kernel und SYSTEM.DAT nicht in die ersten 16 MB Arbeitsspeicher passten. Mit der Einführung von Vista fiel die Beschränkung weg. Ebenfalls mit Windows Vista wurde der Kernel Transaction Manager eingeführt, mit dem sich atomare Operationen innerhalb der Registry realisieren lassen, siehe Abschnitt Ausfallsicherheit. Mit Windows 7 wurde die Registry in Bezug auf das Sperr-Verhalten verbessert: Zuvor wurden bei einem Zugriff auf einen Unterschlüssel möglicherweise einige Oberschlüssel des Pfades mitgesperrt; mit Windows 7 wird nur noch der Schlüssel gesperrt, auf den tatsächlich auch zugegriffen wird.[4]

Aufbau[Bearbeiten | Quelltext bearbeiten]

Computer
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_CLASSES_ROOT
 
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_CURRENT_USER
 
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_LOCAL_MACHINE
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BCD00000000
 
 
 
 
 
 
COMPONENTS
 
 
 
 
 
 
HARDWARE
 
 
 
 
 
 
SAM
 
 
 
 
 
 
SECURITY
 
 
 
 
 
 
SOFTWARE
 
 
 
 
 
 
SYSTEM
 
 
 
 
 
 
 
 
 
 
HKEY_USERS
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.DEFAULT
 
 
 
 
 
 
S-1-5-18-...
 
 
 
 
 
 
S-1-5-19-...
 
 
 
 
 
 
 
 
 
 
HKEY_CURRENT_CONFIG
 
 
 

Überblick und Terminologie[Bearbeiten | Quelltext bearbeiten]

Die Registrierungdatenbank besteht aus Schlüsseln (engl. keys) und Einträgen (engl. entries). Ein Schlüssel ist dabei ein Behälter für Einträge und weitere Unterschlüssel, ähnlich einem Ordner auf Dateiebene. Die nebenstehende Grafik zeigt eine Auswahl wichtiger Schlüssel der heutigen Registry, angeordnet in einer Baumstruktur. Ein Eintrag in der Registrierungdatenbank ist ein Name-Wert-Paar, ähnlich einer Datei.[5] Der Wert (engl. value) eines Eintrags kann unterschiedliche Datentypen aufweisen, etwa Binärcode, Zahl oder Text. Manchmal wird mit dem Begriff „Wert“ auch das Name-Wert-Paar gemeint. Die eigentlichen Werte werden dann als „Daten“ bezeichnet.[6] Einträge in der Registry können auch unbenannt sein, so kann jeder Schlüssel in der Registry einen unbenannten Eintrag beherbergen. Diese werden als Standard-Werte bezeichnet.[7]

Hauptschlüssel[Bearbeiten | Quelltext bearbeiten]

Die Registrierungsdatenbank ist in mehrere Haupt- bzw. Wurzelschlüssel unterteilt. Folgende Hauptschlüssel sind in aktuellen Windows-Versionen vorhanden:[8][9]

  • HKEY_CLASSES_ROOT enthält Informationen über unterstützte Dateitypen des Rechners und die dazugehörigen Dateiendungen. Der Wurzelschlüssel ist bei den meisten Windows-Versionen nicht real, sondern nur eine Spiegelung auf HKEY_LOCAL_MACHINE\Software\Classes bzw. seit Windows 2000 eine Kombination aus diesem Schlüssel und HKEY_CURRENT_USER\Software\Classes. Nur in Windows ME war dieser in einer separaten Datei gespeichert.
  • HKEY_CURRENT_USER ist eine Spiegelung von HKEY_USERS\<Benutzer-SID>, wobei <Benutzer-SID> die SID des aktuell am System angemeldeten Benutzers ist.
  • HKEY_LOCAL_MACHINE speichert Einstellungen, die alle am System angemeldeten Benutzerkonten betreffen.
  • HKEY_USERS enthält die Schlüssel der einzelnen Benutzerkonten. Für jeden Benutzer ist dort ein eigener Unterschlüssel angelegt, benannt nach der SID des jeweiligen Benutzerkontos. Diese Unterschlüssel sind Sammelstellen für alle Einstellungen, die nur für das jeweilige Benutzerkonto gelten.
  • HKEY_CURRENT_CONFIG ist eine Spiegelung auf HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current.

Daneben gab es in früheren Windows-Versionen zusätzlich die folgenden Hauptschlüssel:[9]

  • HKEY_DYN_DATA diente zur Speicherung von Plug & Play-Geräten unter Windows 9x.
  • HKEY_PERFORMANCE_DATA war ein Wurzelschlüssel unter Windows NT und diente dort zur Speicherung von Leistungsdaten.

Die Hauptschlüssel werden häufig abgekürzt geschrieben, z.B. „HKLM“ für HKEY_LOCAL_MACHINE oder „HKU“ für HKEY_USERS.

Werte und Datentypen[Bearbeiten | Quelltext bearbeiten]

Jeder Wert kann eine theoretische Größe von 1024 kB haben, die meisten Werte sind aber deutlich kleiner, und bestehen nur aus wenigen Bits. Es sind folgende Datentypen für Windows Vista und höher möglich:[10]

  • REG_BINARY: Roher Binärcode, der ohne Formatierung oder Umwandlung verarbeitet werden kann. Die Daten können entweder direkt binär (Nullen und Einsen) oder mit einem Hex-Editor angesehen werden.
  • REG_DWORD: Ein Binärdatentyp, bei dem 32-bittige Integer-Werte als 4-Byte lange Hexadezimalwerte speichert. Wird für inkrementelle Werte, 4-Byte-Statuscodes oder boolesche Variablen (0=falsch, 1=wahr) genommen.
  • REG_QWORD: Ein Binärdatentyp, bei dem 64-bittige Integer-Werte als 8-Byte lange Hexadezimalwerte speichert. Wird wie DWORD eingesetzt, nur für größere Werte.
  • REG_SZ: Eine Zeichenkette aus Unicode-Schriftzeichen. Für Namen, Beschreibungen, Systempfade usw.
  • REG_EXPAND_SZ: Eine Zeichenkette variabler Länge die Umgebungsvariablen wie %systemroot% enthält, die beim Lesezugriff expandiert werden.
  • REG_MULTI_SZ: Multi-Parameter-String, dessen einzelne Elemente durch Standard-Trennzeichen abgetrennt werden, sodass diese einzeln aus der Zelle herausgepickt werden können.
  • REG_FULL_RESOURCE_DESCRIPTOR: Ein Wert der eine kodierte Beschreibung der Hardware-Ressource enthält, z. B. eines Laufwerkes, Chipsatzes usw.

Dateien der Registry (Hives)[Bearbeiten | Quelltext bearbeiten]

Die Registrierungsdatenbank wird über mehrere Dateien verteilt gespeichert, die in verschiedenen Verzeichnissen des Rechners abgelegt sind. Somit wird die Registry in mehrere Teilabschnitte unterteilt, welche auch als Hives (englisch für Bienenstöcke) bezeichnet werden.[11][12] Ein Hive ist dabei nicht zwangsweise mit einem Wurzelschlüssel identisch. So gibt es Wurzelschlüssel, die aus mehreren einzelnen Hives bestehen (z.B. HKEY_LOCAL_MACHINE bei Windows NT), des Weiteren können Wurzelschlüssel auch nur virtuell sein, also einen Link auf einen anderen Teil der Registrierungsdatenbank darstellen.

Je nach Betriebssystem-Version unterscheiden sich Aufteilung und Speicherort der Dateien.

Windows 9x[Bearbeiten | Quelltext bearbeiten]

In Windows 9x gibt es die folgenden Hives:[13][9]

Hive Speicherort Beschreibung
HKEY_CLASSES_ROOT %systemroot%\Classes.dat (nur Windows ME) In Windows 95 und 98 ist dieser Schlüssel ein Link auf HKLM\Software\Classes.
HKEY_CURRENT_USER %systemroot%\Profile\%username%\User.dat Speichert Benutzer-Einstellungen.
HKEY_LOCAL_MACHINE %systemroot%\System.dat Speichert System-Einstellungen.
HKEY_DYN_DATA Arbeitsspeicher Speichert Informationen über am System angeschlossene Geräte.

Windows NT[Bearbeiten | Quelltext bearbeiten]

In Betriebssystemen auf Basis des NT-Kernels, bis einschließlich Windows 10, gibt es folgende Hives:[6][14]

Hive Speicherort Beschreibung
HKEY_CURRENT_USER
HKU\<Benutzer-SID>
 %systemdrive%\Users\%username%\NTUSER.DAT Enthält Einstellungen für Windows und Anwendungsprogramme, die nur das jeweilige Benutzerkonto betreffen. Unter HKEY_CURRENT_USER wird der Hive des aktuell am System angemeldeten Benutzerkontos eingebunden.
HKLM\BCD00000000 \Device\HarddiskVolume1\Boot\BCD Dies ist die Boot Configuration Database (BCD), welche seit Windows Vista existiert. Sie enthält Konfigurationsdaten, die für den Bootloader benötigt werden.
HKLM\COMPONENTS %systemroot%\System32\config\COMPONENTS Hier werden Informationen über den Zustand von Windows-Features und Updates abgelegt. Aus Effizienzgründen wird dieser Hive nur bei Bedarf in die Registrierungsdatenbank geladen. Dieser Hive ist Teil der mit Windows Vista eingeführten Component Based Servicing (CBS)-Architektur.
HKLM\HARDWARE Arbeitsspeicher Enthält Informationen über am System angeschlossene Hardware, wie Eingabegeräte und das ACPI. Dieser Hive wird nicht in einer Datei gespeichert; stattdessen werden die benötigten Informationen bei jedem Start des Rechners erneut ausgelesen und im Arbeitsspeicher abgelegt. Nicht alle Hardware-Komponenten sind hier gelistet. Bei neueren Systemen wird dazu hauptsächlich der Schlüssel HKLM\SYSTEM\CurrentControlSet\Enum verwendet.
HKLM\SAM %systemroot%\System32\config\SAM Datenbank, die Benutzerinformationen wie Anmeldename und Kennwort enthält. Siehe auch: Security Accounts Manager.
HKLM\SECURITY %systemroot%\System32\config\SECURITY Speichert die systemweit gültigen Sicherheitsrichtlinien und Benutzerrechte.
HKLM\SOFTWARE %systemroot%\System32\config\SOFTWARE Unter diesem Hive werden systemweite Windows-Einstellungen, die nicht zum Booten benötigt werden, sowie Einstellungen der Anwendungsprogramme abgespeichert.
HKLM\SYSTEM %systemroot%\System32\config\SYSTEM Enthält Windows-Einstellungen, die bereits während des Bootens benötigt werden. Dazu gehören Einstellungen und Zustand der Treiber und Systemdienste.
HKU\.DEFAULT
HKU\S-1-5-18
%systemroot%\System32\config\.DEFAULT Es handelt sich um den Hive des Benutzerkontos „Lokales System“ (Local System), das für einige Systemdienste und -prozesse verwendet wird. Dieser Hive wird zweifach eingebunden; die Schlüssel HKU\.DEFAULT und HKU\S-1-5-18 sind also identisch.[15]
HKU\S-1-5-19[16] %SystemRoot%\ServiceProfiles\LocalService\Ntuser.dat Hive des Benutzerkontos „Lokaler Dienst“ (Local Service).
HKU\S-1-5-20[16] %SystemRoot%\ServiceProfiles\NetworkService\Ntuser.dat Hive des Benutzerkontos „Netzwerkdienst“ (Network Service).

Technik[Bearbeiten | Quelltext bearbeiten]

Dieser Abschnitt bedarf einer Überarbeitung: Liest sich alles andere als flüssig, da viel zu ausschweifend und kaum verständlich. Hier sollte man sich auf das Wesentliche konzentrierten und nicht noch nebenbei vergeblich versuchen, die halbe Windows-Architektur zu erklären.
Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Arbeitsweise der Registry[Bearbeiten | Quelltext bearbeiten]

Die Registrierungsdatenbank ist wie oben gezeigt auf mehrere Dateien verteilt. „Die Registry“ als monolithisches Objekt und Single Point of Failure gibt es deshalb im strengen Sinne nicht (je nach beschädigter Datei kann dies aber dennoch so betrachtet werden, z.B. bei der SYSTEM.DAT). Das, was zum Beispiel mit dem Registry-Editor regedit.exe als monolithische Datenbank dargestellt wird, ist die Implementierung des Configuration Managers, der Teil des NT-Kernels ist. Die Registry besteht aus einzelnen Dateien, von denen einige oben aufgeführt sind, die als Hives bezeichnet werden. Jeder dieser Hives enthält einen Registry-Baum, wobei der erste Schlüssel in der Datei die Wurzel (root) des Baumes darstellt. Wie bereits oben erwähnt, sind nicht alle Registry-Bäume real, d. h. sie haben kein Wurzelverzeichnis. Manche sind nur Spiegelungen, oder volatil. Wenn in der Bootphase SYSTEM.DAT in den Arbeitsspeicher geladen wird, schaut der Configuration Manager unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist nach den Liegeplätzen der Hives.[6][17] An einem Beispielrechner:

\REGISTRY\MACHINE\BCD00000000         REG_SZ                \Device\HarddiskVolume1\Boot\BCD
\REGISTRY\MACHINE\HARDWARE         REG_SZ
\REGISTRY\MACHINE\SAM                  REG_SZ                \Device\HarddiskVolume2\Windows\System32\config\SAM
\REGISTRY\MACHINE\SECURITY           REG_SZ                \Device\HarddiskVolume2\Windows\System32\config\SECURITY
und so weiter...

Wie ersichtlich gibt es für den NT-Kernel keine Laufwerksbuchstaben, das Stammverzeichnis beginnt mit „\“. Der Configuration Manager legt nun Symbolische Verknüpfungen an, beispielsweise von \REGISTRY\MACHINE\SECURITY auf \Device\HarddiskVolume2\Windows\System32\config\SECURITY. Dies ist notwendig, weil der Object Manager des Kernels beim Parsen des Strings \REGISTRY\ den Handle an den Configuration Manager weitergibt.[6][17] Die Registry wird also wie ein Gerät („Device“) angesprochen.

Der Configuration Manager unterteilt jeden Hive in Datenblöcke zu je 4096 Bytes, wie es auch bei einer Festplatte der Fall ist. Der Hive kann nur blockweise vergrößert oder verkleinert werden, also in Schritten zu ±4kB. Der erste Block eines Hives ist der Basisblock, der die Signatur „regf“, Sequenznummern, Zeitstempel des letzten Schreibzugriffes im Hive, die Versionsnummer des Hives, eine Prüfsumme, und dessen vollen Name (z. B. %SystemRoot%\CONFIG\SAM) enthält. Die Daten der Registry werden in Zellen (cells) abgelegt, welche Schlüssel, Wert, Security Descriptor, eine Liste der Unterschlüssel oder Schlüsselwerte enthalten können. Ein Feld am Anfang der Zelle beschreibt den Typ und die Größe. Wird eine neue Zelle in den Hive gelegt, und ist dafür eine Expansion des Hives nötig (+4096 Bytes), wird ein Behälter (bin) geschaffen, der die Zelle und den Leerraum des Blockes beinhaltet. Der Raum zwischen dem Ende der Zelle und dem Ende des Behälters kann später mit weiteren Zellen gefüllt werden. Behälter (bins) haben ebenfalls einen Header der die Signatur „hbin“ beinhaltet, sowie den Offset vom Beginn des Behälters/Zelle zum Leerraum hinter der Zelle, sowie die Größe des Behälters.[6][17]

Die Unterteilung der Registry in Behälter (bin) und Zellen (cell) ermöglicht eine effiziente Arbeitsweise: Da Behälter seltener neu zugewiesen werden als Zellen, kann der Configuration Manager entscheiden, statt den Zellen die Behälter in den Arbeitsspeicher zu laden, um die Zahl der (Ent)ladevorgänge zu senken. Beim Einlesen kann der Configuration Manager auch entscheiden, nur Behälter die Schlüssel enthalten in den Arbeitsspeicher zu laden, und die leeren Behälter zu ignorieren. Wenn eine Zelle angelegt oder entfernt wird, fragmentiert der Inhalt der Behälter mit der Zeit, ähnlich wie bei einem Laufwerk. Der Configuration Manager defragmentiert die Registry deshalb kontinuierlich selbst: Wenn ein Behälter leer wird, werden die leeren Behälter in möglichst zusammenhängende Anschnitte gelegt. Ferner führt er Zellen zusammen, die durch Löschungen fragmentiert wurden.[6][17][2]

Das Finden von Zellen und Werten findet durch Anspringen statt: Eine Schlüssel-Zelle enthält einen Zellen-Index, der Zeiger (Informatik) auf Unterschlüssel-Zellen enthält. Um die Unterschlüssel zu finden, ist in den Zellen auch eine Liste der Unterschlüssel enthalten, welche mit dem jeweiligen Zellen-Index verknüpft sind. Um die Suche zu beschleunigen, sortiert der Configuration Manager die Listen alphabetisch. Die Listen werden durch binäre Suche nach dem Zielwert abgesprungen: Der Configuration Manager springt zuerst in die Mitte der Liste, prüft dann, ob der Wert vor oder nach dem Zielwert im Alphabet kommt, und springt dann in die Mitte der oberen bzw. unteren Hälfte. Die Halbierung läuft so lange weiter, bis der Zielwert gefunden wird. Dann wird der Zellen-Index des Ziels ausgelesen, und diese Zelle angesprungen. Der Vorgang wird so lange wiederholt, bis die Zielzelle gefunden ist, oder das Ziel nicht in der Liste der Unterschlüssel auftaucht. In diesem Fall wird eine Fehlermeldung zurückgegeben.[6] Die folgende Grafik veranschaulicht die Sprünge von Zelle zu Zelle in einem Registry-Hive, um Werte (Val 1, Val 2) oder Unterschlüssel (root, Sub Key) auszulesen.[17]

Registry structure.jpg

Es gibt fünf verschiedene Arten von Zellen, der Einfachheit halber ist die Sicherheitsbeschreibungszelle in der Grafik nicht abgebildet. Der Configuration Manager springt erst den Basisblock an, und springt dann auf den Wurzelschlüssel. Von diesem Schlüssel aus springt er zum einen zu einer Wert-Listen-Zelle (hellblau), welche ihn zu den Wert-Zellen Val 1 und Val 2 springen lässt. Andererseits wird vom Wurzelschlüssel aus eine Unterschlüssel-Listen-Zelle (dunkelblau) angesprungen, welche ihn zum nächsten Unterschlüssel (Sub Key) springen lässt. Die fünf verschiedenen Zellenarten sind:[6][17]

  • Die Schlüssel-Zellen (key cell), welche in regedit.exe in der linken Fensterseite als Baumstruktur eingeblendet werden. Sie haben die Signatur kn für Schlüssel oder kl, wenn sie nur eine symbolische Verknüpfung zu einem Schlüssel sind. In diesen Schlüssel-Zellen werden ein Zeitstempel der letzten Aktualisierung, ein Zellen-Index der Über- und Unterzellen, und ein Index zur Sicherheitsbeschreibungszelle (security descriptor cell) sowie der Name des Schlüssels (z. B. CurrentControlSet) abgelegt.
  • Die Wert-Zellen (value cell) enthalten die Werte des Schlüssels, welche in regedit.exe auf der rechten Fensterseite eingeblendet werden. Die Signatur der Zelle ist kv, sie enthält auch Typ (REG_DWORD, REG_BINARY) und Namen des Wertes (z. B. debugger).
  • Unterschlüssel-Listen-Zellen (Subkey-list cell) enthalten eine Liste der Unterschlüssel eines Schlüssels, mit deren Zellen-Index.
  • Wert-Listen-Zellen (Value-list cell) enthalten eine Liste der Werte ihres Schlüssels und ihres Zellen-Indexes.
  • Sicherheitsbeschreibungszellen (Security-descriptor cell) enthalten die Zugriffssteuerungsliste und andere sicherheitsrelevante Einstellungen eines Schlüssels. Die Signatur ist ks. Mehrere Knoten können sich eine Sicherheitsbeschreibungszelle teilen, deshalb enthalten diese auch eine Liste der Knoten.

Der Configuration Manager greift nicht bei jeder Suche auf das Festplatten-Abbild des Hives zu. Stattdessen werden alle nötigen Hives in den Adressraum des Kernels einbezogen, indem diese in den Auslagerungsspeicher (pagefile.sys) geladen werden. Nur beim Booten wird der System-Hive komplett in den Arbeitsspeicher geladen. Der Configuration Manager betreibt aufgrund der Fragmentierung im Auslagerungsspeicher Cell Index Mapping, was der virtuellen Speicherverwaltung entspricht, nur eben für die Zellen der Registry. Er unterteilt auch jeden Hive im Auslagerungsspeicher in Blöcke zu 512 Bytes, und weist ihnen je ein Bit zu. Wird dieser Abschnitt modifiziert, wird das Bit von 0 auf 1 gedreht, und der Abschnitt zur Synchronisierung freigegeben. Der Hive-Sync findet 5 Sekunden nach dem Ereignis statt, und synchronisiert alle geänderten Hive-Abschnitte zwischen Auslagerungsspeicher und Image. Finden derweil oder danach weitere Modifikationen an Hives statt, so werden diese erst nach weiteren 5 Sekunden synchronisiert. Um sicherzugehen, dass eine Wiederherstellung auch nach einem Abschmieren des Rechners während der Synchronisierung möglich ist, werden die geänderten Abschnitte zuerst in die *.log-Dateien geschrieben, die neben allen Hive-Dateien vorhanden sind. Danach erhöht der Configuration Manager eine fortlaufende Nummer im Hive, schreibt den modifizierten Abschnitt vom *.log in die Hive-Datei *.DAT, und erhöht eine zweite fortlaufende Nummer im Hive. Stürzt der Rechner während des Schreibvorganges ab, sieht der Configuration Manager nach dem Reboot dass die fortlaufenden Nummern nicht passen, und aktualisiert weiter von *.log in *.DAT.[6][17]

Früher hatte jede Datei des Maschinenhives und die .DEFAULT.DAT eine *.sav und *.log als Redundanz, wobei SYSTEM.DAT zusätzlich noch SYSTEM.alt als Redundanz besaß. Nur NTUSER.DAT war auf eine *.log beschränkt.[6][17] Dies wurde bis einschließlich Windows Vista beibehalten.[18] Moderne NT-Systeme ab Windows 7 haben als Redundanz *.log, *.log1, *.log2 für jede Registry-Datei, nicht nur SYSTEM.DAT.

Für jeden geöffneten Registry-Schlüssel legt der Configuration Manager einen Key Control Block (KCB) an. Dieser enthält den kompletten Pfad des Schlüssels, einen Zellen-Index des Knotenpunktes, und eine Flag ob der Schlüsselsteuerblock gelöscht werden soll wenn der letzte Handle beendet wurde. Windows legt alle Schlüsselsteuerblöcke in einer alphabetisch geordneten Hashtabelle[19] ab, um schnelleren Zugriff zu ermöglichen. Wenn der Object Manager des Kernels von einer Anwendung \REGISTRY\Namenspfad zu parsen bekommt, übergibt er den Namenspfad an den Configuration Manager. Dieser springt wie oben beschrieben die Schlüssel und Unterschlüssel durch, bis der Zielschlüssel (Ziel-Zelle) gefunden wurde. Danach prüft der Configuration Manager, ob der Schlüssel bereits geöffnet wurde. Wenn ja, wird der Zähler im Schlüsselsteuerblock um 1 erhöht. Wenn nicht, erstellt der Configuration Manager einen weiteren Schlüsselsteuerblock, und fügt diesen in die Hashtabelle ein. Dann erstellt er ein Schlüsselobjekt, das auf den Schlüsselsteuerblock zeigt, und übergibt dieses an den Object Manager, der es an die Anwendung weitergibt. Wenn noch eine andere Anwendung auf denselben Schlüssel zugreifen möchte, bekommt sie ebenfalls das Schlüsselobjekt zu sehen. Soll ein neuer Schlüssel erstellt werden, springt der Configuration Manager zuerst den letzten bestehenden Schlüssel der Sprungkette an. Dann prüft er, ob der Raum in der Liste der freien Zellen ausreichend ist, um den neuen Schlüssel aufzunehmen. Wenn nicht, wird ein neuer Behälter eröffnet. Ansonsten wird der neue Schlüssel mit allen Daten angelegt, und in die Index-Liste des Vaterschlüssels eingetragen.[6][17]

Bis Windows NT 6.1 gab es nur eine globale Hashtabelle für alle KCBs. Ab Windows 7 besitzt jeder Hive eine eigene Hashtabelle, ferner wurde der Zugriff auf Schlüssel verbessert: Bei Schreibzugriffen auf einen Unterschlüssel waren früher alle Oberschlüssel des Pfades abgeschlossen; nun ist davon nur der Schlüssel betroffen, der tatsächlich auch beschrieben wird. Ferner wurde der Synchronisierungszyklus erhöht.[4]

Speicherung von Programmeinstellungen[Bearbeiten | Quelltext bearbeiten]

Ein weiter verbreiteter Irrglaube ist, dass Programme all ihre Einstellungen in der Registrierungsdatenbank speichern würden. Tatsächlich werden dort im Idealfall von Nicht-Betriebssystemsoftware nur die nötigsten Informationen abgelegt. Diese Informationen sind entweder für Windows, oder andere Programme von Interesse. Die Registry speichert meist weder die Spielstände des Ego-Shooters, noch je die Themes des Firefox, welche Software aber wirklich wieviel in der Registry ablegt ist vom System nicht beschränkt und daher kaum pauschal vorherzusagen. Die Registrierungsdatenbank ist für Anwendungen mehr eine Pinnwand oder ein Schwarzes Brett. Nur betriebssystemeigene Komponenten wie der Internet Explorer oder betriebssystemnahe Komponenten wie Treiber machen stark von der Registry Gebrauch. Für die Masse der Anwendungen gibt es folgende Pfade, um Informationen und Dateien abzulegen:

  • C:\Programme, was allerdings ungünstig ist, da hier nur mit Adminrechten geschrieben werden kann. Wenn hier Programmeinstellungen geändert werden müssen, meist im Zuge von Updates, kommt der Dialog der Benutzerkontensteuerung.
  • %userprofile%\AppData\Roaming wird meist gewählt. Die hier hinterlegten Ordner ziehen mit dem Benutzer um, wenn sich dieser an einem anderen Rechner der Domäne anmeldet. LibreOffice legt hier Konfigurationsdaten ab.
  • %userprofile%\AppData\Local wird seltener gewählt, da dieser Ordner bzw. sein Inhalt nicht mit dem Benutzer wandert. JRE und LibreOffice legen hier nichts ab, aber zum Beispiel der Ressourcen-Monitor (resmon.exe) seine Konfigurationsdatei.
  • %userprofile%\AppData\LocalLow ist ein Sandbox-Verzeichnis mit niedriger Verbindlichkeitsstufe. Die Java-Laufzeitumgebung legt hier ihre Konfigurationsdateien und weitere ab.
  • C:\Programdata ist das Verzeichnis der Daten, die alle Benutzer betreffen. LibreOffice legt hier zum Beispiel nichts ab, aber die Java-Laufzeitumgebung eine XML-Datei mit Update-Einstellungen.

Manuelle Bearbeitungsmöglichkeiten[Bearbeiten | Quelltext bearbeiten]

Registrierungs-Editor[Bearbeiten | Quelltext bearbeiten]

Icon von regedit.exe

Um manuell in der Registrierungsdatenbank zu editieren, stellt Windows den Registrierungs-Editor regedit.exe bereit. Dieser kann in der Suchleiste durch Eingabe von regedit aufgerufen werden. In der linken Spalte werden die Hives und Schlüssel-Zellen hierarchisch abgebildet, rechts werden die dazugehörigen Wert-Zellen eines Schlüssels samt ihres Inhaltes einzeln aufgelistet. Die Schlüssel-Listen-Zellen werden nicht dargestellt, sondern nur durch die Baumstruktur der Schlüssel abstrahiert. Die Wert-Listen-Zellen sind ebenfalls nicht sichtbar, bilden aber die Struktur der Liste rechts. Die Sicherheits-Beschreibungs-Zellen werden durch das Kontextmenü abstrahiert, wenn auf einen Schlüssel Rechtsklick > Berechtigungen... ausgeführt wird.

Die gesamte Registry kann exportiert werden wenn auf das Symbol „Computer“ Rechtsklick > Exportieren ausgeführt wird. Gerade nicht eingehängte Teile, z. B. Schema.DAT und Components.DAT bleiben dabei aber unberücksichtigt. Wird ein (Unter)Schlüssel angewählt und exportiert, wird dieser samt seiner Unterstrukturen in eine Registrierungsdatei mit der Dateiendung *.reg geschrieben, welche in Unicode kodiert, und damit menschenlesbar ist. Wird ein Schlüssel gewählt und im Fenstermenü Datei > Drucken... gewählt, werden auch die Informationen der Schlüssel-Zellen ausgedruckt, welche im Registrierungs-Editor nicht angezeigt werden, aber Teil der Zelle sind. Zum Beispiel den letzten Schreibzugriff und der Klassenname.[20] Die *.reg-Dateien sind Unicode-Textdateien mit der Zeichenfolge „Windows Registry Editor Version 5.00“ in der ersten Zeile. Die Syntax ist wie folgt:

[<Hivename>\<Schlüsselname>\<Unterschlüsselname>]
"Wertname"=<Werttyp>:<Wertdaten>

Wenn der Standardwert eines Schlüssels bearbeitet werden soll, wird ein At-Zeichen vorangestellt:

[<Hivename>\<Schlüsselname>\<Unterschlüsselname>]
@=<Werttyp>:<Wertdaten>

String-Werte benötigen keine Werttyp-Angabe. Pfade in Wert-Zellen müssen aber mit Doppelbackslash „\\“ geschrieben werden, einzelne „"“ als „\"“. Für den Werttyp gibt es folgende hex()-Abkürzungen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Wikipedia]
"PathToExe"="C:\\Program Files (x86)\\ACME Corp\\ACE.exe"
"haenschen"=hex:<Binär-Wert>
"klein"=dword:<DWORD-Wert>
"geht"=hex(0):<REG_NONE-Wert>
"allein"=hex(1):<REG_SZ-Wert>
"in"=hex(2):<REG_EXPAND_SZ Wert>
"die"=hex(3):<Binär-Wert> ; identisch mit "hex:"
"weite"=hex(4):<DWORD-Wert> ; Little-Endian
"Welt"=hex(5):<DWORD-Wert> ; Big-Endian
"hinein"=hex(7):<REG_MULTI_SZ-Werte> ; getrennt durch Komma
"Stock"=hex(8):<REG_RESOURCE_LIST-Werte> ; getrennt durch Komma
"und"=hex(a):<REG_RESOURCE_REQUIREMENTS_LIST-Werte> ; getrennt durch Komma
"Hut"=hex(b):<QWORD-Wert> ; acht Hex-Werte getrennt durch Komma

Ein vorangestelltes Minus entfernt den Schlüssel:

[-HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]

Werte in einem Schlüssel werden durch ein „-“ nach dem Wertname entfernt:[20]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]
@=-
"MeineMeinung"=-

wobei @=- den Standardwert entfernt, und "MeineMeinung"=- den String MeineMeinung und seinen Wert. In die Reg-Daten können auch Kommentare einfließen:

; Dies ist ein Kommentar. Er fällt vergleichsweise lang aus
[HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]
"MeineMeinung"="WikipediaIstGut"

Die Reg-Dateien werden in die Registrierungsdatenbank gelesen, wenn sie doppelt geklickt werden. Ein Editieren ist mit Rechtsklick > Bearbeiten möglich.

PowerShell[Bearbeiten | Quelltext bearbeiten]

Hauptartikel: Windows PowerShell

Seit dem Erscheinen der Windows PowerShell gibt es eine weitere sehr einfache Möglichkeit, die Registry zu verwalten. Dabei kann man auf die Registry direkt über die Konsole oder durch ein Shellskript wie auf ein herkömmliches Laufwerk zugreifen. Die PowerShell kann quasi zwischen den Verzeichnis-Welten des Object Managers und des Configuration Managers wechseln. Im „normalen“ Verzeichnis navigiert man mit den Aliassen ls um sich Unterverzeichnisse anzeigen zu lassen, cd <ziel> um ein Unterverzeichnis anzunavigieren, cd .. um ein Verzeichnis zurückzugehen usw. Gibt man beispielsweise cd HKLM: ein, wechseln man auf den Hauptschlüssel HKEY_LOCAL_MACHINE. Zu den Unterschlüsseln gelangt man ebenfalls über den Befehl cd oder in der Langform Set-Location. Der Befehl Get-ItemProperty . zeigt alle Eigenschaften (Registry-Einträge), die für den aktuellen Registryschlüssel gespeichert sind. Auf diese Weise lassen sich beispielsweise durch Eingabe der folgenden Befehlsfolge in der PowerShell alle Einträge des Run-Schlüssels anzeigen:

cd HKLM:
cd Software\Microsoft\Windows\CurrentVersion\Run
Get-ItemProperty .
Navigieren mit der PowerShell

Nach dem Eingeben erfolgt unter anderem (PSPath, PSParentPath, PSChildName, PSProvider) als Ausgabe PSDrive: HKCU. Gleiches gilt, wenn man die Laufwerke des Rechners durch den Befehl Get-PSDrive anzeigen lässt, wobei hier nicht alle Registry-Laufwerke angezeigt werden. Wie bereits oben im Anschnitt „Arbeitsweise der Registry“ gezeigt, wird die Registry von Windows selbst wie ein Laufwerk/Gerät verwaltet, was in der PowerShell auch sichtbar wird. Mit dem Befehl cd C:\ oder einem anderen Laufwerksbuchstaben wechselt die PowerShell wieder in die Welt des Object Managers / Datei-Explorers zurück.

Auch ein indirektes Auslesen der Registry wird damit möglich: Mit den Befehlen $key="HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" wird der Pfad geholt und in die Variable $key geschrieben, $wert="Test" holt den Wert „Test“ und steckt ihn in die Variable $wert, und mit (Get-ItemProperty $key).$wert kann die Eigenschaft „Test“ im Schlüssel „Run“ ausgegeben werden, hier also der Pfad des Autostarteintrages.

Der Befehl New-Item HKCU:\Software\Wikipedia (Alias: md) legt einen neuen Schlüssel namens „Wikipedia“ an, Remove-Item HKCU:\Software\Wikipedia (Alias: del) entfernt ihn wieder. Mit New-ItemProperty -Path HKCU:\SOFTWARE\Wikipedia -Name MeineMeinung -PropertyType String -Value WikipediaIstGut wird eine Zeichenfolge namens „MeineMeinung“ mit dem Wert „WikipediaIstGut“ im Schlüssel „Wikipedia“ abgelegt. Neben String (REG_SZ) sind ExpandString (REG_EXPAND_SZ), Binary (REG_BINARY), DWord (REG_DWORD), MultiString (REG_MULTI_SZ) und QWord (REG_QWORD) ebenfalls zulässig.

Konsolenregistrierungsprogramm[Bearbeiten | Quelltext bearbeiten]

Das Konsolenregistrierungsprogramm reg.exe läuft nur innerhalb einer Eingabeaufforderung cmd.exe, wobei die Befehle auch in der PowerShell eingesetzt werden können. Die Syntax ist dabei sehr einfach, der Nachteil aber die fehlende Befehlszeilenergänzung, was das Risiko von Schreibfehlern erhöht. Die Syntax zum Abfragen von Schlüsseln ist wie folgt:REG QUERY Schlüssel(pfad), mit den angehängten optionalen Parametern /v Wert (sucht nach einem bestimmten Registrierungswert), /ve (sucht nach dem Standard- oder leeren Wert), und /s (sucht nach allen Unterschlüsseln und Werten). Der Befehl

reg query HKCU\Software\Microsoft\Windows\Currentversion\run

in einer cmd.exe eingegeben gibt eine Liste aller Autostarteinträge des Run-Schlüssels im Benutzer-Hive zurück. Die Syntax zum Anlegen von Schlüsseln ist wie folgt: REG ADD Schlüssel mit den angehängten optionalen Parametern /v Wert (hinzuzufügender Wert unter dem Schlüssel), /ve (fügt einen Standardwert hinzu), /t (Datentypen: REG_SZ | REG_MULTI_SZ | REG_DWORD_BIG_ENDIAN | REG_DWORD | REG_BINARY | REG_DWORD_LITTLE_ENDIAN | REG_NONE | REG_EXPAND_SZ), /s (bestimmt das Trennzeichen in der Datenzeichenfolge), /d (Daten), und /f (Überschreiben). Der Befehl

reg add HKCU\Software\Microsoft\Windows\Currentversion\run /v Test /t REG_SZ /d calc.exe

legt im Autostartschlüssel „Run“ die Zeichenfolge (REG_SZ) namens „Test“ an, welche als Wert „calc.exe“ hat. Würde dieser Schlüssel beibehalten, würde sofort nach dem Einloggen des Users der Taschenrechner aufpoppen. Die Syntax zum Entfernen von Schlüsseln ist wie folgt: REG delete Schlüssel mit den angehängten optionalen Parametern /v Wert (zu löschender Wert unter dem Schlüssel), /ve (löscht den Wert des Standardwertes), /va (löscht alle Einträge des Schlüssels), und /f (für “mit Gewalt”). Der Befehl

reg delete HKCU\Software\Microsoft\Windows\Currentversion\run /v Test

löscht die Zeichenfolge „Test“ mit ihrem Wert „calc.exe“. Der böse Taschenrechner ist gebannt. Mit dem Befehl REG COPY Schlüssel1 Schlüssel2 wird der Schlüssel 1 an die Position von Schlüssel2 kopiert. Mit dem Parameter /s werden die kompletten Unterschlüssel mitgenommen, /f erzwingt das Kopieren. Weitere Befehle wie Save, Load, Unload, Restore, Compare, Export, Import, usw. usf. sind möglich.

Ausfallsicherheit[Bearbeiten | Quelltext bearbeiten]

Aufgrund der Tatsache, dass in der Registry große Teile der Systemkonfiguration gespeichert sind, wird diese oft als Single Point of Failure angesehen. Eine Beschädigung der Registrierungsdatenbank kann das Starten des Betriebssystems erschweren oder gar unmöglich machen.[12] Aufgrund dessen werden eine Reihe von Maßnahmen ergriffen, die einer Beschädigung der Registrierungsdatenbank vorbeugen oder diese rückgängig machen können:

  • Durch den in Windows Vista eingeführten Kernel Transaction Manager können mehrere Einzeloperationen zu einer Transaktion zusammengefasst werden, die entweder als Ganzes erfolgreich verläuft, oder durch einen Rollback rückgängig gemacht werden kann, was inkonsistente Zustände verhindern soll.[21]
  • Einen Schutz vor inkonsistenten Zuständen wird auch durch die Implementierung der Registry selbst gewährleistet, da Änderungen an der Registry in Logdateien protokolliert werden. Bricht ein Schreibvorgang unerwartet ab (z.B. durch einen Stromausfall), nachdem bereits ein Teil der Daten verändert wurde, können diese Änderungen so wieder zurückgenommen werden.[22]
  • Auch das Dateisystem, in dem die Dateien der Registry gespeichert sind, kann einer Beschädigung entgegenwirken. So besitzt NTFS, das in allen modernen Windows-Versionen eingesetzt wird, weitreichende Fehlerüberprüfungs- und Reparaturmechanismen.[22]
  • Der besonders sensible Abschnitt SYSTEM wurde in früheren Windows-Versionen als Backup in der Datei SYSTEM.ALT gespeichert.[11]

Registry-Cleaner[Bearbeiten | Quelltext bearbeiten]

Vielfach wird damit geworben, dass eine „Reinigung“ der Registrierungsdatenbank notwendig oder wünschenswert sei, um einen Geschwindigkeits- und Stabilitätsvorteil zu erhalten.

Der Nutzen von sogenannten „Registry-Cleanern“ wird jedoch überwiegend angezweifelt und als Mythos eingestuft.[23][24] So würden ungenutzte und damit überflüssige Einträge in der Registry nur einen verschwindend geringen Teil ausmachen, deren Bereinigung nicht ins Gewicht falle. Der US-amerikanische Autor und Most Valuable Professional Ed Bott schätzt den Nutzen als verschwindend gering ein und warnt gleichzeitig davor, dass ein fälschlicherweise entfernter Eintrag dazu führen könne, dass auf dem System installierte Programme nicht mehr ordnungsgemäß funktionieren. Die Nutzung von Registry-Cleanern sei somit abzulehnen: „Don't run registry cleaner programs, period.“ (deutsch: „Benutze keine Programme zum Bereinigen der Registry. Punkt.“).[25]

Auch in Testberichten konnte der vermeintliche Nutzen durch das Bereinigen der Registry nicht nachgewiesen werden: Die Webseite Windows Secrets testete die Reinigungsprogramme CCleaner und jv16 PowerTools 2011 und verglich diese mit der Windows-internen Datenträgerbereinigung. Bei beiden Programmen konnte kein Geschwindigkeitsvorteil gegenüber der Windows-Datenträgerbereinigung gemessen werden. Die Windows-Datenträgerbereinigung lässt die Registry jedoch unberührt und beschränkt sich auf das Löschen überflüssiger Dateien auf der Festplatte.[26]

Bis hin zu Windows XP (inkl. Windows Server 2003) konnte der Bootvorgang scheitern, wenn Kernel und SYSTEM.DAT mehr als die ersten 16 MB Arbeitsspeicher belegten.[27] Microsoft bot deshalb das hauseigene Tool „RegClean“ zum Entfernen unnötiger Registry-Einträge an. Dies ist aber bei allen modernen Windows-Versionen überflüssig.

Sichern der Registrierung[Bearbeiten | Quelltext bearbeiten]

Windows 9x[Bearbeiten | Quelltext bearbeiten]

Windows 95 sichert die Registrierung bei jedem erfolgreichen Start und speichert diese als SYSTEM.DA0 und USER.DA0 im Systemverzeichnis.[28] Eine manuelle Sicherung ist mit dem Programm ERU.EXE möglich, das sich auf der Windows 95-CD befindet.[29]

Unter Windows 98 und Windows Me existiert stattdessen das Programm SCANREG.EXE, das bei jedem erfolgreichen Start von Windows zahlreiche wichtige Systemdateien, darunter die Registrierung, sichert, aber auch manuell aufgerufen werden kann, um eine Sicherung anzulegen oder das System von einer Sicherung wiederherzustellen.[30] Standardmäßig werden bis zu fünf Backups als CAB-Datei im Ordner %systemroot%\Sysbckup angelegt. Über eine INI-Datei können diese und weitere Einstellungen modifiziert werden.[31] Aufgrund eines Programmfehlers sichert SCANREG.EXE die USER.DAT nicht, wenn diese nicht im Systemverzeichnis liegt, weil mehrere Benutzerprofile angelegt wurden.[32]

Alle Versionen von Windows 9x bieten zudem die Möglichkeit, mittels des Registierungseditors REGEDIT.EXE im MS-DOS-Modus die gesamte Registrierung in eine Registrierungsdatei zu exportieren und auch wieder zu importieren.[28] Windows 9x sichert außerdem direkt nach Ende des Windows-Setups eine Kopie der SYSTEM.DAT unter dem Namen SYSTEM.1ST im Stammverzeichnis der Festplatte.[33]

Windows NT[Bearbeiten | Quelltext bearbeiten]

Windows NT bis einschließlich Version 4.0 boten die Möglichkeit, eine Kopie der Registrierung unter dem Verzeichnis %systemroot%\repair anzulegen und diese bei Bedarf auf einer sogenannten Notfalldiskette zu sichern. Standardmäßig legt Windows eine solche Notfalldiskette am Ende des Setups an, eine Sicherungskopie der Registrierung und (optional) eine Notfalldiskette kann aber auch manuell durch Aufrufen des Programms RDISK.EXE erstellt werden.[34] Standardmäßig werden die Dateien SAM und SECURITY nicht gesichert, es sei denn RDISK.EXE wird mit dem Parameter /S aufgerufen.[35]

In Windows 2000 und Windows XP wird die Registrierung stattdessen über das Programm Sicherung (NTBACKUP.EXE) gesichert.[36] Standardmäßig ist in der Windows XP Home Edition das Programm Sicherung nicht vorhanden, es kann aber von der Windows XP-CD nachinstalliert werden.[37]

Betriebssysteme ab Windows Vista aufwärts bieten keine Möglichkeit mehr, die Registrierung zu sichern.

Windows-Registrierungsdatenbank ohne Windows[Bearbeiten | Quelltext bearbeiten]

Das für Linux- und Unix-Systeme verfügbare Win32-API namens Wine enthält eine eigene Implementation der Windows-Registrierungsdatenbank. Wine selbst legt seine eigenen Einstellungen darin ab. Daneben können andere Windows-Programme, die auf Wine laufen, ihre Einstellungen dort eintragen. Für Win32-Anwendungen erscheint die Registrierungsdatenbank genau gleich wie auf einem Windows-NT-System. Im Hintergrund befindet sich aber – anders als bei Windows-NT-Systemen und wie in unixoiden System für Einstellungen üblich – keine Datenbank, sondern einfache ASCII-Textdateien. In den folgenden Dateien im Verzeichnis ~/.wine ist die Registrierungsdatenbank von Wine in Form lesbarer Texte enthalten:[38]

Datei Schlüssel
system.reg HKEY_LOCAL_MACHINE
user.reg HKEY_CURRENT_USER
userdef.reg HKEY_USERS\.Default

Das ReactOS-Projekt, das versucht Windows-NT nachzubauen, übernimmt Teile von Wine, darunter auch die Umsetzung der Windows-Registrierungsdatenbank.[39]

Alternativen[Bearbeiten | Quelltext bearbeiten]

In den meisten unixoiden Betriebssystemen, wie FreeBSD, Mac OS X oder in den Linuxbasierten gibt es keine zentrale Konfigurationsdatenbank, sondern zahlreiche zentral abgelegte Konfigurationsdateien.

Jedoch gibt es Projekte die Registry-artige Datenbanken auch für unixoide Systeme bereitstellen wollen, beispielsweise Elektra[40][41] oder die Gnome-Konfigurationsdatenbank GConf bzw. der Nachfolger DConf. GConf baute im Gegensatz zur Windows-Registry und DConf konsequent auf XML-Dateien auf, was die Möglichkeit bot, die Schlüssel mit jedem Texteditor oder XML-Parser zu lesen und bearbeiten. Ebenso legt Elektra die Schlüssel in Plain-text-Dateien ab, die z. B. mit Editoren wie vi bearbeitet werden können.[42]

Apple setzt bei Mac OS X teilweise auf sogenannte Property Lists, die im XML-, JSON- oder in einem proprietären Binär-Format vorliegen können.[43]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b Martin Grotegut: Windows 7 in Unternehmensnetzen mit Service Pack 1, IPv4, IPv6. Springer, 2011, ISBN 978-3-642-01034-7.
  2. a b Ingo Böttcher (MVP): Die besten Windows Tuning Tipps… 7. Juni 2011, abgerufen am 18. Januar 2015.
  3. Tools rund um die Windows-Registry. Computerwoche, 28. Mai 2013, abgerufen am 18. Januar 2015.
  4. a b Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing. Microsoft TechNet, 1. Oktober 2009, abgerufen am 18. Januar 2015 (englisch).
  5. Registry Keys. In: Microsoft Developer Network. 4. August 2010, abgerufen am 3. Dezember 2015 (englisch).
  6. a b c d e f g h i j k Mark Russinovich, David Solomon, Alex Ionescu: Windows Internals, Part 1. Microsoft Press, 2012, ISBN 978-0-7356-4873-9, S. 277 ff.
  7. Why do registry keys have a default value? In: The New Old Thing. Microsoft, 18. Januar 2008, abgerufen am 3. Dezember 2015.
  8. Windows-Registrierungsinformationen für Benutzer mit fortgeschrittenen Kenntnissen. Microsoft Support, 6. Mai 2013, abgerufen am 11. Februar 2015 (englisch).
  9. a b c Total Registry – Infoguide rund um die Registry. In: WinTotal.de. 20. Juni 2004, abgerufen am 29. November 2015.
  10. William Stanek: Windows Server 2008 Inside Out. Microsoft Press, 2008, ISBN 978-0-7356-2438-2.
  11. a b Registry Hives (Windows). In: msdn.microsoft.com. Abgerufen am 27. November 2015 (englisch).
  12. a b Paul Robichaux: Managing The Windows 2000 Registry. O’Reilly & Associates, 2000, ISBN 1-56592-943-8.
  13. Barry Simon: The Windows 95 Registry, Part 1. In: PC Magazine. Volume 14, Nr. 8, 1995, S. 251 ff. (Vorschau auf Google Books).
  14. Appendix A – Windows NT Registry. In: Windows NT 4.0 Server Product Documentation. Microsoft, abgerufen am 29. November 2015 (englisch).
  15. The .Default user is not the default user. In: The Old New Thing. Microsoft, 2. März 2007, abgerufen am 28. November 2015 (englisch).
  16. a b Bekannte Sicherheits-IDs in Windows-Betriebssystemen. Microsoft, abgerufen am 29. November 2015.
  17. a b c d e f g h i Mark Russinovich: Inside the Registry. 2000?, abgerufen am 18. Januar 2015 (englisch).
  18. Paul McFedries: Microsoft Windows Vista Unleashed. Sams, 2008, ISBN 978-0-672-33013-1, S. 299 ff.
  19. Tarik Soulami: Inside Windows Debugging. Microsoft Press, 2012, ISBN 978-0-7356-6278-0.
  20. a b Holger Schwichtenberg u. weitere: Windows Vista Business. Addison-Wesley Verlag, 2007, ISBN 978-3-8273-2422-1.
  21. Kernel Transaction Manager (Windows). In: MSDN Library. Abgerufen am 4. Dezember 2015 (englisch).
  22. a b Mike Halsey, Andrew Bettany: Windows Registry Troubleshooting. Apress, 2015, ISBN 978-1-4842-0992-9, S. 33 f. (Vorschau auf Google Books [abgerufen am 6. Dezember 2015]).
  23. Der Mythen-Jäger – Folge 22: Registry säubern. In: CHIP Online. 29. Dezember 2012, abgerufen am 3. Dezember 2015.
  24. What's the Registry, Should I Clean It, and What's the Point? In: Lifehacker. 3. Januar 2010, abgerufen am 3. Dezember 2015 (englisch).
  25. Ed Bott: Why I don't use registry cleaners. 19. April 2005, abgerufen am 3. Dezember 2015 (englisch).
  26. Putting Registry-/system-cleanup apps to the test. Windows Secrets, 10. November 2011, abgerufen am 18. Januar 2015 (englisch).
  27. System may not start when creating a large number of logical units and volumes. Support Microsoft, abgerufen am 20. Januar 2015 (englisch).
  28. a b Microsoft Knowledge Base – Using Registry Editor in Real Mode
  29. Microsoft Knowledge Base – Windows 95 Emergency Recovery Utility
  30. Microsoft Knowledge Base – Description of the Windows Registry Checker Tool (Scanreg.exe)
  31. Microsoft Knowledge Base – How to Customize Registry Checker Tool Settings
  32. Scanreg.exe Does Not Back Up User.dat Files When Using User Profiles
  33. Microsoft Knowledge Base – Troubleshooting Windows 95 Using Safe Mode
  34. Microsoft Knowledge Base – Description of Windows NT Emergency Repair Disk
  35. RDISK /S and RDISK /S- Options in Windows NT
  36. Microsoft Knowledge Base – How to Create an Emergency Repair Disk in Windows 2000
  37. How can I get NTBackup for Windows XP Home Edition?
  38. Using the Registry and Regedit (englisch)
  39. Using ReactOS Registry format (englisch)
  40. Interview: Elektra, die Linux Registry auf golem.de (2004)
  41. www/ Software/ Elektra auf Freedesktop.org (englisch)
  42. Interview: Elektra, die Linux Registry auf golem.de (2004)
  43. The plist(5) manual page auf developer.apple.com. Abgerufen am 23. Januar 2014.