64-bit and 32-bit Processes

[This is preliminary documentation and subject to change.]

This section assumes that you are familiar with the Component Object Model (COM). It is outside the scope of this document to discuss COM. Please see Inside COM by Dale Rogerson, ISBN:1-57231-349-8, Microsoft Press, and Inside Distributed COM by Guy Eddon and Henry Eddon, ISBN: 1-57231-849-X, Microsoft Press.

On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL. However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers). On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client. Therefore, if you have a 32-bit DLL that is not COM-aware, you can wrap it in an out-of-process COM server and use COM to marshal calls to and from a 64-bit process.

In-process servers are currently registered using the InprocServer registry entry. On 64-bit Windows, 64-bit and 32-bit in-process servers should use the InprocServer32 entry.

To port handles, which by their nature are local to the computer and would never be used across the 32-bit to 64-bit boundary, use the HANDLE_PTR type instead of the INT_PTR or DWORD_PTR type. This includes porting RPC interfaces passing such handles as DWORD values. The 64-bit HANDLE_PTR is 64 bytes on the wire (not truncated) and thus does not need mapping.

For more information, see Designing 64-bit-Compatible Interfaces.