So I know that if you compile for Any CPU, you get an MSIL output. If you compile as x86, you get an x86 output.
My understanding of the process is like as follows
.NET Code -> Compiler -> MSIL -> JIT compiled in CLR -> Native Instruction
My question is if you compile in x86/x64, does that skip the MSIL -> JIT compiled in CLR step above? Or is my understanding off?
Your understanding is not quite correct. Providing the assembly consists of only managed code, it will always be compiled to pure MSIL, regardless of the compiler setting (AnyCPU/x86/x64), so even if you compile as x86, you still get MSIL.
If you compile as AnyCPU, then your assembly can run as or be loaded into a 32 bit or 64 bit process, whereas if it's compiled as x86, it can only run as (or be loaded into) a 32 bit process. Similarly, when compiled as x64, it can only run as (or be loaded into) a 64 bit process. The same MSIL is used in either case, and the JIT compiles the MSIL to the required 32/64 bit native code.
Related
Visual studio 2015/2017/2019/2022 all come with (somewhat hidden) compiler for 32-bit ARM processors. The 64-bit ARM Windows also comes with support for running 32-bit applications. However, after I built some C++ applications using that 32-bit compiler I find myself unable to actually run it because build rules for most software include /MD compile flag which links the exe/dll-s against the dynamic VS runtime in a few dll-s (vcruntime140.dll, etc.). My arm system is missing that runtime (at least the arm version) and I cannot find it anywhere. All the publicly available runtime downloads include only x86, x64 and arm64.
What am I missing? Building modern software with the runtime linked-in is inefficient and often will not work correctly due to sharing runtime-specific structures across library boundaries. But the dynamic runtimes are nowhere to be found. Is 32-bit ARM considered deprecated or only useful for simple single-binary embedded applications? Or is there something about arm platform which makes linked-in runtimes work for applications spanning multiple binaries? Are the arm runtime installers available in some dark corner?
I have a 32-bit object file o.obj and want to use it in a project that uses a 64-bit library l.lib.
To make the .lib happy, the Visual Studio configuration needs to be set to x64. However, the linker then throws an error of error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'.
I went through Visual Studio's linker options, but nothing jumped out. Is there a way to resolve this error?
I was under the impression that any 32-bit code is also compatible with 64-bit systems, modulo libraries.
x86 executables (that is, object code compiled for 32-bit x86 processors) can be executed on x64 machines running 64-bit operating systems, through a special compatibility mode supported jointly by the processor and the operating system. This is feasible because the x86 instruction set is a subset of the x64 instruction set.
However, many elements of the ABI differ between x86 and x64 code, notably calling conventions and pointer size. The calling convention needs to match between the calling code and the called code, or things will screw up. Thus, there is no straightforward way to call 64-bit code from 32-bit code, or vice versa.
I want to to compile my C++ code into PowerPC ELF file which is Big Endian, i'm on windows and i already have GCC compiler installed with Eclipse, CodeBlocks, Visual Studio, RAD C++ Builder, and Qt, each one has specific use, can that be done with GCC? or is there any other compiler for that?
See the compiler options here:
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html
I am not very experienced. Just trying to make some changes to source code that someone else wrote.
I had to add a reference to a .dll to get it to work in "Release" mode. However when I try to get it to work in Debug, it does not work. (assembly reference not loaded).
Help?
It looks like the Chillkat dot net is a actually a mixed mode assembly and it's quiet possible that you need to have the appropriate c runtime as well. This exception and a way to fix this is documented here
Hope this helps.
Typically I get this error when the executable is x86 and the dll it's referencing is x64. Check your build configurations to make sure it's targeting the correct platform.
In VS2013 go to Build -> Configuration Manager. There should be a drop down in the top left of the new window which contains the different build modes. Compare Debug to Release.
BadImageFormatException is one exception thrown from the execution engine when you are trying to load one assembly compiled for a specific platform in another platform.
Example A
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in X86
all work fine in x86 machine and x64 operating system
Example B
- project A, compiled as X86
- project B, compiled as X86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example C
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in AnyCPU
all work fine in x86 operating system
this throw exception in x64 OS (executable is in AnyCPU so it's run on x64 engine, so can't load x86 dll's)
Example D
- project A, compiled as AnyCPU
- project B, compiled as x86
- executable, compiled in x86
all work fine in x86 operating system
all work fine in x64 operating system
the exe is compiled specifically for x86 platform, so also in x64 machine run under x86 mode.
Conclusion
Visual studio run projects in OS configuration, so in debug mode if you don't have a specific x86 configuration for starting project and try to execute an x86 referenced dll it will fail
I have a problem related to this question. Two players:
C# application
Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.