DLL Hell //2138

Mein RSS-Reader hat mir inzwischen schon seit etlichen Jahren gute Dienste geleistet. Hin und wieder habe ich ein paar Verbesserungen daran gemacht – so etwa die Unterstützung von SSL vor ein paar Jahren.

Dass die HTML-Anzeige kein Javascript konnte, war mir ganz recht. So musste ich mich wenigstens nicht um eventuelle darauf beruhende Sicherheitslücken kümmern. Was mich allerdings zunehmend störte, war, dass der Reader dennoch bei jedem Skript ein Meldungsfenster aufpoppen ließ, das ich erst händich wegklicken musste – immerhin ein Klick per Tweet und sogar drei pro Youtube-Video. Allmählich nervte das.
Und so nahm ich mir irgendwann ein paar Minuten Zeit, stellte die HTML-Komponente auf silent, kompilierte die Sourcen, und es funktionierte auf Anhieb.

Wie wohltuend das Fehlen dieser nervigen Popupfenster war, merkte ich erst, als ich kürzlich auf einem anderen Rechner war, der noch die ältere Version meines RSS-Readers laufen hatte.
Kurzerhand überschrieb ich die alte Exe.
Als ich sie neu startete, musste ich jedoch feststellen, dass nur die Feeds angezeigt wurden, die noch ohne SSL liefen – ein einziges Blog war das in diesem Fall.
Mir war klar, dass das Problem an den Libraries von OpenSSL liegen musste.

Da im gleichen Verzeichnis gar keine DLL vorhanden war, suchte ich im Windows- und Systemverzeichnis danach. Die OpenSSL-DLLs, die ich dort fand, waren schon recht alt. Momentan hatte ich nur Zugriff auf einen einzigen anderen Rechner, der den RSS-Reader nutzte. Fragt mich nicht warum, aber ich hatte meinen Reader damals so eingestellt, dass er die OpenSSL-Libraries der Apache-Installation nutzte.
Um lange herumzuprobieren, hatte ich keine Lust. Also kopierte ich die beiden entsprechenden DLLs in das gleiche Verzeichnis wie meine Anwendung. Ich startete die Anwendung – nur die Feeds des Non-HTTPS-Blogs wurden geladen.
Also lag es doch nicht an den beiden DLLs?

Ich startete die Anwendung aus dem Netzwerkshare des anderen Rechners – also remote. Alle Feeds wurden korrekt geladen. Lag es also doch nicht an den beiden DLLs? Oder benutzten die DLLs noch irgendwelche anderen Dateien in diesem Verzeichnis?
Einerseits wollte ich nun wirklich nicht sämtliche Dateien rüberkopieren, andererseits die Dateien auch nicht einzeln ausprobieren.
Mit einer Kombination aus Glück und Intuition kopierte ich die zlib1.dll noch herüber. Ich konnte mein Dusel kaum fassen, aber so funktionierte es!

Ich nehme an, dass auf Windows 10 (bzw. Server 2012) die benötigten Funktionen vom Betriebssystem bereitgestellt werden. Auf dem benutzten Windows-7-Rechner dagegen standen sie nicht automatisch zur Verfügung, weshalb sie durch eine zusätzliche DLL geliefert werden mussten.

Über Anne Nühm (breakpoint)

Die Programmierschlampe.
Dieser Beitrag wurde unter Uncategorized abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

2 Antworten zu DLL Hell //2138

  1. Pingback: Zur Überbrückung //2322 | breakpoint

  2. Pingback: Der Hölle entkommen //2521 | breakpoint

Hinterlasse einen Kommentar