What does the word "supported" mean?

It depends on what you mean by "supported". Unfortunately, the word has multiple meanings, and the intended meaning is not always obvious from context.

One definition of "supported" is "The software makes a good-faith attempt to implement the functionality." For the purpose of this discussion, I will use the word "implemented" to describe this sense of the word "supported".

Another definition of "supported" is "The functionality has been tested to a high enough degree of confidence that the product support team will help you if you have problems with it." I don't have a good word for this concept; I will use the word "blessed" for lack of a better term.

In the vast majority of cases, the product teams keep the two concepts in sync. If the test team won't bless a feature, its implementation will be pulled from the product. The /3GB switch is one of those odd cases where implementation does not match blessing.

Windows Server 2003 Standard Edition does implement the /3GB switch, but its use is not blessed. (It is blessed for Enterprise Edition and Datacenter Edition, however. See the linked article for more details.)

According to the /3GB documentation you are pointing to, this feature was added to Windows (at some risk to its stability) to support the needs of one particular software product. [Although it’s quite possible that this KB article rewrites history].

You will assure us, won’t you, that Microsoft would have made such a modification to Windows irrespective of who the developer of that software product was?

Over ten years ago I was working on a Mac groupware product when Apple announced AOCE/Powertalk, which we perceived as a direct competitor. Because it was from Apple, our customers were concerned. In fact some wanted us to support AOCE. We happened to have a meeting with Jean Louis Gassee, former CEO of Apple and we mentioned this conflict. The conversation went something like this:

JLG: "Tell them that you support AOCE"

US:"But we don’t. The APIs are horrible and it would take us years to make our software compatible"

"Caution Microsoft supports using the /3GB switch in Windows Server 2003, Standard Edition in a production environment for use by Active Directory. For other applications, Microsoft supports using the /3GB switch in Windows Server 2003, Standard Edition only in a production environment if the application vendor has tested in this environment and if the vendor is willing to support the customer who is using this functionality. Microsoft Exchange Server 2003 and Microsoft SQL Server 2000 are supported in production using this functionality. Contact your application vendor regarding their application. The /3GB switch can cause some applications to have problems that are related to address dependencies or to a reduction in kernel space. Except in the cases described here, the /3GB switch in Windows Server 2003, Standard Edition is only for development and testing purposes."

Further it is my understanding, at least for the DCs, that full support extends all the way into the product teams so would be considered "blessed". I can’t speak to Exchange and SQL but I would expect it is for those products as well. The benefit for the DCs is to increase the LSASS cache to cache the DIT.

<blockquote>According to the /3GB documentation you are pointing to, this feature was added to Windows (at some risk to its stability) to support the needs of one particular software product. [Although it’s quite possible that this KB article rewrites history].

You will assure us, won’t you, that Microsoft would have made such a modification to Windows irrespective of who the developer of that software product was?</blockquote>

I’m not a big fan of some of Microsoft’s business practices, but the article does not even say that Exchange is the reason for the 3/1 split option. As far as I can tell "This additional virtual address space helps reduce the amount of memory fragmentation in the virtual address space of the Exchange information store process." is a statement of effect not cause.

Changing the VM split is a common enough idea (For example various Linux kernels have the option to to 1/3, 2/2, 3/1, or other random userspace/kernelspace splits). I’d almost be surprised if Exchange was the reason for making the split configurable. I’d bet that as soon as >2GB systems became remotely common, they added this option, just to increase speed of any large-memory application and avoid the ugliness of PAE.

"The /PAE switch lets developers perform similar testing of device drivers by forwarding 64-bit addresses to kernel-mode components. This feature is known as Physical Address Extension (PAE), and it may not work on all chip sets. Any addresses that are over 32 bits are guaranteed to work by using the /nolowmem switch from the Boot.ini file that discards the lower 4 GB of memory."

There’s nothing particularly ugly about /PAE, it’s just another way to organize page tables on x86. /nolowmem is a test switch that you can use to detect drivers that can’t handle physical addresses above 4 GB.

/PAE is also necessary to enable some useful features on x86, such as NX and NUMA.

PJ: The rest of the world does very much make a distinction. Go and have a look at "supported" platforms for software out there. For example you may see software that runs on Linux claim to only support one or two distros (eg Redhat) when in fact they run fine on many others. Similarly Windows programs may claim to only support XP when in fact they run on other versions just fine.

Generally the "implemented" list is far larger than the "blessed" list.

"Changing the VM split is a common enough idea (For example various Linux kernels have the option to to 1/3, 2/2, 3/1, or other random userspace/kernelspace splits)."

It’s true that like Microsoft, Linus originally blessed a variable split. The split exists (at least last time I looked) in current versions, but it’s deprecated in favour of a memory model with 4GB of userspace. Most vendors use PAE and 4GB userspace by default in their current 32-bit legacy offering.

Unlike Microsoft though, the Linux kernel team deliberately didn’t try to add a "large memory" API which would quickly turn into an albatross. Why did Windows need that API when Linux didn’t? There are really two reasons, one more compelling than the other, see if you can figure out which is which…

1. Anybody who said "I want to use 6GB of RAM" in Linux was pointed to the heap of 64-bit CPU architectures running Linux. On such systems /every/ program could take advantage of 6GB of RAM, not just those which were painstakingly re-written.

2. Those who just wanted to squeeze a bit more out of x86 with custom software were able to abuse the shared memory APIs. You could write a piece of clumsy software that used abstract handles to swap 128MB chunks of RAM in and out of its address space, and it would run fine on any system, with our without PAE, 32-bit or 64-bit, and with no pretense that this was making the software better, it was an obvious kludge.

"Supported" can be a confusing word. Recently I had a heated debate on a discussion forum. It seems that nVidia’s more recent drivers (version 8x.xx, including 81.94) simply do not work well when I enable all my memory with 32-bit Windows 2003. One user argued that this was a "server OS", hence it was only to be expected that games didn’t work. (not only doesn’t games work, but it is almost impossible to log on! The old driver works 100% though)

And indeed, nVidia’s site do not list 2003 Server as a supported OS. Unless we’re speaking of the 64-bit version, but at that point I get BSODs and games that refuse to launch, unless I revert back to version 79.11 (or older)…

Which is all academical of course, because there’s no support in any case. If I tell my video card OEM, they simply state that the newer nVidia drivers are for a specific game, so I shouldn’t be using them at all… (never mind that the older drivers are hard to find on nVidia’s site) And if I try nVidia’s website, all I find is a note that tells me to contact my video card OEM.

So, if I understand this correctly, I have one instance where I’m using a "non-blessed" and unsupported configuration (32-bit Win2003 and nVidia based video card), and another instance where I’m using a "blessed", yet still unsupported configuration (64-bit Win2003 and nVidia based video card).

Actually the linked article looks like this is another of those ternary Booleans.

* Important

* The /3GB switch should not be used on

* Windows 2000 Server because it is

* unsupported and can cause application or

* operating system crashes.

Now _that_ is not blessed. Windows 2003 Standard isn’t mentioned. Windows 2003 has Schroedinger’s blessing, which requires subjecting a live cat to the possibility of an ugly death in order to find out if the blessing exists or not.

I wonder if those articles are intended to have an implicit "x86" (or "32-bit") adjective on their mentions of OS versions.

Sorry for the tangent but this is the first piece of useful information I’ve seen on this:

Monday, November 21, 2005 4:19 AM by Rune

> It seems that nVidia’s more recent drivers

> (version 8x.xx, including 81.94) simply do

> not work well when I enable all my memory

> with 32-bit Windows 2003.

Oh, thank you thank you thank you. Do you know if the same problem exists under 32-bit XP and 64-bit XP? Actually 32-bit XP and 64-bit XP are already failing to use all of my memory on my newest machine, by different amounts, but nonetheless nVidia’s drivers are refusing to start. How much do you have to restrict the memory usage? Or…

> unless I revert back to version 79.11 (or

> older)…

Do you know if those work with GeForce 6100? And could you give a URL for that version? (Yeah I didn’t buy a motherboard with on-board 6100 for gaming or anything like that, but still the VGA Save driver isn’t a fun environment.)

"The benefit for the DCs is to increase the LSASS cache to cache the DIT."

I was dunned for saying this as it is actually the ESE Buffer Manager that gets the big bang for the buck. I started to mention ESE before but figured most folks reading these comments A. Wouldn’t know about ESE B. Wouldn’t care. Saying that it was the DIT caching by the LSASS process which manages AD I figured would be close enough. My inbox tells me a different story now. I apologize profusely to the individual(s) I made *sigh*. I didn’t intend to perpetuate the myth that "the process is the database".