If you’re not running a 64-bit version of Windows, I bet that at least one of your customers is. While you should be working on porting your native applications to 64-bit, it doesn’t look like that many teams have made that step. While it will take effort and testing to make the switch, you can make a small change to your 32-bit builds that will provide a big benefit when running on x64: more memory!
All you need to do is add the /LARGEADDRESSAWARE to the linker for your EXE and when your 32-bit EXE is run on a 64-bit system, it will have a 4GB address space instead of the default 2GB address space normally associated with 32-bit applications. As with any switches like this one, you will need to test your application on the 64-bit machine to ensure you don’t have problems. If you are using the high bit of pointers addresses or subtracting pointers that are not from the same object, setting /LARGEADDRESSAWARE will cause a serious bag of hurt.
To turn on /LARGEADDRESSAWARE, go into your EXE project properties, Linker, System and set the Enable Large Address field:
To show you the benefit of the /LARGEADDRESSAWARE switch, I created a simple EXE application that allocated and committed 50 MB every time you clicked a button and popped up a message box when the allocation failed. Without the /LARGEADDRESSAWARE switch set, here’s what Process Explorer reported for Private Bytes and Working Set when running on Vista x64:
After turning on the /LARGEADDRESSAWARE, here’s how much memory the application was able to use on x64:
If you’re curious, the exact same EXE with /LARGEADDRESSAWARE set runs perfectly fine on normal 32-bit machines. For those of you wondering what affect this has with the /3GB boot switch for the operating system, read more about the /3GB here.
While some people are taking /LARGEADDRESSAWARE to interesting extremes, it’s definitely something that anyone building 32-bit EXEs should be looking at. However, as I said before, don’t just flip it on and ship, you do need to test on x64 machines to ensure you or any libraries you use don’t do stupid things with pointer addresses.