0

My understanding of "AnyCPU" when compiling .NET programs is that the compiled EXEs/DLLs should run on both x86 and x64 (and other?) CPUs.

I imagine that the generated Intermediate Language is translated by the Just-In-Time compiler to the relevant machine code, and that the .NET runtime knows the target CPU, so this makes sense.

What I don't understand is how an EXE (and therefore the JIT compiler / CLR) actually starts up; surely some machine code needs to exist at the entry point of the program? Wouldn't the target CPU architecture then need to be known ahead of compilation?

[Edit: Removed disassembled code, as I was looking at the wrong address]

What I didn't realise when I originally posted this question is how similar x86 and x64 machine code is, so my guess is that the code at the entry point is generated to work on both x86 and x64.

Samuel B
  • 36
  • 2
  • It is a lot more complicated than it looks, creating a 64-bit process out of a 32-bit .exe file takes [significant tricks](https://stackoverflow.com/a/10392396/17034). That's not so relevant anymore, .NETCore requires an explicit host, either dotnet.exe or apphost.exe (renamed to the project name) when you build with VS. The choice of host locks in the bitness. – Hans Passant Oct 16 '21 at 22:22
  • I don't quite follow what you're saying. First, the case I'm really interested in (which is what I'm seeing on compile) is how an apparently 64-bit EXE would run on a 32-bit machine. Second, if I double-click my EXE, it surely runs as a native EXE regardless of whether or not I have any .NET framework installed. Sure, it'll fail later, but it'll run far enough to tell me I need the framework, right? – Samuel B Oct 17 '21 at 22:13

1 Answers1

-1

There seems to be some flags that operating system checks before the code executes and decides if it needs to return BadImageFormatException error or runs the program (based on the x86 or x64 compilation method); the Any CPU option basically is a 32 bit compiled version that can easily run on 64 bit OS too, because in a 64-bit windows system, both the 32-bit and 64-bit versions of system dlls are stored. For more information read this Dr.Zone page which I quote a part of it here:

when using that flavor of anycpu, the semantics are the following:

  • if the process runs on a 32-bit windows system, it runs as a 32-bit process. il is compiled to x86 machine code.
  • if the process runs on a 64-bit windows system, it runs as a 32-bit process. il is compiled to x86 machine code.
  • if the process runs on an arm windows system, it runs as a 32-bit process. il is compiled to arm machine code.

Also read this similar question in StackOverflow

iѕєρєня
  • 524
  • 4
  • 14
  • "...the Any CPU option basically is a 32 bit compiled version that can easily run on 64 bit OS too" - I don't think this is true though, the "AnyCPU" program that I compiled appears to be 64-bit from a purely "native" EXE perspective. By that, I mean that the PE Optional Header section has the magic number 0x20b, which I understand to be the bitness flag and meaning 64-bit. – Samuel B Oct 16 '21 at 00:07
  • That extract from DZone also refers to "AnyCPU 32-bit preferred", whereas I'm really interested in the standard "AnyCPU", which the bullet points in the section just above describe. – Samuel B Oct 16 '21 at 00:10
  • well as I understand from this sentence from msdn: **anycpu (default) compiles your assembly to run on any platform. Your application runs as a 64-bit process whenever possible and falls back to 32-bit when only that mode is available.** it compiles to both architectures and starts with x64, if it fails it jumps to 32 bit part of the code. you should check any cpu compiled binary headers on both x64 and x86 to figure out exactly how it operates. @SamuelB – iѕєρєня Oct 16 '21 at 00:28
  • there is also the matter of JIT compiler which compiles the code to required architecture as it requires. An AnyCPU assembly will JIT to 64-bit code when loaded into a 64-bit process and 32 bit when loaded into a 32-bit process. Also look at this [image](https://i.stack.imgur.com/xzfCG.png). – iѕєρєня Oct 16 '21 at 00:31