1

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?

codewario
  • 19,553
  • 20
  • 90
  • 159
  • 1
    Enabling this would probably not make Visual Studio run faster. If Visual Studio were running out of address space it would crash or emit out of memory warnings. If Visual Studio is not running out of memory, this will likely do nothing positive – shf301 May 29 '13 at 23:32
  • You never mentioned whether you were running on 32 bit or 64 bit Windows, or whether you were using the /3GB switch. – Robert Harvey May 29 '13 at 23:50
  • 1
    Fear not, it is entirely safe. The option was already turned on. – Hans Passant May 30 '13 at 00:30
  • @shf301: I did notice a pretty decent build time decrease, and my memory usage now exceeds 250000KB as opposed to the 150000KB it was using before. I'm curious as to why because I verified that an unmodified devenv.exe already has this option enabled – codewario May 30 '13 at 14:36
  • @RobertHarvey: Sorry, I am using Win7 Ultimate 64-bit, and VS 2010 Premium – codewario May 30 '13 at 14:38

3 Answers3

3

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.

Community
  • 1
  • 1
shf301
  • 31,086
  • 2
  • 52
  • 86
2

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.

Community
  • 1
  • 1
Les Ferguson
  • 351
  • 1
  • 6
  • Well, it did something, because before VS was using some 150000 KB or memory, now it's using around 375000, and my build time has decreased by about 25% – codewario May 29 '13 at 23:42
  • This is the correct answer, the option is already turned on. Has been at least since VS2008, possibly before. Run dumpbin.exe /headers on devenv.exe to see this. Well, the unmodified version. – Hans Passant May 30 '13 at 00:23
  • This is very interesting. I just checked the headers on another machine with an unmodified devenv.exe, and indeed the application already has the option turned on. But I definitely checked my build time and memory usage both before and after running the editbin /largeaddressaware command and there is a noticeable performance/memory usage increase. I'm wondering if the editbin command does something to the executable that wasn't shipped with devenv.exe by default? – codewario May 30 '13 at 14:30
  • Also, a correction for my first comment on here (won't let me edit at this point) after running editbin on devenv.exe, the memory usage went up to 275000 on average, not 375000 – codewario May 30 '13 at 14:35
0

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.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • Very true. I did read the MSDN page on the command, but the documentation on the utility seems meager. The article you linked to didn't even come up when I searched Google, maybe I'm just starting to get old, I can't even search the internet properly lol – codewario May 29 '13 at 23:20
  • To clarify: I don't think Microsoft has made any claim that VS will work if modified with Editbin (or any such tool); the claim is that Editbin works. Also note that section 9 of the VS2010 EULA (titled "Scope of License") notes that "You may not: work around any technical limitations in the software;". – Jimmy May 29 '13 at 23:26
  • @Jimmy: Yes, I concur with your assessment of Editbin and its sanctioned uses. The clause you pulled from the license is meant to prevent things like hacking Visual Studio Express so that it will accept plugins (a feature that is blocked in the Express editions). Editbin is designed specifically to execute this hack, so it seems unlikely that Microsoft would not want you to use it for this purpose. – Robert Harvey May 29 '13 at 23:28