The Norton Removal Tool uninstalls all Norton 2007/2006/2005/2004/2003 products from your computer
http://www.majorgeeks.com/download4749.html
In my eyes the best Symantec product ever
4GB RAM, Win XP
Thanks Gary for the confirmationgaryb wrote: the /3gb switch works on all xp sp2 versions. regardless if you use it or not, 4gb is the maximum xp can use, but the switch allows the memory to be used more efficiently. without the switch, xp uses 2gb for the system, which is a complete waste. xp won't report more than 3gb correctly, but afaik, it WILL use all 4gb, assuming the applications are capable of using large amounts of memory...
I have used the 3GB PAE Switch for months now, and even apps that don't support it seem to take advantage of it.
I decided to try this on a new hardware upgrade that would prepare me for 64bit OS's if I decided to make that move. A simple addition of 2 extra 2 GB sticks in the spare 2 x DIMM's seemed like a reasonable upgrade.
Turns out that GaryB's advice was incredibly accurate.
Gigastudio 4 using XP Home takes advantage of the 3GB Switch, but GS4 will use all 8GB's of RAM under XP64 or Vista.
Soniccore's new hardware will replace the old cards and the old OS.
It was the best upgrade I ever had done for me.
I am prepared to go different directions, but of course have chosen the long haul w/ GS4 and XITE-1.
A simple addition of 4 GB's more of DDRII 800, and an E8500 is all I need to do.
I know of no other DAW builder who can offer better advice than our very own GaryB. Several times I have dreams of all of new hardware available, water-cooling, and other useless high tech hype, and at the end of the day, GaryB's designs and hands on experience building w/ Scope DSP cards is always the best solution.
BTW, my next door neighbor just had a Dell w/ the E8500 and a super dooper SLI video combo delivered and he hasn't slept a wink !
I have no idea what he is bragging about w/ the FPS he is getting in certain games, but watching the benchmarks of quads versus fast dual cores, it seems that the expensive Q9750 has no edge on the new Wolfdale E8500 and twice the heat.
Just another example of GaryB's accurate insights on a CPU that has just been released.
BTW, the 8500's are a perfect match for the P35 chipset and DDRII. If the need arises, the BIOS can alter the SPD on the RAM for a free OC of the memory subsystem, and CL3 / CL4 speeds w/ the P35 appear to be a reality after months of geeks @ xtremesystems.org have proven.
I imagine his XITE-1 install for me up in Tahoe will be the talk of the town this summer. ( hopefully by the 4th of July )
I decided to try this on a new hardware upgrade that would prepare me for 64bit OS's if I decided to make that move. A simple addition of 2 extra 2 GB sticks in the spare 2 x DIMM's seemed like a reasonable upgrade.
Turns out that GaryB's advice was incredibly accurate.
Gigastudio 4 using XP Home takes advantage of the 3GB Switch, but GS4 will use all 8GB's of RAM under XP64 or Vista.
Soniccore's new hardware will replace the old cards and the old OS.
It was the best upgrade I ever had done for me.
I am prepared to go different directions, but of course have chosen the long haul w/ GS4 and XITE-1.
A simple addition of 4 GB's more of DDRII 800, and an E8500 is all I need to do.
I know of no other DAW builder who can offer better advice than our very own GaryB. Several times I have dreams of all of new hardware available, water-cooling, and other useless high tech hype, and at the end of the day, GaryB's designs and hands on experience building w/ Scope DSP cards is always the best solution.
BTW, my next door neighbor just had a Dell w/ the E8500 and a super dooper SLI video combo delivered and he hasn't slept a wink !
I have no idea what he is bragging about w/ the FPS he is getting in certain games, but watching the benchmarks of quads versus fast dual cores, it seems that the expensive Q9750 has no edge on the new Wolfdale E8500 and twice the heat.
Just another example of GaryB's accurate insights on a CPU that has just been released.
BTW, the 8500's are a perfect match for the P35 chipset and DDRII. If the need arises, the BIOS can alter the SPD on the RAM for a free OC of the memory subsystem, and CL3 / CL4 speeds w/ the P35 appear to be a reality after months of geeks @ xtremesystems.org have proven.
I imagine his XITE-1 install for me up in Tahoe will be the talk of the town this summer. ( hopefully by the 4th of July )
I cannot use the 3GB PAE anymore due to it;s incompatability w/ Gigastudio 4.
No biggie I thought.
But I have many delays in projects and now that I boot to XP w/o the PAE switch I am experiencing crashes from the excessive time based effects that worked flawlessley until recently.
It's no biggie, they are an added luxury that I can do without.
But obviously the 3GB PAE Switch seemed to help out in having multitudes of time based effects.
It might be of use to guys with cards that use the A100/P100 DSP verbs from warp69, and the various other time based DSP effects.
That Is My Take on the 3GB switch.
No biggie I thought.
But I have many delays in projects and now that I boot to XP w/o the PAE switch I am experiencing crashes from the excessive time based effects that worked flawlessley until recently.
It's no biggie, they are an added luxury that I can do without.
But obviously the 3GB PAE Switch seemed to help out in having multitudes of time based effects.
It might be of use to guys with cards that use the A100/P100 DSP verbs from warp69, and the various other time based DSP effects.
That Is My Take on the 3GB switch.
I have only read this from other Giga users, but SP3 seems to have no need for the switch at all when using the older GS3.
I will be experimenting w/ a new O.S. very soon, and hope I can follow GaryB's instructions properly.
So far the O.S. that seems to work the best for GS4 is XP32 / 64. It seems likely that Vista will be able to use more cores more efficiently, but those results come from the refinements of the new cache designs on the Nehalem CPU's. Other quads have shown higher plug in counts for certain apps, and from what I have read, Sonar seems to have a jump on the rest.
But I have seen enough extra polyphony and load amounts from extra RAM, and mature Core Duo's that when I go 64bit w/ 8GB's of DDR2, I doubt I will see more than a 20% boost in performance.
Hopefully that will suffice.
The 3GB switch was sweet w/ Bidule & GVI. It held me over for a while, and showed me that all of this 64bit stuff should have, and could have been avoided.
I will be experimenting w/ a new O.S. very soon, and hope I can follow GaryB's instructions properly.
So far the O.S. that seems to work the best for GS4 is XP32 / 64. It seems likely that Vista will be able to use more cores more efficiently, but those results come from the refinements of the new cache designs on the Nehalem CPU's. Other quads have shown higher plug in counts for certain apps, and from what I have read, Sonar seems to have a jump on the rest.
But I have seen enough extra polyphony and load amounts from extra RAM, and mature Core Duo's that when I go 64bit w/ 8GB's of DDR2, I doubt I will see more than a 20% boost in performance.
Hopefully that will suffice.
The 3GB switch was sweet w/ Bidule & GVI. It held me over for a while, and showed me that all of this 64bit stuff should have, and could have been avoided.
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.
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.
GREAT post valis. Thanks for taking the time.
As a software developer, I regularly test under XP32, XP64, Vista32 and Vista64. I agree that XP64 is the best of the bunch, but only if you have drivers for it already; don't expect new ones to come out. Scope 4.5 and below does not work with XP64, and I doubt the new Scope 5.0 will. I'm just hoping Scope 5 will work with Vista64.
FWIW, the Edirol UM-3EX is a good USB 3-Port MIDI interface, not too expensive, that that works well under all four Windows OSs:
http://www.sweetwater.com/store/detail/UM3EX/
As a software developer, I regularly test under XP32, XP64, Vista32 and Vista64. I agree that XP64 is the best of the bunch, but only if you have drivers for it already; don't expect new ones to come out. Scope 4.5 and below does not work with XP64, and I doubt the new Scope 5.0 will. I'm just hoping Scope 5 will work with Vista64.
FWIW, the Edirol UM-3EX is a good USB 3-Port MIDI interface, not too expensive, that that works well under all four Windows OSs:
http://www.sweetwater.com/store/detail/UM3EX/
Excellent response as usual from Brotha' Man Valis.
XP64 if we are lucky might be upgraded at a later date in the same wat that XP got a couple of boosts, but I believe that you are correct on Vista and developers moving forward.
My rep is in town from Tascam this weekend and I am sure we will be discussing developmental trends and how his recent experiences w/ Visat were.
He claims it is a wise choice for the long haul, especially where mutiple cores are concerned, and said that is was a pain in the ass but had removed many useless features. However on the same note XP64 bit was smooth, and very easy to use.
My only problem is that I will have to buy XP64, and Vista, just to see which one works best for my immediate use. XITE-1 running alongside of Gigastudio 4 will be a dream, just as Gigasampler / Gigastudio 2.54 & GS3 were with the Scope Type II Pro cards.
I wonder if we will seea PAE Switch in the future to use w. a 64bit app?
I still hate the idea of M$ controlling all of our purchases with their one way choice of Operating Systems.
XP64 if we are lucky might be upgraded at a later date in the same wat that XP got a couple of boosts, but I believe that you are correct on Vista and developers moving forward.
My rep is in town from Tascam this weekend and I am sure we will be discussing developmental trends and how his recent experiences w/ Visat were.
He claims it is a wise choice for the long haul, especially where mutiple cores are concerned, and said that is was a pain in the ass but had removed many useless features. However on the same note XP64 bit was smooth, and very easy to use.
My only problem is that I will have to buy XP64, and Vista, just to see which one works best for my immediate use. XITE-1 running alongside of Gigastudio 4 will be a dream, just as Gigasampler / Gigastudio 2.54 & GS3 were with the Scope Type II Pro cards.
I wonder if we will seea PAE Switch in the future to use w. a 64bit app?
I still hate the idea of M$ controlling all of our purchases with their one way choice of Operating Systems.