New 64-bit material available on MSDN

This new site covers common 64-bit questions about the .NET FX and gives examples.  I’m often asked a few FAQ’s, so let me answer them right here:

  • Version 2.0 (Whidbey) is the first version to support 64-bit.
  • Versions 1.1 (SP1) will run only as 32-bit in the WOW
  • V2.0 supports x64 processors (AMD Opertron, Intel EM64T), as well as the Intel Itanium (IA64).  In fact, you can see a tour of our lab running all this hardware on Channel 9.
  • Whidbey Beta 1 and subsequent CTP’s already support 64-bit, so you can down load and try it out today
  • Pure and type safe MSIL code (VB.Net, C# without the unsafe keyword, etc) can be JIT compiled automatically to 64-bit instructions.  We only ship one copy of the BCL and System.* with the FX using this technique.
  • The most important piece of advice to write 64-bit capable code is to use IntPtr in your interop definitions and run FxCop.  More hints on the site.
  • If you use pure code and run the FxCop rules cleanly, your code should generally just work on 64-bit.  We had a lot of good experience while bootstrapping the system.  The more unmanaged code and interop you do, the more of a traditional bootstrap it will feel like for you.  But if you ever lived through something like Win32s or the 16-bit macro crackers, this will feel like heaven <g>

If you have feedback on the 64-bit support or questions, please do let us know. 

So tell me, do you have an application that can use the extra processing power and address space of 64-bit?  What chips do you think you’ll be running on over the next five years?

Comments (2)

  1. SBC says:

    Is there another version of Whidbey to run on 64-bit or is it the same 32bit verision with additional components installed? I couldn’t gather that difference..

  2. Jason Zander says:

    There are multiple redist packages, one for x86, x64, and ia64. For Beta 1, you can use these links:

    [x86 – dotnetfx.exe]

    [x64 – netfx64.exe]

    [ia64 – netfx64.exe]

    We need one per CPU to deliver the unmanaged portion of the CLR engine for each. The copy of the BCL/System.* in each is the same. There is also a CPU neutral portion of the GAC to allow you to bind to the same file from either 32-bit or 64-bit as required.