[10/15, 2:04pm, fixed a couple typos; 10/15, 4:51pm, clarified a point]
Before you read this entry, you might want to read these two entries:
In case you skipped the link and kept on reading I’ll summarize the first post linked to (I however believe that they are really worth reading):
- “Bitness” is what we call an assembly’s ability to tell the OS and CLR what type of machine the assembly is safe to run on (32-bit vs. 64-bit, and on 64-bit: X64, IA64 or both).
- There are things that you can do in a managed assembly which force you to need to bind it to one platform; these include: p/invoke, unsafe code, managed c++, etc…
The point is, in v1.0 and v1.1 we let you create assemblies that might very well have problems running on a 64bit platform, because of that we have decided that with
We have gone back and forth on the right way to do this and have settled on the following:
- MinorRuntimeVersion <5 will be used by the OS Loader to determine if the assembly is a
- This will cause only
For reference, here is the definition of the IMAGE_COR20_HEADER:
// CLR 2.0 header structure.
// Header versioning
// Symbol table and startup information
// Binding information
// Regular fixup and binding information
// Precompiled image info (internal use only - set to zero)
It turns out that the 2.0 in the header structure name is kind of a misnomer and results from some pre-1.0 definitions of this structure. All released versions of the
What does this mean?
Well, it means that if you have a v1.0/1.1 assembly and run it on a 64-bit box with
NOTE: /platform:anycpu doesn’t keep you from shooting yourself in the foot with a bad P/Invoke signature, unsafe code, etc… See this (http://blogs.msdn.com/joshwil/archive/2004/03/16/90612.aspx) blog entry for an example.
If you do have a managed v1.0/1.1 app which you believe to be 64-bit safe and whidbey compatible there is an easy way to make it run in 64-bit mode… You just have to whack the MinorRuntimeVersion to 5 in the IMAGE_COR20_HEADER for the image. Along these lines there will be a tool in the
WARNING: If you don’t know what’s going on inside of some v1.0/1.1 image (if you didn’t write it say) you should be _VERY_ careful bumping it up to 64-bit as it may break in unexpected ways.
If you are a compiler writer and you want your application to run in 64-bit native mode under
What about v1.0/1.1 dlls?
If you make a
Appendix: Why I think this is a good solution:
There are a number of ways in which we could have solved this problem. An easy one would have been to use the version string contained within the metadata for managed images. That string looks something like “v1.1.4322”, it represents the version of the framework which the assembly was compiled against, and
This however forces a tight binding between the runtime version and the compiler version, and doesn’t recognize the fact that there are plenty of assemblies compiled against the v1.0/1.1 frameworks that will run fine in 64-bit mode under v2.0. But even given that, its downfall is that it is a very Microsoft centric view, it assumes that the compilers will be updated at the same time as the runtime (which currently our compilers are). That tight binding wouldn’t recognize that there are compilers out there that only produce code which is safe to run in either 32-bit or 64-bit mode. Those compilers currently produce an image that works with the v1.0 or v1.1 runtime, and the compiler vendors may very well want to produce an image that also runs in 64-bit mode under the v2.0 runtime.
That’s the distinction, while Microsoft is producing compilers in this version of
This does put a great responsibility upon compiler vendors who chose to produce images that are marked this way, those compilers should only produce code which is safe to run in both 32-bit and 64-bit mode. Alternatively, they can do as our compilers do and let you shoot yourself in the foot if you want to by producing MSIL images with bad P/Invoke signatures and unsafe code… That puts the onus on the developer.