I was compiling a .NET application targeting x86-64; however, the application references a 32-bit dll. The executable compiles fine, but Visual Studio throws a warning:
Referenced assemply ‘path/to/dll’ targets a different processor than the application.
Now, my understanding has been that you can’t simply link a 64-bit executable to a 32-bit shared library. What black magic does .NET (or Windows?) use to accomplish this?
I have noticed a considerable memory footprint difference when the application is built targeting x86 and x86-64. When the 32-bit dll is dynamically loaded and begins processing, the memory footprint of the 64-bit application will be about 60 MB larger (250MB as 64-bit vs 190MB as 32-bit) than if the application is built as a 32-bit app. This difference is only so great when a certain code path in the dll is hit, however, and I can’t look into the dll to see the internals, unfortunately.
How is it possible that a 64-bit binary is linked to a 32-bit shared library? Wouldn’t the 32-bit ABI prevent this?
Why would there be such a large different between the memory footprint when the application is compiled as a x86-64 architecture?
Any other info to look into to explain this would be appreciated.
x86 and x64 can’t be loaded into the same process. Are you sure that the reference isn’t an AnyCPU assembly, or that the 32-bit reference doesn’t have a 64-bit or AnyCPU version in the GAC?
Also note that on 64-bit Windows, DLLs in System32 are 64-bit. 32-bit ones are in SysWOW64.