nifty trick to address more memory under win 32-bit

[urlwolf]

Acording to Microsoft:

The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of
additional virtual address space above 2 GB.

This tiny switch /3GB can do wonders.

The catch: the application must use IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header.

From nettakeaway.

[f0dder]

You need the combination of boot.ini flag and the PE appheader flag... there's probably a lot of programs around that don't have this flag set even though they wouldn't have any problems (problematic apps are the ones that assume they'll never see addresses higher than 2GB-1, and thus use bit31 of pointers for "whatever").

How much you gain from this tweaking is questionable though - you need some real memory-hungry apps to have any advantage, in which case (if you're a developer) it'd be best to move to 64bit. And you could run into trouble when the kernel only has 1GB address space available (at least you won't be able to have large memory-mapped files nor a lot of filesystem cache).

[justice]

You'll want to know that someone commented on related article that PAE is disabled in desktop versions of windows due to the fact that not all drivers support it and this would impact system stability - or your pc might not boot up.

Windows XP originally supported a full 4 GB of RAM. You would be limited to 3.1-3.5 GB without PAE, but if you enabled PAE on a 4 GB system with proper chipset and motherboard support, you would have access to the full 4 GB. As more people began to take advantage of this feature using commodity (read: cheapest product with the features I want) hardware, Microsoft noticed a new source of crashes and blue screens. These were traced to drivers failing to correctly handle 64-bit physical addresses. A decision was made to improve system stability at a cost of possibly wasting memory. XP SP2 introduced a change such that only the bottom 32 bits of physical memory will ever be used, even if that means some memory will not be used. (This is also the case with 32-bit editions of Vista.) While this is annoying to those who want that little bit of extra oomph, and while I would have liked a way to re-enable the memory “at my own risk”, this is probably the right decision for 99.9% of the general population of Windows users (and probably saves Dell millions in support costs). See the relevant KB article and a TechNet article for details.

Some of the server Operating Systems still allow the use of larger amounts of memory. I’m guessing that this is done with the assumption that higher quality parts will be used and drivers will be more likely to have been tested in PAE mode with large addresses.

http://support.microsoft.com/kb/929605/en-us
http://technet.microsoft.com/en-gb/library/bb457097.aspx

[lanux128]

this switch came to my notice when i was playing Gothic3 where some of the German gamers had made patches of the exe and dll files to take advantage of the extra 1GB since the game itself was not so optimized at that time. i guess they just re-compiled the files to be LARGE_ADDRESS_AWARE (LAA) compliant but i'm not so sure of the results since i didn't have 3gb then.

here is the link (in German):
• http://forum.worldofplayers.de/forum/showthread.php?p=2668283&#post2668283

[f0dder]

justice: PAE isn't disabled on XP, it's enabled and used to support hardware-assisted per-page no-execute protection. But with SP1 and onward, while PAE is enabled on supporting hardware, physical memory addresses are artificially limited to 32bit. The official explanation is, as you mention, "bad drivers" which is of course part of the truth. But I bet that "not wanting to carve the market for server OSes" is part of it as well.

lanux128: as long as your application doesn't do "dirty tricks" with pointers and doesn't assume it only has 2 gigabytes of address space available, you don't need to recompile or anything - simply use a hex editor and change a single bit in the PE header and the app is now made large-address-space-aware - editbin.exe (which is really just a frontend for link.exe) from Visual C++ can also be used for this, and is a bit easier than messing around with hex editors :]

[lanux128]

thanks for the pointer, f0dder. i never got in touch with the original patcher so i don't know how he did it, therefore your explanation helps a lot. i'm also curious to know if there is a way to show that the application is indeed taking advantage of the 3gb ram.

[f0dder]

thanks for the pointer, f0dder. i never got in touch with the original patcher so i don't know how he did it, therefore your explanation helps a lot. i'm also curious to know if there is a way to show that the application is indeed taking advantage of the 3gb ram.

Look at it's memory statistics with Process Explorer or the like