windows 10 loadlibrary error

[HPW]

Hallo,

Seit langer Zeit hatte ich folgenden code zum Dll-Laden genutzt:

Delphi-Quellcode:

DllHandle := LoadLibrary( Pchar( 'xxxxxx.dll' ));

Ich habe mich also darauf verlassen, das Windows die Dll im Suchpfad mit den bekannten Regeln findet.
Dabei war meine Dll im Programmverzeichnis.

Unter Win10 geht das nun so nicht mehr.
Nun muss man den kompletten Pfad mitgeben damit es wieder funktioniert.

Grüsse,

Hans-Peter

[Luckie]

Delphi-Quellcode:

LoadLibrary( Pchar( 'xxxxxx.dll' ))

Du lädst die DLL aus dem aktuellen Arbeitsverzeichnis, welches nicht zwingen das Programmverzeichnis sein muss. Unter Windows < 10 hat es wohl eher durch Zufall funktioniert.

[SMO]

Zitat:

Zitat von Luckie (Beitrag 1322284)

Du lädst die DLL aus dem aktuellen Arbeitsverzeichnis, welches nicht zwingen das Programmverzeichnis sein muss. Unter Windows < 10 hat es wohl eher durch Zufall funktioniert.

Stimmt nicht. Den Regeln nach wird immer zuerst im Programmverzeichnis gesucht. Das aktuelle Arbeitsverzeichnis kommt im normalen "SafeDllSearchMode" erst an vorletzter Stelle. Daran wird sich in Windows 10 bestimmt nichts geändert haben.

Hans-Peter, wie heißt denn die DLL genau? Falls sie denselben Namen wie eine der "KnownDLLs" hat, kann es nicht funktionieren. Ob sich an der Liste der KnownDLLs in Windows 10 etwas geändert hat, weiß ich nicht.

[Der schöne Günther]

Ohne es nachgeschlagen zu haben: Sagt einem der where-Befehl (in der Konsole) nicht sogar genau die Reihenfolge in welcher sich eine Anwendung für die DLL entscheiden würde?

[Luckie]

Ok, stimmt. Ist ja eine DLL und keine normale Datei. Aber wenn er weiß, wo sie liegt (Programmverzeichnis) warum gibt er dann nicht gleich den Pfad mit an? Dann würde es erst gar nicht zu solchen Fehlern kommen. Denn offensichtlich hat sich zu Windows 7/8 doch was geändert.

[SMO]

Zitat:

Zitat von Der schöne Günther (Beitrag 1322297)

Ohne es nachgeschlagen zu haben: Sagt einem der where-Befehl (in der Konsole) nicht sogar genau die Reihenfolge in welcher sich eine Anwendung für die DLL entscheiden würde?

Nein, eben nicht, siehe den MSDN-Artikel, den ich verlinkt habe, oder die Hilfe zu LoadLibrary.

Zitat:

Zitat von Luckie (Beitrag 1322319)

Ok, stimmt. Ist ja eine DLL und keine normale Datei. Aber wenn er weiß, wo sie liegt (Programmverzeichnis) warum gibt er dann nicht gleich den Pfad mit an?

Warum sollte man den Pfad für eine eigene DLL angeben, die im Programmverzeichnis liegt, wenn dort sowieso als erstes gesucht wird?

Zitat:

Zitat von Luckie (Beitrag 1322319)

Dann würde es erst gar nicht zu solchen Fehlern kommen. Denn offensichtlich hat sich zu Windows 7/8 doch was geändert.

Was zu beweisen wäre. Der Fehler könnte jede Menge andere Ursachen haben, die nichts mit dem DLL-Suchverhalten zu tun haben. Solange Hans-Peter uns keine Details nennt, wie z.B. den konkreten Dateinamen und den Fehlercode (GetLastError) direkt nach LoadLibrary, ist alles nur Spekulation.

[HPW]

Hallo,

In meinem Fall war es die newlisp.dll mit der ich den Interpreter in meine Anwendung lade.
Also kaum eine KnownDll.
Windows 10 macht jedenfalls definitiv etwas anderes als die Versionen davor.

Jetzt nerven nur noch die ganzen Warnmeldungen beim Download und installieren wegen fehlender Signatur. Für kleine Software-Projekte sehr schwierig.

Grüsse,

Hans-Peter

[Sir Rufo]

Dann signiere deine Anwendungen doch einfach ...

Ein selbst erstelltes Zertifikat reicht in dem Fall wohl aus und der Installierende muss nur einmal dein Zertifikat als vertrauenswürdig abnicken, danach ist es wie bei einem gekauften Zertifikat.

[Dalai]

Auch bei LoadLibrary kann man bei Fehlschlag GetLastError bemühen, um herauszufinden, warum das Laden der DLL nicht klappt.

[EDIT] Hoppla, SMO hat ja bereits darauf hingewiesen. Naja, doppelt hält besser :mrgreen: [/EDIT]

MfG Dalai

[Luckie]

Und wenn da kommt: "File not found".... :cyclops: