@drfuture: Warum die Registry schon technisch Kacke ist:
Sie ist ein eigenes Dateisystem. Sie hat Inodes, Referenzen zu internen Dateien, extended attributes etc pp, aber ohne sie als tatsächliches Dateisystem einzubinden; Das lustige Resultat ist, eine riesige Datei zu haben, die man mit ext3 vergleichen kann(in einem loopback mount), allerdings ohne Zugriffsschutzmechanismen auf TATSÄCHLICHER Dateisystemebene.
Ihr Format ist im Prinzip ein C-Struct-Dump: 32bit, Endian-dependant(LULZ) aus einer Heap-Map, was weitere lustige Aspekte mit sich bringt: Man kann Keys erstellen, die im Register so nicht in der Liste auftauchen, auf die aber zugegriffen werden kann, indem man ihre Namen direkt referenziert. Das wurde später dann übrigens zu einem Pseudofeature. Außerdem erzeugt das weitere Typspezifika, z.B. Wordspecific(Ja, ASSEMBLER-WORDS), und muss für Backward-Compatiblity mit einem Toolset kompiliert werden, dass den Stand 1992 entspricht.
Durch die fehlende tatsächliche Dateisystemeinbindung hat man sich wohl Gedacht, man könnte einfach Konsistenzchecks weglassen; Resultiert nur eben darin, dass man einfach Blocks in die Registry schieben kann, die einfach ignoriert(Read: Überlesen) werden. die Toolsuite ignoriert sogar Blocks, die nicht in korrekter Alphabetischer Form abgespeichert wurden, und ignoriert fehlerhafte Fields. Sie hat dadurch unreachable-blocks, wie ein Dateisystem, fehlerhafte Inodes, wie ein Dateisystem, aber keinen Weg, um das zu "reparieren", weil das einfach nicht implementiert wurde. Außerdem sind Memory-Dumps in Fields nicht unüblich, da man ausversehen die Einträge nicht korrekt ausgenullt hat.
Es ist schlecht im Umwandeln von Encodings, es hat sogar keine spezifische Dokumentation dazu, wie man Sachen zu escapen hat. Im UTF-16 scheint ein normaler Backslash zu reichen, in einem anderen müssen es plötzlich zwei sein.
Wenn man sich
diese PDF ansieht bemerkt man im übrigen auch, wie "durchdacht" und "gut gewartet" sie ist. Es ist nicht unüblich, mehrere überlappende, exakt gleiche, Informationen in Unterschiedlichen "Ordnern" zu entdecken, an absolut zufälligen Orten.
Es ist nicht häufig genug zu sagen: Die Registry ist keine Datenbank. Sie wäre es vielleicht gerne, aber sie ist, defacto, ein Dateisystem. Der Unterschied hier ist darin begründet, dass sie kaum Datenbanktypische Funktionen enthält, dazu aber relevante für Dateisysteme. z.B. gibt es keine indices, die absolut hilfreich sein könnten, damit man nicht wie aktuell
die Registry von oben nach unten nach etwas durchsuchen müsste, wenn man etwas sucht.
Security: Habe ich oben bereits mehrfach angesprochen, aber auch das ist sehr wichtig: Es gibt ein Crapload an Software, die das Format lesen und manipulieren können. Darunter z.B. die
Hivexsh. Man kann damit soviel "schönen" "Spaß" haben... Man sieht plötzlich ganz viele Random-Entrys, an vollkommen zufälligen Orten, mit absolut wirrem Inhalt, häufig, wie gesagt, Memory-Dumps.
Was sie allerdings besser gemacht haben seit XP, ist endlich ein Userverzeichnis für Konfiguration ala AppData/LocalLow zu haben. Nur leider will selbst Windows 10 noch immer nicht wirklich das benutzen, stattdessen bleiben wir lieber bei der Möchtegern-DB-Die-Aber-in-Fakt-Ein-Dateisystem-Ohne-Dateisystem-Checks-ist.
(Großteil der Dinge hier aus
https://www.reddit.com/r/programming/comments/b3mr2/why_the_windows_registry_sucks_technically/ genommen, hatte ich vor ein paar Monaten schon mal so ähnlich für einen anderen Registry-Jünger geschrieben)
---
keines dieser Probleme hat Linux/Unix in dem Falle. Das einzige, was hier inkonsistenzen hervorrufen können, sind die jeweiligen Dateiformate.