32bit-DLL mit LoadLibrary auf einem 64bit-System laden?

[himitsu]

Weil es eben nicht DIE Lösung gibt.

Wie gesagt, entweder man kann was Allgemeines nehmen, dann ist alles fast schon fertig (DCOM/COM)
oder du mußt eben alles selber machen (dir die WrapperEXE bauen und das Interface in dein Programm).

Und wie die beiden dann miteinander Reden, da gibt es auch massenhaft Lösungen ... nennt sich allgemein IPC.
SendMessage (auch WM_COPYDATA oder nicht), MMF, TCP, Pipes oder sonstwas Höheres, so in Richtung Client/Server ala REST, SOAP, DataSnap bzw. RADServer, mORMot uvm.

Man kann die Funktionen im Interface genauso bauen, wie das was die DLL exportiert, und kapselt darin dan was wirklich die Verbindung macht
oder man kann es auch anders machen und das die Verbindung machende direkt verwenden
oder ...
(Ersteres hat den Vorteil, dass es für das nutzenden Programm egal ist, was wie dazwischen passiert, da die Funktionsaufrufe unverändert bleiben, also so als ob die DLL direkt benutzt würde)

[TERWI]

Ich hab das hier nun mittels WM_COPYDATA gelöst.
Finde ich zwar irgendwie ein bischen "von hinten durch die Brust ins Auge" ... aber es funktioniert tadellos.

Dazu hab ich einen Variant-Record gebastelt, den ich die Sendmessage hänge.
Je nach Anforderung darin liest oder schreibt der Wrapper in/aus der DLL und gibt den ggf. gefüllten Record gleich wieder zurück.

Praktisch ist, das TWmCopyData den Handle des aufrufenden Prog in Msg.From mitliefert und der Wrapper ohne zu wissen wer da "anfragt" die Antwort gleich wieder zurückschicken kann.

Mit ShellExecute und SW_HIDE gestartet habe ich kein Fenster ... und auch kein Icon in der Taskleiste ?!
Eine Sendmessage mit WM_CLOSE macht den Wrapper bei Programmende wieder zu.
Fühlt sich nun so an, als wenn da gar nichts zwischenhängt.

[TERWI]

Eine kleine Klinke ist doch noch da:
Das senden von Daten an die DLL und von da zum 'Gerät' geht so weit ja prima.

Jetzt hätte ich aber z.B. auch gern Daten zurück (vom 'Gerät' gelesen) bzw. das Ergebnis der aufgerufen Funktion....

Die Antwort vom Wapper kommt ja immer in der Message-Routine und das ist (logo ?) eine andere wie die welche Daten anfragt.

Die urspüngliche Funktionalität, der anfragenden Funktione per var einen Paramter zu geben und den nach 'Request' wieder zurückzubekommen ist dahin ...

Hat jemand eine Idee, wie man man das ohne nennenswerte Klimmzüge wieder hinbekommt ?

[himitsu]

Du kannst ein zweiters WM_COPYDATA auch als Antwort zurück an das Fenster des Aufrufers schicken.

oder eben Streams/Pipes, jeweils in die beiden Richtungen
oder man kann MemoryMappedFiles nutzen ... da können Beide lesen und reinschreiben (hin und her)
oder ...

[venice2]

Manchmal hat man es schwer jemandem helfen zu wollen wenn dieser nicht liest was man schreibt bzw. einfach ignoriert.
Was steht denn hier unter punkt 6.

Hatte angenommen alles ausführlich beschrieben zu haben.
Helfe gern wenn ich es kann aber wenn man so was liest

Zitat:

Finde ich zwar irgendwie ein bischen "von hinten durch die Brust ins Auge"

vergeht einem die Lust daran.

Bin raus!

[TERWI]

???
Ich hab das schon gelesen ...
Ist hier auch in etwa das gleiche: Win 10 64 bit, Treiber dito - aber eben eine 'Zubehör-DLL' für erweiterten Zugriff in 32 bit.

Kompilere ich eine 32 bit EXE, kann ich die DLL laden und anwenden. Alles grün.
Als 64 bit kann ich zwar mit LOAD_LIBRARY_AS_DATAFILE laden - hab aber (wie bei MS auch beschrieben) nur Lesezugriff.
Das hilft nur bedingt weiter.

Mit dem 'Spruch' war sinngemäß gemeint, dass man es auch einfacher haben könnte, wenn eben ein kplt. durchgängiger Support in 64 bit vorhanden wäre.