Accessing 32 bit DLLs' from 64 bit code

A 64-bit process cannot load a 32-bit module into its process space, and a 32-bit processes cannot load a 64-bit module into its process space. The only way that communication can happen between 32-bit and 64-bit modules is through interprocess communication (IPC).

In other words, 32-bit and 64-bit processes can exchange data using IPC techniques such as out-of-process COM, sockets, Windows messages or memory mapped files.

A 32-bit software product contains the main module which calls into the DLL. As long as both the main module and the DLL are 32-bit processes the product can run on both 32-bit and 64-bit platforms. If both the main module and the DLL are migrated to the 64-bit platform, then they can both run in a native 64-bit process. However if only the main module is migrated to 64-bit, it will not be able to load the 32-bit DLL.
The best way to migrate such a product to a 64-bit platform is to migrate both the main module and the dependency DLL, but if the dependency DLL cannot be migrated then it cannot be loaded into the 64-bit process and the application won't work.

Alignment in Memory: The alignment of data in memory is different for 32-bit and 64-bit processes. This means that your more complicated custom data structures may be serialized by a 32-bit process in a way that is different to that expected by a 64-bit process, and vice versa.

Datatype Size: The differences are mainly in pointers which are 32 bits long in 32-bit platform and 64 bits long in 64-bit platform. The pointer-derived data types such as HANDLE and HWND (Windows) are also different between 32-bit and 64-bit versions.

More on Accessing 32 bit DLLs' from 64 bit code