Author: Nikolay Martyshchenko
In mid-nineties, migration from 16-bit to 32-bit systems ran its course: on one hand, advantages of 32-bit applications were quite obvious; on the other hand, porting drove developers mad because it required studying of a new memory model, new API and changing pointer arithmetic.
Today the whole situation repeats itself but now developers have to deal with moving from 32-bit applications to 64-bit ones. Lucky we are, changes are much more moderate this time and in most cases software developers do not need to do much to successfully launch a 32-bit application on a 64-bit system. Due to virtualization technologies and CLR specifics, a .NET application becomes 64-bit automatically.
It is comparatively simple for unmanaged applications: if they are compiled as 32-bit applications, they will work using Windows-on-Windows (WoW64) which provides a compatible environment for "transparent" execution of 32-bit applications in all 64-bit Windows versions.
In case of a managed application, presence of some issues occurring during porting from a 32-bit operating system to a 64-bit one might look strange because managed code is technically independent from capacity of operating system and processor (actually, there is a stub there but it is not used since the boot loader in all the contemporary operating systems including the latest 64-bit ones knows about managed code directly). However, there are some traps you might fall into.
- using x86 compilation mode, build will be launched in a 32-bit x86-compatible CLR;
- in case of Itanium, an application will be compiled to work under a 64-bit CLR on computers with the Itanium processor. They are intending to stop supporting this platform;
- an application, compiled using x64 compilation mode could be executed only 64-bit CLR on computer with processors that support AMD64 or EM64T instruction set;
- AnyCPU enables cross-platform build compilation.
This separation appears due to the necessity of obsolete code -although .NET application do not depend on operating system's capacity itself, it may depend on unmanaged code, for instance, on some additional components the developers decided to use in application development for some reasons. These additional components/libraries often become a burden that restrains a managed application and does not allow to gain benefit from an independent architecture.
In a 64-bit operating system:
- builds compiled in the x86 mode will be executed by 32-bit CLR under WoW64;
- AnyCPU executable files will be executed by 64-bit CLR;
- AnyCPU DLL libraries will be executed by the same CLR as the process that loaded them.
To make it clearer, we arranged this information in a table. The columns reflect information about models of executable files while rows represent dynamic libraries. The cells show if it is possible to load a corresponding DLL.
32-bit operating system:
64-bit operating system:
For unmanaged applications, information about the platform is saved in the PE header, so you need a dumper to view it. You may use standard means: dumpbin /HEADERS - now this functionality is integrated into link.exe /dump /HEADERS. The main thing you should consider in dump is the target machine: 8664 machine (x64), 14C machine (x86). As an alternative, you may use PEDump by Matt Pietrek but it has some issues: you will have to decode the x64 value manually (8664), x86 has name (i386) and it crashes when analyzing 64-bit DLL's under 64-bit Windows 7, though it manages to display the header before crashing. If you wish, you may fix the source code to avoid this problem if you are not satisfied with link.exe /dump for some reason.
Do we have to move to 64 bits?
Like with any other question related to performance, the answer depends on a particular situation. Anyway, the following pros and cons should be taken into account.
- the most important advantage of 64-bit processes is increased address space;
- optimized 64-bit mathematics;
- the 64-bit kernel of an operating system uses a larger amount of available memory to improve many aspects of work.
- you need more memory for many operations (pointers occupy a larger size, especially in managed code that contains references all over the code);
- the effective part of processor cash is smaller (if we compare 32-bit and 64-bit modes) due to the same reason;
- the size of code also increases because of additional prefixes and instructions containing 8-byte operands instead of 4-byte ones.
Therefore, any code that works well on 32 bits, contains no 64-bit arithmetic (i.e. in no other ways uses new capabilities of the 64-bit processor) and does not require more than 2 GB of available memory to have only disadvantages when being launched in a 64-bit operating system: a larger size of memory consumed and some operation slow-down.
However, in many cases the benefits outweigh the above mentioned disadvantages that is of crucial importance for developers. For instance, many applications reach the memory limit. Besides, port to 64-bit mathematics provides a significant performance gain for some applications. For instance, it holds true for applications working with graphics, video coding, etc.
- development for two various modes (32-bit mode and 64-bit mode) raises a product complexity and testing cost. It is very often unclear that if an application depends on unmanaged code, you must make sure that you can get these components in the both versions and, most importantly, that the necessary version is selected automatically in each case. Usually you can solve this problem rather simply through the operating system redirection functions but sometimes issues are possible.
- some of capabilities are not available in the 64-bit mode: debugging of x64 code was added only in CLR v4 while it had been only mixed mode before (x86). The "edit-and-continue" function still isn't supported in x64, and the same thing happened to the Historical Debugging option (IntelliTrace) in VS 2010. This is the consequence of usage different codebases (for instance, completely separate JIT compilers for 32 bits and 64 bits) that forces you to make a compromise and renders it impossible to implement some functionality due to huge time costs.
- from the performance viewpoint, pointer size gets larger, so the size of data structures also increases while the processor cache remains the same (i.e. its effective part is reduced) - all this causes mere performance loss in general. In other words, you are sitting in a pit and try to get out using additional memory of more than 4 GB as an auxiliary means. Yes, it maybe helpful for some huge projects, but you'd better start with optimizing the size of used structures - it will enable you to increase processing rate for at the same memory consumtion.
- from the cost viewpoint, the most economical way to port Visual Studio to 64 bits is to rewrite its major part into managed code and then finish writing the rest. The cost of such a porting is very high, besides it will cause all known extensions to stop working, so we will have to create a new 64-bit ecosystem like it was done for drivers. Certainly there are people that could take advantage of a new 64-bit version but still it is better to spend this money on reducing consumed memory of IDE than porting.
Possible problems during the porting
Like with a 32-bit operating system, there is a 2GB limit for a size of one object that can be created by a 64-bit managed application running under a 64-bit operating system.
In many cases, builds work the same way in the 32-bit and 64-bit versions of CLR. The main reasons why execution in the 64-bit CLR environment might differ are the following:
- difference of sizes of structures withmembers of platform-dependent size, for instance, pointers;
- pointer arithmetic including operations with definition of constant sizes;
- incorrect definition of P/Invoke or COM-object defining Int32 for handles instead of IntPtr;
- conversion of IntPtr into Int32 during marshalling.
We cannot cover all available material in one article, so I recommend you several links for further reading.
Recommended articles / sites
Find out what is involved in migrating 32-bit managed applications to 64-bit, issues that can impact migration, and the tools that are available to assist you.
Site for C/C++ developers of 64-bit and parallel applications.
A wonderful resource devoted to the whole 64-bit world. Do not miss technological articles.
The site is devoted to the topic of x64. You may download the latest new x64 software (currently we are laying out only free software for Windows x64) and read interesting articles about 64-bit programs and systems on our site.
Extended64 is a website dedicated to the 64-bit Windows platform. Our goal is to help users of all kinds, from the most experienced IT Professionals and Application Developers, to the home user who is just starting with 64-bit. Lead by highly experienced technology experts, Extended64 is a collaborative community where our members get to write their own tips and guides, ask questions, and answer other people's questions.
x(perts)64 - The unofficial x64 FAQ
The mission of 64bits.net is to explore all aspects of the 64 bit generation of computing systems from the gory technical details to the issues that drive the business need for these systems.
64-bit processors, operating systems and separate applications appeared a rather long time ago. But quite not all the users have moved to 64 bits completely. The article discusses the reasons why.
Good question. And here is the answer in a single sentence: We have everything and still, we have nothing. Of course, this sounds cynical and highly biased. The truth lies somewhere in the middle. It will probably be best for us to take a look around. A detailed analysis.
Windows x64 - All the Same Yet Very Different, Part 1: Virtual Memory, Part 2: Kernel Memory, /3GB, PTEs, (Non-) Paged Pool, Part 3: CPUs, AMD64, Intel 64, EM64T, Itanium, Part 4: Code Trees, Drivers, Part 5: NTVDM, Services, WoW64, Part 6: COM, DLLs and Processes, Part 7: File System and Registry Redirection, Registry Reflection , x64? My Terminal Servers Run Just Fine With 32 Bits and 8/12/16 GB RAM!, x64 Divided by Two is NOT x32!
A series of articles on Windows x64, changes that took place, crucial restrictions of the x86-32 platform, specifics of processes and development on 64-bit platforms.
The article discusses basic steps providing correct migration of 32-bit Windows applications to 64-bit Windows systems. Although the article is intended for developers that use C/C++ in the Visual Studio 2005/2008 environment, it will be useful for other developers as well who intend to port their applications to 64-bit systems.
64-Bit .NET Framework Development (MSDN Forum)
Need help making your .net applications (any language) work on 64-bit? Ask your questions here!
Information on features in the Visual Studio development environment that help you create 64-bit applications.
The article briefly discusses the AMD64 architecture by AMD company and its implementation EM64T by Intel company. It describes the specifics of the architecture, its capabilities, advantages and disadvantages.
x86-64 (also x64/AMD64/Intel64/EM64T) is a 64-bitharware platform: microprocessor architecture and corresponding instruction set and chipset developed by AMD company. This is an extension of the x86 architecture with full backward compatibility. Microsoft and Sun Microsystems corporations use the term "x64" for this instruction set, but the folder with files for the architecture in Microsoft distribution packages is named "amd64" (compare "i386" for the x86 architecture).
This article describes some compatibility issues for 32-bit programs in 64-bit versions of Windows Server 2003 and Windows XP. It compares 32-bit and 64-bit versions of Windows Server 2003, Windows XP or other 64-bit operating systems. The author of the article assumes that the readers understand the difference between 32-bit and 64-bit binary codes.
In this article, I will share with you the essence of my knowledge in the sphere of Win64 and x64 architecture - that minimum any skillful Win32-programmer must have to move to the x64 platform. I am proceeding from the assumption that you already know the basic concepts of Win32 and x86 platform and understand what for your code must work in the Win64 mode. It will let me focus on our basic topic. Well, take my article as a review where we consider only the most important differences between the architectures Win64/x64 and Win32/x86.
Beginning in Visual Studio 2005 you can compile your application and specify that it should run on a 64-bit operating system either as a native application or under WOW64. WOW64 is a compatibility environment provided by the operating system that allows a 32-bit application to run on a Windows 64-bit operating system.
Microsoft has released 64-bit versions of the Windows operating system, such as 64-bit Windows Vista, Windows XP Professional x64 Edition, and Windows Server 2003 R2 x64 Enterprise Edition. 64-bit Windows was designed with compatibility in mind. Developers can ensure that their existing 32-bit applications run well under 64-bit Windows or take advantage of the benefits of 64-bit Windows by migrating their applications.
In this article, you are going to learn the basics of moving your ,.NET & C# applications to 64-bit systems. Along the way, you are also going to learn a bit about memory management, code compatibility, and discover migration tips.
PAE is an Intel-provided memory address extension that enables support of greater than 4 GB of physical memory for most 32-bit (IA-32) Intel Pentium Pro and later platforms. This article provides information to help device driver developers implement Windows drivers that support PAE.
The current version of 64-bit Windows supports the x64 and Intel Itanium Processor Family, and is built for the highest levels of scalability. It has support for up to 64 processors and 16-terabyte (TB) of memory (architectural limit). This page contains links to information for developers interested in creating 64-bit applications.
Here's the guts of a response that I posted a while back to an internal mailing list re: tradeoffs of running your managed code as 64-bit vs 32-bit. YMMV, and I'll remind you that every perf question has a thousand answers depending on the situation.
Over the past few months I've had some interesting debates with folks here (and some customers) about the cost/benefit trade-off of "AnyCPU" (architecture-neutral) managed EXEs. I think we've converged on a consensus that most of the time they're not what you want and so shouldn't be the default in Visual Studio. I suspect this topic may interest (and even shock) some folks, so I thought I'd share the rationale with you here.
From time to time customers or partners ask me about our plans to create a 64 bit version of Visual Studio. When is it coming? Why aren't we making it a priority? Haven't we noticed that 64 bit PC's are very popular? Things like that. We just had an internal discussion about "the 64 bit issue" and so I thought I would elaborate a bit on that discussion for the blog-o-sphere.