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

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.

From stackoverflow

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

  smartins : Even if the hook dll only task is to communicate with the main app to send windows messages?

  Lars Truijens : Not, the 32bit dll gets loaded in the 64bit process or the other way around. If that not is the case, then there is no problem.

• 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.

  Lars Truijens : Only if it is an out of process COM Service, like an EXE, DCOM or COM+. Otherwise the COM dll would be loaded into your process and has to have been build for the same platform.

• 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.

  smartins : 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.

• Also see http://stackoverflow.com/questions/34294/64bit-memory-allocation

  smartins : I'm actually 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 post you indicated.