Why CLR is two-in-one on 64bit platform

As I mentioned in my previous post when we install .Net framework on a 64bit machine we put both 32 bit and 64 bit runtimes on it. A reasonable question is “Why do we need 32 bit runtime on a 64 bit machine?”. The answer is “To enable your .Net app to run as a 32 bit process on a 64 bit platform”.

One of important features of 64bit platforms is ability to execute both native 64 bit code and 32 bit x86 code. The problem is that 32 bit and 64 bit native code cannot be mixed within the same process. There are many conceptual and technical problems that make this impossible or not worth doing. As a result if you have a component which is 32bit and has to be loaded into the client’s address space, the whole process must be running as 32bit process as well. This scenario is relatively common and includes 32bit dlls, COM32 inproc servers etc. Obviously unmanaged applications are never impacted by this feature as they are precompiled for a particular architecture so no client-server bitness mismatch can occur.

Now imagine the following scenario. There is some very cool .Net application that uses some COM32 component that does not have 64bit counterpart (note that most platform components have both 32bit and 64bit implementation on 64bit OS). It would be just wrong if your .Net app would be jit-compiled into 64bit code and loaded as a 64bit process as it would not be able to use the 32bit component that it needs. Ooops! We need x86 CLR here.

To resolve this situation both 32 bit and 64 bit .Net runtimes are installed at the same time and there is a way to tell the OS process loader whether a managed application requires loading in a particular way. If you use VB, then you can use /platform switch to tag your executables as requiring a particular platform.