2-4GB game memory limits and solutions
- 1 OVERVIEW
- 2 BACKGROUND
- 3 THE PROBLEM
- 4 THE (Limited) SOLUTION
- 5 IMPLEMENTATION
- 6 FAQs
- 7 REFERENCES
Most games that are written for Windows are "32-bit" by default, and as such are limited by Windows to having access to only 2 Gigabytes (2GB) of system memory (not video memory, which is separate). (Games written specifically for 64-bit systems have a much, much larger memory limit.) It is possible for the player to make some relatively simple changes to their Windows configuration to enable their 32-bit game to access up to 4GB of Random Access Memory (RAM), assuming at least that much is installed. This article attempts to explain some of the complexities behind this issue as well as how the fix needs to be accomplished and what the limitations are, depending upon the combination of your version of Windows and hardware. It also applies to Operating Systems (OS) that are acting 'Windows-like', such as the Apple MacIntosh with OSX and Unix style platforms using 'WINE'.
Which solutions apply to your personal circumstances depend upon both hardware and software considerations. These assume you are using a workstation rather than a server as your hardware platform. You need to understand what is involved to determine how to resolve the issue satisfactorily.
While a bit technical, the following simplified explanation is essential to understanding both the problem and the solution. For a more precise technical description of what is described here, see RAM Limit and the related articles linked there. For an in depth technical perspective on the impact of this issue on games in general at the time of the release of Windows Vista (2007), see the article A Messy Transition: Practical Problems With 32bit Addressing In Windows.
All computers have a limit to how much RAM memory they can address. This is determined by the size of the address registers used in the Computer Processor Unit, the CPU, as measured in 'bits', and the number of hardware address pins. The maximum addressable memory for any given number of address bits without utilizing special techniques, is 2 to the power of the number of address bits x 1 byte (2^16 × 1 byte). The original IBM PC used an Intel 8080 processor with 16-bit addressing and 16 address pins. It could address up to 65,536 bytes or 64 kibibytes. The Intel 20386 process had 16 bit addresses and 24 address pins, and a maximum addressable limit of 16MB. The Intel Pentium processor series could handle 32-bit addressing with 32 address pins, raising the default limit to 4GB.
So you can see from this that the limits of addressable RAM memory are hardware related. Game developers are constrained by the hardware and Operating System (OS) limitations available at the time of development.
What follows is a very condensed summary of a specific portion of the issue pertaining to the use of the "Large Address Aware" (LAA) flag to enable the use memory beyond the 32-bit application's default 2GB boundary. It is from the perspective of the Operating System (OS), rather than that of the application or developer which only see "virtual memory" as a single contiguous address space. "Virtual memory" separates the applications view of memory from the systems physical memory.
For an in-depth technical discussion of how Windows and applications handle the specific resources of memory (physical and virtual), please read Mark Russinovich’s (of Windows System Internals fame) technical blog series titled "Pushing the Limits of Windows" on TechNet.com. The first two articles are essential to understand the difference between "physical" and "virtual" memory and how the LAA flag affects these resources.
Games have to be designed to run on a target CPU, whether that is a game console or an IBM PC based system or an Apple MacIntosh or a Unix system. It is only sensible to shoot for the widest possible audience, which means the broadest 'lowest common denominator' hardware not only for the moment but also the near future. Games designed to run on Windows XP were written using 32-bit addressing. Their virtual addressing limit is 4GB. Only games specifically written to do so will be able to exceed this limit by utilizing certain features, such as Physical Address Extension (PAE), which are not enabled by default. And assuming larger addressing limits won't happen until the game developers decide there has been sufficient market penetration of such systems supporting that methodology to be profitable.
A game written with a 32-bit addressing scheme can also run on a 64-bit OS, but will still be limited to 4GB. Nothing can fix that except re-writing the game with a different scheme that addresses beyond 4GB. This is not to say addressing beyond 4GB is not possible, only that it requires certain prerequisites game developers do not assume to be present by default at this time.
While a 32-bit addressing scheme permits addressing 4GB, there are other, hardware constraints: primarily the amount of physical RAM installed in the computer as well as the addressing capabilities of the CPU, memory required for device mapping, and the OS configuration. Given that a 32-bit OS has to use some of that same 4GB for it's own purposes (such as device drivers and communication between programs), a game only gets whatever RAM remains after the OS needs are fulfilled. By default, Windows splits the system RAM evenly between the OS and applications.
Virtual Memory Management
The OS (Windows in this case) manages the allocation of 'virtual memory' space to programs (apps), which means the memory address used by the app is different from the actual physical RAM address. [See the wiki article Virtual Memory.] Each app requests a certain amount of space when it starts up (which is at a specific location in the file header). The OS allocates physical RAM memory and builds a table allocating the first allocated block as the starting address of that block of virtual memory and the requested length (in blocks). As far as the app (and every other app) is concerned, that starting address is byte zero of the system RAM available to it. When the app wants more space than was originally allocated to it, it issues a request to the OS, which updates it's memory table for that app linking in the starting address of another block of memory and that block's requested length. Again, as far as the app is concerned, it's all one contiguous block of memory. It's the OS' job to keep the physical to virtual block allocations straight as various other apps release their allocated space and request additional memory.
Apps request additional memory, the OS allocates blocks of memory to meet that request as best it can (on a 'first come, first served basis' normally), and apps are responsible for not exceeding their allocated space. There is no 'conflict' as long as everyone follows the rules, but apps vary considerably in how well they prevent themselves from exceeding their allocated space (i.e. 'memory leaks'). When the OS has no more blocks of memory available to meet a request (after garbage collection), it looks for idle processes, suspends them, and swaps their allocated memory contents to 'secondary memory' (disk swap space), and updates the memory table accordingly before allocating this 'freed memory' to the request. (This manifests in the apps as 'stuttering'.) Despite this, eventually there is no more available memory to be freed up and the request is denied.
What happens when the request for more memory is denied? That depends upon the design and coding of the app. The evidence so far suggests that games notorious for CTDs or other 'out of memory' errors don't consider that possibility, or at least handle it poorly.
So there is not really any 'fighting for space', but one can conclude that there is an unintentional race between memory hungry apps to request all available space. However, since they each are (as far as they know) the only process in the system, they assume they have access to all the memory not normally consumed by the OS overhead itself (i.e. "2 GB"). Games in general (and especially ones designed for consoles) appear to not consider the possibility they might have a lessor limit due to a competing app.
It may be that some OS manages memory differently (such as giving priority to particular classes of app), even among the Windows versions. But that's the basic process at the core of all virtual memory management, which Windows has used ever since version 3.0. Because RAM is a limited physical resource, there always has to be some mechanism to manage it. This is independent of whether the OS is 32-bit or 64-bit based, and how it works in Win XP which is the environment most current Windows games were designed to run under. Windows 64-bit uses the same basic virtual memory management technique. A 64-bit OS is fundamentally just as limited with 4 GB of RAM as a 32-bit OS.
Windows evolved from a shell layered upon the DOS operating system. DOS loaded most of it's core functions starting at address zero, or in what became referred to as 'low memory'. So games became used to loading above a certain point in memory, and only really needing to worry about where their available memory ended. As Windows evolved, it required more and more of that 'low memory'. According to the 'Microsoft Developer Network' (MSDN) article 4-Gigabyte Tuning:
On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system.
The 4-gigabyte tuning (4GT) feature, formerly called 4GT RAM Tuning, increases the virtual address space that is available to the application up to 3 GB, and reduces the amount available to the system to between 1 and 2 GB.For applications that are memory-intensive, such as database management systems (DBMS), the use of a larger virtual address space can provide considerable performance and scalability benefits. However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.
See also the MSDN article Memory Limits for Windows Releases.
Devices have to map their memory below 4 GB for compatibility with non-PAE-aware Windows releases. Therefore, if the system has 4GB of RAM, some of it is either disabled or is remapped above 4GB by the BIOS. If the memory is remapped, X64 Windows can use this memory. X86 client versions of Windows don’t support physical memory above the 4GB mark, so they can’t access these remapped regions. Any X64 Windows or X86 Server release can.
X86 client versions with PAE enabled do have a usable 37-bit (128 GB) physical address space. The limit that these versions impose is the highest permitted physical RAM address, not the size of the IO space. That means PAE-aware drivers can actually use physical space above 4 GB if they want. For example, drivers could map the "lost" memory regions located above 4 GB and expose this memory as a RAM disk.
NOTE: Here 'X86' refers to versions of the Intel Pentium processor family and later.
Due to a number of interactions, there developed a perception of what came to be called the '3GB barrier' (based upon the '/3GB' switch in the Windows BOOT.INI file) to the amount of memory games could access. For a technical discussion of this, see the Wiki article 3GB Barrier. In particular, as the article says:
RAM near the 4 GB point conflicts with memory-mapped I/O space. Either the BIOS simply disables the conflicting RAM; or, the BIOS remaps the conflicting RAM to physical addresses above the 4 GB point, but x86 Windows client editions refuse to use physical addresses higher than that, even though they are running with PAE enabled. The conflicting RAM is therefore unavailable to the operating system whether it is remapped or not.
However, it is important to note that the motherboard and it's chipset must also support the PAE modification of the 'protected mode' address scheme capability, which allows virtual or linear addresses to be translated to 36-bit physical addresses up to 64GB. Fortunately, this has been true of most systems since the days of the 1995 Pentium Pro processor.
THE (Limited) SOLUTION
There are some steps the typical game player can take to enable their game to access more than 2GB of virtual memory. These are two-fold and specific to the 'bit version' of Windows in use.
- Add modifications to the Windows 'BOOT.INI' file on 32-bit versions of the OS.
NOTE these are MAY still be needed on a 64-bit OS, depending upon the default configuration.
- Enable the 'Large Address Aware' (LAA) flag on the game executable (all bit versions).
[See the IMPLEMENTATION section for details.]
"On Windows Server 2003 [and later versions of workstations], the amount of address space available to applications can be adjusted by setting the /USERVA switch in BOOT.INI to a value between 2048 and 3072, which increases the amount of address space available to the system. This can help maintain overall system performance when the application requires more than 2 GB but less than 3 GB of address space." [ibid.] There are trade-offs in using this, because it causes the OS to reduce the size of pools of memory used for Input/Output and other operations.
The mechanism for changing BOOT.INI switches has evolved over time, and the syntax of the switches have developed variants as well. Microsoft has gone away from directly editting the BOOT.INI to using tools like BOOTCFG or the more recent (Vista+) BCDEditor. Both of these tools are run from the command line. There are also some GUI versions available from third-parties, such as the freeware 'Visual BCDEditor'. Please see the MSDN article BCD Boot Options Reference for a list of the 'BCDEditor' equivalents to the older switches.
The following is taken from the MSDN article Physical Address Extension (PAE).
The Intel Itanium and x64 processor architectures can access more than 4 GB of physical memory natively and therefore do not provide the equivalent of PAE. PAE is used only by 32-bit versions of Windows running on x86-based systems.
Windows automatically enables PAE if [Data Execution Prevention (DEP), in WinXP-SP2 onwards] is enabled on a computer that supports hardware-enabled DEP, or if the computer is configured for hot-add memory devices in memory ranges beyond 4 GB. If the computer does not support hardware-enabled DEP or is not configured for hot-add memory devices in memory ranges beyond 4 GB, PAE must be explicitly enabled.
PAE, 4-gigabyte tuning (4GT) (aka the "/3GB" switch), and Address Windowing Extensions (AWE) serve different purposes and can be used independently of each other:
• PAE allows the operating system to access and use more than 4 GB of physical memory.
• 4GT increases the portion of the virtual address space that is available to a process from 2 GB to up to 3 GB. This is the primary "fix" for 32-bit systems with 3-4GB of RAM.
• AWE is a set of APIs that allows a process to allocate nonpaged physical memory and then dynamically map portions of this memory into the virtual address space of the process.
When neither 4GT nor AWE are being used, the amount of physical memory that a single 32-bit process can use is limited by the size of its address space (2 GB). In this case, a PAE-enabled system can still make use of more than 4 GB of RAM to run multiple processes at the same time or to cache file data in memory.
4GT can be used with or without PAE. However, some versions of Windows limit the maximum amount of physical memory that can be supported when 4GT is used. On such systems, booting with 4GT enabled causes the operating system to ignore any memory in excess of the limit.
AWE does not require PAE or 4GT but is often used together with PAE to allocate more than 4 GB of physical memory from a single 32-bit process.
It is necessary to use an account with Administrator privileges to make changes to the BOOT.INI file. If you use a GUI version of the BCDEdit tool, you can simply right-click on it and in the context menu select the 'Run as administrator' option from a 'normal user' account.
Use the command line 'BCDEdit /set' command or a GUI equivalent (or directly edit BOOT.INI) to:
- 32-bit Windows:
* set the 'INCREASEUSERVA' boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).
[64-bit OS NOTE: this switch MAY be needed.]
- 32-bit Windows XP Professional, and Windows Server 2003 or earlier:
* add the '/3GB' switch * add the '/PAE' switch (to disable set '/NOPAE')
[64-bit OS NOTE: these two switches definitely are needed on 32-bit systems. However, they are not available on a 64-bit OS. See BCDEdit /set article for the list of valid BCDEdit options, and the 64-Bit SIDEBAR section.]
[See the previously referenced '4-Gigabyte Tuning' article for implementation instructions on Itanium versions of Server 2003, and the 'BCD Boot Options Reference' for the correct syntax.]
LAA in General
- Enable the 'Large Address Aware' (LAA) flag on the game executable:
- Visual Studio MSDN docs say that large-address-awareness is a process property, which comes from the executable. Note that the LAA flag is an option for the linker during a code compilation, and is a specific thing that works in a unique way. Enabling the flag after compilation is not documented. What is known is that DLLs compiled with that linker option have the flag set. (An article on the subject Large Address Aware has a screenshot of the 'Dumpbin /Headers' command for a DLL showing it enabled.) Consequently, enabling the flag for DLLs associated with an EXE with the flag would likely provide consistent behavior. Observe that DLLs are in the "virtual address space" of the EXE, and as such do not appear in the Task Manager as separate processes.
LAA is a FLAG. A flag has to be interpreted. To the Linker (when a program is compiled) it means it needs to follow certain rules in resolving addressing of the virtual address space. To the Memory Manager (a service of the OS) it means (supposedly) the program developer has "followed the rules" to do so successfully, and thus it can be loaded above the 2GB boundary in the "physical memory address space".
A free-to-use program called 4GB Patch is available to easily turn on the LAA flag in game EXEs. This is the most commonly suggested LAA tool due to it's ease of use, though there are others available. However, this patch program from NTCore, according to it's home page description 4GB Patch, only modifies EXE files. And it doesn't provide a means to verify for yourself that it modified any other type of file (like DLLs) even if you manage to use it on them.
CFF Explorer (from the same site) does, and is also easy to use, though less obviously so as it doesn't provide any documentation. Follow the general instructions given here under LAA for Steam. (The '4GB Patch' is a stripped down version of the CFF Explorer functionality for a single purpose: modifying EXEs.) It is recommended you use it to enable the LAA flag on both EXE and DLL files.
Before you install ANY games on a Windows Vista or later Operating System, read the wiki article Installing Games on Windows Vista+. Installing to the default "C:\Program Files" tree will cause problems, of which fighting with the UAC is only one.
A more recent option is the 4GB Ram Patcher tool, which is customized to patch all the EXE and DLLs related to Oblivion. It works in a similar manner to CFF Explorer but may be easier to use for some people. However, it appears to be specific to Oblivion only.
Testing an application for compatibility with LAA
Despite the above, the use of large address spaces is dependent upon the game developers having followed certain "rules". When retroactively applying the LAA flag, you have no way of knowing if the game conforms to those rules.
There is a registry key value that instructs the Windows Memory Manager to allocate memory "from the top down", i.e. from the uppermost available addresses. By default memory is allocated from low memory upwards. This can be used to check for an application or it's components compatibility with the use of LAA. Note that this registry key does not appear to be automatically set by applications. Therefor, it may be of assistance in some instances as an option where other configuration changes have not proven sufficient to free up enough memory.
If you are using any third-party components, you should confirm that these components support the LAA setting. You can test an application for compatibility with LAA by forcing it to use the large address memory space. To do this, configure the following registry key:
Note: Consider creating a backup before modifying the registry. To make a backup, select File»Export in the Registry Editor.
Location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference Key Name REG_DWORD New Value 0x100000
With this registry key configured, the memory gained from the LAA flag will be used first by the application, thus making it more likely that any incompatibilities will be encountered in your testing.
LAA for Steam
The following instructions are cribbed from SteamPowered Forums:
- Make a backup of the game EXE (i.e. 'Oblivion.exe') and (if a Steam game) Steam's 'GameOverlayRenderer.dll' (an easy way is to just copy the file, then paste it into the same directory, or the Desktop, or anywhere else).
- Download "CFF Explorer" from the NT Core site or CFF Explorer file.
- Launch "CFF Explorer" and open the game EXE (i.e. 'Oblivion.exe': File -> Open -> navigate to the Oblivion install folder and select 'Oblivion.exe')
- In the left side of the window, choose the "File Header" section under "Nt Headers"
- Look on the right side for the row starting with "Characteristics", and the "Click here" field. Click there. (A context menu appears for the next part).
- Select/enable the checkbox for "App can handle >2gb addresses" and click 'OK'.
- Save the file (File > Save).
- Repeat 3-7 for Steam's 'GameOverlayRenderer.dll' and any other files you believe needed.
- Exit "CFF Explorer" and start up your game normally.
There are some other Steam DLLs which can also be patched to have the LAA flag enabled. They are not required to get the game to use more memory, but as with other DLLs [see FAQ below] may free up some memory for the game.
STEAM USERS NOTE: If you leave Steam enabled to connect online when you bootup, and allow automatic updates for your game, you may find any modified Steam files (either the Steam Client app or games) need to be repatched periodically. This is because Steam is replacing your modified (and thus 'corrupt') files with their current versions, as it is designed to do. See this Steam and mods wiki article for steps to control this.
Page File Size and The Commit Limit
The size set for your "page file" can make a difference as well in terms of something called the "commit limit". This is described in Mark Russinovich's "Pushing the Limits of Windows: Virtual Memory" article in the section titled "Committed Memory". The key point is:
... the commit limit is the sum of physical memory and the sizes of the paging files. In reality, not quite all of physical memory counts toward the commit limit since the operating system reserves part of physical memory for its own use. The amount of committed virtual memory for all the active processes, called the current commit charge, cannot exceed the system commit limit. When the commit limit is reached, virtual allocations that commit memory fail. That means that even a standard 32-bit process may get virtual memory allocation failures before it hits the 2GB address space limit.
Since the commit limit sets an upper bound on how much private and pagefile-backed virtual memory can be allocated concurrently by running processes, the only way to reasonably size the paging file is to know the maximum total commit charge for the programs you like to have running at the same time. If the commit limit is smaller than that number, your programs won’t be able to allocate the virtual memory they want and will fail to run properly.
So how do you know how much commit charge your workloads require? You might have noticed in the screenshots [in the article] that Windows tracks that number and Process Explorer [(a SysInternals tool)] shows it: Peak Commit Charge. To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number.
The default system page file configuration does not follow this advice, so it's something to look into. See Mark's article for details.
"With the introduction of 32-bit libraries in Windows 95 every [DLL] process runs in its own address space." [This would be physical address space. As far as the application is concerned, the DLL is loaded into it's virtual address space.]
DLLs share the same file format as an EXE. As with EXEs, DLLs can contain code, data, and resources, in any combination, within their own address space. Conceptually in abstract they are the same type of file: separate but cooperating programs or applications ('apps'). The LAA flag is a 'Large Address AWARE' flag (my emphasis). It enables a DLL (which is loaded as needed by the calling program, and thus relatively unpredictable by the player) to load into physical memory locations greater than the 4 GB virtual space addressable by the 32-bit game. Without the flag, they will only be loaded into the same 4 GB space as the game. The more code you can get to utilize the higher memory above 4 GB, the more room for the code (and data) which can't (not LAA enabled). It's about memory management in loading code, which reduces the chances of exceeding available memory.
LAA flagging does not prevent a program from gobbling up all available memory until it crashes, nor is it a magic bullet that makes the code 'better'. There is no guarantee that a DLL will perform correctly when loaded to upper memory if it was not LAA flagged by the developer. But it should manifest problems quickly in that case if the registry test setting suggested above is used, and has proven to successfully improve the amount of available memory for some games (i.e. The Elder Scrolls: Oblivion).
1. As pointed out above: in a game that is written for a 32-bit environment, 'virtual memory' addressing only goes up to 4 GB. If the game does not handle 'out of memory' conditions well, you get CTDs when it attempts to write data beyond the bounds of it's allocated memory. This is the OS protecting itself from 'rogue apps'. While each 32-bit app gets it's own 'allocated' memory space, they all must share the lower 4 GB of memory because they can't address memory above 4 GB. The more loaded in the lower 4 GB, the less available memory is allocated to each process. All have to fit into the same 4 GB 'bag'.
2. In order to get the maximum use out of that lower 4 GB of memory for a 32-bit game, you need to reduce the 'reserved footprint' of the OS and anything else occupying that space as much as possible. That means loading everything you can above 4 GB with a 64-bit OS, and shutting down any non-essential programs and services with a 32-bit OS. Programs like ioBit's (now Razor's) GameBooster help you determine and decide which apps and services are 'non-essential' as well as provide a simple mechanism to stop and start them. How well you manage this determines how close to the 4 GB game virtual memory limit you can get, even on a 64-bit system. If DLLs are not flagged as LAA, then they won't get loaded above 4GB. They still might not, even with the flag. The only way you can tell is to track each process and find the starting address, but what can you do if it isn't loading high? (Nothing: it's out of your control.) But if the LAA flag is not set, it's guaranteed the EXE or DLL will be loaded into the lower 4 GB of memory and reduce the available memory.
So: flagging a DLL as LAA enables it to be loaded above the 4 GB boundary, and thus make more space available to your game. But it is not absolutely essential, of only minor effect with a 32-bit OS, and any particular DLL might not have any practical effect. But having a chance to reduce your lower memory footprint is commonly regarded as preferable to having no chance. Whether these efforts are worth it to you is a personal decision.
A 64-bit OS will load much of it's core functions into high memory as a matter of course to protect them from older 32-bit apps, thus reducing the size of the 'reserved footprint' well below 2 GB and out of their ability to address directly such as by writing beyond their allocated space. The older 32-bit OS does not, which is one reason why the LAA flag is less successful with those systems. The reserved footprint of a 32-bit OS in the lower 4 GB is larger from necessity.
Windows Vista+ versions of the OS in 64-bits no longer use a BOOT.INI. Instead the equivalent is called the Boot Configuration Data store (BCD), which is accessed with the provided command line tool BCDEdit. The only option mentioned above for 32-bit OS which is available with the 'BCDEdit /set' command is:
/PAE and /3GB equivalents are not available (or needed) with a 64-bit OS. See BCDEdit /set, for details, paying careful attention to statements about the 'bit-ness' of the OS for each option.
Some Q&A for clarification
Question - Scenario 1: 32-bit system with 4 GB RAM. Windows XP reserves 1 GB for itself. With the LAA flag, the game EXE and every other process running share the remaining 3 GB. If I understand this scenario correctly, I fail to understand what flagging the DLLs as LAA does. (If someone is using W7 32-bit, it will reserve 2 GB for itself, making even applying the LAA flag to the game EXE practically useless, it seems to me.)
Answer: Re Scenario 1 (32-bit OS w/4 GB of RAM): Your understanding is correct. LAA flagging of DLLs will do little in this circumstance, a point often overlooked in such discussions which are really focused upon 64-bit systems. GameBooster is much more effective here. However, as I recall, reports were that the LAA flag on the game will get a little more memory use before the CTD. Note that the recommended BOOT.INI switches can also help here.
Question - Scenario 2: 64-bit system with 8 GB RAM. The OS reserves 2 GB for itself. The remaining 6 GB is available for allocating to programs. If the game EXE is flagged LAA, it should be able to address 4 GB, leaving 2 GB for all other processes, programs. Are you saying that flagging the DLLs as LAA will force them to address the leftover 2 GB, and without flagging them LAA, they will share the 4 GB the game is addressing?
Answer: Re Scenario 2 (64-bit OS w/8 GB of RAM): Basically, yes. Without the LAA flag, both the game and the DLLs will be loaded into the same 4 GB of memory, as in Scenario 1. The space occupied by the DLLs is thus unavailable to the game. As far as the OS is concerned, the game and DLLs NEED to believe they are in Scenario 1. With the LAA flag, they get loaded into any portion of free memory space (i.e. the upper 6 GB postulated) and can be given up to 4 GB. Though it is more correct to say they are 'enabled' to be loaded high rather than 'forced'. (The OS has it's own mechanism for deciding what gets loaded where in physical RAM.) In this situation, the DLLs are loaded separately and away from the memory space that can be claimed by the game itself, which is thus maximized to a 4 GB limit. (This does assume the DLLs do not occupy more than another 2 GB.)
Referred to by this article:
- RAM Limits
- A Messy Transition: Practical Problems With 32bit Addressing In Windows
- Virtual Memory
- 4-Gigabyte Tuning
- Memory Limits for Windows Releases
- 3GB Barrier
- 'Visual BCDEditor'
- BCD Boot Options Reference
- Physical Address Extension
- BCDEdit /set
- 4GB Patch & CFF Explorer
- SteamPowered Forums
- CFF Explorer file
- Installing Games on Windows Vista+
- Steam and mods
- Dynamic-link library
- Virtual Memory
- Process Explorer
That refer to this article: