The default processor limits of Windows NT 3.x are surprisingly difficult to establish. Quite possibly because although SMP was a big selling point of NT, in reality only a tiny fraction of PCs in the mid-1990s supported SMP, and of those, most only had two processors.
After some poking around, it appears that the default for NT Workstation is two CPUs of all NT 3.x releases (and NT 4 as well). A notable exception is the checked build which for whatever reason defaults to four CPUs.
For the (Advanced) Server version, the default is four CPUs; however, the server uses the same kernel/HAL and to get beyond the defaults, the registry must be modified. For the server versions, the modification happens during installation.
In Windows NT 3.1, if the standard Microsoft installer finds the ProductType being LanmanNT (i.e. it is Advanced Server rather than Workstation, whose ProductType is WinNt), it adds a DWORD key called HKLM\System\CurrentControlSet\Control\Session Manager\RegisteredProcessors and sets it to 4. This is plainly visible in a file called REGISTRY.INF.
Not too surprisingly, adding said registry key allows NT 3.1 Workstation to operate four processors:
The key can be simply added with REGEDT32.EXE from an Administrator account. There is no protection or other hassle.
The same key controls the number of processors on Windows NT 3.5 and 3.51. For all of these versions, the key can be simply added (with sufficient privileges) and NT will recognize more than the default number of processors, up to the number specified by RegisteredProcessors.
Note that the above discussion applies to vanilla NT builds from Microsoft (as found on MSDN CDs or generic OEM discs). OEMs who sold NT with SMP hardware often customized the defaults.
The architectural limit is 32 CPUs in NT 3.x and 4.x. The HAL and/or hardware may impose further limits. For example, standard MPS hardware (Pentium and P6 family processors) would be limited to fewer than 16 processors due to the use of 4-bit APIC IDs.
Interesting problems could potentially arise as systems with more than 4-8 CPUs were extremely rare and software was not usually tested on such machines. It also does not help that the NT 3.x MPS HALs do not idle CPUs at all, so any configured CPU will burn cycles even when it has nothing to do (especially aggravating in virtualized systems).
The processor licensing logic in NT 4 and later is much more complicated and will not be discussed here. For NT 4.0, Microsoft obviously put some effort in locking down the supported number of CPUs to some extent, presumably in order to prevent easy “license upgrades”. Several registry keys must match and if Windows gets sufficiently upset, it will bug check and not run at all.
The NT4 logic is not really that complicated, especially if you modify the CD. The leaked NT source actually contains the whole OAK with examples of such configurations. On a running system it’s a bit more painful, but the funny thing is learning how poorly MS obfuscated the value in the registry. I’ve gathered the values of SystemPrefix for several systems I’ve run and was surprised most of it are just random bits.
Yuhong Bao! Your ftpFu is good, but mine is better: Link does not work, but
lists: KRNL40I.EXE /32proc-fix Q140065 as…