A
Windows developer and Sysadmin has compiled a "Watch List" of the small
but annoyingly important things to keep in mind when moving from 32 bit
Windows to Windows x64.
Introduction
Like many others in the IT world, I tend to wear a lot of hats in my
job. Often, I'm both an application developer and a system
administrator. I'll develop an application and then optimize the
operating system for it.
And again, like many others in IT, I like to use new technology when I
can, especially if it can save me time down the road. So, once I had
the opportunity to look into the 64-bit editions of Windows (also known
as "x64"), I jumped at the chance.
In order to take advantage of the benefits of these x64-based Windows
environments, I've begun to look closely at the differences between
them and the traditional 32-bit Windows systems. And frankly, what I've
found so far has blown BOTH
of my hats clean off. While most of the differences between the two
look pretty subtle, they are significant. Whether you are trying to
develop 64-bit applications for the x64 world, or just trying to
migrate your existing 32-bit applications or scripts over, there are
several things that need to be taken into account before you make the
64-bit plunge.
Background: 64-bit Windows...why should we care?
For those of you who are new to the terms "x64" or "64-bit", what it
boils down to is a way of utilizing more memory. Traditionally,
applications on 32-bit Windows systems can only address 2 gigabytes of
system memory. No matter if you have a system with 4GB of memory, 2GB
is all the memory any single application can use.
With IIS, Microsoft's built-in web server, that limit is even lower.
At the most, an IIS process can utilize only 800MB
of memory on a given 32-bit system. Again, regardless of how much
memory is free on the system, 800MB is the most IIS can utilize on a
32-bit system, and remain stable.
64-bit operating systems can utilize an exponentially larger amount
of memory, changing things drastically.
As a result, any application built to run on one of these x64
environments can address up to 8 terabytes.
While
you aren't likely to find anything currently that has 8TB of memory
nowadays, it's great to know there's got plenty of room to expand.
The Watch List
In order to ease my transition to the 64-bit world, I compiled my own
"Watch List" of the small, but annoyingly important things to keep in
mind when moving up to Windows x64.
64-bit applications cannot access 32-bit libraries, or vice
versa
Although you can run your old 32-bit applications on a
64-bit machine, they'll run on a separate layer called WOW64 (Windows
On Windows 64). Windows x64 is architected to keep 32 and 64-bit code
separate. If you did actually attempt to merge the two, application
crashes would be in your immediate future.
There are now separate system file sections for both 32-bit
and 64-bit code
Windows x64's architecture keeps all 32-bit system
files in
a directory named "C:\WINDOWS\SysWOW64", and 64-bit system files are
place in the the oddly-named "C:\WINDOWS\system32" directory. For most
applications, this doesn't matter, as Windows will re-direct all 32-bit
files to use "SysWOW64" automatically to avoid conflicts.
However, anyone (like us system admins) who depend on
_vbscript_s to
accomplish tasks, may have to directly reference "SysWOW64" files if
needed, since re-direction doesn't apply as smoothly.
There are now separate registry sections for both 32-bit and
64-bit code
With x64, the registry has separate sections as well.
The
"HKEY_LOCAL_MACHINE/SOFTWARE" key is used to contain registry entries
for 64-bit programs, and 32-bit programs are re-directed to use
"HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node" instead.
In most cases, this shouldn't be an issue...unless someone has
both 32
and 64-bit applications that depend on the same registry settings. If
that happens, at least one application may fail, since it is looking
for registry data that it can't find.
The default ODBC Data Source Administrator is 64-bit only
A wide variety of scripts, programs, and web
applications
use ODBC settings set up by the ODBC Data Source Administrator (located
in "Control Panel -> Administrative Tools") to connect to a given
database.
Oddly enough, if you set up an ODBC connection with this tool
on an x64
box, that connection will only work for 64-bit applications. If you
want to set up an ODBC connection for a 32-bit program, you have to set
up the connection using the identical-looking, but somewhat hidden,
32-bit ODBC manager, which is here: C:\WINDOWSS\ysWOW64\odbcad32.exe.
IIS can run either as a 64-bit or 32-bit process
I mentioned earlier that running on 64-bit moves your
memory limit with Microsoft's default web server from 800MB to the
terabyte range. It runs as a 64-bit process by default, but can be
easily re-started as a 32-bit process to run 32-bit code. Remember,
once IIS is rolled back to a 32-bit process, the 800MB memory limit
comes back into play, so you'll have to watch your resource usage if
you need to run 32-bit code for your web site.
The "C:\Program Files" directory has been split into
"C:\Program Files", and "C:\Program Files (x86)"
As part of the 32/64 separation layer, 32-bit
applications
now get installed to a "C:Program Files (x86)" directory, while 64-bit
applications are installed in the familiar "C:\Program Files"
directory. By keeping the different types of applications separate, it
is much easier to tell what will be 32-bit and 64-bit, especially from
a system administrator's perspective.
Occasionally, you may run into an application with a
hard-coded
reference to the "C:\Program Files" directory. If it's a 32-bit
application, then it'll likely experience problems, since it's located
in "C:\Program Files (x86)", and will be trying to access a directory
that it shouldn't be viewing.
Microsoft.NET applications may be able to run in 64-bit mode
automatically
Microsoft.NET is a framework where the program code
compiles itself on
the fly (known as Just-in-Time Compiling), based on whatever machine
it's running on. By default, Microsoft's Visual Studio 2005 (or higher)
will build your application to run either as 32 or 64-bit
automatically. Visual Studio also allows the option to build 32-bit or
64-bit-only applications you'd prefer. So, if you're migrating a
.NET-based application onto your new 64-bit server, it could
potentially run as a 64-bit application without doing anything extra.
On the plus side, anything running in 64-bit mode will be able
to
access more memory than it's 32-bit counterpart, and since Windows
doesn't have to use 32-bit WOW64 emulation, it will likely run a hair
faster as well.
Unfortunately, if the application was designed to run as a
32-bit
application, it may run into dependency issues when moving up to
64-bit. For example, if the application depended on registry entries,
system files, or ODBC settings that were set up for 32-bit
applications, the program would likely fail, since it wouldn't be able
to access those resources while in 64-bit mode.
Note: While I haven't been able to test this yet, Java code
runs on
top of a similar Just-in-Time Compiling principle as .NET. Java code
should be able to run as 64-bit automatically, provided a 64-bit Java
Virtual Machine is installed on the operating system.
Conclusion
Making the leap to the 64-bit world, whether you're in Windows or
not, is well worth it. The increased ability to address memory solves a
lot of the current memory limitations of the 32-bit systems, and gives
plenty of room to expand for the future. However, expanding for the
future usually tends to have some initial growing pains, and migrating
to Windows x64 is no exception...so hang on to your hats, use the watch
list, and enjoy the ride!
About the author:
David Handlos is a software engineer from Lincoln, Nebraska. Working
professionally with web-based technologies since 1998, he has also been
a computer/electronics enthusiast since 1992. His "enthusiasm" has led
him to work with radio communications, hardware programming, web
development, and XML-related applications.
Most recently, this has also led him to begin graduate work in
information security. 
