A Messy Transition: Practical Problems With 32bit Addressing In Windows
by Ryan Smith on July 12, 2007 12:00 PM EST- Posted in
- Software
As it turns out, it's possible and actually quite easy to move the 2GB barrier by increasing the size of the user space, but at the cost of reducing the size of the kernel space. Under Windows XP, this is the fabled "/3gb" switch for boot.ini, and for Windows Vista it's the "IncreaseUserVa" option in BCDedit. By using these options applications can use more than 2GB of virtual address space (generally up to 3GB), and ideally this would be the end of the article.
Unfortunately this is not the case as there are problems on both the application and kernel side of things. On the application side, a common poor programming practice has been to always assume that an application will only be dealing with 2GB of user space; code that makes this assumption will likely error if more than 2GB of user space is actually available. This is avoidable by following proper programming practices, but as a safety precaution even with additional virtual address space allocated to user space Windows still defaults to limiting an application to 2GB. Only finally, if an application indicates to Windows that it is capable of handling more than 2GB, via the "/LARGEADDRESSAWARE" flag, may it have access to any space above 2GB.
As for the kernel, having had up to half of its space taken away must now find a way to live in a smaller space. The (in)ability of any specific system/Windows configuration to deal with this is why the 3gb switch is considered dangerous, seldom recommended, and just generally a bad idea. The biggest culprit here is drivers that run in kernel space. Like applications, they may assume that there's an entire 2GB of address space to work with, except unlike applications this space gets smaller instead of bigger.
Windows' own memory needs can also cause problems with the reduced kernel space. As we mentioned before, space is required for the kernel to do a multitude of things, if a lot of space is required - video cards with a lot of memory are a particular offender here - then everything needing space may not fit in the kernel space. Because there are no strong safeguards against these conditions it may cause a failure to boot or system instability, especially if the culprit is a driver that is well enough behaved to boot. Many modern drivers from hardware vendors that deal with enterprise-level hardware are capable of handling this, many more consumer hardware drivers are not. Stability concerns are the number one reason that breaking the 2GB barrier on a 32bit version of Windows is not recommended.
There is also a second concern however: performance. While an individual application may benefit from more user space in which to work, the kernel now has less space to cache data (as non-obvious as this may seem given all the addresses are virtual) and this can in theory hurt performance. This condition is something we will take a look at in a bit.
Facebook
Twitter
RSS
69 Comments
View All Comments
johnsonx - Saturday, July 14, 2007 - link
We are both right. While many 32-bit apps run fine on 64-bit windows, some don't. In particular, any app that employs any sort of driver (I'm talking software drivers, not hardware drivers) must at least have the driver compiled in 64-bit mode. In my case the example is a file synchronizing application that installs a driver to monitor file system changes. There are many apps that wouldn't appear to need a driver, but in fact they do. If you want to see the software drivers on your system, go into Device Manager and select Tools->Show Hidden Devices. Now look in "Non-Plug and Play Drivers". Everything in there is a software driver. If you're running 64-bit Windows, everything in there MUST be 64-bit. Applications can also install drivers at runtime, which also must be 64-bit.There are other 32-bit apps that for whatever reason just won't work on 64-bit windows. I believe AutoCAD 2006 and earlier have this problem. Likewise, any apparently 32-bit app that still has some 16-bit legacy code won't run either (for example some rather old but still perfectly useful 32-bit apps use a 16-bit version of InstallShield; the app itself might run, but there's no way to get it installed.).
Regarding the Retail version, I've never had a retail version of Vista in my hand. I recall Microsoft saying at one point that both versions would be on the same disc and had never heard anything contrary.
Christopher1 - Sunday, July 15, 2007 - link
So this 64-bit software driver problem doesn't apply to things like games, I would assume, considering that they usually do not install software drivers?Well then, I think I'm going to contact Toshiba and use their 'Upgrade to x64 version of your operating system' option that recently appeared, if this doesn't effect games.
miahallen - Sunday, July 15, 2007 - link
No, all games should run fine on x64...however, tests have shown that most games run slightly faster on Vista x86.miahallen - Saturday, July 14, 2007 - link
OK you are right, I stand corrected. I knew about this, just wasn't thinking about it. But from my experiance, those particular apps (that use SW drivers) seem to be the ones getting the quickest attention. I do recall having a couple issues related....a freeware plugin for MCE called mymovies. x64 is not supported at all. Also, Daemon Tools & PowerISO were having issues...but I believe they have both been resolved since then (I went to x86 about four months ago, not much point for me to go back until my next upgrade - 8GB RAM).strikeback03 - Friday, July 13, 2007 - link
Somehow I'm doubting that the "average computer user" who buys a prebuilt system without knowing or caring about OS design will stand for random peripherals not working due to a 64bit OS. Probably part of why finding 64bit versions of Vista on prebuilt systems is hard. What should happen is Microsoft state right now that the next version of Windows will be 64bit only; then try and educate consumers that some things won't be compatible, and notify companies that they really need to have their 64bit drivers working by then.jay401 - Thursday, July 12, 2007 - link
No, they should have rendered their units properly (if that's even the real reason... somewhere though they aren't doing something right in their coding, given the way SupCom eats memory).jpeyton - Thursday, July 12, 2007 - link
On page 5, under Software Test Bed, the RAM should read (4x512MB) instead of (4x512GB).fic2 - Thursday, July 12, 2007 - link
First sentence on the front page summary:"As applications being to approach"
I assume that "being" is supposed to be begin.