PureBoard

Verfasst: **08.04.2025 13:19**

Hallo,

ich verwende momentan noch libmysql.dll in der Version 6.1.6.0 und muss diese auf 8.4.4.0 aktualisieren.
(Wer es nicht kennt: Das ist die Connector-DLL für MySQL)

Vorab: Die interne OpenDatabase-Funktion kann ich nicht verwenden, da ich spezielle Optionen brauche welche hier nicht verfügbar sind.

Wenn ich versuche die neue DLL mit OpenLibrary() zu öffnen, schlägt dies mit Return-Wert 0 fehl.
Die alte Version funktioniert ohne Probleme. Ich verwende bzw. brauche PB6.20 x86 (wobei ich auch x64 getestet habe).

Code: Alles auswählen

Debug OpenLibrary(#PB_Any, "libmysql.dll")

libmysql.dll
libmysql.dll.old

Hat jemand eine Idee, was hier schief läuft?

Danke und schöne Grüße

Verfasst: **08.04.2025 13:41**

Ich kann dir nicht besonders viel weiter helfen, da ich kein Windows besitze. Aber unter Linux zeigt mir `file` Unterschiede an bei den Bibliotheken:

Code: Alles auswählen

$ file libmysql.dll*
libmysql.dll:     PE32+ executable (DLL) (console) x86-64, for MS Windows, 6 sections
libmysql.dll.old: PE32 executable (DLL) (console) Intel 80386, for MS Windows, 6 sections

PE32+ bedeutet, dass es eine 64-Bit Bibliothek ist, wenn man Stackoverflow glauben mag. Das heißt du musst Purebasic auch in der 64-Bit-Version nutzen.
Da du das aber auch schon getestet hast und es scheinbar nicht funktioniert, muss es an noch etwas anderem liegen. Und da weiß ich leider nicht weiter. Aber vielleicht hilft dir das schon mal auf die Sprünge.

Verfasst: **08.04.2025 13:45**

Führe ich folgenden Code in PB6.2 x86 aus, so bekomme ich als Fehlercode 193 angezeigt.

Code: Alles auswählen

Debug LoadLibrary_("libmysql.dll")
Debug GetLastError_()

Dies sagt aus:

ERROR_BAD_EXE_FORMAT
193 (0xC1)
%1 is not a valid Win32 application.

Führe ich den Code unter PB6.2 x64 aus, bekomme ich folgenden Fehlercode:

ERROR_MOD_NOT_FOUND
126 (0x7E)
The specified module could not be found.

Damit steht fest, dass es eine 64Bit-DLL sein muss.
Was es aber mit dem "ERROR_MOD_NOT_FOUND" auf sich hat, ist mir noch ein Rätsel..

Verfasst: **08.04.2025 14:10**

Also wenn ich danach recherchiere, finde ich hauptsächlich Pfadprobleme als Grund. Kannst du mal versuchen den Pfad der DLL als absoluten Pfad anzugeben? Womöglich hat die libmysql.dll auch noch weitere Abhängigkeiten, die nicht gefunden werden?

Verfasst: **08.04.2025 14:17**

Ja, diese Info habe ich auch schon gefunden. Danke für deine Unterstützung.

Der absolute Pfad bringt keine Veränderung, daher vermute ich eine Abhängigkeit - nur welche?
Ich finde immer nur den Hinweis "Show loader snaps" - aber dies bezieht sich auf VS und bringt mir nichts..

Verfasst: **08.04.2025 14:52**

Ich hab noch ein paar Fragen und Ideen:

Hast du mal versucht die DLL ohne den Debug-Modus zu laden, also das Ergebnis von `LoadLibrary()` in eine Variable speichern und dann über ein MessageRequester auszugeben?
Hast du einen Antivirus laufen? Die mögen ja so einiges nicht und verhindern bestimmte Zugriffe pro-aktiv, also könntest du den mal kurz deaktivieren und nochmal testen?

Sind alle Abhängigkeiten installiert? Unter Linux hab ich zwar beschränkte Mittel, aber ich konnte herausfinden, was die Abhängigkeiten der DLL sind:

Code: Alles auswählen

$ objdump -p libmysql.dll | grep 'DLL Name'
	DLL Name: VCRUNTIME140.dll
	DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
	DLL Name: KERNEL32.dll
	DLL Name: libssl-3-x64.dll
	DLL Name: libcrypto-3-x64.dll
	DLL Name: DNSAPI.dll
	DLL Name: Secur32.dll
	DLL Name: ADVAPI32.dll
	DLL Name: VCRUNTIME140_1.dll
	DLL Name: api-ms-win-crt-heap-l1-1-0.dll
	DLL Name: api-ms-win-crt-string-l1-1-0.dll
	DLL Name: api-ms-win-crt-conio-l1-1-0.dll
	DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
	DLL Name: api-ms-win-crt-convert-l1-1-0.dll
	DLL Name: api-ms-win-crt-environment-l1-1-0.dll
	DLL Name: api-ms-win-crt-math-l1-1-0.dll
	DLL Name: api-ms-win-crt-utility-l1-1-0.dll
	DLL Name: api-ms-win-crt-time-l1-1-0.dll
	DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll
	DLL Name: MSVCP140.dll
	DLL Name: WS2_32.dll

Die müssen natürlich alle auch da sein. Die meisten werden von Windows selbst kommen, aber möglicherweise sind da auch welche dabei, die noch fehlen. Gerade die VCRUNTIME140.dll ist ein Hinweis auf die entsprechende Microsoft Visual C++ Runtime, die vielleicht fehlen könnte.

Verfasst: **08.04.2025 15:16**

Danke für deine bisherige Hilfe. Da die DLL eine 64-bit ist, nützt Sie mir sowieso nichts.
Ich werde das Thema weiterverfolgen, wenn ich einmal Zeit habe.

Das wird wohl meine notdürftige Lösung werden, bis die SW auf 64-bit migriert wird:
(bin gerade am testen)
https://en.delphipraxis.net/topic/2002- ... ment=57047

Verfasst: **08.04.2025 16:04**

Normalerweise müsste ein Sprung von 32-Bit auf 64-Bit nicht so kompliziert sein, außer du hast noch viel mehr Abhängigkeiten, die ich jetzt nicht kenne.
Dann weiterhin gutes Gelingen.

Verfasst: **08.04.2025 16:11**

Danke. In der Anwendung werden 18 Zukauf-DLLs eingebunden, wovon z.T. die Firmen nicht mehr existieren.
Es ist fraglich, ob in naher Zukunft überhaupt auf 64-bit migriert wird. Die Anwendung hat bisher ~250k Zeilen PB-Code.

Verfasst: **08.04.2025 17:36**

Ohje, ich verstehe. Leider sind die Möglichkeiten 32-Bit DLLs von einer 64-Bit-Applikation nutzen zu lassen, nicht existent. Man kann es nur umschiffen mit zwei getrennten Anwendungen, die miteinander über IPC/COM oder Netzwerk kommunizieren.

PureBoard

DLL mit OpenLibrary öffnen schlägt fehl

DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl

Re: DLL mit OpenLibrary öffnen schlägt fehl