A Messy Transition: Practical Problems With 32bit Addressing In Windows
by Ryan Smith on July 12, 2007 12:00 PM EST- Posted in
- Software
Other Problems, Other Solutions
Although for this article we are focusing on Supreme Commander, there are other games and applications that are already known to encounter this exact problem. Company of Heroes developer Relic has warned that this problem can occur, especially in conjunction with using Direct3D 10 mode and STALKER developer GSC Game World has also seen this problem. Both have gone so far as to ship the latest versions of their games with the LARGEADDRESSAWARE flag.
Although not an exhaustive list, we have compiled a list of recent games and applications and if they are flagged or not. Ideally every possible game and application that can run in to the 2GB barrier will be flagged so that it can be worked around without modifying the application directly itself.
| Large Address Aware Status | |
| STALKER: Shadow of Chernobyl | Yes |
| Lost Planet | No |
| Company of Heroes | Yes |
| Supreme Commander | No |
| Enemy Territory: Quake Wars | Yes |
| Battlefield 2142 | No |
| Call of Juarez DX10 BM | No |
| World of Warcraft | No |
| The Elder Scrolls IV: Oblivion | No |
| Photoshop CS3 | Yes |
| Dreamweaver CS3 | No |
| . | |
The importance of the above applications and games being flagged is not just to avoid the need to modify the executable, but also because there is another solution to the issue we haven't talked about so far. 64bit versions of Windows(i.e. XP and Vista) do not suffer from the traditional 2GB barrier, as all the kernel mode addressing is usually moved to well above the confines of the limited 32bit addressing area. As such, these versions of Windows don't need to have their space allocations adjusted for an application to gain access to more addressing space, bypassing the instability and any possible performance problems that occurs as a result of making this adjustment.
However in order to maintain compatibility with older applications, Windows still keeps the artificial 2GB barrier in place to keep from triggering any bugs that result from the extra space. So even if we use a 64bit version of Windows, the offending application must still either be flagged by the developer or modified by the user if we want to get past the 2GB barrier.
This in turn is an interesting proposition for developers who may be looking at ways to deal with the 2GB barrier, but don't want to make the jump to having to program and support 2 versions of their executables and associated compiled code. Although as a 32bit application there is still the 4GB hard limit, flagging executables lets a developer keep a single package and is perfectly safe on both stock 32bit and 64bit installations of Windows. They can effectively buy another 2 years or so before they need to actually offer 64bit executables, and can direct users to install a 64bit version of Windows if they are hitting the 2GB barrier, instead of directing them to make the much riskier user space modification.
Of course this is not all roses. As we covered in our Vista performance guide, there are still some issues with Windows Vista 64bit, and Windows XP 64bit is even worse as a result of having been orphaned quickly after its release. For prospective 64bit Vista users, they will still find that driver support is not as good as with the 32bit version of Vista, and 64bit drivers may not be as stable as the 32bit versions. There are also still lingering concerns over application compatibility and performance.
Things have gotten better since we published our February article, but we're not ready to write them off completely yet. Users getting along with 32bit versions of Windows right now will find themselves in between a rock and a hard place as more applications and games start to hit the barrier - they'll either need to make the user space modification or switch to a 64bit version of Windows when neither of these is a perfect solution. This leaves the less imperfect but also less fun option of simply turning down the settings on any affected games. Lower settings result in lower user space usage and reduced chances of crashing, but in spite of the highest stability and compatibility offered by this option we suspect few users will actually opt for it.
Facebook
Twitter
RSS
69 Comments
View All Comments
titan7 - Thursday, July 12, 2007 - link
There is nothing you can do. If you ship a game you could test it and ensure it doesn't run out of memory (e.g. GameCube has just 24megs of system memory and the last Zelda looked great. Quite a ways away from 2048megabytes PC games run into!), but what about a mod?When the application starts just allocate 512 megabytes or whatever you feel is reasonable. When new throws an exception free that memory, display a warning you're low on memory and need to upgrade to Vista64, and continue. When it new fails again one microsecond later you're screwed so display a message to the end user along the lines of "I told you so!" End users really like that type of thing. ;)
You could get a bit fancier by replacing all units with simple cubes or something, but all that does is delay in the inevitable a bit longer.
ncage - Thursday, July 12, 2007 - link
1) First step is to detect which OS you are using at startup. Is it 64 bit os or not?2) You SHOULD never code your application around a 2GB memory limit. It is very bad coding practice. Going through thorough examples in a short post like this isn't very practicle
3) Some higher level langauge/constructs abstract this away from you. For example if you are using .Net CLR you don't really have to worry about this unless maybe your doing some crazy pinvoke stuff which in most cases you shouldn't be doing anyways. Of course if your doing VB6 your never going to get around it anyways because vb6 is only 32 bit.
4) If you are doing C++ or assembly with windows then you can use the GlobalMemoryStatus() Function to Effectively see how much available address space you have.
Ryan Smith - Thursday, July 12, 2007 - link
The key to any of this is monitoring how much of the virtual address pool is in use; there should be an API call to ask Windows this. The easiest thing to do would be to give a warning at 1.9GB or so and then either do nothing, trigger a crash early, or attempt to reduce detail or flush space to stay below the 2GB barrier. The warning is the easy part, the hard part is preventing the crash, and I don't honestly believe anyone can or will be preventing crashing.yacoub - Thursday, July 12, 2007 - link
I just wish we had a better solution than Vista. Sure we can use 64bit XP but that's only going to last how much longer with full patch support from MS?If Vista wasn't such a pile and didn't perform worse in games when using equivalent hardware as the same system running XP, it wouldn't be such an unappealing alternative.
And even so, when running 4GB of RAM, how much over a LargeAddressAware flagged game with the 3GB boot.ini switch are you really gaining by using 64bit OS? Not much, really. We first need motherboards that are happy running 8GB of RAM, RAM cheap enough to buy 8GB for a reasonable price (which is not too hard with DDR2 2GB DIMMs right now), and do so at full performance/speed settings.
Really it's not just a move to a 64bit OS, it's also a move to 8GB of RAM.
OR it's simply having developers who code their games to work properly within 3GB of addressable RAM.
instant - Saturday, July 21, 2007 - link
How many more patches do you need for XP 64bit anyway?As long as the games work for it, why care about microsoft updating "security" hotfixes or not.
Tegeril - Thursday, July 12, 2007 - link
Articles like this make me very glad that I opted to go with 64bit Vista. All my hardware is supported at this point with stable drivers (we can argue the Creative X-Fi, but it works fine). I'm just amazed that people saw this coming and yet we have games that just die because of the problem. 64 bit isn't as bad as people make it out to be regarding compatibility :D - except iTunes and Quicktime :(halfeatenfish - Thursday, July 12, 2007 - link
How do the *nix variants deal with this same issue? Do they even have it? Can someone shed some light, especially in terms of OS X... Leopard, if anyone knows anything there. But Tiger info is just as good.titan7 - Thursday, July 12, 2007 - link
They all do the same thing for 32bit. Bu generally speaking *nix has been 64bit for years (decades) so if it is a problem just run the 64bit version of everything. And being more cross platform their code tends to have less hacks like you get in Windows apps that assume there is an extra bit available on every pointer. A single bit! Bah, we're talking about billions of bytes and elite programmers are trying to squeeze every last bit out of their application at the expense of future compatibility. LAME.The Boston Dangler - Thursday, July 12, 2007 - link
OSX is a 64-bit system, *nix ymmvMadBoris - Thursday, July 12, 2007 - link
Cool article Ryan. Good to see these issues getting more global attention.Since 32 bit seems it is here to stay for a lot longer than we want it to, and with software bloat continuing, this will hopefully continue to put pressure on driver devs to write better drivers that can handle >2GB addresses without issue. So that people can use the /3Gb switch without concern. I personally have never had problems with /3GB with any of my hardware/drivers but certainly 'less mainstream' drivers may not be handled with the care that they should be.
I like the breakdown of games/apps that support the LargeAddressAware flag, maybe this list can grow for future articles covering more apps/games. I also enjoyed your testing on the "potential" penalty of less kernel space, something I never took the time to do on my own.
Imagine my suprise today when making my rounds to my favorite hardware site. ;)