64-Bit .NET Framework
The 64-bit version of the .NET Framework 2.0 enables the .NET Framework platform, tools and applications to run on 64-bit workstations and servers which provide increased performance and scalability by addressing more memory (16 TB vs. 4G), processing more data (64 vs. 32 bits) per clock cycle and performing faster numeric calculations.
The increased performance and scalability of today’s 64-bit workstations and servers are ideal for workloads that are:
The 64-bit version of the .NET Framework 2.0 has the same components as the 32-bit version:
This allows .NET Framework developers to realize the benefits of 64-bit computing by leveraging their existing investments in .NET Framework code, .NET Framework development tools and techniques, and ultimately in Windows.
Leverage Existing .NET Framework Code
The 64-bit version of the .NET Framework 2.0 allows you to take full advantage of the underlying 64-bit hardware platform without having to deal with differences between the 32-bit and 64-bit hardware platforms:
In most cases, applications developed using the 32-bit .NET Framework can be ported to the 64-bit version of the .NET Framework and executed as 64-bit native applications without any source code modifications. However, 32-bit .NET Framework applications that have floating-point or native code (e.g. DLLs or COM InProc Servers) dependencies may require modifications when porting to 64-platforms.
The key to writing portable code is to write verifiable code. Verifiable code is code that can be proven to be typesafe. .NET Framework applications are built using types defined in class libraries. Each type in a class library defines fields, properties and methods that are used to access the type’s functionality. The fields, properties and methods defined by a type represent a contract between the type (which provides functionality) and the user of the type (which consumes functionality). Typesafe code is code that obeys ALL type contracts. Types represent memory. And the fields, properties and methods defined by types represent ways to access memory. Ultimately, this means that typesafe code is code that doesn’t improperly access memory. And because typesafe code doesn’t improperly access memory, the common language runtime is able to safely execute multiple verifiable applications, each isolated in its own AppDomain, within a single (more expensive) operating system process. Also, because typesafe code doesn’t improperly access memory it also reduces memory corruption which results in a more stable execution environment. The C#, VB.NET, J# and managed C+ compilers that ship with the .NET Framework 2.0 SDK all produce verifiable (typesafe) code. The C#, VB.NET and J# compilers produce verifiable code by default, while the managed C++ compiler produces verifiable (typesafe) code when the /clr:safe flag is used. In addition, the .NET Framework SDK ships a tool (PEVerify.exe) that allows developers to determine if their code is verifiable.
It would be great to never have to know about the differences of the underlying platforms. Unfortunately, there are some situations (e.g. dealing w/floating-point) when developers must be aware of underlying platform specifics. There are also situations when developers may indeed explicitly want or need to deal directly with the underlying platform (e.g. interoperating w/native DLLs or COM InProc Servers). For these situations, the C#, VB.NET, managed C++ and IL compilers that ship with the .NET Framework SDK are also capable of producing “unsafe” code. When dealing directly with the 64-bit hardware platform, here’s a few things you should remember:
Leverage Existing .NET Framework Development Experience
The 64-bit version of the .NET Framework 2.0 allows you to take full advantage of the increased performance and scalability of today’s 64-bit workstations and servers using the same familiar tools and development techniques used for 32-bit .NET Framework application development:
Leverage Existing Windows Investments
The 64-bit version of the .NET Framework 2.0 runs on Windows Server 2003 SP1 64-bit or Windows XP 64-bit, both of which support the two mainstream 64-bit processor architectures available today:
In addition to executing new 64-bit applications, both Windows Server 2003 64-bit and Windows XP 64-bit can execute existing 32-bit applications using the Windows On Windows 64 (WoW64) x86 emulator. Wow64 allows 32-bit productivity applications developed using the .NET Framework 1.0, 1.1 and 2.0 and Win32 to run on 64-bit Windows and take advantage of the 64-bit Windows kernel which offers a larger number of kernel handles and window handles. WoW64 supports 32-bit console, GUI and service application, and although some 32-bit server applications may be certified to run on WoW64, WoW64 is NOT intended for 32-bit server apps. WoW64 does NOT support 16-bit Windows apps. WoW64 emulation is performed natively (on the chip) by the x64 micro-architecture, which means WoW64 performance on x64 is similar to that of 32-bit Windows. However, because the Itanium (IA64) architecture does not support native WoW64 emulation, WoW64 performance on the Itanium is substantially less than that of 32-bit Windows.