cluberti

Make sure your taskbar is "unlocked" - the quick launch bar is probably set to take up the majority of the space on the taskbar somehow, and sliding the separator back to the left should fix it. Lock the taskbar when you're done so it doesn't happen again.

erpdude8, I hate to do this, but forum rule 1b expressly forbids redistributing any component of a vendor product (free or otherwise) unless you have express rights to do so. Unless Microsoft granted you the right to redist those .dll files, please remove the zip file and any links directly to it. Thanks. edit by tommyp - removed erpdude8's quotation. cluberti - you're right that you aren't supposed to redistribute things. That does not mean that you can quote erpdude's questionable post. Let's keep things clean.

I hate to do this, but forum rule 1b expressly forbids redistributing any component of a vendor product (free or otherwise) unless you have express rights to do so. Unless Microsoft granted you the right to redist that .dll, please remove the zip file and any links directly to it. Thanks.

There's an option in Group Policy to FORCE ENABLE CLASSIC START MENU, but it doesn't work at all, when ENABLED. That's because classic start menu does not exist in Win7, at all. You can't force it if it doesn't exist .

I will blame you though for violating rule #5 with your sig though . Please do clean it up.

Just do some research on Active Directory "Sites". It's quite simple, actually, once you know how that works.

Question - what OS level are you speaking of? Windows 2008 has Read-Only domain controllers for this scenario, but in 2003 if replication will be an issue (assuming slower or costly links) having a main domain (with a DC) at the main office and then child domains is somewhat preferable. You can have a single domain with multiple sites, but if the route links are expensive it does create some issues. If the links are relatively fast (256K or higher) and reliable, a single domain with multiple sites might make more sense.

I'd say integrating them into the image itself is easier than trying to use a path (and no, there's no variable for cdrom in the answer file). However, if you do have access to a network location, that would work as well. I know MDT allows creation of installers for Vista like this, and MDT 2010 is available as a beta on connect. I'd suggest checking it out, as it's the best way short of using SCCM to do Windows+drivers+apps in an automated lite-touch fashion.

Good point - modified, added Win7 x86 and Win7 x64 (for now, as editions are subject to change until RTM).

That's because win9x has a flat-memory model - meaning usermode code can mess with kernel-mode memory (and vice-versa), and there's zero protection. So, unlike an NT-based system, an application with no kernel-level code can crash/BSOD an entire Win9x box with just a simple pointer issue, for instance.That's the main reason Win9x goes down like a house of cards so often.

Consider WMI filtering of the policies (have a policy for both) and apply one or the other based on the OS.

You might be having a problem with the drive letter - assuming this is local, it may not be H: during this pass. It's the only obvious thing I can think of. If it's an actual network location, I'd suggest using the UNC path instead.

Vista was a big failure, but the fact is that the OS was not. It was perception that killed Vista - well, that and the fact that it really did have serious driver issues until SP1 (also not totally the fault of Microsoft - I'm looking at you specifically, nvidia). If Vista had RTM'ed at the SP1 codebase rather than RTM, things would've been different. Maybe not vastly so, but people wouldn't be comparing it (totally wrongly) to Windows ME.

If it's *specifically* 3.0, with latencies like that I'd suspect disabling the write cache will clear that up.

If you have an application that is hanging or crashing, or a system that is misbehaving due to hangs, high CPU, severe slowness, etc, you may be asked to create a memory dump - perhaps of the application that is believed to be having issues, or of the entire system if the computer is misbehaving (or of both an application and the whole system!). This post is meant as an instruction manual on how to gather data if you are going to post for help on resolving one of these types of problems. Here are instructions on how to create the appropriate dump if you are so asked: Memory dump of the entire system: 1. Create or set the following registry value by running regedit.exe: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Click Start, type sysdm.cpl (and press ENTER to launch), and then click the "Advanced tab. On the "Advanced" tab, click "Settings" under the "Performance" header. Click the "Advanced" tab, then click "Change" under "Virtual Memory". Click the top box, labeled "Automatically manage....", and click the "OK" button.(twice). 3. Also in the "System Properties" window on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value by running regedit.exe: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system is exhibiting the problem you were asked to dump the machine for, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp that can be analyzed. Memory dump from an application/process that is HANGING (not crashing): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is hanging) 4. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump from an application/process that is CRASHING (not hanging): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is crashing) 4. Once the application you have attached to in step 3 eventually crashes, the debugger will create a .dmp file (or files) of the process. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed.

If you have an application that is hanging or crashing, or a system that is misbehaving due to hangs, high CPU, severe slowness, etc, you may be asked to create a memory dump - perhaps of the application that is believed to be having issues, or of the entire system if the computer is misbehaving (or of both an application and the whole system!). This post is meant as an instruction manual on how to gather data if you are going to post for help on resolving one of these types of problems. The first thing to do, before doing ANYTHING else, is to download and install the "Debugging Tools for Windows" for your Windows platform: - x86 version. - x64 or Itanium (64bit) Once you've installed the tools, here are instructions on how to create the appropriate dump if you are so asked: Memory dump from an application/process that is HANGING (not crashing): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is hanging) 4. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump from an application/process that is CRASHING (not hanging): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is crashing) 4. Once the application you have attached to in step 3 eventually crashes, the debugger will create a .dmp file (or files) of the process. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump of the entire system: 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced tab. On the "Advanced" tab, click "Settings" under the "Performance" header. Click the "Advanced" tab, then click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB. 3. Also in the "System Properties" window on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system is exhibiting the problem you were asked to dump the machine for, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp that can be analyzed.

If you have an application that is hanging or crashing, or a system that is misbehaving due to hangs, high CPU, severe slowness, etc, you may be asked to create a memory dump - perhaps of the application that is believed to be having issues, or of the entire system if the computer is misbehaving (or of both an application and the whole system!). This post is meant as an instruction manual on how to gather data if you are going to post for help on resolving one of these types of problems. The first thing to do, before doing ANYTHING else, is to download and install the "Debugging Tools for Windows" for your Windows platform: - x86 version. - x64 or Itanium (64bit) Once you've installed the tools, here are instructions on how to create the appropriate dump if you are so asked: Memory dump from an application/process that is HANGING (not crashing): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is hanging) 4. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump from an application/process that is CRASHING (not hanging): 1. Create a directory called c:\adplus 2. Open a command prompt and change to the directory where you installed the debugging tools. By default, this is "C:\Program Files\Debugging Tools for Windows" 3. Type the following command in the command prompt: cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus (where "appname" is the .exe name of the application that is crashing) 4. Once the application you have attached to in step 3 eventually crashes, the debugger will create a .dmp file (or files) of the process. Once the debugger has finished (this can take some time), the command prompt window(s) will close, and you will have data in your C:\adplus folder that can be analyzed. Memory dump of the entire system: 1. Create or set the following registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters Value: CrashOnCtrlScroll Type: REG_DWORD Data: 1 2. Right-Click on the "My Computer" icon on the desktop and select "Properties", then click the "Advanced tab. On the "Advanced" tab, click "Settings" under the "Performance" header. Click the "Advanced" tab, then click "Change" under "Virtual Memory". Set the pagefile to be located on the partition where the OS is installed, and set it to be equal to Physical RAM + 50 MB. 3. Also in the "System Properties" window on the "Advanced" tab, click the "Settings" buttun under the "Startup and Recovery" header. Make sure "Complete Memory Dump" is selected (see 3a if this is not in the list). You can change the location of the memory dump file to a different local partition if you do not have enough room on the partition where the OS is installed. 3a. If the "Complete Memory Dump" option in step 3 is not available, you will need to manually set this registry value: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 4. You will need to reboot for these changes to take effect. 5. The next time that the system is exhibiting the problem you were asked to dump the machine for, hold down the RIGHT CTRL key and press the SCROLL LOCK key twice to cause the machine to bugcheck and create a memory dump. After the box comes back up, you'll find the resulting memory dump file in %systemroot%\memory.dmp that can be analyzed.

This is a good post for a sticky, so I'm going to re-use this thread for educational use and strip out the name of the person asking the question:First, we'll discuss the 4GB RAM limit on x86 systems. The 4GB limit is hardware-based (well, almost - I'll explain the workaround later that allows up to 128GB) - the x86 architecture can really only address memory addresses at 2^32, or 4,294,967,296 (4,294,967,296/1024x1024=4096, or 4GB) at any one time. So, no executable code can be at any address higher than the 4GB "window" that the x86 CPU can see. However, there were 2 workarounds that Intel put in place awhile ago to try and extend the life of the 32bit platform until it could get it's 64bit Itanium platform mainstream, and these were PAE and PSE (read here for more on why Microsoft chose to implement PAE rather than PSE). The specific workaround used in Windows is called Physical Address Extension (PAE), which was added by Intel in the Intel Pentium Pro and Pentium II lines of CPUs (and continued subsequently to this day) to allow data (and data ONLY) to be mapped into RAM above the 4GB memory address range - however, there is a set of limitations on this. The first limitation is that this window to the RAM above 4GB *must* be mapped into a contiguous memory address range in the application's original 2GB (or 3GB, with /3GB) process space, because again the x86 architecture can only address memory up to the 4GB range (so mapping it into this window allows it to be addressed, with the application handling the management overhead). That brings us to the second limitation, specifically that this window must be managed entirely by the app, as I mentioned previously - there is no using the OS's memory manager, as the memory manager does not know how to handle memory above the 4GB boundary in a process' space, thus placing an overhead on the app. The last limitation is that the memory window *must* not contain executable code (again, the CPU's eip register doesn't understand addresses above 0xFFFFFFFF, the address limit of the x86 architecture). PAE is technically a hack, and if you want your applications to *really* use memory above 4GB, you will want to use a CPU architecture that supports it (Intel's Itanium ia64 or the AMD/Intel x86-64, or x64). Note that there are ways to get a 32bit system to use and run applications above the normal 4GB boundary, as Windows Server editions can do this natively when /PAE is enabled. Microsoft has limited this (artificially) on client systems, however, due to potential for client-side driver incompatibility, as well as the fact that x86-based servers with more than 4GB of RAM have been fairly common for awhile, whereas 4GB client systems were fairly rare and probably not as well tested with all of the possible myriad of drivers that can be found on a client system. Addressing that much memory can also increase the size of the PFN entries, doubles the size of each PTE, and otherwise starts to constrain the kernel's normal 2GB of VA. For example, an x86 Windows system with 16GB of RAM is already using ~112MB of VA just for PFN entries, and you take the available PTEs available to the system and reduce them by approximately 7x. While I don't agree (at all) with doing this as it violates the EULA and license you have to run a Windows client OS, as well as cripples the OS kernel in many ways, Geoff Chappell has an article about how the 4GB restriction on client OSes can be bypassed here. If you want to use more than 4GB of RAM with an actual legally licensed copy of Windows client, however, you need an x64 license. The section portion of this sticky is the problem people see when they boot up an x86 system with 4GB of RAM, but Windows only reports the available RAM as somewhere between 3GB and 4GB. Rather than be lengthy about it and rehash old threads, I'll simply point to them to explain why this happens: 1. Start here, here, and here for a technical overview of how this can happen, and 2. Read this, this, this, and this to see real-life examples of this happening, and what can (and cannot) be done to resolve it. Now it's been stickied, so if you ask these types of questions going forward, you will simply be pointed to the contents of this thread. These are not necessarily Windows problems, these designs and limitations are an outcome of the design and architectural limitations of the 32bit architecture - especially the second issue, where the BIOS reserves memory for hot-add/hot-swap memory, PCI-X/PCI-E buses, and (if it applies) your 256MB or 512MB video card reserve memory resources for their usage, causing the discrepancy in reporting of installed memory vs *available* memory to the OS. Last updated 2 August 2010

This is a good post for a sticky, so I'm going to re-use this thread for educational use and strip out the name of the person asking the question:First, we'll discuss the 4GB RAM limit on x86 systems. The 4GB limit is hardware-based (well, almost - I'll explain the workaround later that allows up to 128GB) - the x86 architecture can really only address memory addresses at 2^32, or 4,294,967,296 (4,294,967,296/1024x1024=4096, or 4GB) at any one time. So, no executable code can be at any address higher than the 4GB "window" that the x86 CPU can see. However, there were 2 workarounds that Intel put in place awhile ago to try and extend the life of the 32bit platform until it could get it's 64bit Itanium platform mainstream, and these were PAE and PSE (read here for more on why Microsoft chose to implement PAE rather than PSE). The specific workaround used in Windows is called Physical Address Extension (PAE), which was added by Intel in the Intel Pentium Pro and Pentium II lines of CPUs (and continued subsequently to this day) to allow data (and data ONLY) to be mapped into RAM above the 4GB memory address range - however, there is a set of limitations on this. The first limitation is that this window to the RAM above 4GB *must* be mapped into a contiguous memory address range in the application's original 2GB (or 3GB, with /3GB) process space, because again the x86 architecture can only address memory up to the 4GB range (so mapping it into this window allows it to be addressed, with the application handling the management overhead). That brings us to the second limitation, specifically that this window must be managed entirely by the app, as I mentioned previously - there is no using the OS's memory manager, as the memory manager does not know how to handle memory above the 4GB boundary in a process' space, thus placing an overhead on the app. The last limitation is that the memory window *must* not contain executable code (again, the CPU's eip register doesn't understand addresses above 0xFFFFFFFF, the address limit of the x86 architecture). PAE is technically a hack, and if you want your applications to *really* use memory above 4GB, you will want to use a CPU architecture that supports it (Intel's Itanium ia64 or the AMD/Intel x86-64, or x64). Note that there are ways to get a 32bit system to use and run applications above the normal 4GB boundary, as Windows Server editions can do this natively when /PAE is enabled. Microsoft has limited this (artificially) on client systems, however, due to potential for client-side driver incompatibility, as well as the fact that x86-based servers with more than 4GB of RAM have been fairly common for awhile, whereas 4GB client systems were fairly rare and probably not as well tested with all of the possible myriad of drivers that can be found on a client system. Addressing that much memory can also increase the size of the PFN entries, doubles the size of each PTE, and otherwise starts to constrain the kernel's normal 2GB of VA. For example, an x86 Windows system with 16GB of RAM is already using ~112MB of VA just for PFN entries, and you take the available PTEs available to the system and reduce them by approximately 7x. While I don't agree (at all) with doing this as it violates the EULA and license you have to run a Windows client OS, as well as cripples the OS kernel in many ways, Geoff Chappell has an article about how the 4GB restriction on client OSes can be bypassed here. If you want to use more than 4GB of RAM with an actual legally licensed copy of Windows client, however, you need an x64 license. The section portion of this sticky is the problem people see when they boot up an x86 system with 4GB of RAM, but Windows only reports the available RAM as somewhere between 3GB and 4GB. Rather than be lengthy about it and rehash old threads, I'll simply point to them to explain why this happens: 1. Start here, here, and here for a technical overview of how this can happen, and 2. Read this, this, this, and this to see real-life examples of this happening, and what can (and cannot) be done to resolve it. Now it's been stickied, so if you ask these types of questions going forward, you will simply be pointed to the contents of this thread. These are not necessarily Windows problems, these designs and limitations are an outcome of the design and architectural limitations of the 32bit architecture - especially the second issue, where the BIOS reserves memory for hot-add/hot-swap memory, PCI-X/PCI-E buses, and (if it applies) your 256MB or 512MB video card reserve memory resources for their usage, causing the discrepancy in reporting of installed memory vs *available* memory to the OS. Last updated 2 August 2010

This is a good post for a sticky, so I'm going to re-use this thread for educational use and strip out the name of the person asking the question:First, we'll discuss the 4GB RAM limit on x86 systems. The 4GB limit is hardware-based (well, almost - I'll explain the workaround later that allows up to 128GB) - the x86 architecture can really only address memory addresses at 2^32, or 4,294,967,296 (4,294,967,296/1024x1024=4096, or 4GB) at any one time. So, no executable code can be at any address higher than the 4GB "window" that the x86 CPU can see. However, there were 2 workarounds that Intel put in place awhile ago to try and extend the life of the 32bit platform until it could get it's 64bit Itanium platform mainstream, and these were PAE and PSE (read here for more on why Microsoft chose to implement PAE rather than PSE). The specific workaround used in Windows is called Physical Address Extension (PAE), which was added by Intel in the Intel Pentium Pro and Pentium II lines of CPUs (and continued subsequently to this day) to allow data (and data ONLY) to be mapped into RAM above the 4GB memory address range - however, there is a set of limitations on this. The first limitation is that this window to the RAM above 4GB *must* be mapped into a contiguous memory address range in the application's original 2GB (or 3GB, with /3GB) process space, because again the x86 architecture can only address memory up to the 4GB range (so mapping it into this window allows it to be addressed, with the application handling the management overhead). That brings us to the second limitation, specifically that this window must be managed entirely by the app, as I mentioned previously - there is no using the OS's memory manager, as the memory manager does not know how to handle memory above the 4GB boundary in a process' space, thus placing an overhead on the app. The last limitation is that the memory window *must* not contain executable code (again, the CPU's eip register doesn't understand addresses above 0xFFFFFFFF, the address limit of the x86 architecture). PAE is technically a hack, and if you want your applications to *really* use memory above 4GB, you will want to use a CPU architecture that supports it (Intel's Itanium ia64 or the AMD/Intel x86-64, or x64). Note that there are ways to get a 32bit system to use and run applications above the normal 4GB boundary, as Windows Server editions can do this natively when /PAE is enabled. Microsoft has limited this (artificially) on client systems, however, due to potential for client-side driver incompatibility, as well as the fact that x86-based servers with more than 4GB of RAM have been fairly common for awhile, whereas 4GB client systems were fairly rare and probably not as well tested with all of the possible myriad of drivers that can be found on a client system. Addressing that much memory can also increase the size of the PFN entries, doubles the size of each PTE, and otherwise starts to constrain the kernel's normal 2GB of VA. For example, an x86 Windows system with 16GB of RAM is already using ~112MB of VA just for PFN entries, and you take the available PTEs available to the system and reduce them by approximately 7x. While I don't agree (at all) with doing this as it violates the EULA and license you have to run a Windows client OS, as well as cripples the OS kernel in many ways, Geoff Chappell has an article about how the 4GB restriction on client OSes can be bypassed here. If you want to use more than 4GB of RAM with an actual legally licensed copy of Windows client, however, you need an x64 license. The section portion of this sticky is the problem people see when they boot up an x86 system with 4GB of RAM, but Windows only reports the available RAM as somewhere between 3GB and 4GB. Rather than be lengthy about it and rehash old threads, I'll simply point to them to explain why this happens: 1. Start here, here, and here for a technical overview of how this can happen, and 2. Read this, this, this, and this to see real-life examples of this happening, and what can (and cannot) be done to resolve it. Now it's been stickied, so if you ask these types of questions going forward, you will simply be pointed to the contents of this thread. These are not necessarily Windows problems, these designs and limitations are an outcome of the design and architectural limitations of the 32bit architecture - especially the second issue, where the BIOS reserves memory for hot-add/hot-swap memory, PCI-X/PCI-E buses, and (if it applies) your 256MB or 512MB video card reserve memory resources for their usage, causing the discrepancy in reporting of installed memory vs *available* memory to the OS. Last updated 2 August 2010

This is a good post for a sticky, so I'm going to re-use this thread for educational use and strip out the name of the person asking the question:First, we'll discuss the 4GB RAM limit on x86 systems. The 4GB limit is hardware-based (well, almost - I'll explain the workaround later that allows up to 128GB) - the x86 architecture can really only address memory addresses at 2^32, or 4,294,967,296 (4,294,967,296/1024x1024=4096, or 4GB) at any one time. So, no executable code can be at any address higher than the 4GB "window" that the x86 CPU can see. However, there were 2 workarounds that Intel put in place awhile ago to try and extend the life of the 32bit platform until it could get it's 64bit Itanium platform mainstream, and these were PAE and PSE (read here for more on why Microsoft chose to implement PAE rather than PSE). The specific workaround used in Windows is called Physical Address Extension (PAE), which was added by Intel in the Intel Pentium Pro and Pentium II lines of CPUs (and continued subsequently to this day) to allow data (and data ONLY) to be mapped into RAM above the 4GB memory address range - however, there is a set of limitations on this. The first limitation is that this window to the RAM above 4GB *must* be mapped into a contiguous memory address range in the application's original 2GB (or 3GB, with /3GB) process space, because again the x86 architecture can only address memory up to the 4GB range (so mapping it into this window allows it to be addressed, with the application handling the management overhead). That brings us to the second limitation, specifically that this window must be managed entirely by the app, as I mentioned previously - there is no using the OS's memory manager, as the memory manager does not know how to handle memory above the 4GB boundary in a process' space, thus placing an overhead on the app. The last limitation is that the memory window *must* not contain executable code (again, the CPU's eip register doesn't understand addresses above 0xFFFFFFFF, the address limit of the x86 architecture). PAE is technically a hack, and if you want your applications to *really* use memory above 4GB, you will want to use a CPU architecture that supports it (Intel's Itanium ia64 or the AMD/Intel x86-64, or x64). Note that there are ways to get a 32bit system to use and run applications above the normal 4GB boundary, as Windows Server editions can do this natively when /PAE is enabled. Microsoft has limited this (artificially) on client systems, however, due to potential for client-side driver incompatibility, as well as the fact that x86-based servers with more than 4GB of RAM have been fairly common for awhile, whereas 4GB client systems were fairly rare and probably not as well tested with all of the possible myriad of drivers that can be found on a client system. Addressing that much memory can also increase the size of the PFN entries, doubles the size of each PTE, and otherwise starts to constrain the kernel's normal 2GB of VA. For example, an x86 Windows system with 16GB of RAM is already using ~112MB of VA just for PFN entries, and you take the available PTEs available to the system and reduce them by approximately 7x. While I don't agree (at all) with doing this as it violates the EULA and license you have to run a Windows client OS, as well as cripples the OS kernel in many ways, Geoff Chappell has an article about how the 4GB restriction on client OSes can be bypassed here. If you want to use more than 4GB of RAM with an actual legally licensed copy of Windows client, however, you need an x64 license. The section portion of this sticky is the problem people see when they boot up an x86 system with 4GB of RAM, but Windows only reports the available RAM as somewhere between 3GB and 4GB. Rather than be lengthy about it and rehash old threads, I'll simply point to them to explain why this happens: 1. Start here, here, and here for a technical overview of how this can happen, and 2. Read this, this, this, and this to see real-life examples of this happening, and what can (and cannot) be done to resolve it. Now it's been stickied, so if you ask these types of questions going forward, you will simply be pointed to the contents of this thread. These are not necessarily Windows problems, these designs and limitations are an outcome of the design and architectural limitations of the 32bit architecture - especially the second issue, where the BIOS reserves memory for hot-add/hot-swap memory, PCI-X/PCI-E buses, and (if it applies) your 256MB or 512MB video card reserve memory resources for their usage, causing the discrepancy in reporting of installed memory vs *available* memory to the OS. Last updated 2 August 2010

This is actually good to sticky, because it's only currently in the NT/2K/2K3 forum as a sticky, where people might not see it.

Why do you think they're so hard-up to get their browser included in Windows? It's obvious when you see it in black and white - they care less about Microsoft's practices than they do about trying to get their product out to the masses. If people won't choose it, they'll lean on the EU to try and get Microsoft to force it on them. Sounds surprisingly like the behavior of the company they accuse of doing the same 15 years ago, no???

The 4GB limit is hardware based (well, almost - I'll explain the workaround later that allows up to 128GB) - the x86 architecture can really only address memory addresses at 2^32, or 4,294,967,296 (4,294,967,296/1024x1024=4096, or 4GB). So, no executable code can be at any address higher than the 4GB "boundary". However, there were 2 workarounds (hacks) that Intel put in place awhile ago to try and extend the life of the 32bit platform until it could get it's 64bit Itanium platform mainstream, and these were PAE and PSE (read here for more on why Microsoft chose to implement PAE rather than PSE). The hack you speak of, used in Windows, is called Physical Address Extension (PAE), which was added by Intel in the Intel Pentium Pro and Pentium II lines of CPUs (and continued subsequently to this day) to allow data (and data ONLY) to be mapped into RAM above the 4GB boundary - however, there is a set of limitations on this window. The first limitation is that this window to the RAM above 4GB *must* be mapped into a contiguous memory address range in the application's original 2GB (or 3GB, with /3GB) process space, because again the x86 architecture can only address memory up to the 4GB range (so mapping it into this window allows it to be addressed, with the application handling the management overhead). That brings us to the second limitation, specifically that this window must be managed entirely by the app, as I mentioned previously - there is no using the OS's memory manager, as the OS does not know how to handle memory above the 4GB boundary, thus placing an overhead on the app. The last limitation is that the memory window *must* not contain executable code (again, the CPU's eip register doesn't understand addresses above 0xFFFFFFFF, the address limit of the x86 architecture). It's a hack, and if you want to actually *really* use memory above 4GB, you *must* use a CPU architecture that supports it (Intel's Itanium ia64 or the AMD/Intel x86-64, or x64). Consider reading: http://blogs.technet.com/markrussinovich/a...21/3092070.aspx http://blogs.technet.com/askperf/archive/2...e-s-my-ram.aspx http://www.brianmadden.com/blogs/brianmadd...eally-mean.aspx

2.0 will run Aero glass, but that's video score. As far as low-end system, they're basically talking about any system that either meets or falls below the *recommended* specifications. These systems will have a difficult time running Windows Vista with all features enabled - it'll work, but it won't work well. Doubling the recommended requirements (as was the case with every version of Windows prior) will give you much better experience with the product than would simply meeting the minimum recommended requirements.