Diskussion:Registrierungsdatenbank/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Registrierungsdatenbank/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Registrierungsdatenbank/Archiv/1#Thema_1

Welche Programme sind empfehlenswert zum reinigen der Registry?

welche programme sind empfehlenswert zum reinigen der registry? -- Qopep 07:57, 7. Okt 2006 (CEST)

Keine! Die Intelligenz derartiger Programme ist begrenzt. Besser ist es, das Betriebssystem und alle Anwendungssoftware nochmal neu zu installieren. Das sollte man sowieso alle 2 Jahre einmal machen. Das ist sicherer. Meine Meinung. --subsonic68 19:20, 5. Jan 2005 (CET)

TuneUp Utilities hat dafür ein echt praktisches Unterprogramm es entmißtet und defragmentiert die Registry
(Dieser Beitrag stammt von 84.132.123.117 19:20, 2. September 2005 (CEST))

Solche Tools oder das manuelle Reinigen ist wichtig. Ich möchte mal den Betrieb sehen der alle 2 Jahre seine Windows Server neu installiert ;-)).

Gruß --SebastianL 6. Jul 2005 10:08 (CEST)

Gar keine Reinigung, wozu reinigen? Die Registry ist indexiert, veraltete Keys verlangsamen daher nicht wirklich den Betrieb, auch wenn das Gerücht immer wieder hartnäckig rumgeht. Was das System langsam auf Dauer macht, sind die häufende Anzahl von Tools und Programmen, die man sich installiert, wovon viele irgendwelche Dinge gleich beim Hochfahren und Einloggen sich starten, z.B. um nach einem Update zu schauen. Lofote 14:04, 26. Jun 2006 (CEST)

Nur komisch, das mein neu installiertes Windows Home viel langsamer ist, als mein vorheriges Windows Professional, obwohl ich gerade mal zwei Autostartprogramme habe... Mit Windows Pro hatte ich glaube ich 5 oder 6 Stück, trotzdem war es bedeutend schneller...weiß da jemand, warum? MfG Oblivion1987 08:13, 17. Okt. 2007 (CEST)

„Vorteil der Registry“

Der Satz

Problematisch bei den separaten Konfigurationsdateien ist die Verwaltung unterschiedlicher Benutzer – da meist nur eine Konfigurationsdatei existiert, müssen sich mehrere Benutzer eine einzige Konfiguration „teilen“.

stimmt doch so höchstens aus der Windows-9x-Perspektive. Das „Konfigurationsproblem“ ist auf anderen Betriebssystemen, die von Anfang an Multiuser-fähig waren nicht existent, da jeder Benutzer seine eigene Konfiguration hat. Unter Windows kommt das Problem daher, dass viele Softwarehersteller immer noch davon ausgehen, dass nur eine Person mit Administratorrechten am Computer arbeitet. --Robb der Physiker 20:52, 11. Feb 2006 (CET)

Das ist richtig, aber halt wirklich nur, wenn der Programmierer dann wirklich im Benutzerprofilverzeichnis schreibt. Wobei ich mich dann frage, warum man nicht gleich die Registry verwendet, anstatts weiter mit ner INI zu "pfuschen" :)... Lofote 14:02, 26. Jun 2006 (CEST)

Dann frage ich mich (als Programmierer!), was daran so schwierig sein soll, in entsprechenden Bentzerverzeichnis seine Konfigurationsdateien abzulegen? Unter Unix beispielsweise funktioniert dies von Anfang an. Und obwohl Microsoft in (fast) jeder Windows-Version den Pfad zu den „Home-Verzeichnissen“ ändert, heißen die entsprechenden Registry-Einträge, die darauf zeigen bzw. die passenden Win32-API-Aufrufe immer noch gleich. Der Vorteil von Konfigurationsdateien ist, dass es ganz normale Textdateien sind, die jeder ganz einfach bearbeiten kann, ohne mit einem auf den ersten Blick unhandlichen Programm arbeiten zu müssen. Außerdem gibt es in der Registry AFAIK keine Möglichkeit, Einträge kommentierend zu beschreibend. --Robb der Physiker 12:43, 1. Jul 2006 (CEST)

DIe Kommentierung ist tatsächlich der einzige mir valide bekannte Grund, gegen die Registry, für eine Speicherung im Anwendungsdaten-verzeichnis des Users. Nachteile: a) viiiiel langsamer im Zugriff, b) schwer zu automatisieren in Firmen (vor allem wenn man nur einzelne Punkte vorschreiben will), c) für den Endanwender, wenn er mal von Hand rein muss, ein absolutes Unding, zu erklären, wo die Datei nun liegt (abhängig von OS-Sprache, Migrationspfad, Windows-Version, Installationslaufwerk/pfad, ...), während die vorgehensweise in REGEDIT (auch wenn er unübersichlich aussieht) immer gleich (lies: identisch) zu beschreiben ist: und das seit Win95/NT4 - das sind verdammt viele Windows-Versionen ;)... und es gibt nichts besseres für den unbedarften Endanwender, wenn er eine EXAKTE Liste an Ausführungen von oben nach unten "stumpf" durchgehen kann, ohne irgendeine "wenn dann"-Frage beantworten zu müssen. d) Vor allem INI-Dateien werden sehr unübersichtlich: Man muss immer im überblick haben, in welchem Bereich man nun ist (also das, was mit [] angegeben wird). Die Suche, ob ein Key schon drin ist, der evtl. auch in anderen Bereichen existieren kann, wird damit zur Tortur. ... AUch das ist unnötig...

Wenn ich mir anschaue, wie schwer sich anscheinend manche Zeitgenossen, die ihre Beiträge nicht unterschreiben mit Konfigurationsdateien, die plattformunabhängig sind, tun, bin ich froh, mit Windows praktisch nichts zu tun zu haben. Es wundert mich jetzt allerdings schon, dass Unix&Co einfach so funktionieren, ohne Registry. --Robb der Physiker 13:28, 2. Jul 2006 (CEST)

Nur weil es neu für dich ist, oder "nicht das für dich gewohnte", redest du es schlecht. Zu Unix+Co: Es geht nicht um Funktionieren oder nicht. Die Registry ist nur ein Mittel, Einstellungs-Informationen zu speichern. Alles was da drinsteht, könnte problemlos auch in zigtausend INI, CONF oder XML-Dateien gespeichert werden. Technisch ist das überhaupt kein Problem und nur Definitions/Implementierungssache. Aber: Es ist dann wesentlich langsamer. Unix&Co. laden wesentlich weniger variable Einstellungen rein, und das ganze System ist anders aufgebaut. Anders heisst "anders", nicht "besser", nicht "schlechter". Zudem hat Unix einen grossen Vorteil: Die Verzeichnisse sind durch die Mountingtechnologie immer gleich (z.B. /usr/home oder so ähnlich (sorry, weiss es nicht auswändig, man verzeihe mir :) )), damit ganz skriptfähig. Bei Windows ist das nicht so, hier gibt es viele Dinge zu beachten, die den Pfad einer Datei ausmacht. Die Registry hingegen ist fix. Unix hat übrigens auch wesentlich mehr Tools zum automatisierten Editieren von Textdateien und wesentlich bessere Skriptfähigkeiten "on board". Trotzdem ist auch unter Unix das Austauschen von z.B. 500 Einstellungen bei jedem Login deutlich langsamer als wenn es in eine Datenbank wie MySQL oder eben die Registry gespeichert werden würde (kann man informatisch beweisen :) ). Ich tue mich übrigens mit den Textdateien nicht schwer, sie sind nur lästig, weil unter Windows(!) schwerer und in allen Fällen langsamer automatisierbar. Du tust dich mit der Registry offensichtlich viel schwerer, womöglich weil du dich nie mit ihr auseinandergesetzt hast und offensichtlich auch nicht willst (hast ja anscheinend auch wenig mit Windows zu tun, daher frage ich mich, warum dich das Thema dann überhaupt so interessiert ;) ). Zuletzt noch: Sorry, wenn ich als Mensch es manchmal(!) (<- also eine falsche Verallgemeinerung von dir) vergesse, meine Kommentare zu unterschreiben. Im Gegensatz zur Registry kann ich mich noch nicht automatisieren ;)... Lofote 16:38, 2. Jul 2006 (CEST)

Ich rede schlecht über die auch unten genannten Absätze, korrekt, weil deren Inhalt IMHO einen POV enthält, was in der Wikipedia nichts zu suchen hat. Beispiel gefällig?

Bevor sich das Konzept der Registry durchgesetzt hatte, wurden Parameter in separaten Dateien für jedes einzelne Programm […] gespeichert. Hobbyprogrammierern verwenden diese Weise leider bis heute meist aus Nichtwissen und Gewohnheit […]

Was hat leider dort zu suchen, das ist eine Wertung? Außerdem ist das, was ich bemängelt habe nicht besser, sondern schlechter geworden:

"Leider", weil es zwei Welten vermischt. Weil es sich nicht an den Standard des Betriebssystems hält. Und dadurch die Vorteile (Performance, Sprach/Installationspfadunabhängigkeit, ...) nicht nutzen kann. Lofote 02:48, 3. Jul 2006 (CEST)

Das ist trotzdem POV, hier gilt aber Wikipedia:NPOV, also, was spräche gegen

Bevor sich das Konzept der Registry durchgesetzt hatte, wurden Parameter in separaten Dateien für jedes einzelne Programm […] gespeichert. Obwohl in [Guideline bitte einfügen] der Verzicht auf Konfigurationsdateien zu Gunsten der Registry vorgesehen ist, werden diese immer noch von Hobbyprogrammierern oder aus Gründen der Plattformunabhängigkeit benutzt.

Zur Pfad-Unabhängigkeit kurz: Das Problem lässt sich mit Hilfe der Registry beheben (s.u.). Warum versuchst du krampfhaft aus wertenden Aussagen angebliche Vorteile der Registry im Artikel zu halten? Eine neutrale Fassung kommt allgemein viel besser an, auch wenn dann dort nur noch die Hälfte des Textes, aber die ganze Wahrheit drin steckt. So sieht es bislang nach typischem Marketing-Müll aus. --Robb der Physiker 17:03, 3. Jul 2006 (CEST)

Was bringt mir denn das Auslesen des Anwendungsdaten-Pfades für den Endanwender? Für den ist das einfach absolut unnötig komplex, herauszufinden, wo denn nun "sein" Anwendungsdaten-pfad ist. Das ist doch das Problem, bzw. einer der Vorteile - das BESCHREIBEN des Vorgangs einer Einstellungsauslesung oder -änderung durch den Enduser (z.B. bei einer Supportanfrage) ist EINDEUTIG bei der Registry ohne Wenn-Fälle, bei Anwendungsdaten ist es extrem komplex (soll ich dir mal ein paar Fälle aufzählen? :) )! Lofote 18:48, 3. Jul 2006 (CEST)

Ich will den Endanwender sehen, der in der Registry schaut oder Win32-API-Calls absetzt, um herauszubekommen, wo seine Konfigurationsdateien liegen. Es geht hier um (Hobby-)Programmierer, jedenfalls steht dieses Wort in der bemängelten Textstelle! --Robb der Physiker 20:24, 3. Jul 2006 (CEST)

Zum Thema "Leider": Der Abschnitt "Vorteile" beschreibt doch warum es "Leider" ist, und warum der Programmierer mit so einer Entscheidung so viele andere mit beeinflusst (Endanwender, vor allem aber auch Administratoren). Der Programmierer ist sich nicht bewusst, was so eine eigenwillige Endscheidung *gegen* den Standard eines OS mit sich führt - weil er die Vorteile i.d.R. auch gar nicht kennt oder sich klar macht, oder halt einfach den einen Stil von früher kennt und sich erst mal gegen Neuerungen stellt - erstens, weil man das alte ja kennt und es auch funktioniert, zweitens, weil man soviel schlechtes über die Registry gehört hat (was zu 95% Unwahrheiten sind). Und das ist, was ich damit ausdrücken will. Mach bitte einen Vorschlag, wie man das besser rüberbringt, ohne dass das POV enthält, ok :)? Lofote 18:48, 3. Jul 2006 (CEST)

Ein Textvorschlag steht nur wenige Zeilen über deiner Antwort. Und ja, es gibt auch Gründe, neben „Konservativismus“, gegen Richtlinien eines Betriebssystems zu verstoßen. --Robb der Physiker 20:24, 3. Jul 2006 (CEST)

Problematisch bei den separaten Konfigurationsdateien ist auch die Verwaltung unterschiedlicher Benutzer – da meist nur eine Konfigurationsdatei existiert, müssen sich mehrere Benutzer eine einzige Konfiguration „teilen“. Aber auch ansonsten ist dieser Ansatz veraltet, u.a. da Standardbenutzer im Programmverzeichnis zu Recht nicht speichern dürfen.

Unix und andere Systeme gehen dem aus dem Weg, indem es zwei Konfigurationen gibt, eine fürs Programm (unter Unix meist unter /etc/… und eine für den Benutzer unter ~/.…. Dieses Konzept lässt sich auch unter Windows benutzen, die richtigen Pfade zu den Dateien findet man mit Hilfe der Registry oder Win32-API-Calls heraus. Folglich stimmt die zitierte Aussage im Artikel einfach nicht. --Robb der Physiker 00:06, 3. Jul 2006 (CEST)

Nichts anderes als eine Trennung in User und Computer macht Windows doch!? HKCU und HKLM. Sowie -für binäre Daten- die Anwendungsdaten. Lofote 02:48, 3. Jul 2006 (CEST)

Was ich damit sagen wollte: Das Zitat, das vor deiner Antwort steht, beschreibt ein Problem, welches mit den richtigen Registry-Zugriffen bzw. Win32-API-Calls beheben lässt. Ich vermute, dass das Problem „Eine config, mehrere Benutzer“ noch aus der Win9x-Single-User-Ära stammt und manche Firmen den Umstieg auf XP-Multi-User verpennt haben. Das Problem ist allerdings ein Programmier(er)-Problem und kann deshalb nicht als Registry-Vorteil ausgelegt werden. --Robb der Physiker 17:03, 3. Jul 2006 (CEST)

Durch XP als einzige Windows-Linie ists ja nun schon deutlich besser geworden, weil früher man es einfach -mangels fehlendem NT-System- nicht besser kannte ;)... Lofote 18:48, 3. Jul 2006 (CEST)

Ich habe eben die Punkte - Wenn eine Software die Registry sauber einsetzt, funktionieren alle Features von Windows sauber, wie z. B. die servergespeicherten Profile - und - Die Funktionsweise ist auch für Nicht-Fachleute einfach zu erklären ... Diesen Vorteil hat keine andere Methode - geloescht. Die Begruendung faellt mir schwer, da es einfach hanebuechener Unsinn ist (wie die Behauptung, dass der schnellste Sprinter der Welt eine Schildkroete nicht ueberholen kann, wenn diese einen Meter Vorsprung hat; bei geeigneter Argumentation eine leicht aufzubauende These, aber dann nur durch Mathematik widerlegbar). Ich versuch es trotzdem mal. Das bei sauberen Einsatz saubere Resultate erzielt werden, ist Minimalanforderung und im Vergleich zu anderen Vorgehenweisen kein Vorteil, da dies andere Vorgehensweisen auch leisten (wenn nicht, werden diese nicht fuer soetwas eingesetzt). Zum anderen Punkt: Eine ini-Datei habe ich schon oefters Nicht-Fachleute erfolgreich erklaert. An der Registry macht der Nicht-Fachmann nur etwas per penibler Anleitung aus dem Netz oder einem Druckwerk.

Stimmt das hier so?
'regedit /s' - zum importieren?
Meines Wissens ist der Schalter '/s' für das stille Importieren 'silent' gedacht. Der 'normale Import geht einfach mit 'regedit <REG-Dateiname>'
siehe [Microsoft Hilfe und Support]
-- Sotel 17:22, 23. Jul. 2009 (CEST)

Zusammenfassung und Überarbeitung (vom 25. Juni 2006)

Hallo,
habe gerade die beiden Artikel Registry und Registrierungsdatenbank hier zusammengefaßt und nach bestem Wissen und Gewissen überarbeitet. ..und ich hoffe, daß dabei nix an Informationen verloren gegangen ist. :-)
Kleiner Tipp an die Neulinge: Bitte vor der Erstellung eines (neuen) Artikels immer erst püfen, ob es nicht schon einen entsprechenden Artikel gibt (welcher dann ggf. erweitert werden kann), um z.B. solche (umfangreichen) Nacharbeiten (wie diese hier) künftig zu vermeiden.
Gruß .. Conrad 20:58, 25. Jun 2006 (CEST)

Weiterentwicklung

"Microsoft hat angekündigt, bei zukünftigen Versionen ihrer Betriebssysteme vom Konzept der Registry abzugehen und ein neues Konzept zu entwickeln."

Dieser Absatz sollte entweder mit einem Link oder einer Quellenangabe versehen werden, oder rausfliegen. Lofote 14:05, 26. Jun 2006 (CEST)

Da niemand eine Quelle gepostet hat, hab ich es jetzt mit einem Hinweis ausgeblendet. Bitte nur wieder reintun, wenn Quellenangabe vorhanden. Lofote 14:39, 1. Jul 2006 (CEST)

Sicherheit: Aussperren von regedit

Das unter Sicherheit beschriebene Vorgehen, um den Registry Editor auszusperren, wendet beispielsweise Worm.Brontok.AA an, den ich selbst für kurze Zeit auf meiner DOSe hatte. Siehe auch Wurm-Beschreibung von Trendmicro. --Robb der Physiker 12:38, 1. Jul 2006 (CEST)

Bitte grundlegend überarbeiten

Die Inhalte der Abschnitte Von .ini zur Registry und Vorteile gegenüber INI und XML-Dateien sind aus dem Blickpunkt der Informatik überzogen, falsch und einseitig. Jemand mit detaillierten Windows- und Informatik-Kenntnissen möge sich bitte dieser beiden Abschnitte annehmen, mir fehlt ersteres (glücklicherweise ;-) ). --Robb der Physiker 13:31, 2. Jul 2006 (CEST)

Jeder Informatiker wird dir bestätigen, dass eine indexierte Datenbank, die zudem Datentypen direkt speichert (also ohne Umwandlung einer Zahl z.B: in String und beim Rückeinlesen wieder umgekehrt), wesentlich performanter ist als das Parsen einer textdatei. :) Ansonsten sind hier nicht Informatiker sondern eher Administratoren gefragt, denn die arbeiten tagtäglich mit der Registry. :) Lofote 15:39, 2. Jul 2006 (CEST)

Ich habe gerade die Vor- und Nachteile, sowie von der *.Ini zur Registry überarbeitet, da dort doch einiges unwissen auf dem goldenen teller präsentiert wurde. Ich kenne mehr als genug leute (mir inklusive), die die registry nicht meiden, weil sie sie nicht verstehen, sondern weil sie der überzeugung sind, dass sie für normale software-entwicklungen nicht nötig ist. es ist nicht umsonst eine art güte-siegel, wenn ein programm NICHTS in die registry schreibt. aus ebendiesem grund verzichten viele entwickler auch auf standard-installer, um den unnötigen registry-overkill zu vermeiden. 09:46, 02. Feb. 2007 (CET)

Bearbeitungsmöglichkeiten

1.Ich denke man sollte den Unterschied zwischen regedt32 und regedit bei Windows NT (< 5.1) beschreiben.

Agreed. Lofote 16:06, 2. Jul 2006 (CEST)

2.Zitat: Man kann dann nur unter erheblichem Aufwand versuchen, entweder die zuletzt als funktionierend bekannte Konfiguration verwenden oder eine eventuell vorhandene Sicherung wiederherstellen.

Der Teil "mit erheblichem Aufwand" ist denke ich ziemlich übertrieben. Der "Aufwand" beträgt 1xF8+Cursor-Auswahl+Return beim Booten. Der "ziemliche Aufwans" mag dann vielleicht auf die zweite Möglichkeit zutreffen.

--Angus Richard Finnson 13:55, 2. Jul 2006 (CEST)

"Es ist auch möglich bereits existenter Registrierungs-Benutzerprofile nachträglich anzupassen. Dies ist jedoch ein recht aufwendiges Unterfangen, da die Unterordner unter „HKEY_USERS“ passend bearbeitet werden müssten." Dafür kann man Login-Skripte, die "regedit /s [präparierte .reg-datei mit den erwünschten Anpassungen].reg" verwenden, bei Administratoren ein Standardvorgehen :). Daher empfehle ich, die Info noch mit reinzubringen. Andere Meinungen? Lofote 16:06, 2. Jul 2006 (CEST)

Nachteile der Registry?

Evtl. sollte man einen solchen Bereich dazuschreiben? Denn im Prinzip können alle alle "Vorteile" auch als Nachteil ausgelegt werden. Und da käme dann noch dazu:

Habe nun einen reingebracht. Aber: Wie willst du denn Dinge wie "Performanter" und auch die meisten andere als Nachteil auslegen? Lofote 16:28, 2. Jul 2006 (CEST)

Export-Schwierigkeiten: Wenn man das Betriebssystem neu installiert, sind alle Einstellungen der verschiedenen Software auch dahin. Es sei denn man exportiert mühsam die entsprechenden Zweige(nein, HKLM\Software reicht nicht). Ini-Dateien kann man einfach kopieren und wieder neueinsetzen.

HKCU\Software, nicht HKLM\Software. Und ja, das reicht für alle benutzerdefinierten Einstellungen. Zumindest bei Programmen, die die Registry verwenden. Mühsam? Warum ist das mühsam? Ist sogar leicht skriptbar (regedit /e). Und in Firmen mit servergespeicherten Profilen sogar gar nicht notwendig. Lofote 15:36, 2. Jul 2006 (CEST)

Habe nun was reingesetzt, nämlich das das Wissen, wie man sowas macht, leider nicht-triviales Spezialwissen ist, wenn man sich nie damit beschäftigt hat. Ich hoffe das ist ok so :)... Lofote 16:28, 2. Jul 2006 (CEST)

Plattformabängig: Die Registry ist ein typisches Produkt der MS-Sturheit immer anders zu arbeiten. Die Einstellungen mal auf ein GNU/Linux oder einen Mac mitzunehmen ist unmöglich.

Sturheit vs. Fortschritt: Die Registry bietet einen immensen Geschwindigkeitsvorteil. Was für Einstellungen man auf Linux/Mac mitnehmen will, ist mir so jetzt nicht klar. Aber wenn das bei einer Anwendungssoftware (z.B. Browser) unbedingt erwünscht sein sollte, wo ist das Problem als Anwender, ein Export-/Importprogramm zu schreiben? Beachtet bitte eines: Die Anzahl User, die ihre Einstellungen auf mehreren Plattformen verwenden wollen ist minimalst (bestimmt nicht viel grösser als paar Prozent, wenn überhaupt!) gegenüber den Leuten (wird wohl gegen 100% gehen), die ein schnelles Laden ihrer Anwendung wollen (was durch eine indexierte Datenbank einfach wesentlich performanter ist als durch eine Textdatei). Von daher ist letzteres als Spezialwunsch einiger weniger zu sehen, und Spezialwünsche sollte man nicht zu Kosten der Allgemeinheit implementieren.

Denk auch mal an die Programmierer, die wahrscheinlich keine Lust haben, nur für die Windows-Version ihres Programmes alle Datei- durch Registry-Zugriffe zu ersetzen. Plattformunabhängigkeit ist das Stichwort. --Robb der Physiker 00:20, 3. Jul 2006 (CEST)

Ein guter Programmierer lagert das ganze eh in zwei Funktionen aus: LeseEineEinstellung und SchreibeEineEinstellung, die dann für jede einzelne Einstellung aufgerufen wird, sobald sie gebraucht bzw. verändert wird. Und diese Stelle muss dann so oder so plattformabhängig sein, da die Pfadbestimmung unterschiedlich ist. Dann 4 Zeilen mehr für ne spezielle Windows-Version ist nicht mal im Ansatz ne Diskussion wert, das ist einfach nur Faulheit in meinen Augen, wenn man die Zeit nicht investiert. Ich bin einfach der Meinung, dass man sich immer an den Standard des Betriebssystems halten soll, soweit das geht. Der Standard des OS ist nicht ohne Grund da, die jeweiligen Programmierer haben sich was dabei gedacht. Ich bin der Meinung, dass eine Windows-Kompatibilität auch bedeutet, dass auch wirklich die Technologie von Windows verwendet wird, das Programm soll sich an den User (der den Standard gewohnt ist) anpassen, nicht der User an das Programm. Eine Linux-Version soll auch dessen Config-Dateien und dessen Verzeichnisstruktur verwenden, sonst ist es kein Linuxprogramm, sondern was halbherziges. Das ist mein POV :)... Lofote 02:48, 3. Jul 2006 (CEST)

Hast du schon einmal unter Benutzung der Win32-API Registry-Zugriffe programmiert, also nicht mit so schicken Klassen von Borland oder M$? Soweit ich das in Erinnerung habe, brauchst du für jeden möglichen Datentyp, den du liest, eine eigene Funktion, genau wie beim Lesen aus Textdateien. D.h. doppelter Aufwand und Informatiker sind grundsätzlich faul ;-)

Ja habe ich - in Microsoft MFC gibts z.B. keine Registryklassen ausser ein paar zu spezielle. Aber da man eh es auf zwei Datentypen i.d.R. beschränkt (integer und strings) sinds dann nur 4 für lesen und schreiben ;))... Gut, ist natürlich ein Aufwand, wenn man net von Anfang an das Programm darauf ausrichtet, zwischen Aufrufen von Integer und Strings-Einstellungen beim Funktionsaufruf zu unterscheiden. Wäre aber auch bei textbasierten sinnvoll weil sauberer, um bei den Integer-basierten eine Fehlerbehandlung einzuführen, falls halt da jemand mal in die Textdatei an der Stelle nen String eingibt ;)... Also mein Informatikprofessor hätte mich gelyncht, wenn ich das nicht sauber getrennt hätte im Studium ;))... Noch was: Ihr müsst ja für das Bestimmen des Anwendungspfades auch Registrycalls machen (es geht auch mit Auslesen der Umgebungsvariable APPDATA, leider aber nicht unter allen Win32-Systemen, daher scheidet das auch schon wieder so gut wie aus). Ihr habt also in dem Fall wo ihr es sauber nach Usern trennen wollt auf jeden Fall so nen Code drin ;)... Lofote 18:54, 3. Jul 2006 (CEST)

Na, ich kann auch indirekt die Registry abfragen: GetSpecialFolder() oder so ähnlich, wobei %APPDATA% natürlich näher am Unix-Weg á la $HOME ist. --Robb der Physiker 20:59, 3. Jul 2006 (CEST)

ShGetSpecialFolder (der Name der Funktion) ist leider nicht Bestandteil aller Win32-Versionen. Genauer gesagt fehlt Windows 95 und meines Wissens auch Windows NT 4.0, es sei denn man installiert zumindest IE 4.0 auf diesen Systemen. Damit ergibt sich das gleiche Problem wie mit %APPDATA%.

Außerdem gilt hier in der Wikipedia NPOV, also neutraler Standpunkt! --Robb der Physiker 16:49, 3. Jul 2006 (CEST)

Bei der Aufzählung von Vor- und Nachteilen ist das gar nicht so leicht, neutral zu klingen. Wie gesagt, mach nen Vorschlag :). Übrigens: "M$" klingt auch net gerade neutral ;)... Lofote 18:54, 3. Jul 2006 (CEST)

Vorteile gegenüber INI und XML-Dateien:

• Einleitender Satz kann weg.
• wesentlich reicht betont, braucht nicht stark betont zu sein.

Woops, das war unbeabsichtigt, hatte die Hochkomma-Syntax durcheinandergewürfelt. Lofote 21:22, 3. Jul 2006 (CEST)

• »Klare Trennung zwischen Computer- und Benutzereinstellungen, durch Default-Sicherheitseinstellungen auch korrekt implementiert.« ist irreführend formuliert, da der Anwender mit regedit erst einmal keinen Unterschied zwischen Computer- und Software-Einstellungen feststellen kann. Lässt sich außerdem auch mit Textdateien lösen.

• CURRENT_USER und LOCAL_MACHINE ist für dich keine namentliche Trennung? Lofote 21:22, 3. Jul 2006 (CEST)

• Der Absatz danach ist für mich als Windows-Laien (denk an den Wikipedia:Oma-Test) unklar, klingt aber trivial, d.h. nicht nenneswert.

Nachteile:

• Der letzte Punkt kann weg, seit wann ist Informationspolitik bzw. Marketing ein Nachteil eines Features?

Das hast du falsch verstanden, ist doch aber klar geschrieben!? Informationspolitik/Marketing ist NICHT ein Nachteil, sondern die URSACHE des genannten Nachteils. Gut auch der ganze Punkt ist nicht wirklich ein Nachteil, aber ein Grund, warum die Registry einen schlechten Ruf hat. Frage mich, wie man das anders machen kann... hmm... ich denk mir was aus. Lofote 21:22, 3. Jul 2006 (CEST)

M$ ist nicht neutral, deshalb schreibe ich so etwas nie in einem Artikel, außer es geht um so Sachen wie Firmenpolitik nach außen ankommt. Dann könnte es tatsächlich heißen: „… wird von Kritikern auch M$ genannt, um auf Geschäftsgebahren anzuspielen …“. Alle Klarheiten beseitigt? --Robb der Physiker 20:59, 3. Jul 2006 (CEST)

Computerunbedarfte...: Haben in der Registry nichts verloren. Für sie gibt es die schönen grafischen Oberflächen, die zwar nur die Hälfte können, aber das muss ihnen halt reichen. Man kann nicht alles tun was man nicht kann.

Bin ich absolut anderer Meinung - zumindest im Vergleich zu herkömlichen Methoden und natürlich nur, wenn es keine andere Möglichkeit gibt (weil es keine GUI für die Einstellung gibt o.ä.). Zum Thema Gefährlichkeit: In der Registry kann man *wesentlich* weniger anstellen als z.B. im Windows Explorer. Der einzige Vorteil für Computerunbedarfte ist dass der Explorer mittlerweile die Standardfolder mit nem Hinweis "warnt", das ist alles.

Ansonsten ist eine Regisry-Änderungs-Beschreibung von einem Supportteam an Computerunbedarfte _wesentlich_ einfacher, denn es gibt keine Wenn-Fälle.

"Für Administratoren können Teilinformationen leicht 'ausgerollt' werden": Ein geschickter Administrator, der in der .ini-Datei das gleiche tut wie in der Registry, nämlich vorsichtig sein, der überschreibt auch so nichts explizit angegebenes. Er überschreibt nämlich sowieso alles selbst, und lässt nicht regedit.exe ran. Und eine Sektion aus einer .ini-Datei rauszukopieren sollte nicht zuviel verlangt sein oder?

Du hast "ausgerollt" nicht ganz verstanden. Es geht um Software- und Einstellungsverteilung im Netzwerk (also "Rollout"). Da tut kein geschickter Administrator von Hand irgendwas mehr machen. Automatisierung ist das Stichwort! Mach das mal mit INI-Dateien... Und vor allem ohne den Loginvorgang durch langsame Loginskripte (die werden bei solchen Aktionen mit textbasierten Files langsam) in die Länge zu ziehen. Schon mal 500 Einstellungen bei jedem Login angewandt? Bei der Registry passiert das in millisekunden, bei INI-Dateien kann das locker 5-10 Sekunden brauchen, je nach Computerspeed und Grösse der vorhandenen INI-Dateien.

"Klare Trennung zwischen Computer- und Benutzereinstellungen": Wozu gibt es dann das schöne Verzeichnis %userprofile%\Anwendungsdaten? Wäre vielleicht gut von MS sich für EINEN Weg zu entscheiden. Denn so wird beides vollgemüllt. --Angus Richard Finnson 13:55, 2. Jul 2006 (CEST)

Anwendungsdaten ist für die Speicherung binärer Daten, die Einsatzzwecke sind also klar definierbar (leider lesen die wenigsten Programmierer die Guidelines von Microsoft). Also z.B. steht in der Registry der Verweis, wo das Hintergrundbild liegt, als String. Das Bild selber ist als Datei in dem Anwendungsdaten-Pfad drin. Das ist das Standardvorgehen für binäre Daten und Datenbanken: In Datenbanken haben einfach binäre Daten nix zu suchen. Microsoft hält sich also an den Datenbankgrundsatz :)...

Andere Einstellungen (also string- und integer-basierte) haben meiner Meinung nach (und auch Microsoft's Meinung nach, for what it's worth) in den Anwendungsdaten nichts zu suchen. Viel zu lahm, etc. etc.

Registry Firewall

Kennt jemand ein programm das ähnlich wie bei einer firewall schreibende zugriffe stoppt und den user fragt ob er dem programm tatsächlich erlauben will das dies den eintrag anlegen darf ? Sollte das zu unmöglich klingen .. dann eben so, das es einem angezeigt wird, welche änderungen zb seit dem letzten start in der registry vorgenommen wurden .. eventuell mit dem namen der exe die die änderung vorgenommen hat ... es muss eine art von überwachung der registry geben .. hat jemand erfahrung mit solcher art von registry verwaltungs tools ?--Xenolux 15:06, 17.Januar.2007

Als Programmierer würde ich dir jetzt sagen, dass du, wenn du nichts findest, sowas ebend selbst schreiben musst. Da ich davon aber nicht ausgehen kann, lasse ich es lieber. 17:02 2.Februar.2007

Ja, als Coder liegt die lösung nahe, dennoch ergeben sich für mich dann noch folgeprobleme .. woher die info das der zugriff schreibend oder lesend ist, und von welcher exe aus ? .. Habe übrigens im Artikel nun das Tool Regmon gefunden, was aber den User nur sehr wenig schützt, es zeigt nur an was gelesen und geschrieben wird, und von welcher exe aus. Einen wirklichen schutz bietet es eher nicht, und bei längerem Betrieb stirbt es an der fülle der Informationen leicht ab (die Funktion einer brauchbaren Firewall ist derzeit daher nicht damit herstellbar) .. weis jemand aus welcher (dll vermutlich) Datei sich das tool seine informationen holt ? Werds decompilieren und ergebnisse (CALLs in DLLs zur Funktionsherstellung) posten wenn ich welche finde. Xenolux 20:08, 2. Feb. 2007 (CET)

Win Defender verteidigt angeblich kritische teile der Reg., aber kann man diese Teile auch definieren, ausserdem ist das ganze eher als spyware schutz von Microsoft (paradox) gedacht. Xenolux 02:38, 3. Feb. 2007 (CET)

Ich glaube langsam das einzig mögliche ist eine Sicherheitskopie von der Reg., die man im Falle einer kaputten Reg. wieder verwendet, offenbar gibt es gegen die vermüllung keinen Schutz, da es den Benutzern meist eh nicht auffällt das die Reg. zugemüllt wurde, und es daher für die meisten keinen Grund gibt ein Aug auf die vorgänge in der Reg. zu haben *seufz Xenolux 02:48, 3. Feb. 2007 (CET)

Kaspersky Internet Security hat seit Version 6 eine Registrierungskontrolle an Board, die zumindest kritische Bereiche überwacht. Das ist ein Teilbereich vom Modul "Proaktiver Schutz" Schützt zwar nicht vor Vermüllung, aber vor einigen Änderungen

Nachteil: Systemausbremsung und Instabilität

Die Aussage "Dadurch wird das System ingesamt langsamer und instabiler (da die Registry vollständig im Speicher gehalten und Windows im laufenden Betrieb sehr viele Zugriffe auf sie macht)." sollte überprüft werden. Ich habe mal gelesen, dass seit Windows XP die Registrierung nicht mehr (komplett) in den Hauptspeicher geladen wird. Ich glaube, dass stand mal in einem Sonderheft der c't.
(Der vorstehende Beitrag stammt von 62.181.136.200 10:04, 15. Feb. 2007 (CET) und wurde nachträglich signiert)

Hallo,

habe diesen Sachverhalt im Artikel mal eben etwas ergänzt. Dieser deckt sich zwar mit meinen Beobachtungen (z.B. in der Win9x-Serie), jedoch wäre eine genaue Quellenangabe dazu auch nicht schlecht.

MfG .. Conrad 16:50, 3. Jun. 2007 (CEST)

Passendere Übersetzung zu Registry

Lieber Benutzer:Conrad Franz,

Registrierung als Übersetzung von Registry ist sprachlich wie sachlich nicht eben glücklich gewählt. Zum einen verwendet Microsoft Deutschland selber den aussagekräftigeren Begriff Registerdatenbank, zum anderen wäre vom Sinngehalt her die beste deutsche Entsprechung Registratur und nicht Registrierung. Letzeres ist ein Verbalsubstantiv, das eine Handlung beschreibt, vergleichbar dem englischen "Registration". Der Bezug zu einem Objekt, der Windows-Datenbank für Konfigurationswerte, wird daraus nicht leicht deutlich.

Ich möchte vorschlagen, wenn deutsche Terminologie statt englischer verwendet werden soll, wie Microsoft die "Registry" einheitlich Registerdatenbank zu nennen, da diese Übersetzung weit verbreitet ist und damit leicht wiedererkannt wird. Textor 03:06, 4. Jun. 2007 (CEST)

Hallo Textor, :-)

ja da könntest du recht haben, aber der Begriff „Registrierung” (bzw. „Windows-Registrierung”) hat sich nach meinem Verständnis nuneinmal im Deutschen so etabliert (siehe auch die Anzahl der Suchmaschinen-Treffer, z.B. bei Google). Zudem könnte man deine Anmerkung (Zitat: „Zum einen verwendet Microsoft Deutschland selber den aussagekräftigeren Begriff Registerdatenbank, ..”) sicher auch in den Artikel einarbeiten, am besten aber mit entsprechender Quellenangabe.

MfG .. Conrad 11:18, 5. Jun. 2007 (CEST)

Die Windows-Registrierung" ist die Registrierung des Produkts und nicht die Bearbeitung der Registry. So verwechselt man das leicht, weil letzteres nur falsch übersetzt ist. --beisst nur selten 20:10, 7. Jul. 2008 (CEST)

INIFileMapping

Wer hat den diesen Unterpunkt gelöscht und warum? -> Siehe History

Aha!

Aktuell) (Vorherige) 20:31, 3. Jul. 2006 Lofote (Diskussion | Beiträge) (→Von .ini zur Registry - IniFileMapping funktioniert nur mit NT-basierten Systemen. HKLM ist nicht benutzerbezogen.) (rückgängig)

Da ist die Änderung. Lieber Änderungswilliger, Ja und Nein. Das mit NT stimmt (klar!), aber benutzerbezogene mappings (sagen wir mal Verweise dazu) sind möglich (das ist ein feature der Funktion und hat nichts damit zu tun das HKLM (klar!) machinenbezogen ist. Der Punkt ist wichtig, da hiermit - wenn wir schon von INIs sprechen - eine INI-Datei für jeden Benutzer einzeln "emuliert" werden kann, OK? -> Mehr kann man in den unendlichen Tiefen der Microsoft-Dokumentationen nachlesen (auf englisch natürlich).

Einbindung der Registry sollte erläutert werden

Hallo Ihr Wikipedianer,

wo immer ich bisher versucht habe, mich über die Registry schlau zu machen, haben ich vergebens nach einigen grundlegenden Einsichten gesucht, nämlich, wie die Registry in die Vorgänge der PC-Aktivitäten konkret und simpel eingebunden ist. Ich lese immer wieder, das sei eine Datenbank, auf welche das System zugreift oder ähnlich. Ich würde gern einmal lesen, und das gleich am Anfang einer Registry-Darstellung, wie diese Einbindung erfolgt, am besten anhand einiger Beispiele. Also, wenn ich den folgenden Doppelklick ausführe, erfolgt eine Adressierung oder was auch immer in die Registry, dort wird der oder jener Befehl oder Verweis abgeholt usf. und am Ende kommt dann das bekannte Ergebnis heraus. Eine Änderung eines Schlüssels könnte sich in dieser oder jener Weise niederschlagen. Ein Aufbrausen, wer solche Wünsche, wie ich sie gerade vortrage, hat, sollte sich erst mal mit IT als olcher gründlicher befassen, ist da wenig weiterführend. Schließlich ist dem interessierten Laien, der mit Windows arbeitet, das Thema "Registry" doch ohne Ende präsent. Ich verlange auch nicht, nach dem Schema des "terrible simplificateurs" an das Thema heranzugehen. Ein Satz wie der, dass dieses oder jene Beispiel einen bewusst einfachen Ablauf aufgreift, könnte da beruhigen und weiter helfen.

Mein Eindruck ist, dass viele der Autoren, die sich über die Registry auslassen, selbst nicht so genau wissen, wie die Interaktionen laufen. Nach einer meist verquälten Einleitung geht es gern schwuppdiwupp zur Aufzählung der Registry-Einträge und welche Folge deren Änderung hat.

Ich benutze selbst Registry Reinigungs- und Bearbeitungsprogramme und freue mich, wenn ordentlich ausgemistet wird, weiß aber eigentlich nichts über die von mir genannten Grundlagen.

Könnte man meine Gedanken vielleicht in der Wikipedia-Darstellung der Registry berücksichtigen?

Grüße

rheinwer

HKEY_USERS

Habe aus eigener Erfahrung gerade merken müssen, dass der Punkt zu HKEY_USERS falsch war. Es ist leider nicht so, wie der Name vermuten lässt, dass hier alle Benutzerprofile hinterlegt sind, sondern lediglich die, deren Benutzer gerad aktiv am System angemeldet sind, sowie einige systemeigene Profile. rheinwer@t-online.de

Stilllegen von RegEdit

ich hab den abschnitt mal gestrafft, insbesondere den code raus:

1. war er falsch angegeben
2. gefällt mir nicht, wenn nicht (wie es etwa die MSKB selbst es tut) nicht ausdrücklich davor gewarnt wird, in der reg herumzubasteln
3. unvollständig: wenn \Policies\Explorer\NoRun oder anderes gesetzt ist, kann man da basteln soviel man will..
4. und sowieso keine quelle angegeben war

ich denke die WP ist nicht der platz, rezeptchen gegen malware anzubieten - gruß -- W!B: 12:21, 13. Sep. 2007 (CEST)

HKEY_PERFORMANCE_DATA

Dieser HKEY fehlt IMHO im Artikel. Evtl. ist das aber nur eine Abart des "HKEY_DYN_DATA". Weiss ich leider nicht. In jedem Fall ist dieser Hive nicht über Regedit erreichbar, sondern nur über Windows-API (laut engl. Registry-Wikipedia-Artikel). Bitte mal ggfs. jemand mit Ahnung in den Artikel integrieren. Danke. 79.213.149.201 13:15, 8. Nov. 2007 (CET)

Zugriff auf die Registry über Windows API

Im Artikel fehlt ein Hinweis darauf, wie man auf die Registry über die Windos API zugreifen kann. In der englischen Version ist das drin und u.U. sehr hilfreich.

Nachteil: Zentralisierung

Ich will einen weiteren Nachteil vorschlagen: Wenn irgendetwas, sei ein Programm, Treiber, Update oder ServicePack blödsinn mit der Registry baut(sind ja letztlich nur 2 sehr große Dateien), dann ist das ganze System betroffen. Da sogar Microsoft abundzu Software baut die die Reg kaputt machen(bsp. XP Service-Pack 3[1]) ist ja klar das das drittanbietern noch viel öfters passiert. Folglich ist die Zentralisierung der Registry ein Nachteil. Abgeleitet davon ist es denk ich auch ein Problem das die Registrierung stark fragmentiert? (nach einer sehr lang laufenden Windows Installation mit hunderten Installationen/Deinstallationen z.b.) 81.210.161.196 00:49, 25. Mai 2008 (CEST)

Die Registry ist eigentlich nichts Anderes als eine Datenbank, physisch halt in den zwei Dateien organisiert. Das Problem, dass Programme (oder Updates des Betriebssystems) die Datenbank in einem inkonsisten Zustand hinterlassen, hast du prinzipiell auch bei dateibasierten Ansätzen (z.B. die init oder rc-Skripte unter Linux/Unix). Und auch die Fragmentierung hat nichts mit der Registry zu tun, sondern mit fehler-/stümperhaften Deinstallern. --Robb der Physiker 23:23, 25. Mai 2008 (CEST)

"einem inkonsisten Zustand hinterlassen, hast du prinzipiell auch bei dateibasierten Ansätzen" Ja stimmt, natürlich hat man da auch diese Probleme, aber die Programme greifen eben _nur_ auf ihre eigenen Konfigurationsdateien zu können also auch nur diese Dateien kaputtmachen.(Sie wissen ja auch gar nichts von anderen.) Bei der Registry greifen alle Programm auf die selbe Datenbank zu und wenn sie da was falsch machen sind nicht nur die Konfigurationsdaten des Programms futsch, sondern aller installierten Programme und des Betriebsystems. Ich habe es schon sooo oft erlebt das Windows komplett neu aufgesetzt werden musste weil die Registry kaputt war, das es mich eben einfach sehr gewundert hat hier nichts von derartigen Prinzipbedingten Problemen zu lesen. (Ich bin auch und wegen der Registry seit ein paar Jahren komplett zu Linux gewechselt)81.210.161.196 03:42, 1. Jun. 2008 (CEST)

---

Windows Vista Ultimate Registry

• http://msdn.microsoft.com/en-us/library/default.aspx
• Game
• Game UX.GameDetails CLSID Curver {6C5CFCDA-1F1A-4c9e-8D65-94771169D0B9}
• Game UX.GameDetails 1 CLSID
• Game UX.GameExplorer CLSID Curver
• Game UX.GameExplorer1 CLSID
• Game UX.GameFolder CLSID Curver
• Game UX.GameFolder1 CLSID
• Game UX.MS.InstalledGameProv CLSID Curver
• Game UX.MS.InstalledGameProv1 CLSID
• Game UX.Profile NotifyHandler CLSID Curver
• Game UX.Profile NotifyHandler1 CLSID
• Game UX.RichGameMediaPropertyStore CLSID Curver
• Game UX.RichGameMediaPropertyStore1 CLSID
• Game UX.RichGameMediaThumbnailCLSID Curver
• Game UX.RichGameMediaThumbnail1 CLSID

194.66.226.95 14:21, 18. Jun. 2008 (CEST)

HKEY_UNKNOWN

Der HKEY_UNKNOWN taucht immer wieder mal bei VB und in Windows auf ... die Registry zeigt ihn aber nicht. Über dieses "Phantom" fehlt hier imhO noch etwas.

Speicherort auf der Festplatte

Im Artikel steht, die Datei heisse system.dat. Bei mir (XP Pro SP3) heisst sie SAM. Die Datei ist mehr als 10 MB gross und kann mit einem Editor (auch Hex) angeschaut werden. --beisst nur selten 20:10, 7. Jul. 2008 (CEST)

system.dat war bei Windows 9x. Bei Windows NT (XP ist NT 5.1) liegt die Registry, wie im Artikel richtig beschrieben, unter %windir%/System32/config. Dort liegt auch die Datei "SAM". Diese ist allerdings nur ein Teil der Registry und vermutlich nach dem Dienst "Security and Accounts Manager" (SAM) benannt, der sie verwendet. In der Datei liegen unter anderem die Logindaten der Benutzer (also unter anderem Benutzername und verschlüsseltes Kennwort). Falls man sich mal ausgesperrt hat (Kennwort vergessen), kann man diese Datei zum Beispiel unter Linux auslesen oder bearbeiten. Es ist allerdings nicht die komplette Registry in dieser Datei abgelegt. Insofern ist richtig, was im Artikel steht. 217.94.243.230 14:16, 10. Jul. 2008 (CEST)

Danke für die Antwort. Also unter Win 9x war alles in system.dat? --beisst nur selten 23:49, 10. Jul. 2008 (CEST)

"system.dat" war alles, was unter dem Hauptschlüssel HKEY_LOCAL_MACHINE abgelegt war, der Schlüssel HKEY_CURRENT_USER lag in einer gewissen "user.dat" (bei NT-Systemen hingegen wird er aus dem Schlüssel HKEY_USERS bei der Netzwerkanmeldung dynamisch erzeugt, HKEY_USERS gab es unter 9x soweit ich weiß nicht, weil das System nicht multi-user-fähig war). Alle anderen Schlüssel (HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG und HKEY_DYN_DATA) sind eh virtuell und können jederzeit aus den physikalischen Schlüsseln erzeugt werden. Daher müssen sie nicht auf der Platte abgelegt werden. 217.94.235.109 09:11, 11. Jul. 2008 (CEST)

Ausser HKEY_CURRENT_USER befindet ich alles in mehreren files unter C:\WINDOWS\system32\config. Z.B. im File "default" befeindet sich HKEY_USERS\.DEFAULT. Und in C:\Users\%username%\NTUSER.DAT ist HKEY_CURRENT_USER zuhause. --Thomei08 14:57, 1. Dez. 2010 (CET)

Weiterer Nachteil: Unverständlichkeit (Vorschlag)

Die Registerdatenbank ist zu großen Teilen kryptisch - Wohlmeinende sehen in der Verschlüsselung von Fakten in Zahlen einen Vorteil leichterer und schnellerer Bearbeitbarkeit. Ich mag das nicht abstreiten, frage mich aber, wieweit das bei den Leistungsdaten moderner Maschinen eine Rolle spielt.

Bei der Verwaltung eines Systems fällt es _mir_ wesentlich_ leichter, Klartext in einer Textdatei, die ich an wohlbestimmten Orten vermuten kann, zu lesen und ggfs. zu verändern, als das Internet nach dem möglichen Schlüsselnamen für die von mir gesuchte Einstellung zu durchsuchen, die Quelle kritisch auf ihre Brauchbarkeit zu untersuchen und möglichst auch noch weitere Belege für die erhaltene Information beizubringen.

Ohne mich als Glaubenskriegerin gerieren zu wollen, schlage ich die Aufnahme der "Nicht-Klartextigkeit" und der nicht-trivialen Strukturierung der Registrierdatenbank in die Liste der Nachteile vor.

Sigrid --82.139.211.11 20:28, 19. Mär. 2009 (CET)

Die kryptische Natur ist aber keine grundlegende Eigenschaft der Registry, man kann z.B. einen ini-Datei auch kryptisch machen, während man in der Registry "Klartext" verwenden kann, indem man aussagekräftige Schlüssel- und Wertnamen + dort, wo man nicht wirklich einfach nur Zahlenwerte einstellt Zeichenfolgen (REG_SZ) verwendet. Sogar kommentare sind in der Registry möglich, indem man einfach Zeichenfolgen erstellt, die dann vom Programm nicht verarbeitet werden.

Also im Endeffekt hängt es von den Softwareentwicklern ab, ob der Inhalt der Registry kryptisch ist.

Es gibt aber natprlich auch Fälle, wo es sich weder bei .ini-Dateien noch bei Registryeinträgenn vermeiden lässt, dasss der Inhalt kryptisch ist.

Hier einmal ein Beispiel für eine kryptische ini-Datei:

[28E]

A25E=A09 --MrBurns 02:38, 21. Mär. 2009 (CET)

Bitte allgemeiner verfassen

Hallo,
Über dem Artikel steht der Hinweis:
"Dieser Artikel behandelt allgemeine Registrierungsdatenbanken. Für die spezielle Implementierung einer Registrierungsdatenbank im Betriebssystem Microsoft Windows, siehe Windows-Registrierungsdatenbank."
Dieser Artikel, welcher eine allgemeine Beschreibung besitzen soll, bezieht sich in fast jeder Zeile auf die Windows-Registry und dies teilweise sogar sehr detailirt. Es wäre schön, wenn der Artikel allgemeiner verfasst werden würde. --79.241.249.243 20:41, 2. Jun. 2010 (CEST)

Redundanz und möglicherweise Falschschreibung?

Da hier Jemand einen Redundanzbaustein reingesetzt hat, möchte ich als erstes anmerken, dass man hier nichts reinsetzen müsste, was unter Registrierungsdatenbank steht. Lediglich Wine und ReactOS stehen hier weiter unten, ist aber m.E. auch in Ordnung so. Das hieße also: Redirect dort nach hier und die Redundanz ist erledigt.

Bei dieser Gelegenheit fällt mir noch eine mutmaßliche Falschschreibung auf: Registrierungsdatenbank kommt bei Google auf 15.200 Ergebnisse, Registrierdatenbank kommt jedoch auf 92.500 Treffer. "Systemregistrierung" ist mit 7.160 Treffern weit abgeschlagen. "Registrier-Datenbank" und "Registrierungs-Datenbank" kommen zwar zwecks Einzelwortzählung auf mehr, werden aber mit der Meldung "Meinten Sie: registrierdatenbank" quittiert, zählt also nicht. Da die Windowshilfe hier nicht weiterhilft (unter XP ist hier einfach nur von "Registrierung" die Rede), würde ich hier gern den Namen "Registrierdatenbank" unterstützen. Falls ich bei der Herleitung richtig liege, bezieht sich "Registrierungs-" auf ein Verb (registrieren, z.B. Registrierungsgröße = die Größe, die beim registrieren entsteht), "Registrier-" dagegen auf das Substantiv "Datenbank". Ist das richtig? Meinem Sprachempfinden nach wäre es das. --Qhx 22:33, 7. Sep. 2010 (CEST)

Leider änderst sich die deutsch. Übersetzung von MS bei solchen Begriffen manchmal bei jeder Win-Version. Deshalb denke ich, dass das einzige was konstant ist das englische "Registry" ist. Auf die Übersetzungen von MS würde ich micht liebe nicht verlassen. Die sind variabel. Redirects sind wohl die einzige sinvolle Lösung. -- Thomei08 09:06, 8. Sep. 2010 (CEST)

Ich habe den Redundanzbaustein eingesetzt und habe die Diskussion hier in diesem Zusammenhang erst nach dem Verschieben von Windows-Registrierungsdatenbank nach Registrierungsdatenbank bemerkt. Die Redundanzdiskussion wurde hier geführt. -- Simon04 17:20, 14. Sep. 2010 (CEST)

Ich glaube ich bin falsch verstanden worden. Mein Hinweis auf MS bezog sich darauf, dass die offizielle Schreibweise ja genau nicht weiterhilft, ich hätte aber den Begriff Registrierdatenbank (also ohne Namensbestandteil „-ungs-“) vorgezogen, weil ich der Meinung bin, dass das Andere nicht korrekt ist. Ich kanns allerdings nicht beweisen, nur klingt Registrierungsdatenbank irgendwie falsch -- m.M.n. jedenfalls. --Qhx 18:31, 14. Sep. 2010 (CEST)

Sorry, kann sein. Ich bezog mich auf deine Bezugnamhen auf XP und Google Ich wollte nur sagen, dass diese wohl nicht weiterhilft, da es in verscheinden Win-Verionen (oder je nach Update-Stand) anders geschrieben werden könnte. Was sprachlich richtig wäre, wage ich selbst nicht zu beurteilen. -- Thomei08 09:41, 15. Sep. 2010 (CEST)

Dritte Meinung: Die deutsche Sprache erlaubt beides, sie hilft hier wenig weiter. Obwohl ich üblicherweise deutsche Begriffe bevorzuge würde ich in diesem Fall das Lemma Windows-Registry vorziehen, da es sich um etwas windows-spezifisches handelt, während Registrierungsdatenbank nach einem allgemeinen Konzept klingt. --Siehe-auch-Löscher 12:14, 15. Sep. 2010 (CEST)

Dritte Meinung: Die Deutsche Sprache ist hier eigentlich nebensächlich. Den Begriff "Registrierungsdatenbank" sehe ich als von Microsoft geschaffenen Begriff, der ihr Produkt beschreibt. Sie können ihr Produkt nennen wie sie wollen, es ist ja ihres. Niemand käme auf die Idee, in dem Artikel sollte vom "Fenster" Betriebssystem geschrieben werden. Auch hier ist das ein Begriff, der so steht: Windows. Microsoft verwendet in allen deutschsprachigen Texten die Bezeichnung "Registrierungsdatenbank" für das, was im englischen "registry" genannt wird (Beispiel: [2]). Möchtest Du jetzt hingehen und denen sagen, sie möchten doch bitte ihr Produkt umbenennen, weil es "falsch klingt"? --P.C. ✉ 13:34, 15. Sep. 2010 (CEST)

Nachtrag: den englischen "Fachbegriff" fände ich allerdings auch besser. --P.C. ✉ 13:35, 15. Sep. 2010 (CEST)

Vorteile teilweise Fachlich falsch bzw. nicht im Kontext

Der folgende Vorteil ist Imho fachlich nicht korrekt:

• Änderungen an Schlüsseln und Werten, die von Programmen ausgeführt werden, können mit Tools wie RegMon „live“ aufgezeichnet werden. Ebenso kann das Auslesen eines Schlüssels mit diesem Tool jederzeit mitverfolgt werden. Das ist zur Diagnose, aber auch zur netzwerkweiten automatischen Vorgabe von Einstellungen, sehr nützlich. Bei INI- und XML-Dateien wäre ein Vergleich von Vorher- und Nachherzustand notwendig (mithin also das vorherige Speichern der Vorversion), um die Änderungen zu identifizieren, da ein entsprechendes Live-Tool wie FileMon nur die Tatsache feststellen kann, dass die Datei verändert wurde.

Es gibt durchaus Tools wie zum Beispiel das Stylus-Studio, die das für XML können. Ein allgemeines Dateivergleichs Tool für eine Spezialaufgabe wie das Vergleichen von INI und XML-Dateien aufzuführen halte ich für schwierig. FileMon findet die Änderungen in den Registriedateien auch nicht.

Der folgende Vorteil ist imho nicht im Kontext, da dies mit XML- und INI-Dateien auch geht:

• Die Registrierungsdatenbank ist leicht mit Skripten zu bearbeiten, auch das Übernehmen von Einstellungen von einem PC zum nächsten ist automatisiert mittels Batchdateien möglich (mittels eines „regedit /e“-Befehls zum Exportieren und einem „regedit /s“-Befehl zum Importieren); eine so migrierte Registry wird auf jedem Windows-Betriebssystem ab Windows 95 und Windows NT 4.0 ohne Beachtung von Installationspfad, Betriebssystemssprache, etc. funktionieren.

-- Highttowers 11:34, 2. Nov. 2010 (CET)

+1; Dass der 2. Punkt graue Theorie ist, weiss jeder der dies schon versucht hatte. Es gibt sehr wohl sehr viele pfadabhänige Daten in der Registry. Mit einzelen Teilen der Registry mag dies funktionieten, ist aber als generelle Aussage total falsch.
Zum ersten Punkt: Jedes Text-File kann eben so gut überwacht werden wie eine ganze Datenbank. Das ist nur von den Tools abhängig. Dass Windows von Haus auf da unterbemittelt ist, liegt bei der Existenz der Registry begründet. Andere OS bieten da deutlich mehr. -- Thomei08 12:54, 2. Nov. 2010 (CET)

Ich habe die Kommandozeilenbefehle im Sinne der Kollegen oben aus den Vorteilen der Registry herausgenommen und einen beschreibenden Abschnitt beim Regedit daraus gemacht. Skriptsteuerung ist nun wirklich nicht auf die Registry beschränkt. S.u. --Philip 20:56, 26. Jan. 2011 (CET) Ein Satz noch zur Pfadunabhängigkeit: Für mich geht es bei den Vorteilen um den Zugriff auf die Registry selbst. Natürlich gibt es auch Möglichkeiten z.B. für alle Windows Betriebssystemvarianten auf %ProgramData% (unter XP: Dokumente und Einstellungen...) zuzugreifen, aber dieses Beispiel zeigt schon, dass dies schwieriger ist bzw. meist nur Experten fehlerfrei hinkriegen. Ein "HKLM:\Software\MeineIchAG\MeinProggi" hingegen wird von Win 95 bis Win 7 an der gleichen Stelle gefunden. Dass man in der Registry Pfad-Strings speichern kann und der Inhalt (Values) damit nicht pfadunabhängig ist, ist eine Trivialität und hat jetzt nichts mit der Frage zu tun, ob ich Konfigurationen in .ini Files oder der Registry ablege. Moderne Software nutzt die Registry natürlich so wenig wie möglich, das ist klar, ist aber eben POV. Abgesehen davon, dass das Thema .ini/.xml vs. Registry im Jahre 2010 nicht mehr besonders spannend ist, weil sich die Fachkreise eigentlich für verteilte Konfigurationsdateien im Sinne auch von Portablen Applikationen (zumindest als Qualitätsmerkmal) entschieden haben, sei hier, am Rande vermerkt. --Philip 20:56, 26. Jan. 2011 (CET)

Streichungen/Kürzungen

Vorteile/Nachteile etwas gestrafft und aus der Sicht von 2010 modernisiert. Dabei u.a. folgende Teile gelöscht, ein Teil wurde oben bereits diskutiert, ich glaube, jedem Fachmann sind die Gründe direkt einleuchtend:

• Die Registrierungsdatenbank ist leicht mit Skripten zu bearbeiten, auch das Übernehmen von Einstellungen von einem PC zum nächsten ist automatisiert mittels Batchdateien möglich (mittels eines „regedit /e“-Befehls zum Exportieren und einem „regedit /s“-Befehl zum Importieren); eine so migrierte Registry wird auf jedem Windows-Betriebssystem ab Windows 95 und Windows NT 4.0 ohne Beachtung von Installationspfad, Betriebssystemssprache, etc. funktionieren.

• Die Struktur der Registrierung ist nicht stark ausgeprägt.

• Es gibt auch Programme, mit denen sich gezielt bestimmte Einstellungen in der Registrierung bearbeiten lassen. Ein Beispiel wäre ein Bestandteil von Windows, nämlich das Programm zum Bearbeiten von Dateitypen. Von Microsoft selbst gibt es zum Beispiel das Gratis-Tool „Tweak UI”, mit dem sich bestimmte Einstellungen verändern lassen. Dort lässt sich zum Beispiel das von Unix-Konsolen her bekannte und beliebte Autovervollständigen mit der Tab-Taste aktivieren. Natürlich gibt es auch Programme, die sich um den Schutz der Registrierungsdatenbanken vor zerstörerischen Programmen und Spyware kümmern. Eines davon kommt selbst von Microsoft und heißt Windows Defender. Es warnt, falls ein Programm versucht, bestimmte Teile der Registrierungsdatenbank zu verändern.

--Philip 20:56, 26. Jan. 2011 (CET)

Na gut:-) Um die Aussage des letzten Abschnitts zu erhalten, hab ich doch noch im Abschnitt Sicherheit folgenden Satz eingefügt:

• Als weiteren Schutz bieten Antivirenprogramme und andere Sicherheitswerkzeuge Zusatzabfragen oder zumindest Meldungen, wenn sich besonders wichtige Einstellungen in der Registry ändern.

--Philip 21:09, 26. Jan. 2011 (CET)

Tabelle

"Die in der Tabelle kursiv ausgezeichneten Schlüssel sind nicht real existent, sondern lediglich Verknüpfungen zu anderen Schlüsseln."

Von welcher Tabelle is'n da die Rede? Von der direkt oberhalb ja wohl, eine andere sehe ich nicht. Nur ist in dieser Tabelle jedenfalls auf meinem Bildschirm nichts kursiv ausgezeichnet. Also ebensowenig die "real nicht existenten", d. h., eigtl. auf andere verweisenden Schlüssel. Die Namen der Wurzelschlüssel sind rot, ansonsten ist da nichts besonders ausgezeichnet. Wurde das vergessen? Ich meine so oder so, den Satz (und was er verspricht) kann man sich eigentlich schenken, denn der Umstand der Verknüpfungsthematik geht ja bereits aus der Spalte "Beschreibung" innerhalb besagter Tabelle hervor. Oder nicht? -- Zero Thrust (Diskussion) 20:26, 23. Mai 2012 (CEST)

Irgendwer hat dadrin mal relativ sinnfreies syntaxhighlight eingebaut (außer das es jetzt rötlich ist, wie ein redlink scheint und eine breitere Spalte bewirkt, hat das keinerlei Zweck). Die echten Kursivschreibungen stehen etwa unter Spezial:Permanenter Link/90939009 vor anderthalb Jahren und sind auch inhaltlich richtig. Wer mag, kann jetzt gleich korrigieren, sonst mache ich das, wenn ich mal Zeit habe. Danke für den Hinweis --PerfektesChaos 21:20, 23. Mai 2012 (CEST)

Abschnitt Registry Reinigung

Dieser Abschnitt gibt nur die Meinung des Verfassers wieder und spiegelt lediglich eine Seite eines Meinungskriegs, der sich qwer durch Internetforen zieht. Der Abschnitt ist unbelegt, widerspricht den WIKI-Konventionen, (persönliche Meinung), ist zudem informationsarm weil unbegründet strittig, widerlegbar und damit inkompetent.

Wer mit der Registry arbeitet, weiß Bescheid, den Anderen wäre mit einem Warnhinweis am Artikelbeginn besser gedient.

Sehr wohl gibt es Programme, die nicht nur zehn, hunderte, tausende, sondern zehntausende Eintragsleichen hinterlassen, u.a. sogar eMail Adressen und anderer Schrott, der eine effektive Auswertung sehr wohl verzögert. (nicht signierter Beitrag von 80.141.227.89 (Diskussion) 07:22, 5. Nov. 2012 (CET))

Ich habe den Abschnitt jetzt ganz gelöscht, da Meinungen der "Fachwelt" nicht belegt sind. --P.C. ✉ 07:31, 5. Nov. 2012 (CET)

Es gab doch mal ein RegClean Tool von Microsoft. Gab es von denen eventuell auch mal eine Aussage über Sinn und/oder Machbarkeit? --P.C. ✉ 07:33, 5. Nov. 2012 (CET)

Die ersatz- und spurenlose Streichung des ganzen Abschnitts finde ich überhaupt nicht gut.

• Zweifelsfrei sammelt sich Müll in der Registry an.
• Umstritten ist, welches Tool nach welchem Algorithmus ohne Kollateralschaden geeignet aufräumt.
• Es ist letztlich eine Entscheidung des Benutzers, ob er den Vorteil einer beschleunigten Arbeit gegen das Risiko eines Ausfalls einzelner Softwareprodukte oder gar des Komplettversagens seines Rechners für größer hält.

Der Artikel muss in jedem Fall die Existenz der Cleaner erwähnen, und auch dass sie umstritten sind. Es ist nicht unsere Aufgabe, sie einzeln zu bewerten, welche sicher wären, welche wie viel Effekt bringen und ob es einen solchen überhaupt gibt. Wir erwähnen jedoch, dass es das Thema gibt.

VG --PerfektesChaos 10:53, 5. Nov. 2012 (CET)

Ok, und wenn Du jetzt Quellen für "Zweifelsfrei", "umstritten" und die diversen Vorteile findest, kann der Abschnitt rein. Aber die vagen Allgemeinplätze waren nicht brauchbar. --P.C. ✉ 10:57, 5. Nov. 2012 (CET)

• Es ist eine triviale Aussage, dass es unbenötigte Einträge in der Registry gibt.
  • Natürlich sind die vorhanden; weil eine Installation abstürzt, weil irgendwas schlampig programmiert ist und bei der De-Installation Bruch zurücklässt, weil etwas im laufenden Betrieb Schlüssel anlegt und sich hinterher nicht mehr daran erinnert wo.
  • Die Frage ist nicht ob es unbenötigte Einträge gibt, sondern wie viele und ob dies negative Auswirkungen hätte.
  • Das hängt wesentlich vom Verhalten des Benutzers ab: Spielkind, das dauernd irgendwelche Gratis-Angebote runterlädt und täglich installiert-deinstalliert, oder Gelegenheitsnutzer, der mit der Basis-Installation glücklich ist.
  • Die nächste Frage wäre, ab welcher Menge toter Einträge es spürbare Änderungen im Verhalten gibt. Meine Registry hat über 200.000 Schlüssel bei fast einer Million Einzelwerte. Die dürften weitaus überwiegend am Leben sein, kommen mir beim Durchflippen alle vertraut vor; und das ist eine relative Normalausstattung ohne Spielkram. Natürlich müssen bei der Suche nach Schlüsseln ein paar tausend Einträge durchsucht werden. Aber dazu gibt es Baumstrukturen und Hashcodes, die werden ja nicht linear einer nach dem anderen durchgelesen. Mein Eindruck ist, dass der meiste überflüssige Müll in meiner Registry von Microsoft Windows stammt und nicht von dritter Seite. Also: Welche Anzahl toter Einträge müsste vorhanden sein, um sich merklich auf die Systemfunktionen auszuwirken?
• Wenn ein Tool eingesetzt wird, wie groß ist die Zahl der falsch-positiven Treffer, also dass etwas entfernt wird, das noch benötigt wird? Wie groß ist die Zahl der falsch-negativen, also dass Überflüssiges drinbleibt? Wie viel wird überhaupt sinnvoll entfernt? Wie groß ist die Anzahl der sinnvoll entfernten im Verhältnis zur Gesamtzahl der Einträge? Macht das einen spürbaren Unterschied?
• Wie sicher entfernen irgendwelche Tools tatsächlich nichts Wichtiges, und wie viele Leichen werden tatsächlich entfernt? Lohnt das das Risiko?

Ergibt den enzyklopädischen Fakt: Es existieren Cleaner-Programme, die lautstark beworben werden; und dies gehört in den Artikel. Dass sie umstritten sind, ist auch eine Binsenweisheit; um das nachzuweisen, reicht kurzes googeln:

• pcwelt.de – Mythos 13
• pc-magazin.de – „Registry-Tuning größtenteils keine Zeitersparnis bringt“
• netzwelt.de – „Das meint die netzwelt-Redaktion: Der Nutzen derartiger Programme ist umstritten“

VG --PerfektesChaos 21:56, 5. Nov. 2012 (CET)

Ich bezweifele nicht, das es Registry Cleaner gibt. (Ich habe meinen Namen nicht zufällig gewählt.) Ich bezweifele nicht, dass es "tote" Einträge in der Registry gibt. Ich bezweifele nicht einmal die meisten der Aussagen, die Du in deinem Text triffst. Nur gibt es einen Unterschied zwischen "ich bezweifele nicht" und unseren Richtlinien. Deine drei Links sind schonmal ein Anfang. Aber: "Spielkinder haben signifikant mehr tote Schlüssel in der Registry" müsste belegt werden. "Die müssen nicht linear durchgelesen werden" ist vermutlich falsch, und müsste ebenfalls belegt werden. "düfte weitaus überwiegend" und "der meiste Müll kommt von Microsoft" sind reine Spekulation, genauso wie deine Rechnung und Statistiken. Aussagen über False-Positives und Risiko habe ich in dem Zusammenhang noch nie gesehen, wären also auch nur Spekulation. Am Ende bleibt ein Satz wie "Es gibt Programme, die die Registry aufräumen können sollen. Der Nutzen ist nicht belegt und umstritten". Quellen von Dir angegeben. --P.C. ✉ 07:24, 6. Nov. 2012 (CET)

• Wenn dir das alles klar it, why the hack hast du dann den Abschnitt vollständig entfernt?
• Wenn du nur explizite Belege dafür gewünscht hattest, dass das Cleaning der Registry umstritten sei: Kannst du nicht selber suchen? Warum stellst du mich dann dazu an, für dich zu googeln? Wenn du noch bessere Belege willst, kannst du englischsprachig suchen; da findest du auch den Rest. Im Übrigen ist der Sachverhalt unter Fachleuten hinlänglich bekannt. (Und was WP:Q angeht: Bei fehlenden Belegen aber unstrittigen Aussagen werden keine Inhalte entfernt, sondern allenfalls {{Belege fehlen}} eingefügt, wenn man selbst keine finden kann.)
• Was ich oben aufgeführt habe, ist die Hintergrundinformation für den Umstand, dass das Verhältnis Risiko+Aufwand ./. Nutzen kritisch gesehen wird. Es ist nicht für den unmittelbaren Einbau in den Artikel vorgesehen; dafür langt der Umfang des von dir entfernten Abschnitts völlig.
• Es ist trivial, dass sich bei jemand, der täglich kostenloses Zeugs installiert und deinstalliert, mehr Schrott ansammelt als bei einem Benutzer, der den Rechner kauft, drei Werkzeuge installiert und ihn dann in Ruhe lässt.
• Die Registry ist eine indexierte relationale Datenbank, keine Textdatei.

VG --PerfektesChaos 00:16, 8. Nov. 2012 (CET)

1) Ich mache nicht deine Hausaufgaben. Derjenige, der den Text haben will, muss ihn belegen, und ich bezweifele, dass Dir das zu deinem Textvorschlag gelingt. Ich wollte erstmal den falschen Abschnitt entfernen und dann hier eine Alternative ausdiskutieren. Denn: Auch wenn ich dieser Ansicht bin, bin ich mir darüber im Klaren, dass es eine Ansicht ist, also mein Standpunkt, und diesen Standpunkt in die WP aufzunehmen ist nicht mit den Regeln vereinbar.

2) siehe 1) Unbelegte Aussagen kann man mit "Belege fehlen" anmerken, aber nur, wenn man diese Belege auch finden kann. Sie können aber auch gelöscht werden. In WP:Q steht übrigens auch "Die Pflicht, Informationen zu belegen, liegt bei dem, der sie im Artikel haben möchte, nicht bei dem, der sie in Frage stellt." Direkt oben und fett... aber das hast Du anscheinend überlesen. (siehe 1)

3) Den Unterschied zwischen "Beispiel" und "Quelle" habe ich schonmal versucht Dir zu erklären. Die Aussage "meistens geht morgen die Sonne auf" lässt sich nicht mit einem Video eines Sonnenaufgangs belegen.

4) Ist es? Warum? Glaubst Du wirklich, nur bei der Installation werden Werte in die Registry geschrieben? Bist Du sicher, dass die Deinstallationsroutinen der vom "Bastler" installierten Software nicht gut genug sind? Und wieviel "mehr" ist "mehr"? Und, verlangsamt dieses "mehr" wirklich? Und: Hast Du für alle diese Aussagen eine Quelle?

5) Nein. Die Registry ist nicht relational. Welche Relationen kommen zum Tragen? Und sie ist nicht indiziert. Auf welchen Spalten liegt denn der index?

--P.C. ✉ 07:50, 8. Nov. 2012 (CET)

Wenn man sich schon streitet, sollte man wirklich wissen worüber man schreibt:
"Die Registry ist eine indexierte relationale Datenbank" (Zitat)
"Datenbank" ==> ja
"indexiert" ==> ja, das auch
"relational" ==> eher weniger... Die Regy ist eine hierarchische DB.

Dass es diese Regy-Cleaner-Tools gibt, ist bekannt. Was sie bringen auch: nicht viel.
Dazu wird es kaum empirische Belege geben, da diese Thema im professionellen Bereich so gut wie niemand interessiert, weil der Nutzen zu gering ist.
Die Zeiten (Win95/98/Me) als sich Programme gegenseitig einfach die Schlüssel überschreiben/löschen konnten sind glücklicherweise auch vorbei. Deshalb haben die Regy-Cleaner-Tools oftmals gar nicht die Möglichkeit wirklich aufzuräumen, da ihnen der Zugriff auf grosse Teile der Regy untersagt ist. Auch mit RegEdit stösst man schnell mal auf bereiche wo der Editor keine Zugriff hat.
Im Artikel sollte nur erwähnt werden, dass es diese Tools gibt und deren Nutzen bezweifelt wird. Mehr wird nicht belegbar sein. --Thomei08 09:44, 8. Nov. 2012 (CET)

Danke für die Schützenhilfe, Thomei08.
@PeeCee:

• Bei enzyklopädisch relevanten Informationen ist auch die von dir vorgenommene ersatzlose Komplettlöschung nicht durch WP:Q gedeckt.
  • Die drei Sätze dieses Abschnitts und damit der von dir ersatzlos gelöschte Abschnitt als Ganzes sind zweifelsfrei relevant; auch deshalb, weil diese Dinger an allen Ecken und Enden beworben werden.
  • Die enWP hält immerhin einen kompletten Artikel für relevant, und diskutiert auch mit einer hinreichenden Anzahl von Belegen die Für und Wider, belegt mindestens dass der Gebrauch dieser Tools umstritten ist.
• Die drei Sätze des mini-Abschnitts, die du aus der deWP zu entfernen verlangst, sind

  • Mit der Zeit gibt es in der Registry nicht nur „tote“, sondern auch falsche Verweise auf Ressourcen.

    Um diese Fehler zu beseitigen, gibt es mehr oder weniger umstrittene Tools.

    Die Fachwelt ist hier geteilter Meinung.

    Zu jedem einzelnen davon räumst du ein, dass du sie nicht bezweifelst. Für was forderst du jetzt eigentlich Belege? Für die Existenz von Cleanern?

• Die von dir vorgenommene ersatzlose Löschung ist nicht durch WP:Q gedeckt, wie du behauptest. Du zitierst unvollständig und damit sinnverfälschend aus WP:Q; tatsächlich steht dort:

  In strittigen Fällen können unbelegte Inhalte von jedem Bearbeiter jederzeit unter Hinweis auf diese Belegpflicht entfernt werden.

  Wie wir eben feststellen konnten, ist nichts an den von dir ersatzlos gelöschten Inhalten in irgendeiner Weise strittig; du räumst selbst ein, dass dir alle Inhalte der fraglichen drei Sätze bekannt wären und du nicht an deren Richtigkeit zweifelst. Was soll also dein ganzes Gewese?

  Des weiteren steht auf WP:Q:

  Angaben, die nur mit Rechercheaufwand bestätigt werden können, sowie strittige Angaben und Zitate sind mit Herkunftsangaben zu belegen.

  „Rechercheaufwand“ meint hier: Umfangreiche Suche in Geheimen Staatsarchiven, Entzifferung von Papyrii und dergleichen. Eine Google-Suche nach "Registry cleaner" liefert über 20 Millionen Treffer; das ist nicht mit einem „Rechercheaufwand“ gemeint, um die Existenz mindestens eines Registry cleaner nachzuweisen.

• Zu Einzelheiten der DB siehe technet.microsoft.com –
  • Am Ende des Abschnitts Hive Structure findest du auch den Indexierungs-Algorithmus beschrieben mit optimierter Suche (Bisektion). Ein simples Textformat wäre hingegen die .INI-Datei, bei der alle Einträge linear durchsucht werden müssten. Da wäre von einer Reduktion eher Beschleunigung zu erwarten.
  • Das Datenbankformat ist proprietär und auf diesen einzelnen Zweck hin geschrieben; gleichwohl relational, da es die physischen hives mit „symbolic link“ zu einer virtuellen Gesamt-DB zusammenfasst und auch dynamisch etwa die CLASSES der LOCAL_MACHINE mit denen des CURRENT_USER zusammenführt („handle“). Natürlich ist das kein universelles relationales DBMS.

HGZH --PerfektesChaos 09:55, 8. Nov. 2012 (CET)

Wie kann ich Dir verständlich machen, dass es einen Unterschied gibt zwischen "Ich meine das, und deshalb muss es in den Artikel" und "seriöse, reputable Quellen sagen XXX, und wir geben deren Aussage wieder"? Ersteres machst Du, letzteres möchte ich, weil es den Regeln entspricht. Es ist völlig wurst, was Du oder Ich über die Registry wissen. Wir können nicht in den Artikel schreiben "Zwei anonyme User haben sich auf der Diskussionsseite darauf geeinigt, dass das stimmt, und Horst Meier stimmt ihnen zu". Erster Abschnitt in WP:TF:Aussagen, die nur auf persönlichen Erkenntnissen von Wikipedia-Autoren basieren, gehören nicht in die Artikel. Also müssen wir uns auf zuverlässige Publikationen stützen, wie es WP:Q fordert. Und daher: Ja. Ich möchte einen Nachweis, dass es "mit der Zeit" (welcher) immer "tote und falsche" (was heist das) "Verweise" (Dieses Wort kommt im Artikel sonst nicht vor... was bedeutet das?) gibt. Dass es diese Programme gibt ist wohl eine "offenkundige Tatsache" und nicht zu bequellen, aber ich möchte Quellen über das "umstritten". Gerade weil es umstritten ist.

P.S. Der TechNet Artikel ist nett... aber von "relationaler Datenbank" lese ich da nichts. Und das mit dem "cell index" verstehst du auch anscheinend falsch. en:Index Abschnitt "Computer Science". Die Registry "indexe" sind Bedeutung 2/3, die in einer Datenbank Bedeutung 1/4. Etwas mehr Sorgfalt muss man beim erbringen von Quellen schon walten lassen.

Davon mal ab... ich frage mich gerade, welches Ziel Du mit dieser Diskussion verfolgst. Verbesserung des Artikels scheint es nicht zu sein, sonst würdest Du hier nicht meterweise Diskussionsseiten vollschreiben, sondern einen vernünftigen, bequellten Vorschlag machen. --P.C. ✉ 16:05, 8. Nov. 2012 (CET)

Versucht doch mal Sätze zu Bilden mit den Satzteilen: "In einem Artikel von XY[Quelle] wird festgestellt, dass…" oder "Gemäss einer Untersuchung von XY[Quelle] soll es…." So kann man auch Quellen verwenden die angezweifelt werden. Am besten man stellt auf diese Art beiden Ansichten dar. Ev. löst das diesen Knoten hier. --Thomei08 16:20, 8. Nov. 2012 (CET)

Na gut.

Die c't zählt die Frage ob ein Windows-System nur "rund läuft", wenn regelmässig die Registry aufgeräumt, die temporären Dateien gelöscht und die Festplatte defragmentiert wird, zu den "PC-Mythen". Im Artikel 'PC-Mythen aufgeklärt' bezeichnet sie das Löschen von Registy-Einträgen als überflüssig, da ohnehin nur benötigte Einträge in den Speicher geladen werden. Andererseits sei es gefährlich, da schon ein einziger falsch gelöschter Eintrag große Probleme machen kann. Registry-Cleaner würden nur zufällig helfen.

Eine aktuellere Quelle habe ich nicht gefunden. Den Status "PC-Mythos" könnte mal als Quelle für "umstritten" ansehen. --P.C. ✉ 07:41, 9. Nov. 2012 (CET)

Jetzt fehlt noch die Darstellung der gegenteiligen Behauptung. Diese findet man bei Anbietern der Cleaning-Tools leicht. Dann könnte der Abschnitt also wie folgt aussehen:

Obwohl Anbieter von Registry-Reinigungs-Anwerbungen immer wieder damit werben, dass Windows nach einer Registry-Reinigung schneller arbeite und weniger Speicherplatz auf der Festplatte und im Arbeitsspeicher belegen soll, zählten die Fachzeitschriften c't und PC-Welt diese Behauptung zu den PC-Mythen. Auch netzwelt meint dass der "Nutzen derartiger Programme umstritten" sei.

Würde das so Passen?--Thomei08 10:13, 9. Nov. 2012 (CET)

Danke - ich finde, das passt sehr gut so. --Schotterebene (Diskussion) 10:26, 9. Nov. 2012 (CET)

Denke ich auch. --P.C. ✉ 13:29, 9. Nov. 2012 (CET)

Änderungen von Textdateien oder Änderungen an der Registry.

1. diff und Patch gibt es auch unter Windows
2. Diff kann zwei Dateien vergleichen. Daraus wird ein Patch erstellt. Die Patch-Datei sagt dann "in zeile X folgende Zeilen einfügen". Woher weiss Patch aber, dass die Zeilenanzahl auf meinem Rechner noch genauso ist?

Genau: Garnicht. Daher werden auch unter Linux, z.B. Debian, Konfigurationsdateien nicht per Patch aktualisiert, sondern neu geschrieben, und der Admin muss sie beim Aktualisieren des Pakets zusammenführen.

Deshalb lösche ich nochmal den hinkenden Vergleich. --P.C. ✉ 09:49, 28. Nov. 2013 (CET)

1. Wir sprechen hier nicht von nachträglich installierten Tools. Wenn ich z.B. Cygwin installiere habe ich nahezu alle Möglichkeiten zur Konfigfile-Edition von Unixoiden-Systmen in Windows auch. Deshalb soll es hier nur um Tools gehen, die Windows schon mitbringt.
diff gibt es in der Power Shell. patch gibt es auch dort nicht.

2. Ja, patch ist nicht das bervorzugte tool um Konfigfiles zu editieren. Normalerweise kommt dafür sed oder nur echo zum Einsatz. sed gibt es in Windwos auch nicht.

Damit ist die Aussage, dass es solche Tools für [Konfigurationsdatei]]en (generell) nicht gibt einfach falsch. Nur Windwos ist in dieser Beziehung etwas eingeschränkt. --Thomei08 10:56, 28. Nov. 2013 (CET)

Bullshit ... Weder sed noch patch sind teil von "Linux" .. es sind Tools, die in fast jeder Distibution dabei sind, ja, aber sie sind nicht "Linux". Und immer noch: keines der Tools wird verwendet um geänderte Konfigurationsdateien von z.B. Debian zu verteilen. --P.C. ✉ 11:02, 28. Nov. 2013 (CET)

Jetzt lehenst du dich aber sehr weit aus dem Fesnter!

sed ist im POSIX-Standard berschieben und somit nicht auf Linux-Systeme oder Debian beschränkt. Auch in BSD, OSX oder Solaris sind sed, diff und patch enthalten. Windows ist bekanntlich ohne zusätzliche Installationen nicht POSIX kompatibel. Auch die meisten Unix-Konfigurationsdateien sind kein Teil von Linux selbst, sondern gehören zum unix-artien Userland. (Regedit oder Win32/64 sind auch nicht Teil des NT-Kernels. Bitte, vergleiche kein Kraut mir Rüben.)

Zurück zum eigentlichen Thema: Es gibt verschiedene Wege um Einstellungen in Unixoiden-Systemen zu verteilen. Man kann eine Managmendsoftware nutzen (zusätzliche Software) oder man nutzt ein selbst erstelltes Shell-Script, das auf Boardmitteln wie sed, awk, grep, diff, patch, ex, echo, cat... zurückgreift. Oft reicht es auch vollkommen aus, ganze Konfigurationsfiles/Verzeichnisse auf Filesystem-Ebne z.B. mit cp, rsync oder unison zu synchronisieren. So flexibel ist Windows leider nicht. Selbst wenn ich nur die Einstellungen von einer Anwendungen in der Regestry verteilen will, kann ich nicht einfach nur ein File/Verzeichnis kopieren/verteilen.

In diesem Artikel sollte kein Unix-Kurs enthalten sein. Es sollte aber aufgezeigt werden, dass die Vor- und Nachteile der Regestry nicht auf jedem anderen Betriebssystem bestehen und anderen OS teilweise mit Konfigurationsfiles einfachere und elegant Lösungen "out of the box" bieten. Windows ist nicht die ganze Welt. --Thomei08 12:50, 28. Nov. 2013 (CET)

Und diese Managementsoftware, und die selbst erstellten Shellscripte sind teil des Betriebssystems? Es ist unbestritten, dass es Systeme gibt, die Konfigurationsdateien verwalten können. Java-Properties können auch sehr schön gelesen werden. XML kann man auch ohne Diff gut bearbeiten. Alles schön und gut. Der Artikel ist aber nicht "Verschiedene Konfigurationsmanagementsysteme im Vergleich" sondern es ging um "Registrierungsdatenbank <-> Textdatei". Und die Registry hat Vorteile gegenüber einer Textdatei. Diese werden aufgezählt. Ob man mit anderen Tools auf anderen Systeme ähnliches machen kann ist dabei in meinen Augen egal. --P.C. ✉ 13:37, 28. Nov. 2013 (CET)

Aussagen wie: "Für Konfigurationsdateien gibt es keine solchen Hilfsprogramme." sind totale WP:TF und Unsinn. Nicht einmal für Windows stimmst dies so generell formuliert, wie du selbst schreibst. Das die Verteilung einzelner Files auch in Windoews einfacher sein kann als die Replikation von hyrarchsichen DB's liegt auf der Hand. Ich denke damit sind wir beim Thmea: Registrierungsdatenbank <-> Textdatei. --Thomei08 13:48, 28. Nov. 2013 (CET)

Dann mach mal einen Vorschlag. Und wenn Du gegen TF bist, dann bitte auch mit Quelle, und nicht aus eigener Erfahrung. Andererseits... Dann müssen wir erstmal alles zum Thema Vor- und Nachteile löschen, denn das ist alles TF. --P.C. ✉ 13:53, 28. Nov. 2013 (CET)

Hmmm... mehr Quellen können nie wirklich schaden. Deswegen sollte man aber nicht gleiche das Kind mit dem Bade ausschütten. --Thomei08 14:58, 28. Nov. 2013 (CET)

Registry auf einen usb stick

kann man eine registry auch auf einen usb stick oder eine externer platte machen so das man programme und/oder windows installieren kann? LG Herocraft 84.59.222.154 14:57, 17. Dez. 2013 (CET)

Die Wikipedia ist kein Hilfeforum. Stell diese Frage bitte an Microsoft oder lese den Artikel. --Thomei08 15:23, 17. Dez. 2013 (CET)

hab den artikel gelesen beantwortet aber immer noch nicht meine frage :/ LG Herocraft 84.59.222.154 15:29, 17. Dez. 2013 (CET) wehre nett wenn nicht immer sowas kommt wie wir sind kein forum oder frag den support wenn du eine antwort oder rat weist dann bitte schreib ansonsten lass es LG Hercraft 84.59.222.154 15:37, 17. Dez. 2013 (CET)

Zumal die FRage im Artikel beantwortet wird, gibt es keinen Grund hier Supportanfragen zu beantwoeren. Lese bitte WP:WWNI und WP:D. Danke. --Thomei08 15:55, 17. Dez. 2013 (CET)

in welchem abschnitt :D ich blig bei den langen artiekeln net duch :( 84.59.222.154 16:02, 17. Dez. 2013 (CET) LG Herocraft

Gib es dann wenigstens eine möglich keit normale windows programme über/auf einem usb stick laufen zu lassen? LG Herocraft 84.59.222.154 18:38, 18. Dez. 2013 (CET)

Du meinst als Portable Software? --P.C. ✉ 07:11, 19. Dez. 2013 (CET)

Ja und wie geht das mit winodws? 84.59.222.154 15:16, 19. Dez. 2013 (CET) LG Herocraft

Kennst Du eigentlich den Unterschied zwischen einer Enzyklopädie und einem Forum? Diese Diskussionsseite dient dazu die Arbeit am Artikel zu koordinieren, und nicht um Hilfestellungen für IT-Fragen zu liefern. --P.C. ✉ 15:17, 19. Dez. 2013 (CET)

Dieser Abschnitt kann archiviert werden. Thomei08 16:13, 19. Dez. 2013 (CET)

Alternativen

Muss dieser Abschnitt sein? Andere Betriebssysteme machen Dinge anders. Müssen alle OS und alle Verfahren hier aufgelistet werden? Stehen bei NTFS alle anderen Dateisysteme, die auf anderen Betriebssystemen auftauchen? Die Alternativen sind noch nicht mal für die anderen Betriebssysteme Standard. --P.C. ✉ 15:48, 23. Jan. 2014 (CET)

Ich denke es nicht nicht notwenig hier über Property Lists, G/Dconf und Elektra zu schreiben. Von mir aus kann man gern, dies alles entfernen. Bleibt es aber drinn, solle man bitte nicht so tun, als folgten sie den genau gleichen Konzepten wie die Win-Registry. Dann braucht es wirklich Erklärungen. Was aus meine Sicht bleiben sollte, ist der Abschnitt zu Wine. Dort geht es wirklich um die Windows-Registry selbst. --Thomei08 07:46, 24. Jan. 2014 (CET)