Writing 64-Bit Applications for Windows 7 (part 1) - OVERCOMING 64-BIT DEVELOPMENT ISSUES

9/17/2012 3:19:23 AM


You may not see many 64-bit applications today — at least not publicly available applications. Most of the current 64-bit application development is for custom applications. Of course, there's the Office 2010 64-bit version. As you can see from the Advantages section of this white paper, the main reasons to use the 64-bit version are:

  • Access to more memory

  • Larger Excel workbooks

  • Improved Microsoft Project capacity

  • Enhanced security through hardware Data Execution Prevention (DEP)

The list of advantages doesn't mention anything about things that users will notice immediately, such as improved application speed. If you look at the list, the majority of the advantages seem to revolve around size — more memory, bigger workbooks, and larger projects. Still, users will notice these advantages quite quickly if they've been complaining about size as an issue.

Creating a 64-bit application can result in improved application performance, which is the combination of speed, reliability, and security. Here's how those three elements will likely play out for you:

  • Security: Of course, the Office 2010 Website already mentions the security part of the performance picture in the form of DEP. Unfortunately, outside of DEP, 64-bit applications aren't inherently more secure than 32-bit applications. Only the fact that there are fewer 64-bit coded exploits will keep outsiders at bay for the short term, but you can be sure that these nefarious individuals are even now writing 64-bit exploits designed to crack your security.

  • Speed: The speed part of the equation comes from the potential to access more memory. Accessing memory is always going to be faster than accessing the hard drive. With the greatly enhanced memory potential of a 64-bit application, it's possible to read an entire document into memory and access it there, rather than keep reading it from the hard drive. Code access is also faster — you can load DLLs into memory and keep them there, rather than load and unload DLLs to keep memory usage to a minimum. However, any speed gain you want to obtain has to be within the limits of the system's hardware. A 64-bit application won't make the hard drive run any faster or supply the processor with any additional clock cycles.

  • Reliability: You can gain reliability in several ways. By reading a document stored on the network to local memory, you not only improve access speed, but you also insulate the application from intermittent network failures, making it more reliable. Reliability is inversely proportional to the number of parts in an application. Because you can create larger application pieces, it's possible to reduce the application's part count and improve reliability in that manner. Reliability is also inversely proportional to iterations. The fewer the number of iterations, the higher the application reliability. By reading larger pieces of data from the hard drive, for example, you can reduce the probability that an iteration will fail.

There's always a potential for false savings when considering speed or reliability in an application. Reading an entire document from disk when you only intend to use half of it still wastes processing cycles whether you're working with a 32-bit or 64-bit application. Using resources with efficiency in mind is always the best way to improve application speed and reliability.

Some types of application actually require 64-bit support today. For example, if your application uses memory-mapped files, you'll definitely want to upgrade to 64 bits at some point because files are quickly becoming large enough to overwhelm a 32-bit application. It doesn't take long to create a file 4 GB or larger. A 32-bit application simply can't handle the large files that users create today.

Processor-intensive applications greatly benefit from 64 bits because the application can often make use of the larger 64-bit registers to decrease the number of steps required to complete a task. This is especially true when the processor-intensive task is data-oriented. A cryptography routine can run three to five times faster on a 64-bit machine simply by making use of the larger registers to process data more quickly.


Some users express disappointment with the 64-bit environment because their applications don't run any faster. It's important to consider the application load. A Web browser will run only as fast as its Internet connection allows. Switching to a 64-bit environment won't change the speed of the application because the Internet connection speed remains the same. Likewise, a 64-bit word processor won't run any faster because its speed is largely limited by how fast the user can type — most word processors already spend considerable time waiting for the user to do something.

Graphics applications also run considerably faster in a 64-bit environment because graphics applications tend to move huge amounts of data in memory. A 64-bit processor can move data twice as fast for a given clock speed because its registers are twice as large. In the case of graphics applications, the actual application code isn't working much faster, but the data used to feed the application code is able to arrive twice as fast, so the application code spends less time waiting. Given that the amount of graphics in applications is increasing, a 64-bit application will offer significant benefits.

Many applications today also rely heavily on XML. It's interesting to note that developers largely see XML as a disk-intensive task, but it really isn't. XML is a mixed task that requires substantial amounts of processing in certain situations. According to sites like Altova (the makers of XMLSpy), 32-bit systems are limited to opening XML files no larger than 200 MB . The world is quickly moving to larger XML files to store everything from application settings to complete databases.


Moving to a higher-level processor is a painful experience in most cases because many people underestimate the requirements for such a move. After all, simply increasing the size of the registers in the processor doesn't seem to be such a big deal. However, changing the size of the registers is only part of the move. A 64-bit processor has additional registers, larger memory access, increased speed, additional operating modes, and a host of other features that only a hardware engineer will care about. All these differences don't look like much until you start writing native code to access them. Of course, as a .NET developer you won't actually write native code in most cases, but Microsoft has to change Windows to work with the 64-bit processor, which is going to change your application.

Changes in the operating system tend to snowball. The 64-bit operating system requires 64-bit drivers. The new drivers require updated support software, and so on. Moving to 64 bits isn't simply a matter of updating your application; it's also a matter of understanding all the changes that surround the application. What the user perceives as a change that improves application speed or reliability is likely a massive change in some respects for your application. The following list describes some of the requirements you should consider when updating your application:

  • Operating system: You must have a 64-bit operating system to run a 64-bit application. There are no 64-bit emulators for 32-bit systems (even if there were, they would run incredibly slowly). One issue that developers sometimes forget is whether application users run the .NET application using Mono. Make sure the user has access to the proper 64-bit version of an operating system for Mono .

  • Drivers: Older versions of Windows were somewhat lenient on the drivers you were allowed to use. Due to security issues, Microsoft has greatly tightened the driver requirements for Windows 7. You must make sure that any special equipment comes with a 64-bit Windows 7-compatible driver before moving your application to 64 bits.

  • Support software: Yes, you can use that older 32-bit support application if you really must with your 64-bit application, but the use of 32-bit software will cost performance and reliability. 

  • Assemblies and libraries: Try to upgrade all 32-bit assemblies to 64 bits if possible. Microsoft has created a 64-bit version of the .NET Framework. You might have to install this version separately.

  • Memory: Depending on how you write your application, you may find that it consumes considerably more memory than it did in 32-bit form. Using 64-bit memory types may help make your application faster or add new features, but at the expense of higher memory usage. It's important to re-evaluate memory requirements for your application after making the move to 64 bits to ensure that the application isn't memory-starved.

  • Supporting hardware: You need a 64-bit system to work with 64-bit applications. The motherboard, processor, and other hardware must provide the required 64-bit support. Obviously, you can't install a 64-bit operating system on a platform that doesn't support it.

One of the potential problems for developers has been persuading management to move to the 64-bit environment. There are many reasons cited, but often it comes down to time and money. Moving to 64 bits costs a lot of money, and businesses want to see a definite return on that investment. The problem is severe enough that Microsoft even put together a white paper for 64-bit SharePoint Server to persuade businesses to make the move. One requirement for your upgrade is to ensure that you've addressed management concerns in addition to the software and hardware requirements listed in this section. Make sure you have a good plan in place before you talk with management about making the move.


As with any new technology, development issues must be overcome when you move to 64-bit programming. You need to consider these issues as part of any plan to move your application to a 64-bit environment. When creating a new application, you need to take these development issues into consideration in defining the application requirements, creating the application design, and assembling your development team. The following sections aren't meant as an inclusive list of every development issue you'll encounter. However, these sections do touch on some of the major issues you must deal with when working with Windows 7.

3.1. Dealing with Programming Issues

No matter which operating system or development platform you use, there are going to be programming issues when moving from 32 bits to 64 bits. For example, the size of variables matters. When working with .NET variables such as Int32, you at least know right from the type name that the variable is 32 bits in size. What you may not remember is that many Windows 7 features require 64 bits when you work with 64-bit code. For example, if you perform any P/Invoke calls, the handle you receive from the Win32 API is 64 bits, not 32 bits.

It's extremely important to consider the requirements of methods and functions you call. In some cases, methods and functions require variables of a specific size. You need to address this requirement as you code because it will become all too easy to try to pass a 64-bit variable to a method or function that expects a 32-bit variable. The method or function might simply truncate the 64-bit value, which will lead to data loss and unexpected results from your application.

Programming issues can sneak into the developer's life without notice. For example, if your 64-bit application interacts with the 64-bit version of Office 2010, you'll have some nasty surprises to consider. Strictly speaking, the 32-bit and 64-bit versions of Office 2010 aren't completely compatible, a situation described here: Even though the information on this site discusses problems with VBA, those same problems will affect your Visual Studio Tools for Office (VSTO) applications as well. Unfortunately, Microsoft doesn't provide a ready resource for these issues, so you have to ferret them out in other ways. You should be prepared for similar problems with other 64-bit applications — Office 2010 isn't alone in this regard.

3.2. Accessing the Registry in Windows 7

Developers are likely to have some terrible surprises when accessing the registry in the 64-bit version of Windows 7. The 64-bit version of the registry contains both 32-bit and 64-bit keys, many of which have the same names. In other words, there's a 32-bit and a 64-bit version of the same key, so you need to know which key you're accessing. In fact, the problem is significant enough that Microsoft provides a Knowledge Base article that instructs administrators and developers alike how to view the registry when working with the 64-bit version of Windows. 

The use of registry redirection makes it likely that the 64-bit version of your application will actually rely on a physically different key from the 32-bit version. Even if your code uses precisely the same key, the physical key is different because the Registry Redirector will redirect the 64-bit key to a different location than the 32-bit key.

Let's say you create a 32-bit version of your application and run it on a 64-bit system. The 32-bit application needs to access the key at HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX. The key is physically located at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX, but the Registry Redirector makes it look as if the key is at HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX. A 64-bit version of the same application will physically store its data at HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX. The 32-bit and 64-bit version of the application will use different physical locations for their data, so you can't assume that data sharing will take place. The way to overcome this issue is to target the Any CPU setting when creating your application, but then you lose some benefits of using a 64-bit application because the compiler can't perform the required optimizations.

To make matters even more confusing, older versions of Windows (including Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP/2000) use registry reflection. Your older code might use P/Invoke to call the RegDisableReflectionKey(), RegEnableReflectionKey(), and RegQueryReflectionKey() functions to control registry reflection. Starting with Windows Server 2008 R2 and Windows 7, you'll note that WOW64 (Windows 32-bit On Windows 64-bit) no longer relies on registry reflection, which means that you have to change any existing 64-bit code to reflect this change. Keys that were formerly reflected are now shared instead.

3.3. Hosting Older DLLs

You don't have to toss out the older 32-bit DLLs in your arsenal when moving to a 64-bit application. However, it's important to know that you also can't load a 32-bit DLL in a 64-bit address space. Windows and .NET may hide the details from you, but the effects are clear. When you access a 32-bit DLL from your 64-bit code, the .NET Framework must marshal the data and calls between the two environments. Consequently, your application will use more resources, run slower, and experience more reliability problems because there's now a layer of marshaling code between your 64-bit application and the 32-bit DLL.

The key to hosting 32-bit code in the 64-bit environment is WOW64, which is an emulation layer that runs in 64-bit versions of Windows. The document found at provides you with some great information about how WOW64 works. Most of these issues are hidden from view for the .NET developer, but you still need to be aware of them. Unfortunately, WOW64 has limitations that you can't avoid, even as a .NET developer. Here are some of the limitations you need to consider:

  • Memory: Your application is limited to 2 GB of address space. Although C++ developers can rely on the /LARGEADDRESSAWARE switch to gain access to 4 GB of address space, there isn't any corresponding switch for .NET developers. This limitation may mean breaking up larger pieces of code before making the move to 64 bits and loading each piece as needed.

  • DLL loading: A 32-bit process can't load a 64-bit DLL (except for certain system DLLs). Consequently, your main application must load and manage all subordinate DLLs. If a 32-bit DLL requires support DLLs, you must ensure that you have the correct 32-bit support DLLs available and not rely on 64-bit DLLs that may be available with Windows.

  • Physical Address Extension (PAE) support: There isn't any PAE support available. You may not think of it immediately, but this particular issue can affect SQL Server, which means your application may suddenly encounter database problems. The Knowledge Base article at discusses how you configure SQL Server to use 3 GB of memory through PAE. The article at describes how PAE works. Make certain your 32-bit version of SQL Server doesn't rely on PAE before making the 64-bit move.

  • DirectX hardware acceleration: Your application may not use DirectX directly, but some third-party libraries rely on it. There isn't any support for hardware acceleration, which means that your application can slow considerably. If your application relies on a third-party graphics library, make sure you check into any DirectX requirement before you make the move to 64 bits.

  • 16-bit processes: Once you move to a 64-bit version of Windows, you can't load any sort of 16-bit process — not even processes that would normally run at the command prompt when using 32-bit Windows. This particular limitation can mean recoding scientific and other older application code.

  • Virtual DOS Machine (VDM) support: There isn't any form of VDM API support provided. This means that older command line utilities won't run.

  • Page-size-dependent APIs: You won't be able to use any of the page-size-dependent APIs, such as Address Windowing Extension (AWE). Although this limitation probably won't affect your .NET application directly, it could affect support code, so you need to check any support requirements.

  •  Developing a Windows 7 Strategy : DETERMINING THE USER WINDOWS 7 COMFORT LEVEL
  •  Windows Server 2008 and Windows Vista : Group Policy Processing Events (part 2) - Foreground Group Policy Processing
  •  Windows Server 2008 and Windows Vista : Group Policy Processing Events (part 1) - Background GPO Policy Processing
  •  Kyocera Mita FS-C5150DN
  •  MSI Power Edition GeForce GTX 670
  •  Transcend's SATA III SSD720 - Safer Data
  •  Asus HD7970 - A Card For Enthusiasts, By Enthusiasts.
  •  Printers : Can't Live With Them, Can't Live Without Them (Part 1)
  •  Printers: Can't Live With Them, Can't Live Without Them (Part 2)
  •  Setting Up Multiple Accounts With OS X Lion
  •  Data Storage Considerations (Part 1)
  •  Data Storage Considerations (Part 2)
  •  Asus Ultrabook N56VM - In More Ways Than One
  •  Asus ZenBook Prime UX21A - Small, Light And Extremely Sleek
  •  Microsoft Windows Server 2003 : Maintaining the Operating System - Administering Software Licenses
  •  Monitoring Microsoft Windows Server 2003 : Using the WMI Event Logging Provider
  •  Windows 7 : Add the Built-in Administrator Account to the Login Screen, Stop Entering Password on Lockout, Using Credential Manager
  •  Windows 7 : Sharing and Securing with User Accounts - Creating a Password Reset Disk, Running Programs as Administrator
  •  A Cost Effective Printer?
  •  Get More Out Of Windows 7 (Part 4)
    Top 10
    Windows Vista : Installing and Running Applications - Launching Applications
    Windows Vista : Installing and Running Applications - Applications and the Registry, Understanding Application Compatibility
    Windows Vista : Installing and Running Applications - Practicing Safe Setups
    Windows Server 2003 : Domain Name System - Command-Line Utilities
    Microsoft .NET : Design Principles and Patterns - From Principles to Patterns (part 2)
    Microsoft .NET : Design Principles and Patterns - From Principles to Patterns (part 1)
    Brother MFC-J4510DW - An Innovative All-In-One A3 Printer
    Computer Planet I7 Extreme Gaming PC
    All We Need To Know About Green Computing (Part 4)
    All We Need To Know About Green Computing (Part 3)
    Most View
    The End Of The Beginning Or The Beginning Of The End? (Part 3)
    The Future Revealed (Part 1)
    Instagram Substitutes On Android (Part 2) - Cinemagram, Clik, Steam Mobile & TeamViewer
    Ipad : Using iTap VNC
    Windows Vista : Performing Local PC Administration (part 1) - Working with workstation administration tools
    Next – Gen Broadband – Optimizing Your Current Broadband Connection (Part 4)
    Designing a Windows Server 2008 R2 Active Directory : Understanding the Federated Forests Design Model
    ASROCK FM2A75 Pro4-M - Limited Performance
    Programming the iPhone : Standard Control Types (part 1) - Buttons
    Linux - The Operating System With A Pure Heart (Part 2)
    Password Hacks (Part 2) - Criminal activity
    Personalizing Windows 7 (part 3) - Choosing and Configuring Your Screensaver
    The best of the web (Part 3) - 3LiveShop, Proust, Grooveshark, OnLive, Open Yale Courses, Instapaper & 8 tracks
    Exchange Server 2010 : Operating Without Traditional Point-in-Time Backups
    Windows Vista : Maintaining Windows Mail
    DirectX 10 : The 2D Resurgence - Sprite Animation
    Programming Windows Services with Microsoft Visual Basic 2008 : Extending the WMI Implementation
    How to buy: SSDs for 2012
    Toshiba, Asus launch new laptops
    Buyer’s Guide - Keyboard and mice (Part 4) - GIGABYTE Aire M1, Gyration Air Mouse Elite, IOGEAR Phaser GME422RW6