Forgive me if this has been covered elsewhere, but I thought I'd explain the various options that interact with how much memory your system 'sees' and what individual applications 'see'.
The /3GB switch affects how "virtual" ram is allocated between OS & Apps. By default apps are limited to using only 2Gb of 'virtual' addressing space, windows allocates itself 2Gb of 'virtual' adressing space as well, and the entirety of the virtual address space is split up evenly between applications and the system processes. /3GB allows applications to use 3Gb of ram (instead of 2)
if they set IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header (ie, if they support large addressing), thus allowing something like gigastudio to access more ram than it otherwise would have been able to. So this only affects how individual processes (or threads) are allowed to access system addressing space (memory). The /3GB switch impacts many areas of the system (maxm amount of disk cache, max number of threads, windows, processes, TCP/IP sockets, etc.) since there is less space available for the operating system, so it should only be used to allow a memory-intensive program (Gigastudio for you) more address space.
The next thing that affects usable memory to a system and it's applications is involved with a legacy issue deating back to 1986.
With the introduction of the 386 cpu from Intel, the x86 architecture was extended to address up to 4Gb of memory. At the time 4Gb of memory was a luxury even for supercomputing, and so Intel decided to allow addressing of the peripherals attached to the system bus using addressing space below the 4Gb limit. Ie, to do i/o operations to PCI devices and other peripherals you simply wrote to memory locations at the upper end of the address space. This was a simple solution in that era, but now over a decade later it's very easy to install 4Gb of ram on a typical PC and so there's been a lot of fuss lately about only "seeing" 3-3.5Gb of ram. This is (obviously) because the system's peripherals (PCI devices, AGP or PCIe graphics cards etc) are 'mapped' to that memory space making it unavailable by default to 32bit windows Operating systems (or Linux etc).
Now from the era of the Pentium Pro on, Intel 32bit cpu's have support 36bit addressing, to allow access up to 64 GB of memory space. And of course modern 64bit cpu's can theoretically address up to 4
Exabytes of addressing space, although Vista64 is still limited to 128Gb as it's currently the limit of what can be installed on Intel & AMD x86-64 motherboards. Also, even though any modern cpu can technically address at least 36 bits, many consumer motherboards don't have the additional 4 pins connected and so are still limited to 4Gb of ram.
To complicate things even further, some hardware devices and 32bit windows drivers don't corretly handle dealing with addressing space beyond 32bits, either assuming that only the bottom 32 bits are valid or they don't properly handle the creation of bounce buffers (necessary when shuffling data from a hardware device to/from a buffer that is above the 4 GB addressing space). And even when a motherboard and it's peripherals all properly support addressing above 4Gb, it usually needs to be properly enabled in the bios (enabling the mapping of the peripherals above 4Gb during system POST). It seems like each bios maker calls this something different, assuming they even support it. So in some cases you might be able to get Vista (32bit or 64bit) to 'see' the full lower 4Gb of addressing space as being fully available to installed system ram (or at least remap much of what was occupying that hole before).
HOWEVER, there are also cases with consumer motherboards where the hardware and/or bios don't support this remapping and even Vista64 'sees' that area of memory being occupied, reporting less ram than is actually installed. In fact if remapping isn't supported, even if you have 8 or 16Gb of ram installed you might find that this hole is still 'stealing' some of your ram, keeping it unavailable to your OS & applications.
Now /PAE allows recent processors to expand the addressing space for physical memory from 32 bits to 36 bits through support in the host operating system for applications using AWE (Address Windowing Extensions). What this means is that if a machine has MORE than 4Gb of ram *and* a motherboard with the proper chipset support, you can enable this so that the system can address above the 4gb limit. The problem is that this is ony supported in full under Windows server OS's, in Xp32 sp2 and up it was partially enabled to allow NX bit application control (physical lock of memory space) and only partially functions in comparison to a windows Server OS.
Windows XP (32bit) originally supported full 4Gb so if you used /PAE with 4Gb of ram on a system with proper chipset and motherboard support, you would have access to the full 4Gb of ram. As more commodity motherboards added this feature, Microsoft noticed a new source of crashes and blue screens. These were traced to drivers failing to correctly handle 64-bit physical addresses and MS made the decision to improve system stability.
XP SP2 introduced a change such that only the bottom 32 bits of physical memory will ever be used (this is also affects 32-bit editions of Vista.) To FURTHER complicate things, most cpu's (since AMD's Atlhlon XP parts) support No Execute (NX-bit) which requires PAE to use it, so you might find that Xp Sp2 (& Sp3) show PAE as enabled due to using DEP/NX/XD (MS, AMD & Intel's terms) even though it still doesn't allow access to more than 4Gb of memory space.
references for these last 2 paragraphs:
The system memory that is reported in the System Information dialog box in Windows Vista is less than you expect if 4 GB of RAM is installed
Deploying Windows XP Service Pack 2 using Software Update Services
--------
So XITE-1/4LIVE, using /3GB was the right way to get Gigastudio to 'see' more than 2Gb of ram on Xp32, but I'm not sure Sp3 impacts this in any way. Sp3 does allow better utilization of modern cpu's and hardware, so there might be some interactions I'm not aware of.
Ultimately moving to a 64bit OS (on a motherboard where bios remapping functions) is the best way to maximize your available ram, both to apps & to the OS in general. Keep in mind that a 64bit OS only requires that 64bit drivers be used, 32 applications still function. Though I'm not sure how to enable the 'large address space' function to allow them to address more than 2Gb I suspect that if the app supports the flag the OS will enable support for the app by default.
Also, I definately prefer Xp64 from a performance standpoint on current hardware, but Xp64 is pretty much dead in the water at this point. Any 64bit drivers are going to be developed primarily for Vista64 from this point forward, and applications will tend to follow suit as well. So unless you're looking at a system usage of only a few months it's probably more worthwhile to just move to Vista64 at this point and make the necessary adjustments now. Assuming you need a 64bit OS that is, I find that I still spend about 60% of my time in Xp32 sp3, booting into Vista64 only for large graphics work and/or 3d projects where access to all 8Gb of my ram makes a big difference (reducing the amount of swapping to disk). Eventually I'll migrate fully over to Vista64 (and OSX) but I still have a midi interface and a few other peripherals that don't function properly there.
