Link 32-Bit Native C++ EXEs with /LARGEADDRESSAWARE

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.

John Robbins

View Comments

  • Hi,
    We're using it in one of our internal applications. I was wondering, do you know how one could test programmatically if the Large Address Aware flag is set for the current process?

  • I have got an old VB 6.0 code base that uses some VS 6.0 C++ DLLs where I am having the same problem. Will this approach work for 32bit DLLs that are used by a VB 6.0 EXE? I am assuming that I will have to migrate by DLL projects from VC 6.0 to VC 2010?.

  • @Petteri - If you call GlobalMemoryStatusEx and check the value of ullTotalVirtual.
    If the number is 2GB, then you are on a 32-bit OS without LAA enabled -or- your app isn't actually built with LAA enabled
    If the number is >2GB, but <4GB then you are on a 32-bit OS with LAA enabled.
    If the number is 4GB, then you are on a 64 bit OS which always supports LAA

Recent Posts

8-Step AWS to Microsoft Azure Migration Strategy

Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…

1 day ago

How to Navigate Azure Governance

 Cloud management is difficult to do manually, especially if you work with multiple cloud…

1 week ago

Why Azure’s Scalability is Your Key to Business Growth & Efficiency

Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…

3 weeks ago

Unlocking the Power of AI in your Software Development Life Cycle (SDLC)

https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…

1 month ago

The Role of FinOps in Accelerating Business Innovation

FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…

1 month ago

Azure Kubernetes Security Best Practices

Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…

2 months ago