OS2.org Forum

Das Rexx-Skript in Anlage listet alle auf dem aktuellen Laufwerk liegenden DLLs, und gibt eine alphabetisch sortierte Liste der Dateien mit Datums- und Verzeichnisangabe aus.
erstellt eine Liste der Dateien im Textformat, und kann dabei helfen, doppelte DLLs oder auch gleichnamige, aber unterschiedliche DLLs aufzuspüren.

Es ist natürlich für weitere Aufräumaktionen (zB. Löschen von DLLs) Vorsicht geboten, nicht jede doppelte oder ältere DLL ist überflüssig.

Suche über mehrere Laufwerke ist bislang nicht vorgesehen, ggf. das Skript auf weitere Laufwerke kopieren, oder ausführen, und die Listen zusammenführen.

Hi Frank,

danke, ist doch sehr hilfreich, um das alles mal in Ruhe durchzuforsten.

Gerhard

Hallo Frank,

danke für dein Skript - ist ganz interessant, was da ausgegeben wird.

Wie war das doch gleich? Mit dem Essen kommt der Appetit ...
Zusätzliche "Features" (über Startparameter oder mittels Abfragen) wären super - zB:
- Suche nur auf die in der config.sys aktuell eingetragenen Pfade begrenzen (dadurch entfallen Funde im Zusammenhang mit irgendwelchen "Oldie"-Programmen, die so herumliegen)
- Nur Ergebnisse mit 2 oder mehr Namensgleichheiten anzeigen

Vielleicht hast du ja einen langweiligen Abend vor dir und erweiterst dein Programm

Schöne Grüße und nochmals danke!
Hanno

Hallo Hanno,

Suche nur auf die in der config.sys aktuell eingetragenen Pfade begrenzen

hast Du den berühmten Punkt im Libpath? Damit ist jedes Verzeichnis ein potentielles Libpathverzeichnis

Nur Ergebnisse mit 2 oder mehr Namensgleichheiten anzeigen

Ja, das wäre wohl sinnvoll. Heute Nacht aber nicht mehr...

Hallo Frank,

hast Du den berühmten Punkt im Libpath? Damit ist jedes Verzeichnis ein potentielles Libpathverzeichnis

o.k., du hast gewonnen

ABER ... du könntest den Pfad auslesen und nur die angegebenen Pfade durchforsten, also den Punk ignorieren.

Hier mal wieder 2 Cent von mir:
Vor vielen Jahren hatte ich mal die Idee den LIBPATH zu nutzen um ein Super-DLL-Verzeichnis zu erzeugen.
Ich habe versucht vom Ende des LIBPATH her beginnend alle Verzeichnisse in das Super-DLL-Verzeichnis zu kopieren, leider habe ich dieses Ziel nicht erreicht.
Irgendetwas habe ich wohl dabei übersehen bzw. nicht verstanden, jedenfalls hat das reduzieren des LIBPATH auf das eine Super-DLL-Verzeichnis nicht funktioniert.

hanno » Fr 1. Apr 2016, 08:16 hat geschrieben:Hallo Frank,

hast Du den berühmten Punkt im Libpath? Damit ist jedes Verzeichnis ein potentielles Libpathverzeichnis

o.k., du hast gewonnen

ABER ... du könntest den Pfad auslesen und nur die angegebenen Pfade durchforsten, also den Punk ignorieren.

Ja, schon, aber dann werden DLLs nicht angezeigt, die aber von Programmen geladen werden können. D.h. beispielsweise, wenn Du in jedem Browserverzeichnis eine glechnamige trouble.dll - jeweils in anderer Version - hast, wird diese von dem Script nicht angezeigt. Deswegen habe ich mich dazu entschlossen, das ganze Laufwerk zu durchsuchen.

Ein paar Hinweise für den Frühjahrsputz: ältere DLLs aus der OS2 und ECS Basisinstallation (Ausnahme s.u.) sind in der Regel unbedenklich. Überprüfen sollte man DLLs in den Haupt-DLL Verzeichnissen (Duplikate in \ecs\dll und\os2\dll, sowie im Unixroot \usr\* & Co., sowie vor allem in allen Verzeichnissen von Programmen, die häufigen Updates unterliegen, insbesondere Unixports.

Wenn alles gut läuft und nur ein neu installiertes Programm nicht geht, dann liegt es natürlich nahe, alle DLL-Dateinamen des neu installiertes Programms zu überprüfen, was das Script hoffentlich leichter macht, als jede Datei einzeln mit PMSEEK aufzuspüren.

Es sollte i.d.R nicht erforderlich sein, wirklich alle DLLs zu überprüfen bzw.. ggf. alle Duplikate aller Programme zu löschen. Es kann auch zu Problemen führen, wenn man doppelte DLLs einfach löscht. Daher: nicht übertreiben.

Ich habe versucht vom Ende des LIBPATH her beginnend alle Verzeichnisse in das Super-DLL-Verzeichnis zu kopieren, leider habe ich dieses Ziel nicht erreicht.
Irgendetwas habe ich wohl dabei übersehen bzw. nicht verstanden, jedenfalls hat das reduzieren des LIBPATH auf das eine Super-DLL-Verzeichnis nicht funktioniert.

Wie wir gerade wieder bei der Browserinstallation gemerkt haben, gibt es Programme, die trotz LIBPATH auf ihre eigene Verzeichnisstruktur bestehen, das könnte der Grund dafür gewesen sein.