Entwickler-Ecke
Sonstiges (Delphi) - Brainstorming: Features für Registryeditor
jaenicke - Mo 08.06.09 15:29
Titel: Brainstorming: Features für Registryeditor
Hallo!
// EDIT: Das entsprechende Open Source Projekt ist jetzt hier zu finden:
http://www.delphi-forum.de/viewtopic.php?p=567719
Ich entwerfe gerade einen neuen besseren Registryeditor. Und da wollte ich mal fragen ob ihr da vielleicht noch Einfälle / Wünsche / Überlegungen dazu habt basierend auf dem Standard-Regedit oder anderen Tools.
Meine Überlegungen:
- Separater Adminmodus für Vista, Start also als normaler Nutzer möglich
- Verlinkung innerhalb der Werte, also z.B. von .txt auf den Schlüssel txtfile. Oder von GUIDs auf deren Definition. Oder auf Dateien und Verzeichnisse. Und so weiter.
- Schnell, erste Tests waren sehr viel schneller als Regedit.
- Automatische Codegenerierung zum Auslesen oder Eintragen von Werten für verschiedene Sprachen.
Und jetzt seid ihr dran: Fällt euch noch mehr ein? Fehlt euch etwas bei Regedit?
Im Moment arbeite ich noch an anderen Projekten und lasse die Planung nebenher anlaufen um das Projekt reifen zu lassen, es sind also noch ein paar Tage Zeit.
Schönen Gruß,
Sebastian
Moderiert von 
Narses: Topic aus Off Topic verschoben am So 14.06.2009 um 23:16
nagel - Mo 08.06.09 15:43
Hallo,
interessantes Projekt.
Ich fände eine verbesserte Suchfunktion hilfreich (RegExp, Case-Sensitive Ja/Nein usw.), nach Möglichkeit natürlich schneller als im „Original“.
jaenicke - Mo 08.06.09 15:53
Die Suche an sich werde ich vielleicht schneller hinbekommen, aber das wird sicher wieder langsamer, wenn ich solche Sachen mit einbaue. Da muss ich schauen was ich in angemessener Zeit hinbekomme, aber das wäre sicher interessant.
Dazu baue ich dann noch ein, dass man bestimmte Zweige ausschließen kann, das beschleunigt die Suche ja auch nochmal.
elundril - Mo 08.06.09 16:11
eine säuberungsfunktion vielleicht, die die registry von unnötigen einträgen befreit.
InCoBra - Mo 08.06.09 16:13
Ich fände es auch cool, wenn man zu einem Schlüssel, den man als String hat navigieren kann (so er denn besteht). Am besten wäre ja, soweit realisierbar (technisch ist es das auf ja jeden Fall, ich meine jetzt eher resourcentechnisch und so :P) eine Eingabe wie die Adressezeile im Windows (XP) Explorer. Also mit Autovervollständigung wäre schon nett ;)
- "Adress"-Eingabezeile
- Import/Export-Funktion
jaenicke - Mo 08.06.09 16:15
elundril hat folgendes geschrieben  : |
| eine säuberungsfunktion vielleicht, die die registry von unnötigen einträgen befreit. |
Das ist ja nicht so einfach, und dass man dabei auch schnell was völlig falsches löscht, zeigen ja nahezu 100% der entsprechenden Cleanertools, die es derzeit gibt... ;-)
| InCoBra hat folgendes geschrieben : |
| Am besten wäre ja, soweit realisierbar (technisch ist es das auf ja jeden Fall, ich meine jetzt eher resourcentechnisch und so :P) eine Eingabe wie die Adressezeile im Windows (XP) Explorer. Also mit Autovervollständigung wäre schon nett ;) |
Ach ja, das hatte ich vergessen, ja, das ist auf jeden Fall dabei. Das habe ich schon bei einem anderen Editor gesehen und werde es auch einbauen.
Inkl. Favoritenfunktion usw., zudem überlege ich eine Art Onlinewiki anzulegen, wo Benutzer Erklärungen zu Zweigen und Einträgen aufschreiben können.
Horschdware - Mo 08.06.09 16:15
Bookmarks!
Ralf Jansen - Mo 08.06.09 16:16
Regedit kann ja bereits ein oder mehrere Remote Registries öffnen.
Was ich gerne hätte wäre das man die Hives der geöffneten Registries vergleichen und gegebenfalls synchronisieren könnte.
BenBE - Mo 08.06.09 16:16
Kurze Liste, was mir sofort einfällt. Erhebt keinen Anspruch auf Vollständigkeit ;-):
- SearchAll\ReplaceAll (gern mit Regexp :P)
- GUID\CLSID\IID-Linking (Infos über die Keys, Welches Programm, ist das Teil gültig, ..)
- Structural\Semantical Browsing*
- Bookmarks häufig genutzter Keys
- Shell-Like-Interface zum switchen zwischen Keys, Werte ändern,
- Keys\Values verschieben
- Gute Hilfe :P
- Wert-Vervollständigung (z.B. bei nem Service, dass ich den Starttyp aus ner Liste auswählen kann)
- Hive-Editing (Lesen\Bearbeiten von Hive-Files, die grad nicht in der Registry hängen). Sprich um z.B. einen Teilzweig als eigenständiges Hive-File exportieren zu können.
* Semantical Browsing könnte so aussehen, dass ich z.B. eine Struktur hab, wo drin steht, WAS ich betrachten will (z.B. Hardware-Konfigs) und mir der Reg-Editor dann die vorhandenen Hardware-Strukturen in eine übersichtliche Form packt. Oder ich in den Autostart-Abschnitt gehe und dort die entsprechenden Einträge aufbereitet bekomme (Wo definiert, Welches Programm, Genaue Kommandozeile,) und ich dort dann managen kann. Sprich insgesamt dass man die semantischen Informationen, die der Registry zugrunde liegen hernehmen kann und dort eine Oberfläche bekommt, wo man diese gleich überschauen kann.
Andreas L. - Mo 08.06.09 16:20
| jaenicke hat folgendes geschrieben : |
| Die Suche an sich werde ich vielleicht schneller hinbekommen, aber das wird sicher wieder langsamer, wenn ich solche Sachen mit einbaue. Da muss ich schauen was ich in angemessener Zeit hinbekomme, aber das wäre sicher interessant. |
Du kannst ja, wie bei anderer Software üblich, die obengenannten Features als Optionen anbieten. So bleibt die Standard-Suche schneller als die von regedit, bietest die anderen Funktionen als etwas langsamere Experten-Suche aber trotzdem an. Suchgeschwindigkeit wäre mir persönlich eins der wichtigsten Features denn RegEdit ist schon sehr lahm...
| jaenicke hat folgendes geschrieben : |
| Dazu baue ich dann noch ein, dass man bestimmte Zweige ausschließen kann, das beschleunigt die Suche ja auch nochmal. |
Coole Sache :zustimm:
Favoriten wären toll. Evtl. mit der Möglichkeit zu jeden Favorit einen Kommentar hinzuzufügen.
jaenicke - Mo 08.06.09 16:24
| Ralf Jansen hat folgendes geschrieben : |
Regedit kann ja bereits ein oder mehrere Remote Registries öffnen.
Was ich gerne hätte wäre das man die Hives der geöffneten Registries vergleichen und gegebenfalls synchronisieren könnte. |
Da muss ich mal schauen wie das geht.
Aber eine diff-Funktion z.B. wäre eine Überlegung wert, allerdings auch relativ aufwendig. Zuerst kommt auf jeden Fall die lokale Registry dran, aber der Hinweis ist gut, ich werde versuchen darauf zu achten, dass ich das so schreibe, dass man es auch leicht auf eine externe Registry anwenden kann.
| BenBE hat folgendes geschrieben : |
| - GUID\CLSID\IID-Linking (Infos über die Keys, Welches Programm, ist das Teil gültig, ..) |
Genau das war meine ursprüngliche Überlegung. Wobei ich bei den Sachen mir die Struktur auch erstmal genauer anschauen muss um selbst zu wissen was da alles möglich ist.
| BenBE hat folgendes geschrieben : |
| - Structural\Semantical Browsing* |
Da wäre vielleicht eine Art Pluginsystem eine Idee, so dass man da einfach verschiedene Ansichten für spezielle Zweige einklinken kann.
| BenBE hat folgendes geschrieben : |
| - Shell-Like-Interface zum switchen zwischen Keys, Werte ändern |
Da dachte ich z.B. u.a. an Tabs um gleichzeitig mehrere offen haben zu können.
| BenBE hat folgendes geschrieben : |
| - Keys\Values verschieben |
Stimmt, daran hatte ich noch nicht gedacht.
Vor allem auch importieren einer Registrydatei an eine andere Stelle, wenn ich das sinnvoll hinbekomme. Aber da bin ich nicht so sicher. Das größte Problem ist ja vor allem, dass das alles sehr stabil sein muss. Schließlich ist die Registry ja sehr wichtig...
| BenBE hat folgendes geschrieben : |
| - Gute Hilfe :P |
Bessere Idee: Intuitive Bedienung, damit man keine braucht. :D
| BenBE hat folgendes geschrieben : |
| - Wert-Vervollständigung (z.B. bei nem Service, dass ich den Starttyp aus ner Liste auswählen kann) |
Inwieweit sowas da sinnvoll ist muss ich schauen. Bei Dateinamen oder Ordnern ist sicher neben einer Verlinkung auch ein OpenDialog sinnvoll.
| Andreas L. hat folgendes geschrieben : |
| Du kannst ja, wie bei anderer Software üblich, die obengenannten Features als Optionen anbieten. So bleibt die Standard-Suche schneller als die von regedit, bietest die anderen Funktionen als etwas langsamere Experten-Suche aber trotzdem an. |
Das ist sowieso klar. Wenn, dann baue ich das als mehrere Klassen ein, die dann in die Suche eingeklinkt werden.
BenBE - Mo 08.06.09 16:38
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - GUID\CLSID\IID-Linking (Infos über die Keys, Welches Programm, ist das Teil gültig, ..) |
Genau das war meine ursprüngliche Überlegung. Wobei ich bei den Sachen mir die Struktur auch erstmal genauer anschauen muss um selbst zu wissen was da alles möglich ist. |
Ggf. hier ein Plugin-System bauen, wo man das mit dem Lookup ergänzen kann. Da könnt ich ggf. helfen bzgl. der Lookups.
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - Structural\Semantical Browsing* |
Da wäre vielleicht eine Art Pluginsystem eine Idee, so dass man da einfach verschiedene Ansichten für spezielle Zweige einklinken kann. |
Da könnte ich von XSetup ggf. die Plugin-Files zur Verfügung stellen, da sind eine Reihe allgemeiner Settings drin; da hätte man eine gute Basis, um das in einer eigenen Struktur zu organisieren und zu sehen, worauf man achten müsste. Xteq Xsetup war bis Version 6 ein absolut geniales Tool (danach aber leider nur noch kommerziell weiterentwickelt).
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - Shell-Like-Interface zum switchen zwischen Keys, Werte ändern |
Da dachte ich z.B. u.a. an Tabs um gleichzeitig mehrere offen haben zu können. |
Meinte das eher bash-like, so dass ich z.B. hingehen kann und "RegSH-Scripts bauen kann, die zum Automatisieren bestimmter Aufgaben genutzt werden können.
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - Keys\Values verschieben |
Stimmt, daran hatte ich noch nicht gedacht. |
Siehst'de :P Das hab ich mich schon öfters bei M$ geärgert, dass das nicht geht.
| jaenicke hat folgendes geschrieben : |
| Vor allem auch importieren einer Registrydatei an eine andere Stelle, wenn ich das sinnvoll hinbekomme. Aber da bin ich nicht so sicher. Das größte Problem ist ja vor allem, dass das alles sehr stabil sein muss. Schließlich ist die Registry ja sehr wichtig... |
.reg-Files sind recht einfach zu parsen; muss man dann halt nur "rebasen" bei den Pfaden ...
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - Gute Hilfe :P |
Bessere Idee: Intuitive Bedienung, damit man keine braucht. :D |
Dann kannst Du aber nicht RTFM sagen :P Überleg's Dir gut!!! :mahn:
| jaenicke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | - Wert-Vervollständigung (z.B. bei nem Service, dass ich den Starttyp aus ner Liste auswählen kann) |
Inwieweit sowas da sinnvoll ist muss ich schauen. Bei Dateinamen oder Ordnern ist sicher neben einer Verlinkung auch ein OpenDialog sinnvoll. |
Auch hier könnte ein Plugin-System durchaus helfen, um den verschiedenen Keys semantische Informationen zu ergänzen.
Bzw. ein Listen-Editor für REG_SZ_MULTI oder bei REG_SZ-Werten wie bei Delphi, wo die Packages aufgezählt werden.
jaenicke - Mo 08.06.09 17:02
Ja, das ist ja schon eine Menge, ich muss mir mal überlegen wie das sinnvoll zusammenpasst. Sowohl auf der Oberfläche als auch im Programm.
Danke schonmal für die Anregungen, ich werde das mal versuchen übersichtlich zusammenzubringen. :zustimm:
jakobwenzel - Mo 08.06.09 18:04
.reg-Datei-Import der nicht per Registry verboten werden kann. :twisted:
Das ist echt ne Qual nachträglich portabel gemachte Programme die ihre Einstellungen in der Registry haben wollen zu benutzen wenn das deaktiviert is...
nagel - Mo 08.06.09 22:24
Überwachen von Registryänderungen durch andere Programme wäre auch noch praktisch.
Popov - Mo 08.06.09 22:36
Eine Säuberungsfunktion würde ich nicht nicht einbauen. Erstens gibt es solche Tools in Massen, also wozu Zeit für etwas opfern was man auch mit einem anderen Toll erledigen kann. Aber wo wir bei Säuberungsfunktion sind, ein Pfad Überpfüfunsfunktion könnte man schon einbauen. Damit meine ich, daß man auf ein Schlüssel wählt und alle Pfade innerhalb des Schlüssels auf Vorhandensein prüft.
Aber was ich bei der normalen Regedit vermisse ist, eine Reg-Dat aus dem Backup zu öffnen, also nicht die gerade benutzte, sondern auch eine externe. Das wäre auch für Admins interessant, denn dann könnten sie die Reg-Dateien anderer Konten öffnen.
Narses - Mo 08.06.09 22:42
Moin!
| Popov hat folgendes geschrieben : |
| Aber was ich bei der normalen Regedit vermisse ist, eine Reg-Dat aus dem Backup zu öffnen, also nicht die gerade benutzte, sondern auch eine externe. |
Das wäre allerdings mal was, da kenne ich bisher auch nur Gurkentools... :?
| Popov hat folgendes geschrieben : |
| Das wäre auch für Admins interessant, denn dann könnten sie die Reg-Dateien anderer Konten öffnen. |
Das können sie doch sowieso? :gruebel: Einfach unter HKU\<SID>\... :nixweiss:
cu
Narses
BenBE - Mo 08.06.09 22:49
Spannend wäre auch, eine .REG-Datei direkt editieren zu können, als ob das ein Hive wäre.
jaenicke - Di 09.06.09 01:12
Also eine .reg Datei direkt zu editieren wäre sicher möglich. Ich muss das so aufbauen, dass die Datenquelle virtualisiert ist, dann kann das auch anderswo als aus der Registry kommen.
Die Registrydatei selbst: Ja, also ich brauchte sowas auch schonmal. Das Format ist nur nicht so ganz einfach, ich glaube nicht, dass das so einfach wird, das auszulesen. Zumal offiziell die Spezifikation wohl nicht herausgegeben wurde.
Vor allem weiß ich nicht wie effizient ich das hinbekomme, also wieviel Geduld man dann braucht. :D
// EDIT:
Also mit der Geschwidigkeit klappt das irgendwie noch nicht richtig, ich hab gerade mal ein bisschen mehr getestet. Im Moment bin ich da langsamer als regedit. :gruebel:
// EDIT2:
Ok, jetzt hab ichs. Jetzt gibts keine spürbaren Verzögerungen mehr, selbst HKEY_CLASSES_ROOT (mit bei mir mehr als 10.000 Schlüsseln) ist sofort offen. :mrgreen:
jaenicke - Di 09.06.09 10:26
Ich hänge mal eine Testversion an, der Button funktioniert noch nicht. Es werden nur die Schlüssel, Wertnamen und Wertetypen, bei REG_SZ Werten auch die Werte selber angezeigt, mehr nicht.
Jedenfalls weiß ich jetzt schon, dass ich auch für den normalen Zugriff auf die lokale Registry mit TRegistry nicht weiterkommen werde. Das ist vor allem schlicht zu langsam. In dem Testprogramm habe ich es auch nicht benutzt.
Das Programm startet sofort, klappt auch die Schlüssel sofort aus, lädt aber die Schlüssel und ob Unterschlüssel existieren erst bei der Anzeige (also beim Scrollen). Das scheint so selbst bei schnellem Scrollen recht gut zu klappen.
Da werde ich noch die Synchronisierung im Auge behalten müssen bei Änderungen an den Inhalten während der Anzeige, aber jedenfalls klappt es soweit wie ich es mir dachte. Und damit bin ich auch bei:
| nagel hat folgendes geschrieben : |
| Überwachen von Registryänderungen durch andere Programme wäre auch noch praktisch. |
Das werde ich natürlich machen. Dafür gibt es auch entsprechende
Notifier [
http://msdn.microsoft.com/en-us/library/ms724892.aspx].
// EDIT:
Angang entfernt, da neuere Testversion vorhanden.
BenBE - Di 09.06.09 11:07
hmmm, bringt mich auf die Idee: Funktionalität von RegMon (Beobachten der Registry-Zugriffe) so einbinden, dass ich eine Baumstruktur der zugegriffenen Werte hab. Bei RegMon ist das immer etwas unübersichtlich in den Logfiles. Sprich Art virtueller Hive der durch ein Programm gelesenen\geschriebenen Keys.
jaenicke - Di 09.06.09 11:10
Da müsste ich mir die Notifier einmal genauer anschauen. Ich hatte eigentlich nur vor die direkt geöffneten Zweige ohne Unterzweige zu überwachen. Für diese Funktion müsste ich ja alles überwachen.
Ich bin mir nicht sicher wie das mit der Performance aussieht. :gruebel:
Nersgatt - Di 09.06.09 11:13
Bei einer Suchfunktion alle gefundenen Stellen in einem extra Fenster darstellen, um nicht mit F3 durch die Suchergebnisse durchsteppen zu müssen, sondern sie im Überblick zu haben. Mit Klick auf die Funstelle dann automatisch zur entsprechenden Stelle springen.
Und Bookmarks!
jaenicke - Di 09.06.09 11:27
| Nersgatt hat folgendes geschrieben : |
| Bei einer Suchfunktion alle gefundenen Stellen in einem extra Fenster darstellen, um nicht mit F3 durch die Suchergebnisse durchsteppen zu müssen, sondern sie im Überblick zu haben. Mit Klick auf die Funstelle dann automatisch zur entsprechenden Stelle springen. |
Ja, so hatte ich das bei meinem alten Editor auch gemacht, da wurde ein entsprechendes Fenster angezeigt, das normalerweise gedockt war.
Im Moment probiere ich gerade ein wenig aus wie das mit dem Eingabefeld laufen könnte. Und danach kommt erstmal mein Updater Projekt dran, das endlich fertig werden soll.
jaenicke - Do 11.06.09 19:58
So, neben anderen Experimenten habe ich mal eine Autocomplete Klasse gebastelt. Die habe ich mal in das vorherige Testprogramm eingesetzt.
Die Verbindung mit dem Rest ist noch nicht vorhanden, es wird einfach nur in der Statusleiste eine Autocompletion gemacht, mehr nicht. Escape bricht die Eingabe ab, Return bestätigt diese. Mit \ kann man einen vorgeschlagenen Eintrag bestätigen und weiter eingeben.
Egal ob HKEY_LOCAL_MACHINE, HKLM, LM oder das alles kleingeschrieben, es wird alles erkannt.
Die Verknüpfung der einzelnen Tests kommt dann erst im echten Projekt, das sind erstmal nur einzelne Tests und Klassen.
BenBE - Do 11.06.09 21:23
Zwei wünschenswerte Änderungen: Tab zum Übernehmen und bitte die Einträge sortiert vorschlagen. Ansonsten aber wirklich schon recht schnell ;-)
Ein Bug ist aber noch drin: Wenn ich HKCR\CLSID\{000000 eingeb, meint er, es gibt keinen Schlüssel, obwohl es (Beim Öffnen des CLSID-Schlüssels) einen Knoten {00000020-...} gibt.
Popov - Do 11.06.09 21:40
Noch eine Idee. Was ich bei jetzigen Regedit vermisse ist der direkte Sprung in einen Schlüssel. Nehmen wir an man kriegt im Internet einen Tipp mit diesem Pfad:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
Dann muß man sich bei Regedit einzeln durchklicken bis man bei Run ankommt. Eine Adressenzeile wie beim Explorer wäre nett, d.h. man gibt den Pfad ein und das Programm springt in den richtigen Schlüssel.
jaenicke - Do 11.06.09 21:43
| BenBE hat folgendes geschrieben : |
| Zwei wünschenswerte Änderungen: Tab zum Übernehmen |
Das ist kein Problem, hatte ich auch schon vor.
| BenBE hat folgendes geschrieben : |
| und bitte die Einträge sortiert vorschlagen. Ansonsten aber wirklich schon recht schnell ;-) |
Genau die Schnelligkeit ist das Problem. Ich habe jetzt eine binäre Suche benutzt. Diese findet aber eben einen zufälligen passenden Eintrag.
Das heißt ich müsste nochmal rückwärts eine modifizierte binäre Suche bis zum ersten passenden Eintrag machen oder sowas. :gruebel:
Mal sehen, vielleicht gibts da ja auch was fertiges, ich hatte erstmal nur die binäre Suche dafür im Kopf.
Das Problem ist nämlich, dass es sonst bei den tausenden Einträgen unter HKCR deutliche Eingabeverzögerungen gäbe, wenn ich eine sequentielle Suche machen würde.
| BenBE hat folgendes geschrieben : |
| Ein Bug ist aber noch drin: Wenn ich HKCR\CLSID\{000000 eingeb, meint er, es gibt keinen Schlüssel, obwohl es (Beim Öffnen des CLSID-Schlüssels) einen Knoten {00000020-...} gibt. |
Das muss ich mir mal anschauen. Ich habe auch beim Schließen von Knoten (wo ich auch den Registryschlüssel wieder freigebe) schon Schutzverletzungen beobachtet, da bin ich dabei das Problem zu isolieren. Vor ein paar Minuten konnte ich das an einer Stelle reproduzierbar hinbekommen, deshalb werde ich das sicher bald finden.
| Popov hat folgendes geschrieben : |
| Eine Adressenzeile wie beim Explorer wäre nett, d.h. man gibt den Pfad ein und das Programm springt in den richtigen Schlüssel. |
Genau das gibts ja. Einfach in die Statusleiste klicken, einfügen, fertig. Nur angesprungen wird das wie gesagt noch nicht, da ich da erst die getesteten Einzelteile zusammenfügen muss.
Regan - Do 11.06.09 22:08
Ich weiß nicht, ob das schon genannt wurde, aber ich würde gern die Exportfunktion verbessert haben. So etwas in der Art "RegKey-Korb" (ähnlich dem PDF-Korb), man wählt dann alle Einträge aus und erstellt zum Schluss dann eine einzige Datei.
Dann wäre noch eine Art "Aufzeichnen"-Funktion gut. D. h. ich starte ein Programm. Dieses greift auf verschiedene Schlüssel zu. Diese sollte sich das Programm merken und dann zum Beispiel in den RegKey-Korb werfen.
jaenicke - Do 11.06.09 22:30
| Regan hat folgendes geschrieben : |
| Ich weiß nicht, ob das schon genannt wurde, aber ich würde gern die Exportfunktion verbessert haben. So etwas in der Art "RegKey-Korb" (ähnlich dem PDF-Korb), man wählt dann alle Einträge aus und erstellt zum Schluss dann eine einzige Datei. |
Ja, das wird sicher gehen, denn mit dem Formar für Registrydateien muss ich mich ohnehin noch genauer auseinandersetzen.
| Regan hat folgendes geschrieben : |
| Dann wäre noch eine Art "Aufzeichnen"-Funktion gut. |
Sowas gibts ja schon, aber werde ich versuchen einzubauen. So ein diff zwischen verschiedenen Daten, nicht notwendigerweise nur auf die Registry und Änderungen daran bezogen, sondern auch von einer Datei zur Registry und so.
Aber da muss ich die Architektur noch entsprechend entwerfen, dass das nahtlos eingeklinkt werden kann.
jaenicke - Fr 12.06.09 01:24
Ok, also ich fasse einmal das ganze zu einem groben Umriss zusammen:
- Als Datenquelle für den Baum sind die lokale Registry, eine Remoteregistry und eine .reg Datei möglich. Die Features sind unabhängig von der aktuellen Datenquelle.
- Gestartet wird mit normalen Rechten, zum Editieren werden ggf. Adminrechte angefordert.
- Angaben von anderen Registryzweigen, Dateien, Verzeichnissen usw. werden entsprechend behandelt und verlinkt. Zum Ändern gibt es entsprechende Auswahldialoge.
- Auf Wunsch wird der Quelltext für verschiedene Sprachen erzeugt, der zum Auslesen / Schreiben selektierter Angaben notwendig ist. (Nicht für .reg Dateien)
- Benutzerdefinierte Suche (Auswahl der zu durchsuchenden Zweige, genaue Optionen vs. schnelle Optionen, evtl. Regular Expressions)
- Eingabeleiste zum Kopieren und Einfügen inkl. automatischer Vervollständigung
- Favoritenfunktion, evtl. direkt in die Status- und Eingabeleiste integriert
- Kommandozeileninterface
- Drag-and-Drop, verschieben, umbenennen von Schlüsseln
- Sicheres Löschen (es wird eine .reg Datei zum Wiederherstellen, ggf. auch aus der Kommandozeile, erstellt)
- Diff-Funktion: Zweige, auch aus unterschiedlichen Datenquellen, vergleichen. Snapshotmöglichkeit zum späteren Vergleich. Differenzen als .reg-Datei exportierbar.
- Schnelles Wechseln zwischen (speicherbaren) Sets von Schlüsseln
- Überwachung auf Änderungen (evtl. aus Performancegründen in begrenztem Umfang)
- Pluginsystem für die Erweiterung von "intelligentem" Umgang mit speziellen Schlüsseln
Was ich zunächst nicht plane:
- Auslesen einer .dat Datei: Das ist einfach zu viel Arbeit, auch wenn es schön wäre. Wenn ich die Klassenstruktur soweit habe und eine erste Testversion soweit habe, kann da aber gerne jemand dran arbeiten. Die nötigen Informationen habe ich größtenteils gefunden, dabei aber eben gesehen, dass es zunächst zu viel Arbeit für mich wäre. ;-)
| Narses hat folgendes geschrieben : |
| Popov hat folgendes geschrieben : | | Aber was ich bei der normalen Regedit vermisse ist, eine Reg-Dat aus dem Backup zu öffnen, also nicht die gerade benutzte, sondern auch eine externe. |
Das wäre allerdings mal was, da kenne ich bisher auch nur Gurkentools... :? |
Stimmt, für später kann ich mir das auch vorstellen das anzugehen, wenn der Rest funktioniert und sich sonst niemand gefunden hat.
- Überwachung bestimmter Programme auf Änderungen: Das liefe auf ein Hooken der entsprechenden Funktionen in dem Prozess und dem zusammenbasteln der so gewonnenen Infos heraus. Das ist für den Anfang zu viel Arbeit.
Was genauerer Überlegung bedarf:
| BenBE hat folgendes geschrieben : |
| - GUID\CLSID\IID-Linking (Infos über die Keys, Welches Programm, ist das Teil gültig, ..) |
Da ist mir derzeit noch nicht klar, was es da alles gibt. Also welche Funktionalitäten entsprechende Plugins dafür anbieten könnten und dementsprechend wie da eine Schnittstelle aussehen könnte.
Aber ich kann ja erst einmal die Vorgehensweise bei der Schlüsselverlinkung und Datei- und Pfadbehandlungen überdenken und dann darauf zurückkommen.
- Die Möglichkeiten, die ein Skripting und die Kommandozeilenfeatures haben sollten (bei letzterem vor allem in Hinblick auf die integrierten Möglichkeiten der neuen Kommandozeilen von Windows XP und so)
Boldar - Fr 12.06.09 23:40
Ich fände es noch toll, wenn du eine Schnittstelle zum Einbinden deiner Funktionen in anderen Programme anbieten könntest, also dass man sich dass in seine Lieblingsanwendung integrieren kann.
(z.B. dll bereitstellen)
mfg Boldar
jaenicke - Fr 12.06.09 23:50
Das meiste sind ja Funktionen, die direkt mit der Oberfläche zusammenhängen, was meinst du denn so für Funktionen? Also was meinst du wäre denn interessant daran?
Denn ich nutze ja im Grunde auch nur die normalen Registryfunktionen und ich kann mir gerade nicht viel vorstellen, was sinnvoll wäre in eigenen Programmen.
Prinzipiell wäre das sicher denkbar, aber wohl eher sinnvoll in Units als in DLLs (es sei denn es geht auch um andere Sprachen als Delphi).
Boldar - Sa 13.06.09 10:28
units währen sicherich noch optimaler, aber ich habe nun nicht verlangen wollen, dass du den Quelltext offenlegst.
Interessant währe dann zum Beispiel die optimierte Suche, die Autovervollständigung usw.
Ich nutze beispielsweise eine Sidebar mit einem eingabefeld (
hier [
http://www.delphi-forum.de/topic_Sidebar+oNtoP_85587.html] ist eine alte version) und dwürde das dann gerne in dass eingabefeld integrieren.
Allerdings:
Bei sovielen Programme, wie du schon (hier für uns) programmiert hast, könntest du villeicht auch darüber nachdenken, in allen (zukünftigen)(und sinnvollen) eine (von dir) standartisierte Schnittstelle zur Verfügung zu stellen, sei es über dll's,
oder über Kommandozeilenparameter, oder über messages.
mfg Boldar
jaenicke - Sa 13.06.09 10:33
| Boldar hat folgendes geschrieben : |
units währen sicherich noch optimaler, aber ich habe nun nicht verlangen wollen, dass du den Quelltext offenlegst.
[...]
Bei sovielen Programme, wie du schon (hier für uns) programmiert hast, könntest du villeicht auch darüber nachdenken, in allen (zukünftigen)(und sinnvollen) eine (von dir) standartisierte Schnittstelle zur Verfügung zu stellen |
Alle diese Programme sind ja Open Source. Das heißt unter den Bedingungen der GPL, LGPL oder MPL kann jeder den Code direkt verwenden, da braucht es gar keine Schnittstelle. ;-) So kann man den Code auch direkt in die Exe einbinden und muss nicht noch DLLs mitliefern.
Und auch dieses Programm wird wieder Open Source, wie die anderen auch alle. ;-)
Grundsätzlich modularisiere ich ja alles sehr stark (die Eingabevervollständigung ist auch in Klassen gekapselt), so dass sich die meisten Sachen relativ einfach auf eigene Problemstellungen anpassen lassen sollten.
Yogu - Sa 13.06.09 12:09
Hallo,
erstmal: geniale Idee, ich wollte auch mal einen Registry-Editor bauen, bin aber nicht weit gekommen. :) Mach da auf jeden Fall, ich werd's brauche können!
Was ich damals einbauen wollte, war eine Art Papierkorb. Das heißt, dass man Werte oder Keys einfach löschen kann, ohne sich groß Sorgen machen zu müssen - denn sie werden vorher in eine .reg-Datei geschrieben und in einem virtuellen HKEY, dem Papierkorb, angezeigt. Das könnte man parallel zum angesprochenen .reg-Visualizer machen.
Dann nehm bitte noch die Standard-Windows-Symbole für Ordner und Arbeitsplatz, die sehen im Regedit schrecklich aus :evil:
Und du verwendest doch hoffentlich das Virtaual Treeview, oder? Dort kann man nämlich auch mit einem Druck auf die mittlere Maustaste scrollen, das wäre wichtig für mich.
Noch was: Eine Zwischenablage wie in Microsoft Office, so dass man mehrere Werte oder Schlüssel gleichzeitig kopieren / ausschneiden und nachher einfügen kann.
Aber übernimm dich nicht, lieber etwas weniger Features und eine saubere Programmierung, als Käse ;)
Grüße,
Yogu
jaenicke - Sa 13.06.09 12:30
| Yogu hat folgendes geschrieben : |
| Was ich damals einbauen wollte, war eine Art Papierkorb. Das heißt, dass man Werte oder Keys einfach löschen kann, ohne sich groß Sorgen machen zu müssen - denn sie werden vorher in eine .reg-Datei geschrieben und in einem virtuellen HKEY, dem Papierkorb, angezeigt. |
Siehe:
| jaenicke hat folgendes geschrieben : |
| Sicheres Löschen (es wird eine .reg Datei zum Wiederherstellen, ggf. auch aus der Kommandozeile, erstellt) |
:mrgreen:
Das Einklinken dieser Dateien hatte ich nicht als Papierkorb überlegt, die Idee gefällt mir aber. Mal schauen. Es sollte auch nicht viel Arbeit machen denke ich.
| Yogu hat folgendes geschrieben : |
| Dann nehm bitte noch die Standard-Windows-Symbole für Ordner und Arbeitsplatz, die sehen im Regedit schrecklich aus :evil: |
Da habe ich ganz andere vor, die je nach Inhalt anders aussehen sollen. Und die auch gut aussehen. ;-)
| Yogu hat folgendes geschrieben : |
| Und du verwendest doch hoffentlich das Virtaual Treeview, oder? |
Natürlich, was sonst. :mrgreen:
Nur so klappt das überhaupt, dass das so sehr viel schneller als regedit ist. ;-)
| Yogu hat folgendes geschrieben : |
| Noch was: Eine Zwischenablage wie in Microsoft Office, so dass man mehrere Werte oder Schlüssel gleichzeitig kopieren / ausschneiden und nachher einfügen kann. |
Man kann einfach CheckBoxen einblenden und mehrere Schlüssel markieren um diese in eine Registrydatei zu exportieren. Und da ist natürlich auch Kopieren möglich.
| Yogu hat folgendes geschrieben : |
| Aber übernimm dich nicht, lieber etwas weniger Features und eine saubere Programmierung, als Käse ;) |
Ich versuche immer modular und sauber zu programmieren. Zuerst kommt die strukturelle Planung, dann die Grundimplementierung, und dann der Reihe nach die Features.
Heißt: Das Projekt wird mit der Zeit wachsen, ich werde bestimmt nicht alle Features irgendwie hinschludern und gleichzeitig hinklatschen. ;-)
Yogu - Sa 13.06.09 12:54
| jaenicke hat folgendes geschrieben : |
| Yogu hat folgendes geschrieben : | | Was ich damals einbauen wollte, war eine Art Papierkorb. Das heißt, dass man Werte oder Keys einfach löschen kann, ohne sich groß Sorgen machen zu müssen - denn sie werden vorher in eine .reg-Datei geschrieben und in einem virtuellen HKEY, dem Papierkorb, angezeigt. |
Siehe: | jaenicke hat folgendes geschrieben : | | Sicheres Löschen (es wird eine .reg Datei zum Wiederherstellen, ggf. auch aus der Kommandozeile, erstellt) |
:mrgreen:
Das Einklinken dieser Dateien hatte ich nicht als Papierkorb überlegt, die Idee gefällt mir aber. Mal schauen. Es sollte auch nicht viel Arbeit machen denke ich. |
Ok, ich hab jetzt nicht die kompletten 2 Seiten durchgelesen, und deinen zusammenfassenden Beitrag hab ich erst danach gesehen.
| jaenicke hat folgendes geschrieben : |
| Yogu hat folgendes geschrieben : | | Dann nehm bitte noch die Standard-Windows-Symbole für Ordner und Arbeitsplatz, die sehen im Regedit schrecklich aus :evil: |
Da habe ich ganz andere vor, die je nach Inhalt anders aussehen sollen. Und die auch gut aussehen. ;-) |
Genehmigt :mrgreen:
---
Moderiert von Narses: Beiträge zusammengefasst---
Ich hoffe mal, dass das noch nicht geschrieben wurde, aber eine schnelle Suche im Topic hat keine Treffer ergeben.
Schön wäre ein Eingabefeld (kann auch die Adressleiste sein), in das man etwas wie "STRING name=value" eingeben kann. Dieser Befehl wird dann geparst und fügt in diesem Fall einen String-Wert mit dem Namen "name" und dem Wert "value" ein. Existiert er bereits, wird er überschrieben (ggf. mit Bestätigung). "DELETE name" löscht den Wert bzw. Schlüssel, "ADD key" erstellt den Key "key" usw. Dann noch eine Tastenkombination wie im FF die F6 zum Springen in die Adressleiste, und ich bin überglücklich :D
Sowas in der Art gibt's übrigens schon von haus aus, wie ich neulich irgendwo gelesen habe. Im Ausführen-Fenster kann man einfach "REG DELETE HKCU\bla" eingeben und in einer Eingabeaufforderung bestätigen. Ist etwas umständlich, aber in deinem Programm könnte man das besser implementieren.
Yogu - So 14.06.09 01:10
| BenBE hat folgendes geschrieben : |
Weil Nested Full-Quotes ja so viel Spaß machen:
| jaenicke hat folgendes geschrieben : | Ich glaube sowas meinte Benny hier: :mrgreen: | BenBE hat folgendes geschrieben : | | jaenicke hat folgendes geschrieben : | | BenBE hat folgendes geschrieben : | | - Shell-Like-Interface zum switchen zwischen Keys, Werte ändern |
Da dachte ich z.B. u.a. an Tabs um gleichzeitig mehrere offen haben zu können. |
Meinte das eher bash-like, so dass ich z.B. hingehen kann und "RegSH-Scripts bauen kann, die zum Automatisieren bestimmter Aufgaben genutzt werden können. |
|
Ja, sowas meinte ich, nur halt nicht allein auf einzelne Befehle beschränkt, sondern wenn gewünscht eine minimale Skriptsprache, mit der man eine Art "Makros" schreiben könnte. |
Ich glaub, irgendwann streikt die Forensoftwaren :mrgreen:
Die Scriptsprache sollte aber nicht zu kompliziert werden. Ich will schon noch meine einfachen "STRING name=value"'s eingeben können, und auf die 5 geschweiften Klammern und den abschließenden Semikolon verzichten. Ich denke mal, das Bearbeiten von Werten und Schlüsseln dürfte die Hauptaufgabe eines Registry-Editors sein - nicht eine Implementation eines kompletten Scripts. ;)
jaenicke - So 14.06.09 01:49
| Yogu hat folgendes geschrieben : |
| Die Scriptsprache sollte aber nicht zu kompliziert werden. Ich will schon noch meine einfachen "STRING name=value"'s eingeben können, und auf die 5 geschweiften Klammern und den abschließenden Semikolon verzichten. Ich denke mal, das Bearbeiten von Werten und Schlüsseln dürfte die Hauptaufgabe eines Registry-Editors sein - nicht eine Implementation eines kompletten Scripts. ;) |
Ja, da werde ich mir etwas einfallen lassen. Aber sowohl Plugins als auch Skripte stehen natürlich relativ weit hinten auf der Featureliste. Wobei deren Implementierung dann einfach sein sollte, denn die Funktionalitäten sind ja alle gekapselt und so leicht erreichbar. So sollten also auch kleine Schleifen möglich sein.
Ich stelle mir das ca. so vor:
Quelltext
1:
2:
3:
4:
| open hklm\software\microsoft
for i := 0 to 4 step 2 do
regsz Testwert=Mein (i)ter Wert
end |
Oder um im Editor einen Wert für den Benutzer zu markieren:
Quelltext
1:
2:
| navigate hklm\software\microsoft
mark Name |
Oder:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| connect c:\test.reg
connect 192.168.1.100
compare hklm\software\borland
with hkcu\software\borland
exportdiff c:\test.reg
showdiff |
Sowas eben. Immer nur ein Befehl und ggf. ein Parameter in jeder Zeile (bis auf die Schleife halt), damit man da nicht noch mit Anführungszeichen und sowas arbeiten muss, keine Klammern oder sowas.
Ich werde im Projekt selbst dann auch statt der TListView rechts eine TVirtualStringTree nehmen, dann kann ich leichte Farbnuancen benutzen um Informationen zu visualisieren (z.B. grün untermalt --> Datei existiert, rot --> existiert nicht). Und auch um die Buttons und sowas für Verlinkungen zu zeichnen und so ist die Komponente besser.
Martok - So 14.06.09 02:29
Wie wärs mit SQL? Ich mein, das würde eigentlich gut passen.
SQL-Anweisung
1:
2:
3:
| CONNECT TO localhost;
USE HKLM;
SHOW \software\what\ever WHERE KEY LIKE "%filter%"; |
SQL-Anweisung
1:
2:
3:
| COMPARE \software ROOT HKLM FROM localhost
TO \software ROOT HKLM FROM sik.reg
EXPORT TO diff.reg |
Ich find das cool. ;)
jaenicke - So 14.06.09 02:38
Das würde aber mehr Schreibarbeit und gleichzeitig einen "echten" Parser bzw. zumindest etwas in der Richtung bedeuten. Der Vorteil von dem was ich geschrieben habe ist ja gerade, dass es sowohl wenig zu schreiben gibt als auch leicht zu interpretieren ist. ;-)
Aber da ist ja noch Zeit dafür sich da etwas auszudenken, insbesondere wenn klarer wird was Plugins und Userskripte alles können sollen.
Ach ja: Ich habe ja nichts dagegen, wenn du dann deine eigene Skriptsprache entwirfst inkl. passendem Parser, wenn dir die eingebaute dann nicht so gefallen sollte. :mrgreen:
BenBE - So 14.06.09 02:42
| jaenicke hat folgendes geschrieben : |
Das würde aber mehr Schreibarbeit und gleichzeitig einen "echten" Parser bzw. zumindest etwas in der Richtung bedeuten. Der Vorteil von dem was ich geschrieben habe ist ja gerade, dass es sowohl wenig zu schreiben gibt als auch leicht zu interpretieren ist. ;-)
Aber da ist ja noch Zeit dafür sich da etwas auszudenken, insbesondere wenn klarer wird was Plugins und Userskripte alles können sollen. |
Nehmen wir doch einfach eine allgemeine Schnittstelle für Skriptsprachen mit rein :mrgreen:
| jaenicke hat folgendes geschrieben : |
| Ach ja: Ich habe ja nichts dagegen, wenn du dann deine eigene Skriptsprache entwirfst inkl. passendem Parser, wenn dir die eingebaute dann nicht so gefallen sollte. :mrgreen: |
Was hältst Du von LLVM ;-)
jaenicke - So 14.06.09 02:59
| BenBE hat folgendes geschrieben : |
| Nehmen wir doch einfach eine allgemeine Schnittstelle für Skriptsprachen mit rein :mrgreen: |
Wird es ja geben: Die integrierte Skriptsprache. :mrgreen:
Man muss es halt übersetzen. :mrgreen:
| BenBE hat folgendes geschrieben : |
| Was hältst Du von LLVM ;-) |
Sicher, das würde genau passen. :rofl: ;-)
Ja, ich werde in ein paar Tagen mal eine erste funktionsfähige Version unter Open Source Projekte einstellen. Bisher ist der Quelltext dafür noch... ungeeignet, sagen wir mal so. ;-)
jaenicke - Fr 19.06.09 06:44
Ich habe jetzt einmal eine Vorschauversion veröffentlicht. Die kann noch nicht viel, manche bereits separat getesteten Teile sind auch noch nicht eingebaut.
Vom Prinzip her klappt es aber sehr gut. Es gibt keine spürbaren Verzögerungen, auch nicht wenn ich die über 10.000 Zweige von HKEY_CLASSES_ROOT aufklappe. Auch das Einlesen des gesamten Zweigs HKEY_CURRENT_USER\Software aus einer .reg Datei (20,5 MiB, 320.000 Zeilen) dauert nur Sekundenbruchteile.
http://www.delphi-forum.de/viewtopic.php?p=567719
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!