Hallo

Ich habe mit Delphi XE also eine 32bit-Anwendung auf meinem 32bit-System geschrieben.
Ich lese eine 32bit-DLL ein und alles ist gut.

Nun soll die Anwendung auf einem Windows7Pro 64bit-System ausgeführt werden.
Beim Laden meiner Anwendung (zu Beginn wird die DLL mit LoadLibrary geladen) sagt mir das System, daß es die DLL nicht findet.

Nun habe ich recherchiert und mit extractfilepath(application.exename)+DLLname den Pfad angegeben, damit es sie auch ganz sicher findet - sie ist ja sogar im gleichen Ordner wie die .exe !
Gleiche Meldung: DLL nicht gefunden!

Nun habe ich weiter geforscht, aber Google sucht mir da nicht richtig ("32bit dll in 64bit system loadlibrary delphi" - findet meist sowas wie '64bit-DLL in 32bit-App', oder für java...).

Wenn es über LoadLibrary nicht gehen würde, habe ich mir gedacht, die DLL "einfach" in die .exe als Resscource einzubinden und im Speicher zu starten, dann entfällt das LoadLibrary - so wie hier beschrieben. Das hätte ergänzend den Vorteil, daß die DLL nicht verloren geht

Aber bevor ich dieses KnowHow mühsehlig erlerne und dafür Stunden invenstiere... - bestehen hierzu überhaupt Aussichten auf Erfolg, daß das auch gelingt? Oder sollte ich in einer anderen Richtung weitersuchen, da ich die DLL nicht verändern kann?!

Zitat:

ich habe eine DLL, mit der ich über USB Befehle an ein Messgerät sende.

Ich denke mal das es um diese DLL geht.

Wenn das der Fall ist dann wird unter einem 64Bit System eine 64Bit.dll (Treiber für das USB Gerät) geladen und nicht eine 32Bit.
Das ist der Grund warum die DLL nicht gefunden wird.

gruss

Gut aufgepasst

Der Hersteller hat auch Treiber mitgeliefert "win32at64bit", diese hab ich dann auch installiert; die DLL, die ich nutze, ist aus den Beispielen und gibt es in keiner anderen Version. Interessanterweise hat das Meldungsfenster jetzt keinen Inhalt mehr

Mit welchen Problemen hätte ich zu rechnen, wenn ich den kompletten Quelltext auf einem 64bit-Delphi kompilieren wollte?
Die 32bit-DLL könnte ich dann wohl trotzdem nicht laden, oder!?

Edit:
Warum greift das WOW64-System nicht bzw. wie kann man es motivieren?

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

Zitat von OlafSt:

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

Nicht unbedingt...
Es gäbe die Möglichkeit mit einer zwischengeschalteten 32Bit Anwendung auch eine 64Bit Anwendung über IPC WM_COPYDATA 32Bit Dll's anzusprechen.

Ob das mit Treiber Dll's möglich ist habe ich noch nicht probiert.
Hingegen bei normalen DLL's (keine Treiber) ist das sehr wohl machbar.

gruss

Man sollte hier DLLs von Treiber und Interface auseinanderhalten. Die DLLs vom Treiber entsprechen natürlich immer der Architektur des Systems, sind also 32 bittig auf einem x86 und 64 bittig auf einem x64 (bis auf Ausnahmen wie Co-Installer).

Sofern aber weitere DLLs zum Zugriff mitgeliefert wurden bzw. vorhanden sind, wie es z.B. bei der Windows API (z.B. shell32.dll) der Fall ist, sehe ich kein Problem. Daher mein Tip: untersuche die DLL, um die es geht, genauer mit einem PE Analysetool, z.B. FileAlyzer o.ä.

MfG Dalai

Zitat von OlafSt:

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs.

Kannst also aufhören, es zu versuchen.

Ja, das weiß ich. Es ist ja auch eine 32bit-Anwendung auf einem 64bit-System. Folglich würde im Hintergrund das WoW64-System aktiv sein, wie ich jetzt gegoogelt habe. Und ich weiß auch, daß 64bit-DLLs nicht mit 32bit-Anwendungen zusammenarbeiten. Daher habe ich ja auch eine 32bit-DLL mit meiner 32bit-Anwendung im Einsatz, allerdings auf einem 64bit-System...

Zitat von EWeiss:

Nicht unbedingt...
Es gäbe die Möglichkeit mit einer zwischengeschalteten 32Bit Anwendung auch eine 64Bit Anwendung über IPC
und WM_COPYDATA 32Bit Dll's anzusprechen.

Ob das mit Treiber Dll's möglich ist habe ich noch nicht probiert.
Hingegen bei normalen DLL's (keine Treiber) ist das sehr wohl machbar.

gruss

Ich habe nochmal die DLL angesehen - es ist eigentlich kein Treiber, sondern eine Schnittstelle zum Treiber (den ich in der x86at64bit-Version (weiß nicht, ob ich den richtigen Begriff dazu verwende) installiert hab). Wenn ich die DLL austausche, geht es trotzdem nicht.

In der x86at64bit-Version, die das Hersteller-Treibersetup im "C:\Program Files (x86)" installiert hat, steht der String
6f1ea56521e5ead1af5152081ea42a971ddbb85c78cbf3.WD1011_64_NL_Newport im Vergleich zu
6f1ea7e7635967b1d4fec0f13548d3b1f10f6484144339.WD1011_32_NL_Newport in der win32-Version, die ich bisher einwandfrei auf meinem 32bit-System genutzt habe.

Und soeben schrieb mir

Zitat von Dalai:

... Daher mein Tip: untersuche die DLL, um die es geht, genauer mit einem PE Analysetool, z.B. FileAlyzer o.ä.

Worauf müsste ich da speziell achten?

Zitat von SearchBot:

Worauf müsste ich da speziell achten?

Lad die DLL im Tool und wirf einen Blick auf die Architektur bzw. Machine. Das ist je nach benutztem Tool unterschiedlich benannt. Bei FileAlyzer ist es auf der Registerkarte "PE Header" zu finden; entweder steht dort "Machine: 64-bit Windows (AMD)" oder "Machine: Intel 386".

[EDIT]
Achso, eine Sache noch: DLLs haben genau wie Programme (EXE) Abhängigkeiten. Die sollte man sich ebenfalls anschauen, ob die allesamt erfüllt sind. Sonst schlägt das Laden einer DLL ebenfalls fehl. Bei FileAlyzer findet man das auf der Registerkarte "PE Imports".
[/EDIT]

MfG Dalai

Also Nochmal!

Zitat:

Alle Hardwaregeräte benötigen 64-Bit-Treiber, um mit einer 64-Bit-Version von Windows funktionsfähig zu sein.

Selbst dann wenn deine Anwendung 32Bit und die Schnittstelle (API) in 32Bit ausgelegt ist.
Du kannst über eine 32Bit Schnittstelle nicht mit einen 64Bit Treiber kommunizieren.
Da hilft auch ein Austauschen nichts.

Das Hardwaregerät wird ohne 64Bit Treiber nicht funktionieren.

gruss

Zitat von OlafSt:

Eine 64Bit-Anwendung erfordert zwingend 64Bit-DLLs

Das ist nicht ganz korrekt. Zumindest kann eine 32 Bit Anwendung "ohne Probleme" eine 64 Bit DLL laden. So funktioniert übrigens auch die ganze WOW64 Emulation. Die System Dlls wie kernel32 sind in einer 64 Bit Anwendung sehr wohl geladen, nur kann die Anwendung diese nicht sehen, da sie in einem Speicherbereich > 32 Bit gemappt werden. Das 32 bittige kernel32 Äquivalent leitet die Aufrufe der Systemfunktionen dann nur noch auf den 64 Bit Code um, während gleichzeitig die CPU kurzzeitig in den 64 Bit Mode geschaltet wird.

Dieses kurzzeitige Umschalten kann man übrigens auch selbst machen:
http://rce.co/knockin-on-heavens-gat...ode-switching/

Ist allerdings nicht ganz trivial und sicherlich ziemlich hacky.