wxDynamicLibrary::Load geht nicht mehr
-
mit dependency walker habe ich herausgefunden, dass meine dll die drei anderen dlls kbas6.dll, khdw6.dll und kioa6.dll benötigt. wenn ich diese dlls in meinen programmordner kopiere, dann gibt wxDynamicLibrary::Load auch true zurück, nur bekomme ich dann die fehlermeldung:
An exception (0EEFFACE) occurred during DllEntryPoint or DllMain in module: C:\path\kbas6.dll
ich kann die fehlermeldung umgehen, indem ich die exe im kompatibilitätsmodus ausführe, aber gibt es noch einen anderen weg, die alte dll nutzen zu können?
alle dlls stammen von einem 32bit winxp, sie sollen auf meinem 64bit win7 laufen.
edit: es scheint nur mit dem kompatibilitätsmodus zu gehen, also deaktiviere ich den programmteil, der diese dll benötigt, wenn das programm auf einem 64bit system läuft.
wxIsPlatform64Bit()
-
ich muss dieses thema nochmal reaktivieren.
hier ist eine exe, die nichts anderes macht als die dll edx5.dll zu laden, welche wiederum u.a. die kbas6.dll braucht.
https://drive.google.com/file/d/0B3ufm_rZo3qJOW1FWlhIS1JfdW8/view?usp=sharing
auf win10pro 64bit läuft es nur, wenn die exe im kompatibilitätsmodus xp sp3 gestartet wird. ohne das gibt es eine fehlermeldung wie bereits vorher beschrieben.
kann ich irgendwie das, was der kompatibilitätsmodus macht, in der programmierung tun? mein ziel ist es, dieses laden der dll in einem programm hinzubekommen, bei dem das umstellen in den kompatibilitätsmodus nicht funktioniert.
-
Ich benutze wxDynamicLibrary auch in einem Projekt und habe damit keine Probleme.
Ich habe die dlls die ich zur Laufzeit lade, aber auch alle selbst gebaut, daher weis ich, dass sie für das jeweils richtige Zielsystem vorliegen. Allerdings benutze ich das im Moment nut mit 32 bit und habe win 10 noch nicht ausprobiert.
Die exe die du da zum download anbietest, ist das einfach dein obiger Source Code compiliert? Woher stammen die DLLs die du laden möchtest?
-
Schlangenmensch schrieb:
Die exe die du da zum download anbietest, ist das einfach dein obiger Source Code compiliert? Woher stammen die DLLs die du laden möchtest?
Ja, das ist nur der obige Code. Die edx5.dll stammt von einem Vorgänger von mir in meiner Firma, leider habe ich aber keinen Quellcode mehr dafür. diese edx5.dll braucht drei alte dlls von kithara. ich habe auch schon kithara angeschrieben, aber leider bisher keine antwort erhalten.
es geht um die kommunikation mit einer ebenfalls alten hardware, die damals zu zeiten von winXP entwickelt wurde.
-
Hm, dass könnte etwas komplizierter sein. Ich habe hier ein Artikel gefunden, der sich mit dem Problem von 32 Bit DLLs in 64 Bit Anwendungen befasst: https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
-
danke, das werde ich mir mal genau durchlesen. es könnte allerdings zusätzlich an etwas anderem liegen, weil sich die dll auch in jedem späteren windows in den 32bit versionen nicht laden lässt. also win7pro 32bit zeigt dieselbe fehlermeldung wie win10pro 64bit. deswegen hoffe ich darauf, die effekte des kompatibilitätsmodus irgendwie anders bewirken zu können.
-
Hm, du kompilierst dein Programm also als 32 bit Anwendung? Dann sollte es ja, wenn die DLL auch als 32 bit Anwendung kompiliert wurde, da keine Probleme geben.
Was anderes, hat die DLL ein C-Style Interface? Ich habe schon mal von Problemen gehört, wenn DLL und exe mit unterschiedlichen Compiler Versionen gebaut wurden und es sich um ein C++ Interface handelt. Bei einem C++ Interface muss man wohl die DLL und die exe gegen die selbe CRT Version linken.
-
ja, ich linke mit /MACHINE:X86
hmmm, ich vermute du meinst mit c-style interface die calling convention?
ich greife erfolgreich folgendermaßen auf die dll zu.typedef void (__stdcall *GETMAXCARD)(int *retVal); GETMAXCARD GetMaxCard; wxString edxPath = wxStandardPaths::Get().GetExecutablePath().BeforeLast('\\') + wxT("\\edx5.dll"); wxDynamicLibrary dynLib; bool isLoaded = dynLib.Load(edxPath); SetMaxCard = (SETMAXCARD) dynLib.GetSymbol(wxT("SetMaxCard"));oder wie könnte ich sonst herausfinden, welches interface die dll hat?
danke!
-
Ob die Funktion mit "extern c" oder anders bekannt gegeben wurde, sollte der Dependency Checker mit ausgeben: https://stackoverflow.com/questions/5979911/how-to-check-whether-a-function-in-dll-lib-is-extern-c-in-windows
-
ja, sowohl edx5.dll als auch die kithara dlls haben ein c-style interface.
-
Hm,
nochmal eine andere Frage. Du hast die Windows Version und wxWidgets Version geupdated. Wie sieht es mit der Entwicklungsumgebung aus? Nutzt du jetzt VS 2017? Oder 2015? Wärend die alte DLL vielleicht mit VS 2005 oder älter gebaut wurde?