Reliably finding general CPU architecture on Windows XP and newer?

[unknown]

I'm attempting to find a useful, reliable test for the actual CPU design
architecture that will work on XP and 2003 systems as well as Vista/2008/Win
7 (which means Win32_Processor's Architecture property isn't usable - it
doesn't give the correct answer for older XP versions).

Let me define the general problem I'm trying to solve, since it should
explain why I don't want to use, say, Family from the same class. I'm trying
to point admins in the right direction for quick automated checks of the
systems they support as we get more 64-bit OS installations (and demo it
with WSH and PowerShell). From this perspective, we want to identify the
underlying _hardware_ architecture as either x86 or ia64 or amd64. (I'm
using amd64 as Microsoft does - it includes EMT64).

The problem with using Family is that although I _could_ map documented CPUs
to a particular architecture, the list is always slightly obsolete - and any
tool would then have no way to categorize new numbers returned by Family. I
don't mind if I need to correlate several distinct values to get the correct
answer, but it is important that I do so for all three general architectures
when they are running XP or newer, and I need to do so correctly even for
32-bit Windows directly running on x86-64 CPUs.

Does anyone know of a way to do this that should remain accurate with future
amd64/Itanium CPUs?

If there's no direct way to do it, I know of a possible approach to try.
However, it depends on an assumption that I need confirmed. Is it correct
that the first Itanium CPUs (the ones with hardware IA32 emulation) could
NOT run 32-bit Windows natively? If there's never a real case where a system
could run 32-bit Windows and be an Itanium CPU, then I can work around the
edge of the problem by using other clues that indicate the CPU is 64-bit.

[Gerry Hickman]

Hi Alex,

A while back I looked in detail at getting the _software_ architecture
using WMI. I never thought much about the hardware.

Here is the output from my scripts. It looks like I use AddressWidth and
Architecture for the hardware and PROCESSER_ARCHITECTURE for the
software. I don't use XP at all, only Win2003/2008/Vista.

32 bit HW+SW first

Properties of the Win32_Processor class:
AddressWidth: 32
Architecture: 0
Name: Intel(R) Pentium(R) III CPU - S 1266MHz
Properties of the Win32_Processor class:
AddressWidth: 32
Architecture: 0
Name: Intel(R) Pentium(R) III CPU - S 1266MHz

Properties of the Win32_Environment class:
Name: PROCESSOR_ARCHITECTURE
VariableValue: x86

Now the 64bit HW+SW

Properties of the Win32_Processor class:
AddressWidth: 64
Architecture: 9
Name: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz
Properties of the Win32_Processor class:
AddressWidth: 64
Architecture: 9
Name: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz

Properties of the Win32_Environment class:
Name: PROCESSOR_ARCHITECTURE
VariableValue: AMD64

The two examples above are 32bit o/s on 32bit system and 64bit o/s on
64bit system. We also have some 32bit o/s on 64bit systems.

I can now see (following your post) that the hardware detection is not
perfectly reliable.

Post by unknown
I'm attempting to find a useful, reliable test for the actual CPU design
architecture that will work on XP and 2003 systems as well as
Vista/2008/Win 7 (which means Win32_Processor's Architecture property
isn't usable - it doesn't give the correct answer for older XP versions).
Let me define the general problem I'm trying to solve, since it should
explain why I don't want to use, say, Family from the same class. I'm
trying to point admins in the right direction for quick automated checks
of the systems they support as we get more 64-bit OS installations (and
demo it with WSH and PowerShell). From this perspective, we want to
identify the underlying _hardware_ architecture as either x86 or ia64 or
amd64. (I'm using amd64 as Microsoft does - it includes EMT64).
The problem with using Family is that although I _could_ map documented
CPUs to a particular architecture, the list is always slightly obsolete
- and any tool would then have no way to categorize new numbers returned
by Family. I don't mind if I need to correlate several distinct values
to get the correct answer, but it is important that I do so for all
three general architectures when they are running XP or newer, and I
need to do so correctly even for 32-bit Windows directly running on
x86-64 CPUs.
Does anyone know of a way to do this that should remain accurate with
future amd64/Itanium CPUs?
If there's no direct way to do it, I know of a possible approach to try.
However, it depends on an assumption that I need confirmed. Is it
correct that the first Itanium CPUs (the ones with hardware IA32
emulation) could NOT run 32-bit Windows natively? If there's never a
real case where a system could run 32-bit Windows and be an Itanium CPU,
then I can work around the edge of the problem by using other clues that
indicate the CPU is 64-bit.

[unknown]

Yeah. There's actually a two-part problem here.

For determining the 'true' OS bitness, reading PROCESSOR_ARCHITECTURE via
WMI will work all the way down through XP - which is probably sufficient for
everything but a dozen boxes in the world.

For the actual CPU architecture, I've done some further digging through the
actual DMTF docs and I think this is a problem that can be generally solved
with a very thorough check of the CPU numeric ID. All existing CPUs can be
conclusively categorized as x86, AMD64, or IA32. Future CPUs from AMD or
Intel that are AMD64 are going to contain the AMD64 or Intel 64 string in
their actual names, and Itanium architecture CPUs are almost certainly going
to contain Itanium or IA64 descriptors. This still doesn't tell us whether
the motherboard supports 64-bit or not, but that should be a moving target
anyway...

Post by Gerry Hickman
Hi Alex,
A while back I looked in detail at getting the _software_ architecture
using WMI. I never thought much about the hardware.
Here is the output from my scripts. It looks like I use AddressWidth and
Architecture for the hardware and PROCESSER_ARCHITECTURE for the software.
I don't use XP at all, only Win2003/2008/Vista.
32 bit HW+SW first
AddressWidth: 32
Architecture: 0
Name: Intel(R) Pentium(R) III CPU - S 1266MHz
AddressWidth: 32
Architecture: 0
Name: Intel(R) Pentium(R) III CPU - S 1266MHz
Name: PROCESSOR_ARCHITECTURE
VariableValue: x86
Now the 64bit HW+SW
AddressWidth: 64
Architecture: 9
AddressWidth: 64
Architecture: 9
Name: PROCESSOR_ARCHITECTURE
VariableValue: AMD64
The two examples above are 32bit o/s on 32bit system and 64bit o/s on
64bit system. We also have some 32bit o/s on 64bit systems.
I can now see (following your post) that the hardware detection is not
perfectly reliable.

Post by unknown
I'm attempting to find a useful, reliable test for the actual CPU design
architecture that will work on XP and 2003 systems as well as
Vista/2008/Win 7 (which means Win32_Processor's Architecture property
isn't usable - it doesn't give the correct answer for older XP versions).
Let me define the general problem I'm trying to solve, since it should
explain why I don't want to use, say, Family from the same class. I'm
trying to point admins in the right direction for quick automated checks
of the systems they support as we get more 64-bit OS installations (and
demo it with WSH and PowerShell). From this perspective, we want to
identify the underlying _hardware_ architecture as either x86 or ia64 or
amd64. (I'm using amd64 as Microsoft does - it includes EMT64).
The problem with using Family is that although I _could_ map documented
CPUs to a particular architecture, the list is always slightly obsolete -
and any tool would then have no way to categorize new numbers returned by
Family. I don't mind if I need to correlate several distinct values to
get the correct answer, but it is important that I do so for all three
general architectures when they are running XP or newer, and I need to do
so correctly even for 32-bit Windows directly running on x86-64 CPUs.
Does anyone know of a way to do this that should remain accurate with
future amd64/Itanium CPUs?
If there's no direct way to do it, I know of a possible approach to try.
However, it depends on an assumption that I need confirmed. Is it correct
that the first Itanium CPUs (the ones with hardware IA32 emulation) could
NOT run 32-bit Windows natively? If there's never a real case where a
system could run 32-bit Windows and be an Itanium CPU, then I can work
around the edge of the problem by using other clues that indicate the CPU
is 64-bit.

--
Gerry Hickman (London UK)