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?

Published 01 December 04 02:10 by Anonymous

Filed under: CLR

Comments

# SBC said on December 1, 2004 3:03 PM:: 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..
# Jason Zander said on December 1, 2004 3:56 PM:: There are multiple redist packages, one for x86, x64, and ia64. For Beta 1, you can use these links:

[x86 - dotnetfx.exe] http://www.microsoft.com/downloads/details.aspx?FamilyID=B7ADC595-717C-4EF7-817B-BDEFD6947019&displaylang=en

[x64 - netfx64.exe] http://www.microsoft.com/downloads/details.aspx?familyid=1061FD6F-86D6-4EB3-B70F-C42ED6F49AE8&displaylang=en

[ia64 - netfx64.exe] http://www.microsoft.com/downloads/details.aspx?familyid=F94B0AFF-2981-4223-90EC-CF00A215A934&displaylang=en

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.