posted by David Handlos on Thu 25th Sep 2008 18:07 UTC
IconA 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 VBScripts 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.

    e p (3)    44 Comment(s)

    Technology White Papers

    See More