C # - mixed assembly (C ++ / CLI, DirectX native) interplay (32/64 bit)

Question

I have a problem with this question . Two players:

• C # application
• Mixed assembly used 1)

The application should support anything: from Windows XP (32 bit) to Windows 7 (32 and 64 bit). Assembly is complex in many ways. It contains C ++ / CLI managed code and some native C ++ classes dancing with native DirectX. It is also associated with several 32-bit native dlls without access to the source (containing C ++ classes with import libraries).

Everything works well in a 32-bit environment (XP and 7 tested), including the 32-bit subsystem in Windows 7. Havoc happens as soon as “Any processor” is used on 64-bit systems to build a complete solution. The 32-bit assembly is unsuitable for use, but, apparently, only in debug mode ("unable to load, incorrect format", etc.). It seems to work in release. A 64-bit build assembly is prevented by implicit dependencies on the mentioned 32-bit third-party dlls.

Is there a way to provide a real native 64-bit application capable of using assembly?

The assembly requirement is not strict. It can be either 32 or 64-bit, but, as mentioned above, it must be accessible from the application one way or another.

Answer 1

On a 64-bit version of Windows, you are faced with a hard limit; a 64-bit process cannot execute any 32-bit machine code in the process. You, of course, depend on machine code when using C ++ / CLI and working with DirectX. Although this does not look like you cannot run in 64-bit mode, C ++ / CLI and DirectX can be compiled / available in 64-bit.

Then it comes down to the build and deployment problem. You need to build C ++ / CLI projects in 64-bit mode and deploy only 64-bit components in a 64-bit operating system. A core exe must be built for AnyCPU. Similarly, on a 32-bit operating system, you should only create and deploy a 32-bit compiled version. You solve the build problem by adding the x64 configuration to the solution so that you separately separate the 32-bit and 64-bit versions. You solve the deployment problem by creating two installers.

Since in any case you need to support a 32-bit operating system, a simple solution is to change the Target platform setting on your x86 exe project. Now everything always works in 32-bit mode, and you do not need to worry about the headaches of assembly and deployment. The only thing you missed is the larger virtual memory address space available in the 64-bit version.

Answer 2

Forget about the C ++ / CLI project for a minute.

You have third-party 32-bit DLLs. They CANNOT boot in 64-bit mode. Thus, your main application should be 32-bit. This limitation has nothing to do with the C ++ / CLI broker.

The only way you can use these DLL files from a 64-bit application is to load them into a separate (32-bit) process and marshal the data back and forth.