Is it possible to access a 64-bit dll from a 32-bi

问题:

I have a Delphi application similar to Taskbar Shuffle that includes a hook dll.

EDIT: This hook DLL communicates with the main app by sending windows messages.

I want to add support to XP and Vista x64 and my initial idea was to convert the dll to 64-bit (compiling it with FreePascal) but keep the application 32-bit for now (Delphi).

Is it possible for a 32-bit application to access a 64-bit dll?

EDIT2: I'm loading the dll via LoadLibrary so I guess I'm stuck since a 32-bit process won't be able to load a 64-bit dll, according with what I read on the link pointed by Lars Truijens on one of the answers below.

回答1:

No. You'll have to compile two versions: 64-bit and 32-bit.

回答2:

As long as the 64-bit DLL is being loaded by a separate 64-bit process, and all communication between 32-bit process and 64-bit DLL is via loose-coupled IPC-like mechanisms that the OS can marshall, then yes you can do that.

I've done something similar. A 32-bit application needed a custom Print Spooler add-in implemented in a DLL. The app and the spooler add-in communicated via IPC mechanisms (a fancy way of saying temporary files, in this case).

On 64-bit systems everything about the 32-bit application worked fine except that the Print Spooler refused to load the add-in DLL, because the Print Spooler was of course a 64-bit process.

The solution was as simple as rebuilding only the Spooler add-in in 64-bit. No need to change the entire 32-bit app.

回答3:

I just found out this solution, from CodeCentral: http://cc.embarcadero.com/Author/802978

It allows to call any 64 bit library from 32 bit code.

It's a complex solution, running an asm-written 64 bit executable in the background, then communicating with it using memory mapped files and windows GDI messages to launch some 64 bit functions from a 32 bit Delphi process.

There is a sample which is able to load any 64 bit library, then call any function of this library, from a 32 bit executable.

Seems to work well. In all cases, code is worth looking at it: it's technical, but well designed!

回答4:

No, but you might be able to get around that using COM. If you run the dll inside a COM object which is running as a stand-alone process, and communicate with marshallable interfaces (eg: automation-compatible interfaces), it should work. It's not always feasible, depending on what the dll does and how extensive the integration and call surfaces are, but it is an option which should be able to make that scenario possible.