1. CONSIDERING THE ADVANTAGES OF 64-BIT APPLICATIONS
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:
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.
NOTE
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.
2. UNDERSTANDING THE REQUIREMENTS FOR 64-BIT APPLICATIONS
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.
3. OVERCOMING 64-BIT DEVELOPMENT ISSUES
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: http://msdn.microsoft.com/library/ee691831.aspx.
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 http://www.microsoft.com/whdc/system/platform/64bit/wow64_bestprac.mspx
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 http://support.microsoft.com/kb/274750 discusses how you configure SQL Server to use 3 GB of memory through PAE. The article at http://blogs.technet.com/b/beatrice/archive/2008/08/29/3gb-pae-and-awe-taking-away-some-confusion.aspx 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.
