nicht angemeldet dedlfix
Der Martin
dedlfix
Der Martin
O'Brien
Der Martin
O'Brien
Der Martin
dedlfix
Ich habe mehrere Pakete eine Software, die für 3 Monate jeweils ein Update inklusive hat. Nach den drei MOnaten wollte ich sie deinstallieren und eine Neue Version mit einer neuen Seriennnummer eingeben. Doch jetzt meldet sie das dies nicht gehe. Ich habe also immer noch irgendwelche Dateien auf dem Server. Wie bekomme ich die weg, bzw. wie finde ich diese, so das ich meine Software wieder installieren kann.
Hi!
Ich habe [von einer Installation] immer noch irgendwelche Dateien auf dem Server. Wie bekomme ich die weg, bzw. wie finde ich diese, so das ich meine Software wieder installieren kann.
Mit einer Neuinstallation des Systems. Ansonsten müsstest du vor der Installation wissen, was alles da ist und nach der Installation (gegebenenfalls erst nach dem ersten Programmstart) nachschauen, was hinzugekommen ist. Dann weißt du, was du entfernen musst. Oder du weißt es aus einer anderen Quelle, die genau diese Analyse schon einmal gemacht hat. Und noch ein Weg: Du weißt, was in dein System typischerweise gehört und was nicht und entfernst das was du dieser Installation zuordnen kannst. Dieser Weg ist (unter Windows) aber praktisch unmöglich, weil sich die fragliche Information auch in den Tiefen der Registry befinden kann, und die kennt mit Sicherheit keiner auswendig.
Lo!
Hallo,
Und noch ein Weg: Du weißt, was in dein System typischerweise gehört und was nicht und entfernst das was du dieser Installation zuordnen kannst. Dieser Weg ist (unter Windows) aber praktisch unmöglich
nein, keineswegs. Zumindest bis einschließlich XP traue ich mir zu, diese Unterscheidung zu machen.
weil sich die fragliche Information auch in den Tiefen der Registry befinden kann, und die kennt mit Sicherheit keiner auswendig.
Nein, sicher nicht auswendig. Aber sie ist -auch wenn es für Außenstehende oft nicht so wirkt- ziemlich systematisch organisiert. So lässt sich meist recht einfach zuordnen, was zum System gehört und was nicht.
Windows und viele Windows-Anwendungen machen es "uns" nur insofern schwer, als bei der Installation von Programmen sehr oft unnötigerweise DLLs und Anwendungs-Komponenten ins Systemverzeichnis kopiert und auch noch quasi-statisch in der Systemkonfiguration verankert werden.
Deswegen lasse ich bei einer Softwareinstallation Änderungen an der Registry und in den Systemverzeichnissen protokollieren, und verschiebe hinterher die Komponenten, die unnötigerweise im Systemverzeichnis gelandet sind, zurück ins Verzeichnis der Anwendung, wo sie hingehören. Natürlich mit Korrektur eventueller Registry-Einträge, die darauf verweisen, oder ich nehme Registry-Einträge komplett wieder raus ("unregister"), wenn sie versuchen, Anwendungskomponenten zu global verfügbaren Objekten zu machen.
Damit habe ich zwar mehr Aufwand, aber dafür weniger Äger mit Versionskonflikten bei verbreiteten Bibliotheken, weil jedes Programm mit der Version der Bibliothek arbeitet, die es selbst "mitgebracht" hat. Außerdem ist die Deinstallation später wesentlich einfacher und sauberer.
So long,
Martin
Hi!
Und noch ein Weg: Du weißt, was in dein System typischerweise gehört und was nicht und entfernst das was du dieser Installation zuordnen kannst. Dieser Weg ist (unter Windows) aber praktisch unmöglich
nein, keineswegs. Zumindest bis einschließlich XP traue ich mir zu, diese Unterscheidung zu machen.
Das sehe ich anders, wenn ich mir nur mal das Datengrab CLSID ansehe. Was sich da alles wunderbar verstecken lässt, da kommst du im Leben nicht drauf, weil nicht ein Bit auf den Konsumenten verweist, wenn nur eine GUID und ein paar kryptische Byte dahinterstecken. Da brauchst du nach meiner Erfahrung Werkzeuge, die Registry-Zugriffe überwachen, um die Kandidaten zu finden.
weil sich die fragliche Information auch in den Tiefen der Registry befinden kann, und die kennt mit Sicherheit keiner auswendig.
Nein, sicher nicht auswendig. Aber sie ist -auch wenn es für Außenstehende oft nicht so wirkt- ziemlich systematisch organisiert. So lässt sich meist recht einfach zuordnen, was zum System gehört und was nicht.
Ja, in den Klartext-Teilen. Aber dann geht das Gesuche los, wenn sie auf GUIDs verweisen, die unter Umständen nur eine weitere GUID beinhalten.
Windows und viele Windows-Anwendungen machen es "uns" nur insofern schwer, als bei der Installation von Programmen sehr oft unnötigerweise DLLs und Anwendungs-Komponenten ins Systemverzeichnis kopiert und auch noch quasi-statisch in der Systemkonfiguration verankert werden.
Das sind die offensichtlichen Dinge (offensichtlich, wenn man sich etwas auskennt). Aber Programmierer verstecken auch gern mal ein paar Informationen, wenn sie nicht wollen, dass man Software über die zugestandene Testphase hinaus weiterbetreiben möchte. (Versuch mal, den ABBYY Finereader 9.0 über die Zeit zu verwenden (mittlerweile gibts die 10, aber die wird sicher nicht "freundlicher" diesbezüglich sein).)
Lo!
Hi,
Aber Programmierer verstecken auch gern mal ein paar Informationen, wenn sie nicht wollen, dass man Software über die zugestandene Testphase hinaus weiterbetreiben möchte.
Und genau das scheint die Fragerin hier ja vorzuhaben.
MfG ChrisB
Tach,
Zumindest bis einschließlich XP traue ich mir zu, diese Unterscheidung zu machen.
Das sehe ich anders, wenn ich mir nur mal das Datengrab CLSID ansehe.
naja, jede CLSID verweist letztendlich auf ein bestimmtes Programmmodul. Eventuell muss man über zwei, drei Zwischenschritte gehen, um das genau herauszufinden. Dann weiß man zwar noch nicht unbedingt, für welche Funktion dieser Schlüssel zuständig ist, aber man kann immerhin die DLL identifizieren, in der diese Funktion verpackt ist, und so auch das zugehörige Programmpaket.
Nein, sicher nicht auswendig. Aber sie ist -auch wenn es für Außenstehende oft nicht so wirkt- ziemlich systematisch organisiert. So lässt sich meist recht einfach zuordnen, was zum System gehört und was nicht.
Ja, in den Klartext-Teilen. Aber dann geht das Gesuche los, wenn sie auf GUIDs verweisen, die unter Umständen nur eine weitere GUID beinhalten.
Ich habe nichts über den nötigen Aufwand gesagt. ;-)
Aber Programmierer verstecken auch gern mal ein paar Informationen, wenn sie nicht wollen, dass man Software über die zugestandene Testphase hinaus weiterbetreiben möchte.
Stimmt. Solche versteckten Informationen findet man tatsächlich nicht mit irgendeiner Systematik, sondern nur, wenn man entweder die Veränderungen während der Installation überwachen lässt, oder die Registry-Zugriffe des Programms, während es läuft. Dafür ist regmon ein sehr hilfreiches Tool.
Versuch mal, den ABBYY Finereader 9.0 über die Zeit zu verwenden
Kenn ich nicht. Aber ich entsinne mich, dass ein Bekannter mal mit einer Paintshop-Pro-Version dasselbe Problem hatte.
Ciao,
Martin
Hi!
Versuch mal, den ABBYY Finereader 9.0 über die Zeit zu verwenden
Kenn ich nicht. Aber ich entsinne mich, dass ein Bekannter mal mit einer Paintshop-Pro-Version dasselbe Problem hatte.
Finereader ist eine OCR-Software. Wenn man sie nur kurzzeitig braucht, lohnt sich die Anschaffung von Spezialsoftware meist nicht. Mit Software as a Service sie bei Bedarf zu nutzen und nur für den benötigten Zeitraum zu bezahlen, wäre eine Lösung, die aber noch nicht sehr verbreitet ist. Aber PaintShop Pro in der 7er Version bei mir läuft, und läuft, und läuft, eine CLSID löschen, und läuft, ...
Lo!
FineReader läuft bei mir in Version 4.0 unter XPPro. Kam als Beilage zum Scanner - ist schon viele Jahre her -, aber genügt mir völlig.
Beste Grüße,
gelu
Hi!
FineReader läuft bei mir in Version 4.0 unter XPPro. Kam als Beilage zum Scanner - ist schon viele Jahre her -, aber genügt mir völlig.
Ja, aber manchmal sind die Ansprüche doch höher als die kostenlosen Dreingaben bieten (unterstelle ich jetzt mal). Beispielsweise chinesische Schrift aus PDFs scannen, wenn Text kopieren nicht klappt, weil nichts halbes und nichts ganzes dabei raus kommt. Außerdem hat es mein Scanner nicht als Beilage gehabt. (Weiß gar nicht mehr, ob da überhaupt was dabei war.)
Lo!
Hi Martin,
Deswegen lasse ich bei einer Softwareinstallation Änderungen an der Registry und in den Systemverzeichnissen protokollieren, und verschiebe hinterher die Komponenten, die unnötigerweise im Systemverzeichnis gelandet sind, zurück ins Verzeichnis der Anwendung, wo sie hingehören. Natürlich mit Korrektur eventueller Registry-Einträge, die darauf verweisen, oder ich nehme Registry-Einträge komplett wieder raus ("unregister"), wenn sie versuchen, Anwendungskomponenten zu global verfügbaren Objekten zu machen.
machst du das von Hand oder mit entsprechenden Tools? Von Hand stelle ich mir das _sehr_ aufwändig vor.
Um mir das System nicht zu versauen, mache ich es so, dass ich neue Software auf meinem Heim-PC teste, bevor ich sie auf dem Produktiv-System-PC im Büro installiere (und hoffentlich nie wieder deinstallieren muss).
Schönen Sonntag noch!
O'Brien
Hallo,
Deswegen lasse ich bei einer Softwareinstallation Änderungen an der Registry und in den Systemverzeichnissen protokollieren, und verschiebe hinterher die Komponenten, die unnötigerweise im Systemverzeichnis gelandet sind, zurück ins Verzeichnis der Anwendung, wo sie hingehören. Natürlich mit Korrektur eventueller Registry-Einträge, die darauf verweisen, oder ich nehme Registry-Einträge komplett wieder raus ("unregister"), wenn sie versuchen, Anwendungskomponenten zu global verfügbaren Objekten zu machen.
machst du das von Hand oder mit entsprechenden Tools? Von Hand stelle ich mir das _sehr_ aufwändig vor.
teils, teils. Das Überwachen während der Installation lasse ich von einem praktischen Tool erledigen. Das erzeugt mir hinterher ein Protokoll aller Änderungen in der Registry, sowie auf Dateiebene in beliebigen frei konfigurierbaren Verzeichnissen.
Dieses Protokoll gehe ich hinterher durch; die Nachbehandlung der Installation erfolgt dann aber von Hand.
Um mir das System nicht zu versauen, mache ich es so, dass ich neue Software auf meinem Heim-PC teste, bevor ich sie auf dem Produktiv-System-PC im Büro installiere (und hoffentlich nie wieder deinstallieren muss).
Völlig neue, mir unbakannte Software teste ich natürlich auch erstmal ein paar Tage auf einem isolierten System (oder in einer VM). Das ist aber unabhängig von der Überwachung und Nachbehandlung einer Installation.
Ciao,
Martin
Hi Martin,
machst du das von Hand oder mit entsprechenden Tools? Von Hand stelle ich mir das _sehr_ aufwändig vor.
teils, teils. Das Überwachen während der Installation lasse ich von einem praktischen Tool erledigen. Das erzeugt mir hinterher ein Protokoll aller Änderungen in der Registry, sowie auf Dateiebene in beliebigen frei konfigurierbaren Verzeichnissen.
das klingt interessant. Der nächste freie Abend ist hiermit verplant ;)
Dieses Protokoll gehe ich hinterher durch; die Nachbehandlung der Installation erfolgt dann aber von Hand.
Ohne gute Kenntnisse der Windows-Interna geht's denn aber nicht, oder?
Völlig neue, mir unbakannte Software teste ich natürlich auch erstmal ein paar Tage auf einem isolierten System (oder in einer VM).
VM ist ein gutes Stichwort. Oft gelesen, nie benutzt. Sollte ich vielleicht mal.
Das ist aber unabhängig von der Überwachung und Nachbehandlung einer Installation.
Ja, schon klar. Nur da ich bisher keine Überwachung/Nachbehandlung vornehme, ist das bei mir derzeit die einzige Maßnahme, das System einigermaßen sauber zu halten.
Schönen Sonntag noch!
O'Brien
Hallo,
teils, teils. Das Überwachen während der Installation lasse ich von einem praktischen Tool erledigen.
das klingt interessant. Der nächste freie Abend ist hiermit verplant ;)
und das Schöne dabei: InCtrl5 hat selbst keine Installationsprozedur nötig, die man wieder auf Treu und Glauben machen müsste - es besteht im Wesentlichen aus nur einer EXE-Datei, speichert seine Konfiguration in einer ini-Datei im Programmverzeichnis und hinterlässt selbst keine Pinkelmarken (ich hab jedenfalls noch keine gesehen).
Dieses Protokoll gehe ich hinterher durch; die Nachbehandlung der Installation erfolgt dann aber von Hand.
Ohne gute Kenntnisse der Windows-Interna geht's denn aber nicht, oder?
Kenntnisse über Windows-Interna oder ein gutes "Gespür" dafür braucht man eigentlich nur, um aus dem Protokoll nachher die Änderungen rauszuwerfen, die auf den normalen Betrieb von Windows zurückzuführen sind. Denn InCtrl5 macht einfach nur einen vorher-nachher-Vergleich, ohne die Unterschiede nach ihrer Ursache zu differenzieren.
Ansonsten ist es meiner Ansicht nach hauptsächlich Common Sense. Wenn ich sehe, dass bei der Installation des Softwarepakets "foo" eine Datei foolib.dll in %systemroot%\system32 abgelegt wurde, die Software aber eigentlich einen in sich abgeschlossenen Zweck hat (und ihre Komponenten daher nicht anderen Programmen zur Verfügung stellen muss), dann schiebe ich foolib.dll halt einfach ins Programmverzeichnis, und schaue nochmal ins Registry-Protokoll: Wurde ein Schlüssel angelegt, der auf diese Datei verweist? Dann muss ich den natürlich anpassen.
Das Installationsprotokoll kann ich außerdem bei der Deinstallation zu Rate ziehen, um zu kontrollieren, ob der Uninstaller auch allen Dreck sauber weggeräumt hat.
Völlig neue, mir unbakannte Software teste ich natürlich auch erstmal ein paar Tage auf einem isolierten System (oder in einer VM).
VM ist ein gutes Stichwort. Oft gelesen, nie benutzt. Sollte ich vielleicht mal.
Ich persönlich habe mit VirtualBox bisher die besten Erfahrungen gemacht (sowohl auf Windows als auch Linux als Hostsystem). Hab ich aber seit Erscheinen der 3er-Version auch nicht mehr benutzt.
So long,
Martin
Hi!
Völlig neue, mir unbakannte Software teste ich natürlich auch erstmal ein paar Tage auf einem isolierten System (oder in einer VM).
VM ist ein gutes Stichwort. Oft gelesen, nie benutzt. Sollte ich vielleicht mal.
Als Gastsysteme kann man auch Windows verwenden, ohne in großartige Lizenzierungsprobleme zu kommen. Aktuelle Versionen laufen unaktiviert mindestens 30 Tage, die meisten mit Verlängerung bis zu 240 und sind teilsweise auch als freie Testversion zu haben (Windows 7 Enterprise 90-Tage-Testversion).
Mit Windows ab so weit ich weiß Vista, kann man auch eine VHD (Virtual Hard Disc) anlegen. Das ist eine (ausreichend große) Datei im normalen System, die im Bootmanager eingetragen werden kann. Da brauchts nicht mal eine VM, um ein Zweitsystem ohne Platten-Umpartitionierung zum Laufen zu bekommen. Läuft dann natürlich als alleiniges System und nicht im Fenster einer VM-Software, dafür aber auch mit (fast) voller Power.
Lo!
