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.
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 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.
…except of course, if your CPU doesn’t support x86_64 instructions, like Intel’s Atom. It’s a shame really, and I’m hopeful the next Atom version will have 64-bit support included.
I’m hoping so too…whether I like it or not, I keep ending up in the Windows environment, and sooner or later they’re going to stop making 32-bit versions of their OS.
Uhm… Last time I checked the Atom is an EM64T processor fully capable of running x64 versions of windows – I have one here running XP x64 just fine as well as a AMD64 build of Ubuntu, so what exactly are you saying?
Some chipsets — especially some mobile chipsets — do not support the x86-64, even when the processor does. Also, on some motherboards with x86-64 chipsets the motherboard traces aren’t connected for 64-bit addressing. That’s likely the cause of the confusion.
Anyone who wants more info can read here:
http://support.microsoft.com/kb/929605/en-us
(Look under the “WORKAROUND” section.)
The most popular models of the Atom processor (the N and Z mobile versions) have the 64bit extensions disabled. Only the desktop version of the Atom can run in 64bit mode.
Except that the intel atom cpu actually DOES have x86_64 support..
Not the mobile versions, sadly, like Thom pointed out.
I quite like the x64 experience and after having convinced a few people to take the plunge they keep thanking me for it everyday. The only gripe for me was drivers but XP x64 is chugging along great for me. I just need a vpn client and then I would be set.
I’m not trying to be rude or anything, but why did you even bother to convince people to go 64 bit? Unless you need the memory why does it even matter? It seems like you set yourself up for headaches and the benefit is not much for most people.
Well, beyond the memory benefit, 32-bit operating systems are going to be phased out at some point. Last time I checked, Windows 2008 was supposed to be the version of server OS running 32-bit.
No argument there, but why run 64 bit now, when there are these headaches?
I tried it with linux for a while before I realized it was a waste of time for me. I never bothered with 64 bit xp or vista.
You’re right, there are some people who don’t need to go 32-bit, and could probably stay that way for several more years.
In my case, and in the case of anyone who’s building large-scale apps, the extra memory is a life-saver.
In another case, there are applications (like Microsoft Exchange 2007) that are being released as 64-bit only applications. That’s definitely a minor occurrence, but I had to help someone out with that exact situation.
Interesting. I was just curious if I was missing out on something as my needs don’t really dictate that I run a 64 bit OS. There are times when the extra memory would be nice (running multiple OSs in vmware), but I’ve been coping.
I will reply by saying most of my friends have over 4 gb ram. They do video editing, (hd footage), lots of gaming, are java developers etc etc. Whenever I do any sort of development using enterprise oracle products, I can easily use up 2.5 gb of memory. If I was using 32 bit, well that does not leave me with much headroom. And if I am bored, I just stop doing some work and turn on some Crysis without having to turn off any of the software.
My brother who is editing HD footage is already consuming over 4 gb of ram and now he has to go and grab 4 more gb to not cause any sort of disk swapping.
Also as far as I understand, 64 bit processes all have DEP enabled by default. No ifs ands or buts so in terms of security its a good idea.
And also before building machines, we do our research to see what works and does not work. So it just works for us and we are quite happy.
No offense taken from all the people who asked why. Main thing was memory usage, server based OS and didnt want to upgrade to Vista. Its just a win win situation fellas. 
I am in the same situation. A year ago, I installed Vista x64 on a high-end computer and I didn’t feel any difference in terms of speed because basically, I use only Opera, Adobe Reader and MS Office.
However, in the case of David, it’s different because he is dealing with servers that can need a lot of memory in some cases. High-end servers can be dramatically relieved with the extra memory unleashed by the x64 architecture.
But unless we are forced to migrate to x64, I don’t see any compelling reason to migrate to x64 on the desktop for regular users who don’t use professional applications (CAD, 3D, audio, video).
I’m surprised that this didn’t make the list:
“The default Internet Explorer is 32-bit”
The 64-bit IE is there, but buried in a sub-menu of the Start Menu. You may not think this is important, but it actually severely hampers the porting of any plug-ins (Flash, Java, Adobe Reader etc.) to the 64-bit platform because lazy-backsided vendors will claim “we don’t need a 64-bit plug-in because no-one ever runs 64-bit IE”.
A vicious cycle of course – no-one runs 64-bit IE because there’s no 64-bit plug-ins (and it’s buried in a sub-menu) and so on and so on. Sadly, Adobe in particular are criminal with their abject lack of 64-bit support of any of the platforms for virtually anything they write. Shame on them!
Bemusingly, the best platform to run 64-bit apps in the many, many years since the Athlon 64 came out is actually Linux – which has far, far more 64-bit apps than the Windows platform (and becaose of that, I suspect a much higher percentage of Linux users run 64-bit than the percentage of Windows users that run 64-bit).
32-bit browser plugins are a pain on linux too.
At work I have a Centos desktop (so not that bleeding edge), running 64-bit Firefox on which I installed (had to) 32-bit flash9 and nspluginwrapper. The setup is pretty easy and straightforward.
Most modern distros use nspluginwrapper by default. I haven’t had to worry about 32 bit vs 64 bit plugins for a long time.
nspluginwrapper is messy with 64bit, some people have no issues, but many have crash after crash. Although I have gotten things moving along, my 64 bit experience on linux has been far more frustrating than in windows, especially in the browser plug in respect.
I guess I’m one of the people who hasn’t had any issues… on Fedora Core 6, Fedora 7, Fedora 8, Fedora 9, Centos 4.x, Centos 5.x, Ubuntu Feisty, Edgy, Gutsy, Intrepid Alpha, on AMD x64 4000+, Intel Core2 Duo 2140, Core2 Quad Q6600, and dual quad core clovertowns, with memory varying from 512MB to 8GB, running from USB, PATA, SATA, SCSI and various combinations, and using NVidia GeForce 6800 AGP, Radeon 9100+ AGP, VIA Chrome 9 IGP, and Intel X4500 IGP video, locally on the console, on Xterminals on the LAN, and over VPNs on NX. Guess my configuration just happens to do well with nspluginwrapper. Lucky me.
Edited 2008-09-26 02:10 UTC
is there a horseshoe and rabbits foot by your computer by chance.
Its weird and from the plethora of posts ive gone through on forums, I know im not alone on this. luckily my need to use it is far and few between, but usually when I have it working, an update somewhere inevitably trashes it and im back to square one.
Looking back, you’re right, I should have put that in the list.
Since it wasn’t as frustrating as the ODBC Administrator issue, that’s probably why it didn’t make the cut.
Does a 64 bit browser make any sense? You need more than 4 GB of memory to run your browser?
Get rid of all the 32 bit apps and you don’t have to have the 32 bit libs in memory. Plus you get the extra registers available in x86_64. Maybe some year the libs won’t even have to be on disk. If we’re going to do 64 bit, let’s do 64 bit rather than this half-way thing with all the unnecessary (and confusing) duplication.
“Do or do not. There is no try.” -Yoda
Edited 2008-09-26 06:08 UTC
I guess that’s my point. There’s no reason for the majority of people to run a 64 bit OS. What use is a 64 bit music player, video player, browser, IM or office suite? Numbers for commercial 3D and graphics packages do not show any significant improvement when run as 64 bit applications.
Cue some tard who will chime in with how I should go back to using an abacus or some such for not embracing “progress”.
Would mod that up if i could, 64bit is important for kernels and apps that need to address an insane amount of ram, and thats about it.
I understand what you are saying, and agree to a point. However, as long as threads like this one are relevant, we do have a problem that needs to be solved. The 32 bit/64 bit thing involves overhead in the form of development time, testing time, user confusion, 32 *and* 64 bit libraries being loaded into memory, etc. etc. etc. Unless you think that 64 bit in user space is going to go away, we really need to move forward to a unified architecture for x86 if only for simplicity’s sake, regardless of whether a 64 bit browser has measurable advantages over a 32 bit one.
I believe it was William of Ockham who said that one should not multiply architectures unnecessarily. And if he didn’t he should have.
What’s your reason for owning a computer. I mean, just get a phone and surf seeing as that seems to be the beginning and end of your existence to have one.
This is true, however if you are talking about the need to run an ASP.net app in 32-bit, it is alot less drastic to flip the “Enable 32-bit Applications” flag in the app pool advanced settings screen.
One big thing I ran into was that JET interop simply doesn’t exist in the 64-bit framework. I have an app that will import Excel files, and for the life of me couldn’t figure out why it would work on one machine, but not another. If you need JET interop, go into the project properties in studio, go to the Build tab, and flip Platform Target from “Any CPU” to “x86”. This will force the JIT compiler to generate 32-bit native code instead of 64-bit.
The paragraph about memory limits is a bit misleading. In 32bit address space you can reference up to 2^32 addresses, or 4 GB of RAM. If your OS limits your app to a lower ceiling, that’s another problem.
As the 16.8 million TB of 64bit registers seems an awful lot, most consumer-grade 64bit-CPUs also have a built-in limit of how much memory they can really address. What’s important is the width of the address bus. In AMD X2 CPUs this used to be limited to 40bit, upgraded to 48bit with the X4.
Not ENITRELY accurate – since that address space needs to also be shared with any memory mapped hardware… Like video cards, audio card framebuffers and of course BIOS.
Which is why my Q6600 with 4 gigs of RAM can only address two and a half gigs of RAM in windows after making room for the 640 meg Ge8800GTS driving my primary display, the 512 meg Ge8400GS driving the outer two displays, the 128 megs of onboard ram in my old EMU Morpheus, the buffer allocation for the Audigy 2 ZS, much less the mainboard, etc. Even a machine with just a single video card and integrated sound is lucky to come up with 3 gigs of addressable space free.
Some OS get around this by swapping memory allocation as needed, but this can be slow as molassas and hang processes waiting for the swap to occur.
That’s not an accurate way of describing what goes on. Given chipset support, you can simply map the extra memory ‘covered’ by the video card to a physical address higher than 4GB. There’s no swapping involved. Windows does not enable this feature for client SKUs since video and audio drivers tended to barf on a 32-bit system when given a physical address bigger than 32 bits.
User mode processes get 2GB of virtual space by default. I’m curious about why this is limited to 800MB for IIS, but swapping is not involved at all regardless of the reason.
I’m guessing this is the problem.
http://blogs.msdn.com/tmarq/archive/2007/06/25/some-history-on-the-…
With some help here:
http://forums.iis.net/t/1148392.aspx
and that memory is bus accessable to the CPU (and by extension system RAM and the HDD) across the PCI x16 bus HOW exactly? Oh wait, you have to memory map it into that bottom 4 gigs to access it – in other words a memory swap – with all the headaches of protecting the RAM being swapped out from being accessed.
Nice try though.
Not exactly:
Imagine you have two processes on an x86 machine. Each one gets 2 GB of private virtual address space. Let’s say that each one is using 1.5 GB of space. Let’s also assume that the kernel is caching 2 GB of file-backed data in the file cache. You’ve now got 5 GB of physical memory consumed.
One thing to note here, is that you don’t have to have memory mapped into the user or kernel virtual address space for it to be used as cache… the Windows Memory Manager will happily keep cache pages around and keep track of them without consuming any of the 32-bit address space (except for some small control structures).
Even if you ignore the file mapping thing, each process gets 2 GB of address space and you already have to swap between them when you switch to a thread of a different process, so if you open four 1 GB images in 4 instances of Photoshop, you can consume 4 GB of RAM on a 32-bit system (assuming you had an Advanced Edition of Windows Server).
The reason this wasn’t allowed on Client SKUs was that if you tried to use the typical GPU driver in this situation, the system would barf when the physical addresses are truncated by the driver and passed to the hardware.
Incidentally, the PAE-enabled Windows Server kernels do not support nearly as much memory as the 32-bit hardware with PAE supports because the per-physical-page descriptors begin to take up a whole lot of space and these have to reside in mapped virtual memory. I think the capped limit is no more than 900MB worth of these PFN entries (at 28 bytes per page, that’s 32GB of physical memory supported).
Virtual memory is a lot more subtle than you think it is.
“Microsoft.NET applications may be able to run in 64-bit mode automatically”
I somehow doubt this. Executable files have a Machine type value in their header. This tells Windows what architecture that file was made for. If you try and run an AMD64 file on a 32 bit Windows build, you’ll get an error stating it’s not a Win32 executable.
While I haven’t read the background on WOW64, I doubt it makes an exception when it comes to .NET applications.
A .NET application is a normal windows application that imediatelly calls the .NET framework. While Windows could in theory have exceptions in place, that would make it very unflexible and modifications to this would need WOW64 updates.
So I’m betting on two .NET runtimes, 32 and 64 bits, that make no effort to update 32 bit code to 64 bit.
On the other side of the box, the Java JIT compiler should be indeed capable as the Java application itself is platform independent and any features unavailable on a 64 bit CPU would be worked around by the VM, at a small speed cost, on other architectures.
All that sounds good except for one thing…you’re wrong. The code is JITed on the fly to be compatible with whatever processor it’s running on. IL is processor/machine independent and is agnostic to the differences between 32 and 64 bit platforms. The .Net framework itself takes care of that at runtime.
What do you mean by “64-bit applications cannot access 32-bit libraries, or vice versa” I think you might be misinformed, but I would like to hear you expound a little more into this.
Edited 2008-09-26 05:41 UTC
They cannot make direct calls to each other… you can’t load a 32-bit dll in a 64-bit program and expect to call into it because there’s no good way to switch processor modes when doing that or to provide the correct views of data that’s above the 4GB line. There are a couple of other technical reasons why this is impossible.
There is an extensive user-mode thunking layer that allows 32-bit executables to communicate with the kernel, and with RPC servers in other processes, but that’s the extent of it.
Just like the push to 32bit from 16bit, during the transition many people thought why do i need to upgrade to 32bit, i don’t have anywhere near 4GB RAM, i only have 2MB, 4MB, 8MB etc.
I know aswell as memory there are other architectural reasons to complete the move.
I think it’s important that users start the mirgration over to x64 OS’s. Drivers will be created, software will be developed, ready for when we do require x64, which personally i think is sooner than alot of people think.
More and more people are watching HD movies on their computers, recording tv shows on MCE computers. The standard is 2GB RAM on PC’s, how long before that changes to 4GB RAM and that to 6GB or 8GB RAM?
We need to start getting into the mindset ready for the migration so we don’t have a last minute scrabble.
I mean if your next PC came with 4GB or even 8GB RAM wouldn’t you want to use it all? I know many people will say they only use their computers for email and surfing, however a lot of people also use their computers for games, video editing, image editing etc, all three OS’s Mac OSX, Windows & Linux are all incredibly stable thus allowing for more and more applications to be mutlitasked and ran at the same time, we have more background tasks (music playing etc..).
I hope Microsoft start a push in the consumer space for x64 windows, even if the machines come with 2GB RAM, just prepping everyone for the migration is worthwhile.
Edit : Thought whilst watching the article on MultiTouch.
The other thing i suppose to bear in mind is new technology. So for example if the multitouch system explained in the other OSAlert article is ready for release but requires 1GB/2GB of RAM to run then again x64 will become a Necessity.
Edited 2008-09-26 08:36 UTC
I usually avoid bashing Windows and comparing to Linux, but come on :
* 32bit libs in “SysWOW64” folder, and 64bit libs in “system32” folder ? Makes perfect sense (sarcasm). Same goes for “program files” folder, even if less troubling (but why do those need to be in different folders at all ?).
* Separate configuration locations for 32bit and 64bit (in registry) ? Who stores bitwidth-sensitive data in there ? And relies on the OS to handle the case when both 32bit and 64bit versions of the program being installed at the same time ?
* Configured data sources (ODBC) only working for n-bits program if configured via n-bits GUI ? I’d really expected better.
Compare this with Linux, where there a “/lib32” and a “/lib64” folder which contain the expected, plus a “/lib” symlink that points to “/lib64”. All the rest (configuration , applications, etc) is in the standard (bitwidth-agnostic) locations. I’ve been using 64bit Linux on my laptop since 2004, and it allways worked just as well as my 32bit machines.
Of course I know why Microsoft does these kind of hacks : backward-compatibility. That’s the price paid for proprietary software, which often won’t issue any update once the package has been sold. And Microsoft has been blessing this behaviour by working around 3rd-party bugs in each new version of Windows. They’ve been doing it for at least 15 years, and can’t turn back.
Pardon the pun, but the bazaar is much tidyer and well-kept than the cathedral.
In order to mix 32-bit and 64-bit code, you have to make your library an out of process COM server.
Device drivers (including printer drivers) must be 64-bit on x64.
Seriously, do you know any casual user (I mean like my mom), that would bother because their 64bits system files are installed into the system32 directory? All of these excuse are somewhat doubtfull when it come to ordinary people. Except for badly written application, all of the WoW64 layer stuff should be transparent.
What advantage is there to run 64bit? Hum, let me see… RAM!!! Vista loves RAM. It love it so much that it can but rape your hard drive so hard that it will be screaming “Help I can’t handle that page file anymore! ” I work in a computer store (custom built) and we sell lots of RAM. Our standard family system has 2gigs of RAM and our gamer one begins with 4gigs. We sell 8gigs system more and more often. A lot of people who take Vista get the 64bits edition too, just because they wont have to reinstall their machine when they’ll add more than 3.5gigs of RAM.
What I’m recommending, is that if you’re running on Vista and not planning on using old or esoteric hardware, get 64bits. The performance difference is minimal, and the memory usage only increase slightly. Most drivers are now stable in both version and theres more and more application that can take advantage of more RAM. Just give it a try. If you don’t like it, than reinstall to 32bit, your OEM license do both