CODEWITHSUNDEEP
visual-studio-2010
codewario
codewario

Reputation: 21428

What are the implications of making Visual Studio 2010 able to use more than 2GB of RAM?

Alright, I found this guide and a few others on the internet which suggest running the following command from the VS 2010 IDE directory using the Visual Studio Command Prompt:

editbin /largeaddressaware devenv.exe

I've run this, and everything so far seems to work fine (I haven't run into any issues yet). But what I can't find information on is what negative implications, if any, there are by making Visual Studio 2010 use more than 2GB of RAM? Visual Studio was built to use a max of 2 GB of RAM. If VS was meant to use more than 2 GB of RAM, then I wouldn't have to hack the binary lol. While I love flying by the seat of my pants and trying new things without preparing for the worst (it's all I'm good at, haha), I'd at least like to know what issues I should be prepared to deal with should something go wrong.

TL;DR;: What negative implications are there, if any, by using the "editbin" command above to make Visual Studio 2010 aware of memory addresses greater than 2 GB?

Upvotes: 1

Views: 1777

Answers (3)

Les Ferguson
Les Ferguson

Reputation: 351

After reading this discussion and checking the existing headers, it looks like VS2010 already has this capability applied, at least for my installation anyway (64bit win7). If it was already compiled in I don't think you need to worry about bad side-effects.

Upvotes: 2

shf301
shf301

Reputation: 31394

The negative implications of enabling largeaddressaware is that the application could crash or corrupt memory in strange ways. The program was written assuming that no pointer value it had to deal with would be > 2GB. This can be done in subtle ways. The canonical example is probably calculating the midpoint address between to pointers.

ptrMid = (ptr1 + pt2) / 2;

That will work great if all of your pointers are < 2GB, but if they aren't you will get an incorrect result due to overflow.

ptrMid = (0x80000000 + 0x80000004) / 2 = 0x0000002, not 0x80000002

And not only do you have to worry about Visual Studio not being able to handle pointers > 2GB, any add-in would be affected by this as well.

See this question for some more things that have to be checked before enable largeaddressaware, see this question: What to do to make application Large Address Aware?

You really should never use editbin to change largeaddressaware on an application you don't control.

Upvotes: 3

Robert Harvey
Robert Harvey

Reputation: 180808

This appears to be by design.

Recall that even when the /3GB switch is set, 32-bit programs receive only 2GB of address space unless they indicate their willingness to cope with addresses above 2GB by passing the /LARGEADDRESSAWARE flag.

This flag means the same thing on 64-bit Windows. But since 64-bit Windows has a much larger address space available to it, it can afford to give the 32-bit Windows program the entire 4GB of address space to use. This is mentioned almost incidentally in Knowledge Base article Q889654 in the table "Comparison of memory and CPU limits in the 32-bit and 64-bit versions of Windows".

In other words, certain categories of 32-bit programs (namely, those tight on address space) benefit from running on 64-bit Windows machine, even though they aren't explicitly taking advantage of any 64-bit features.

http://blogs.msdn.com/b/oldnewthing/archive/2005/06/01/423817.aspx

Editbin is a Microsoft utility, so they're basically claiming that it works.

Upvotes: 0

Related Questions