Registrierungsdatenbank

Registrierungsdatenbank
Basisdaten
Entwickler	Microsoft
Aktuelle Version	Windows 10
Betriebssystem	Windows
Lizenz	EULA (proprietär)
deutschsprachig	ja

Die Windows-Registrierungsdatenbank (meist nur Registry genannt) ist seit der ersten Version von Windows NT die zentrale hierarchische Konfigurationsdatenbank des Betriebssystems Windows. Hier werden sowohl Informationen zu Windows selbst als auch zu Programmen gespeichert.

Mit Microsoft Windows 3.1 wurde die Windows-Registry 1992 auch im Bereich der Consumer-Betriebssysteme eingeführt. Während unter den frühen Windowssystemen in der Registry hauptsächlich Dateierweiterungen gespeichert wurden, ist sie seit Windows NT 3.1 und Windows 95 eine umfassende Datenbank zur Speicherung aller Einstellungen für die Verwaltung des Systems und aller integrierten Systemdienste und -prozesse. Anwendungsprogramme können ihre Einstellungen ebenfalls dort speichern.

Das Symbol der Registrierungsdatenbank ist ein aus vielen kleineren Würfeln zusammengesetzter großer Würfel mit drei freischwebenden Teilwürfeln.

Motivation und Entwicklungsgeschichte

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 geparst werden müssen. Dies brachte in den 1990er Jahren Performancenachteile mit sich. Ferner können Berechtigungen nur auf Dateiebene, nicht auf Eintragsebene gesetzt werden; verschiedene 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, 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.

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, 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; es 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 der Hive SYSTEM 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.

Nachteile der Registrierungsdatenbank

Die Windows-Registrierung hat neben den genannten Vorteilen auch einige bedeutende Nachteile, die sich aufgrund ihrer Architektur ergeben:

Die zentralisierte und hierarchische Struktur kann leicht zu einem Single Point of Failure führen, wenn hierarchisch übergeordnete Schlüssel fehlerhaft sind. Einstellungen, die keine oder eine flache hierarchische Struktur, wie Konfigurationsdateien, aufweisen, funktionieren meist auch dann noch, wenn einzelne Werte fehlerhaft oder einzelne Dateinamen falsch sind.

Anwendungen, die ihre Einstellungen in der Registry speichern, sind oft an den lokalen Rechner gebunden, was bedeutet, dass die Migration von einem Computer zum anderen sehr oft eine komplette Neuinstallation des Programms erfordert. Das Migrieren oder zentrale Speichern von Einstellungen auf einem Server ist mit der Windows-Registrierung nur mit großem zusätzlichem Aufwand und spezieller Software durch Synchronisation möglich. Konfigurationsdateien können dagegen direkt und ohne Umweg auf einen eingebundenen Server geschrieben werden.

Das Anzeigen und Bearbeiten der Einstellungen in der Registrierdatenbank benötigt spezielle Software. Konfigurationsdateien sind dagegen mit jedem einfachen Texteditor zugänglich. Dies kann je nach Aufgabe den Wartungsaufwand minimieren.

Aufbau

Überblick und Terminologie

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

Die Registrierungsdatenbank besteht aus Schlüsseln (englisch keys) und Einträgen (englisch 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 Registrierungsdatenbank ist ein Name-Wert-Paar, ähnlich einer Datei. Der Wert (englisch 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. 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.

Hauptschlüssel

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

• 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:

• 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. Die Abkürzung HKEY steht dabei für „handle (to a) key“.

Werte und Datentypen

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:

• 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-Bit große Integer-Werte als 4-Byte lange Hexadezimalwerte gespeichert werden. Wird für inkrementelle Werte, 4-Byte-Statuscodes oder boolesche Variablen (0=falsch, 1=wahr) verwendet.
• REG_QWORD: Ein Binärdatentyp, bei dem 64-Bit große Integer-Werte als 8-Byte lange Hexadezimalwerte gespeichert werden. 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)

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. 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

In Windows 9x gibt es die folgenden Hives:

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

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

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.
HKU\S-1-5-19	%SystemRoot%\ServiceProfiles\LocalService\Ntuser.dat	Hive des Benutzerkontos „Lokaler Dienst“ (Local Service).
HKU\S-1-5-20	%SystemRoot%\ServiceProfiles\NetworkService\Ntuser.dat	Hive des Benutzerkontos „Netzwerkdienst“ (Network Service).

Technik

Arbeitsweise der Registry

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. 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. 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 Namen (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.

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 der 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.

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. 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.

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:

• 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.

Früher hatten 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. Dies wurde bis einschließlich Windows Vista beibehalten. 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 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.

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.

Speicherung von Anwendungseinstellungen

Anwenderprogramme können ihre eigenen Informationen in die Registry ablegen.

Für Anwendungen ist es nicht erforderlich, die Windows-Registrierung zu verwenden. NET-Framework-Anwendungen verwenden beispielsweise XML-Dateien zur Konfiguration, während portable Anwendungen ihre Konfigurationsdateien in der Regel zusammen mit ihren ausführbaren Dateien ablegen. Anwendungen die plattformunabhängig sind, wie z. B. Firefox oder VLC speichern ihre Einstellungen in Konfigurationsdateien, die speziell für ihre Bedürfnisse gestaltet sind. Viele Anwendungen benutzen die Windows-Registrierung nur spärlich, um von nur in Windows verfügbaren Schnittstellen unabhängig zu sein.

Es ist dem Programmhersteller überlassen, ob diese Informationen in die Registrierungsdatenbank oder in einem der unten aufgelisteten gemeinsamen Ordnern abgelegt werden sollen (Stand: Windows 10):

Nicht benutzerbezogen:

• %programdata% ist das Verzeichnis der Daten, die alle Benutzer betreffen (auf Windows-10-Systemen: C:\ProgramData). Für das Anlegen von Ordnern und Dateien dort werden Administratorrechte benötigt. Daher werden diese durch das Installationsprogramm des Anwenderprogramms angelegt, die entsprechende Ordner können dabei so konfiguriert werden, dass auch Programme, die unter dem Benutzerkontext laufen, Schreibzugriff darauf haben.

Benutzerbezogen:

• %userprofile%\AppData\Roaming: Die hier hinterlegten Ordner ziehen mit dem Benutzer um, wenn sich dieser an einem anderen Rechner der Domäne anmeldet.
• %userprofile%\AppData\Local: Die dort abgelegten Einstellungen sind an den Rechner gebunden.
• %userprofile%\AppData\LocalLow ist ein Sandbox-Verzeichnis mit niedriger Verbindlichkeitsstufe.

Manuelle Bearbeitungsmöglichkeiten

Registrierungs-Editor

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 ihrem Inhalt 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 seinen 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). 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>

Zeichenketten ("string values") benötigen keine Werttyp-Angabe. Pfade in Wert-Zellen müssen aber mit „\\“ 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 Wertnamen entfernt:

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

wobei @=- den Standardwert entfernt und "MeineMeinung"=- die Zeichenkette 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

→ 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. 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

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

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. 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.
• Ein 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.
• 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.
• Der besonders sensible Abschnitt SYSTEM wurde in früheren Windows-Versionen als Backup in der Datei SYSTEM.ALT gespeichert.

Registry-Cleaner

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. 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.“).

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.

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. 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

Windows 9x

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

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. 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. Aufgrund eines Programmfehlers sichert SCANREG.EXE die USER.DAT nicht, wenn diese nicht im Systemverzeichnis liegt, weil mehrere Benutzerprofile angelegt wurden.

Alle Versionen von Windows 9x bieten zudem die Möglichkeit, mittels des Registrierungseditors REGEDIT.EXE im MS-DOS-Modus die gesamte Registrierung in eine Registrierungsdatei zu exportieren und auch wieder zu importieren. 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.

Windows NT

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. Standardmäßig werden die Dateien SAM und SECURITY nicht gesichert, es sei denn RDISK.EXE wird mit dem Parameter /S aufgerufen.

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

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

Windows-Registrierungsdatenbank ohne Windows

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 Systemen 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:

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.

Alternativen

In den meisten unixoiden Betriebssystemen, wie FreeBSD, macOS oder in den Linux-basierten 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 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.

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.

Weblinks

• Registry Microsoft Developer Network (MSDN) (englisch)
• Günter Born (MVP): Tuning-Tools, die Plage des 21. Jahrhunderts?