64-Bit .NET FrameworkQuick Links 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: - Memory intensive - Access to greater memory (16 TB vs. 4G) enables large data sets to be loaded entirely into memory, reducing the need for slower disk I/O, resulting in increased performance, which is important for database servers. In addition, processing more data (64 vs. 32 bits) per clock cycle is important for applications that process a lot of data like video composition and animation.
- Compute intensive - The ability to perform numeric calculations faster is especially important in high-performance computing (engineering domains, scientific & financial computing, etc.) as numeric calculations that took hours to perform on 32-bit computers can now be performed in minutes on 64-bit computers.
The 64-bit version of the .NET Framework 2.0 has the same components as the 32-bit version: - The Common Language Runtime (CLR)
- The Framework Class Libraries (FCL) - e.g. WinForms, ASP.NET, ADO.NET, etc.
- The .NET Framework Software Development Kit (SDK)
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. 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: | 32-bit vs 64-bit Platform Difference | Description |
|---|
| Floating-point | Sections of the IEEE 754 standard for floating-point arithmetic indicate that the results of certain operations may be indeterminate or platform-specific. For example, Sin(1e37), or Sin(any number at the edge of its resolution) results in a platform-specific answer. | | Pointer size | On 32-bit platforms, pointers are 32-bits (4 bytes). On 64-bit platforms, pointers are 64-bits (8 bytes). | | Memory alignment | On 32-bit platforms, types are aligned on boundaries of the natural lengths (1, 2, 4, and 8 bytes). On 64-bit platforms, types are aligned on their natural lengths (1, 2, 4, 8, 10, and 16 bytes), except items that are greater than 8 bytes in length. Those are aligned on the next power-of-two boundary. For example, 10-byte data items are aligned on 16-byte boundaries. |
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: | 32-bit vs 64-bit Platform Difference | Recommendation(s) |
|---|
| Floating-point | - Do NOT perform comparisons for direct equality between floating-point numbers because you MAY end up with a very small difference between numbers
- Test your results on both platforms
| | Pointer size | - Use IntPtr.Size to determine native pointer size
| | Memory alignment | - When marshaling data structures to/from the underlying platform:
- Align data on natural boundaries using StructLayoutAttribute:
- LayoutKind.Sequential - Use appropriate PackingSize
- LayoutKind.Explicit - Use appropriate FieldOffset
- Use Marshal.SizeOf to determine the actual size of native structures and types
| | Native code | - NO loading 32-bit DLLs into 64-bit processes
- NO loading 64-bit DLLs into 32-bit processes
- NO loading 32-bit COM InProc servers into 64-bit processes
- No loading 64-bit COM InProc servers into 32-bit processes
- Remote procedure calls (RPC) ARE SUPPORTED between 64-bit and 32-bit processes (both on the same computer and across computers)
|
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: - The 64-bit .NET Framework SDK - which includes 64-bit hosted command-line compilers for C#, VB.NET and J# as well as a 64-bit C/C++ cross-compiler, debuggers and a variety of other development and administrative tools
- Visual Studio 2005 – which provides a Graphical User Interface (GUI)-based Integrated Development Environment (IDE) that provides project management and a variety of developer productivity features
Leveraging existing investments in .NET Framework development tools and techniques greatly reduces the time and financial costs associated with developing 64-bit applications.
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: - The Intel Itanium (IA64) processor family which is based on Explicitly Parallel Instruction Computing (EPIC)
- x64 processors like the AMD Opteron and Intel Xeon with Extended Memory 64 Technology (EM64T) which are based on extensions to the x86 instruction set
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. |
|