Operating systems based on Microsoft® Windows NT® technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software.

Windows XP Professional and Windows Server 2003 Memory Support. The maximum amount of memory that can be supported on Windows XP Professional and Windows Server 2003 is also 4 GB. However, Windows Server 2003, Enterprise Edition supports 32 GB of physical RAM and Windows Server 2003, Datacenter Edition supports 64 GB of physical RAM using the PAE feature.

The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting.

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.

The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file. The following example shows how to add the /3GB parameter in the Boot.ini file to enable application memory tuning:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="????" /3GB

Background:

By default, the Windows operating system only allows a process to access up to 2 gigabytes (GB) of main memory (RAM). Therefore, if you install 4 GB of RAM, software programs such as Combustion will NEVER see nor use that extra RAM.

Even with a full 2 GB of RAM installed, the amount available to Combustion is actually less than 2GB, because some memory is required for the application's instructions, as well other memory used by shared libraries and other background tasks.

Note that, in the future, Microsoft will offer Windows XP-64 that will allow 64-bit processors to address up to 8 Terabytes; however, 32-bit processors will still be limited to 3GB per application due to physical addressing constraints of the CPU.

The Solution:

But for NOW, current versions of 32-bit Windows (ie. 2000, XP Pro) - there is a special "boot.ini" modification that will allow you to configure your Windows operating system to permit Combustion (and other software applications) to use up to 3GB of main memory! This modification has been tested by some users and reported to work well with both Combustion v3.0 and Adobe After Efects. See below for the link to the website explaining the modification.

Please Note: While the required changes to boot.ini are "simple" - please remember that ANY erroneous changes or modifications of a .ini file can make your computer un-bootable. If you are NOT comfortable making these modifications, seek the help of your system administrator. We assume NO responsibility for any errors resulting from modification or change of any boot.ini file.

Read how to change your Windows RAM Allocation here:

http://www.ensight.com/FAQ/faq.0061.html

SUMMARY
You can use the /userva=xxxx switch for more precise tuning of user and kernel virtual memory space in the Windows Server 2003 family. Use this new switch with the /3GB switch in the Boot.ini file to tune the User-mode space to a value between 2 and 3 gigabytes (GB), with the difference (3,072 less xxxx) being returned to Kernel mode. Note that xxxx is expressed in megabytes (MB).

The following sample Boot.ini file demonstrates how to use the new switch to tune a computer to allocate 2,900 MB of User-mode virtual memory and 1,196 MB of Kernel-mode virtual memory. This increases the available kernel space by 172 MB:

[Boot Loader]
Timeout=30
Default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[Operating Systems]
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows Server 2003" /fastdetect /3GB /Userva=2900

AI Tuning: Manual
CPU Frequency: 266FSB
DRAM Frequency: DDR2-800Mhz
PCI Express Frequency: 100
PCI Clock Synchronization Mode: 33.33Mhz
Spread Spectrum: Disabled
Memory Voltage: 2.00v
CPU Vcore Voltage: 1.35v
FSB Termination Voltage: 1.2v
NB Vcore: 1.25v
SB Vcore (SATA/PCIE): AUTO
ICH Chipset Voltage: AUTO

Memory Remap Feature: Enabled
Configure DRAM Timing by SPD: Disabled
DDRAM CAS# Latency: 4
DRAM RAS# to CAS# Delay: 4
DRAM RAS# Precharge: 4
DRAM RAS# Activate to Precharge: 12
DRAM Write Recovery Time: 6
DRAM TRFC: 42
DRAM TRRD: 10
Rank Write to Read Delay: 10
Read to Precharge Delay: 10
Write to Precharge Delay: 10
Static Read Control: Disabled

Modify Ratio Support: Enabled
Ratio CMOS Setting: 10x
CIE Support: Disabled
Max CPUID Value Limit: Disabled
Vanderpool Technology: Disabled
CPU TM function: Disabled
Execute Disable Bit: Disabled
PECI: Disabled

By default, an all-64-bit PC will still have the standard big holes in its memory from three to four gigabytes. This is the lowest-hassle way to deal with the problem - just install more than 4Gb of memory, and live with the fact that your 8Gb PC with a 768Mb graphics card only actually has seven-point-not-much gigabytes of visible RAM.

One advantage of this is that you can still boot a 32-bit OS, if you want to. Another is that this vanilla configuration is most likely to actually work. Cleverer memory configurations aren't necessarily properly supported by hardware and OSes yet.

If you don't care about these factors, though, there are two ways to get the lost memory back.

Some 64-bit motherboards these days give you an option for "memory hole remapping". That moves the fourth-gigabyte MMIO memory holes higher into the 64-bit address space, probably way above the maximum RAM you can physically install.

Many other 64-bit boards, though, are even smarter, and can leave the memory holes where they are and remap (at least some of) the physical RAM out from under the holes and up past 4Gb. This process is often entertainingly referred to as "memory hoisting", and it used to be the preserve of server motherboards. It's been showing up in more and more desktop mobos, though. And on some of them, the memory-hoisting BIOS setting even works, and doesn't horribly crash the system as soon as something tries to use the remapped RAM.

You may only be able to "hoist" the last 512Mb of the 4Gb address space, but that's better than nothing. If it works.

I should add a note about the /3GB, /4GT and /PAE Windows boot.ini switches, too, because they often come up when people are talking about 4Gb-plus Windows PCs.

They are all useless to you. You do not want them.

/3GB and /4GT are config settings for different versions of Windows that tell the operating system to change the partitioning of the 4Gb 32-bit address space so that applications can use 3Gb and the OS kernel only 1Gb, as opposed to the standard 2Gb-each arrangement. They don't help at all with the 3Gb barrier, and most applications don't even notice them, so desktop users lose kernel memory space (and system performance) for no actual gain at all.

The /PAE boot.ini switch, on NT-descended Windows flavours, activates the Physical Address Extension mode that's existed in every PC CPU since the Pentium Pro. That mode cranks the address space up to 64 gigabytes (two to the power of 36), and the computer can then give a 4Gb addressing block within that space - or even more, with extra tricks - to each of several applications.

PAE's no good to the everyday 3Gb-problem-afflicted user, though, for two reasons.

First, it presents 64-bit addresses to drivers, and thus causes exactly the same compatibility problems as a proper 64-bit operating system, except worse, because now you need PAE-aware drivers for 32-bit Windows, instead of just plain 64-bit drivers for a 64-bit OS. From a normal user's point of view, PAE gives you the incompatibility of a 64-bit operating system when you're still running a 32-bit OS.

For this reason, Microsoft changed the behaviour of the /PAE option in all versions of WinXP as of Service Pack 2. They fixed the endless driver problems by, essentially, making /PAE in XP not do anything. All versions of WinXP - even the 64-bit versions - now have a hard 4Gb addressing limit, no matter what hardware you use them on and what configuration you choose.

This isn't a big problem, of course, since XP is not meant to be a server operating system. But it's still mystifying to people who try the /PAE flag and can't figure out why it doesn't work.

Oh, and just in case you for some reason still wanted to try PAE: It eats CPU time, too.