[Born-IT] Microsoft setzt den CCleaner-Domain auf die Black-List

[English]Noch eine kurze Information für CCleaner-Nutzer (interessiert sicherlich einige meiner Blog-Leser/innen). Microsoft hat die komplette CCleaner-Domain auf eine interne Black-List gesetzt – sprich: Auch das Programm CCleaner für Windows von Piriform steht jetzt ‘als unerwünscht’ auf dem Index. Die Info →

Weiterlesen


Autor: Günter Born

 

[Sp1xx]

Speccy und Recuva hab ich tatsächlich schon ein paar Mal genutzt, war und ist ganz hilfreich.
CCleaner ist in meinen Augen nichts mehr als Snakeoil mit dem man sich mit Pech noch die registry zerschießt.
"Reparieren", so wie es manche unbedarfte Anwender erwarten, tut das ganze schonmal gar nichts.

Wenn es um die Entfernung von Temp Dateien geht würde ich da eher Bleachbit verwenden.

Kann ruhig geblockt bleiben..

 

[musv]

CCleaner ist in meinen Augen nichts mehr als Snakeoil mit dem man sich mit Pech noch die registry zerschießt.
"Reparieren", so wie es manche unbedarfte Anwender erwarten, tut das ganze schonmal gar nichts.

CCleaner hatte ich zu WinXP-Zeiten immer verwendet. Ich fand das Teil damals ziemlich brauchbar. Damals war der Speicher auch noch knapp. Und Windows hat mit Bordmitteln ebenselbigen nur sehr widerwillig oder gar nicht wieder rausgerückt.

Und ja, die Registry konnte man sich damit leicht zerschießen. Allerdings ist das kranke Konstrukt "Registry" sowieso eine der schlimmsten Fehlentwicklungen in der Windows-Geschichte. Das Ding gehört abgeschafft.

 

[drfuture]

@musv: warum? Gegenvorschlag?
Ich finde config / ini / xml / json Files schlimmer.
Grundsätzlich geht man bei allem dazu über Datenbanken zu nutzen für höhere Geschwindigkeit, durchsuchbarkeit und Integrität (siehe selbst Bookmarks egal welchen Browsers).
Da die registry nichts anderes ist, wo ist das schlechte und was währe dein Wunsch?

Ccleaner ist jedenfalls unnötig und macht wenn dann eher schaden. Wobei es von den ganzen cleanern noch zu den besten gehört.

Edit: das lustige ist ja das der Beitrag von Born mal wieder mehr Schlagzeile als Inhalt ist. Die Links zu ccleaner sind nur im den ms-community Foren zensiert worden.

 

[musv]

@musv: warum? Gegenvorschlag?
Ich finde config / ini / xml / json Files schlimmer.

Tja, damit wäre die Diskussion schon wieder beendet, da ergebnislos.

 

[drfuture]

Nunja wenn du config Datein besser findest kannst du z.b. Schreiben warum?

 

[musv]

Ich finde Config-Dateien wesentlich übersichtlicher. Außerdem kann man nicht mehr benötigte Config-Dateien problemlos löschen, ohne das ganze System zu zerschießen.

Deswegen mag ich z.B. auch bei Gnome die GSettings nicht. Das geht nämlich auch in Richtung Registry.

 

[darksider3]

@drfuture: Warum die Registry schon technisch Kacke ist:
Sie ist ein eigenes Dateisystem. Sie hat Inodes, Referenzen zu internen Dateien, extended attributes etc pp, aber ohne sie als tatsächliches Dateisystem einzubinden; Das lustige Resultat ist, eine riesige Datei zu haben, die man mit ext3 vergleichen kann(in einem loopback mount), allerdings ohne Zugriffsschutzmechanismen auf TATSÄCHLICHER Dateisystemebene.

Ihr Format ist im Prinzip ein C-Struct-Dump: 32bit, Endian-dependant(LULZ) aus einer Heap-Map, was weitere lustige Aspekte mit sich bringt: Man kann Keys erstellen, die im Register so nicht in der Liste auftauchen, auf die aber zugegriffen werden kann, indem man ihre Namen direkt referenziert. Das wurde später dann übrigens zu einem Pseudofeature. Außerdem erzeugt das weitere Typspezifika, z.B. Wordspecific(Ja, ASSEMBLER-WORDS), und muss für Backward-Compatiblity mit einem Toolset kompiliert werden, dass den Stand 1992 entspricht.

Durch die fehlende tatsächliche Dateisystemeinbindung hat man sich wohl Gedacht, man könnte einfach Konsistenzchecks weglassen; Resultiert nur eben darin, dass man einfach Blocks in die Registry schieben kann, die einfach ignoriert(Read: Überlesen) werden. die Toolsuite ignoriert sogar Blocks, die nicht in korrekter Alphabetischer Form abgespeichert wurden, und ignoriert fehlerhafte Fields. Sie hat dadurch unreachable-blocks, wie ein Dateisystem, fehlerhafte Inodes, wie ein Dateisystem, aber keinen Weg, um das zu "reparieren", weil das einfach nicht implementiert wurde. Außerdem sind Memory-Dumps in Fields nicht unüblich, da man ausversehen die Einträge nicht korrekt ausgenullt hat.

Es ist schlecht im Umwandeln von Encodings, es hat sogar keine spezifische Dokumentation dazu, wie man Sachen zu escapen hat. Im UTF-16 scheint ein normaler Backslash zu reichen, in einem anderen müssen es plötzlich zwei sein.

Wenn man sich diese PDF ansieht bemerkt man im übrigen auch, wie "durchdacht" und "gut gewartet" sie ist. Es ist nicht unüblich, mehrere überlappende, exakt gleiche, Informationen in Unterschiedlichen "Ordnern" zu entdecken, an absolut zufälligen Orten.

Es ist nicht häufig genug zu sagen: Die Registry ist keine Datenbank. Sie wäre es vielleicht gerne, aber sie ist, defacto, ein Dateisystem. Der Unterschied hier ist darin begründet, dass sie kaum Datenbanktypische Funktionen enthält, dazu aber relevante für Dateisysteme. z.B. gibt es keine indices, die absolut hilfreich sein könnten, damit man nicht wie aktuell die Registry von oben nach unten nach etwas durchsuchen müsste, wenn man etwas sucht.

Security: Habe ich oben bereits mehrfach angesprochen, aber auch das ist sehr wichtig: Es gibt ein Crapload an Software, die das Format lesen und manipulieren können. Darunter z.B. die Hivexsh. Man kann damit soviel "schönen" "Spaß" haben... Man sieht plötzlich ganz viele Random-Entrys, an vollkommen zufälligen Orten, mit absolut wirrem Inhalt, häufig, wie gesagt, Memory-Dumps.

Was sie allerdings besser gemacht haben seit XP, ist endlich ein Userverzeichnis für Konfiguration ala AppData/LocalLow zu haben. Nur leider will selbst Windows 10 noch immer nicht wirklich das benutzen, stattdessen bleiben wir lieber bei der Möchtegern-DB-Die-Aber-in-Fakt-Ein-Dateisystem-Ohne-Dateisystem-Checks-ist.

(Großteil der Dinge hier aus https://www.reddit.com/r/programming/comments/b3mr2/why_the_windows_registry_sucks_technically/ genommen, hatte ich vor ein paar Monaten schon mal so ähnlich für einen anderen Registry-Jünger geschrieben)

---
keines dieser Probleme hat Linux/Unix in dem Falle. Das einzige, was hier inkonsistenzen hervorrufen können, sind die jeweiligen Dateiformate.

 

[thom53281]

Ich möchte zu den Vorteilen von Config-Dateien noch einen weiteren Punkt ergänzen. Ab und an möchte/muss man auch mal was am System modifizieren. Bei Windows geschieht das oft über eine manuelle Änderung in der Registry per regedit, unter unixoiden Systemen nimmt man eine Änderung an einer Config-Datei mit einem Editor vor. Was passiert nun, wenn diese Änderung problematisch war und das System plötzlich nicht mehr bootet?

Bei einer Config-Datei: Live-CD/USB booten, HDD mounten, Änderung mit Editor rückgängig machen. Hat man irgendein halbwegs passendes Live-Medium zur Hand, sind das keine fünf Minuten, die man braucht.


Unter Windows: Boot im Abgesicherten Modus um an regedit zu kommen - Hm, nö, bootet auch nicht...

Ok, dann spielen wir ein Backup der Registry zurück.

Ab der Windows 10 1803 muss die Sicherung der Registry erst aktiviert werden. Diese Funktion hat Microsoft deaktiviert, um Speicherplatz zu sparen.

Ahm...

Na gut, dann machen wir eine Systemwiederherstellung. Ohje, ist der Wiederherstellungspunkt alt. Na dann müssen wir uns wieder mal wieder auf Drittanbieter-Programme verlassen oder der automatischen Systemreparatur eine Chance geben.


Ich will jetzt nicht behaupten, dass es keine Möglichkeiten gibt, die Registry wieder zu fixen. Ganze Bücher könnte man zu dem Thema füllen. Mit fünf Minuten Arbeit ist das fast nie getan und andere Kollateralschäden beim Einspielen von Backups oder der automatischen Reparatur (was auch immer die genau macht), muss man billigend in Kauf nehmen, wenn man vor der Änderung kein Backup angelegt hat. Noch schlimmer wird es dann, wenn irgendwelche Tools Änderungen an der Registry vornehmen und man das gar nicht manuell rückgängig machen kann, weil man die entsprechenden Registry-Keys nicht kennt, die verändert wurden. Unter Linux ist so ein amoklaufendes Tool zwar ebenfalls fatal, aber im schlimmsten Fall ersetzt man die betroffenen Config-Dateien durch eine Vanilla-Version vom Distributor und fängt wieder von vorne an. Nicht dass das besonders viel Spaß macht, aber man muss zumindest nur bei einem Teil von vorne anfangen und nicht mit dem ganzen System.

 

[musv]

Unter Linux ist so ein amoklaufendes Tool zwar ebenfalls fatal, aber im schlimmsten Fall ersetzt man die betroffenen Config-Dateien durch eine Vanilla-Version vom Distributor und fängt wieder von vorne an.

Wenn ich irgendwas kritisches am etc-Verzeichnis bastel, dann vergitte ich das vorher. Damit kannst du die Änderungen sehr leicht nachvollziehen und auch wieder rückgängig machen.

Ganz hübsch sind auch BTRFS-Snapshots. Wenn man BTRFS als Dateisystem nutzt, legt man einfach vor kritischen Änderungen einen Snapshot an. Man kann darüber dann ziemlich einfach sämtliche Änderungen auf Dateisystemebene vergleichen und auch wieder rückgängig machen.

 

[thom53281]

Ja, wenn man sich ein wenig auskennt, macht man vor solchen Aktionen natürlich vorher ein Backup. Das kann ich aber mit der Registry auch genauso machen, daher ist das in meinen Augen kein Vorteil/Nachteil.

Geht mir da eher um die Semi-Profis, die dann halt meinen, dass sie wissen, was sie tun. Und das dann eben ohne Sicherung machen. Oder auch, wenn mal ein Programm unverhofft Amok läuft, oder irgendwie sowas. Unter Linux kann man sowas wenigstens dann noch halbwegs nachvollziehen, spätestens dann wenn man einen Diff sämtlicher vermeintlich betroffener Configs mit den Originalversionen durchführt. Unter Windows mit der Registry hat man dann eher keine Chance mehr.

 

[drfuture]

Unter Windows: Boot im Abgesicherten Modus um an regedit zu kommen - Hm, nö, bootet auch nicht...

Wenn Windows nicht bootet landet es (jedenfalls bei Win10, bei win8 bin ich mir nicht zu 100% sicher) in der Revocery-Konsole insofern man diese nicht absichtlich abgeschaltet hat.
Dort lässt sich ohne größere Umstände über die commandline ein regkey ändern / löschen / erstellen.

Ganz davon abgesehen das eine Änderung an der Registry schon länger nicht mehr so einfach zu einem stehenden System führen, bei defekten Treibern wird inzwischen z.B. auch automatisch eine Reparatur ausgeführt. Wenn du mal einen Fehler hast der das System nicht mehr starten lässt würde mich das interessieren (ist ehrlich gemeint - nur an besonderen Fehlern lernt man was ;D)

...Drittanbieter-Programme verlassen...

Es gibt noch das DART - https://docs.microsoft.com/de-de/microsoft-desktop-optimization-pack/dart-v10/ - aber das ist zugegeben für den normalen Verbraucher nicht so leicht zu bekommen.

... im schlimmsten Fall ersetzt man die betroffenen Config-Dateien durch eine Vanilla-Version vom Distributor und fängt wieder von vorne an. Nicht dass das besonders viel Spaß macht, aber man muss zumindest nur bei einem Teil von vorne anfangen und nicht mit dem ganzen System.

Das löschen des Reg-Keys erzeugt mit ziemlich hoher Wahrscheinlichkeit beim nächsten Start des OS oder der Anwendung den Default-Wert.
zu 100% funktioniert das bei Linux ebenso nicht "so einfach" - vor allem bei über Jahre Migrierten Configs muss man genau hinschauen wenn man dann meist ja die aktuelle default nimmt die so manches anders macht.

Aber eigentlich wollte / sollte man das nicht mit Linux vergleichen da eine Diskussion Linux VS Windows Bodenlos ist ;D - Und vor allem nutze ich Linux ja ebenso regelmäßig - mir macht aber zum Teil das Suchen der richtigen Config dann keinen Spaß bzw. halten sich sehr viele zumindest an /etc/ aber nicht alle und die Struktur ist auch je nach Anwendung unterschiedlich - bis hin zum Syntax was es für mich nicht gerade Intuitiv macht.
Klar muss ich eh nachlesen was ich einstellen möchte - dennoch schleichen sich dann mal Flüchtigkeitsfehler ein ob ich etwas in '' oder in "" machen muss oder ein ; am Ende kommt oder nicht.

Ich finde mich in der Hirarchischen Struktur der Reg. halt irgendwie besser zurecht.

@Darksider3 - Thx für den Ausführlichen Beitrag - DB war durchaus etwas Polemisch - ich war immer der Meinung die Registry basiert auf einer LDAP-Struktur? - Muss mir die Verlinkten Infos mal genau durchlesen - vor allem da ich nen Tool für die Registry entwickeln will und in der Tat ist das ganze nicht sonderlich toll dokumentiert somit könnte mir das helfen

 

[thom53281]

Ich finde mich in der Hirarchischen Struktur der Reg. halt irgendwie besser zurecht.

Das beruht auf Gegenseitigkeit, ich komm mit dem Linux-Way viel besser klar. Vermutlich liegt das daran, dass ich seit Jahren eigentlich fast nichts anderes mehr nutze. Bei der Windows-Registry dagegen denke ich mir immer: