[Iska]

Iska, только вот кто в здравом уме станет запускать 32-битный командный шелл (из SysWOW64) в 64-битной ОС? »

Только здесь штук шесть таких за последний год было. Типичный пример — x86 Total Commander, любители репаков «всё-во-всём».

Правильно ли я понимаю, что она определяет только архитектуру CPU (меня в данном случает интересует только разрядность), а не разрядность ОС? »

Нет. Вот в этом случае:

но и на x64 железо может быть установлена x32 ОС. »

будет только %PROCESSOR_ARCHITECTURE%, и будет она содержать x86.

WOW64 Implementation Details - Win32 apps | Microsoft Docs
Detect 64 vs 32 bit OS or Process - Windows CMD - SS64.com

[Andrey_Vladimirovich]

Забавно, зачем же разработчики так назвали переменную %PROCESSOR_ARCHITECTURE%, если её значение зависит от условий, в которых она запущена? Вот об это я изначально и споткнулся.

[Iska]

Andrey_Vladimirovich, видимо решили, что она должна отражать состояние для окружения именно текущего процесса. А потом оставили, вероятно — чтобы не ломать совместимость. Изначально-то ни о каких x64 процессорах речь не шла — были Intel x86, MIPS, Alpha и PowerPC. И проверка была банальная (причём, я веду речь не только о пакетных файлах):

Код:

IF %PROCESSOR_ARCHITECTURE% == x86 (…)

Теперь представьте, что меняется платформа, и под x64 запускается некое унаследованное приложение, в котором используется подобного рода проверка. И тут выбор — либо Вы оставляете для x86-процессов под x64-платформой те же значения переменных окружения и добавляете новую (PROCESSOR_ARCHITEW6432) — и всё унаследованное у Вас гладко и безболезненно продолжает работать, либо Вы кромсаете по живому — и теряете рынок.

[Andrey_Vladimirovich]

Iska
согласен, что оставили для совместимости. Но изначально было принято не правильное решение. Ведь само название переменной %PROCESSOR_ARCHITECTURE% говорит об архитектуре процессора, либо я не правильно понимаю, что имеется в виду под словом "PROCESSOR" в данном контексте. Поправьте меня, если я не прав. А если прав, то очевидно, что ОС никак не может влиять на процессор. Максимум, что может, так это изменить микропрограмму (если такая имеется) и то, это, например, изменит логику работы процессора, но не его разрядность. И если сходить по ссылке в сообщении 61 написанном greg zakharov, то, как он и указал, написано "The processor architecture of the installed operating system.". Правда, сам он почему-то сделал иной вывод из написанного. Я понимаю, что так сделал разработчик и понимать это нужно так, как это работает, но логики в этом нет. Либо я в упор чего-то не вижу и/или не понимаю.

[DJ Mogarych]

Andrey_Vladimirovich, видимо, это просто костыль с древних времён, который никто не будет уже менять. Не стоит искать в этом какую-то непогрешимую логику, надо просто принять это как данность.

[Iska]

Но изначально было принято не правильное решение. »

Andrey_Vladimirovich, ещё раз: изначально всё было правильным. Несоответствие возникло при переходе к x64-процессорам, потому что разработчики сделали правильный вывод — пусть лучше будет несоответствие, но приложения работают, нежели будет соответствие, но приложения перестанут работать.

Вот, например:

Код:

…
# Determine the architecture we're running on.
# Define ARCH for our purposes;
# Define CPU for use by ntwin32.mak;
# Define CONFIG_H to the appropriate config.h for the system;
#
!ifdef PROCESSOR_ARCHITECTURE
# We're on Windows NT
CPU		= $(PROCESSOR_ARCHITECTURE)
CONFIG_H	= config.nt
OS_TYPE		= windowsnt
! if "$(PROCESSOR_ARCHITECTURE)" == "x86"
ARCH		= i386
CPU		= i386
! else
!  if "$(PROCESSOR_ARCHITECTURE)" == "MIPS"
ARCH		= mips
!  else
!   if "$(PROCESSOR_ARCHITECTURE)" == "ALPHA"
ARCH		= alpha
!   else
!    if "$(PROCESSOR_ARCHITECTURE)" == "PPC"
ARCH		= ppc
!    else
!     error Unknown architecture type "$(PROCESSOR_ARCHITECTURE)"
!    endif
!   endif
!  endif
! endif
!else
# We're on Windows 95
ARCH		= i386
CPU		= i386
CONFIG_H	= config.nt
OS_TYPE		= windows95
!endif
…

[Andrey_Vladimirovich]

Andrey_Vladimirovich, ещё раз: изначально всё было правильным. »

Нет, просто изначально это не создавало проблем с точки зрения логики (правильнее сказать, таких проблем).

[Iska]

Andrey_Vladimirovich, нет. Вы никак не поймёте — изначально эта переменная окружения и показывала именно архитектуру процессора. Я же Вам даже образец реального кода тех времён привёл.

[Andrey_Vladimirovich]

Iska
то, что эта переменная изначально имела отношение к железу, тут у меня вопросов нет. То есть, изначально эта переменная предназначалась исключительно для определения архитектуры CPU (т.е. железа) и вопроса в определении разрядности (как CPU, так и ОС) не стояло, т.к. все были x32. А потом, с появлением x64 решили, что называется "перегрузить" переменную и использовать её, в добавок с другой, в определении разрядности, как ОС, так и запущенного процесса. Так?

[Iska]

изначально эта переменная предназначалась исключительно для определения архитектуры CPU (т.е. железа) и вопроса в определении разрядности (как CPU, так и ОС) не стояло, т.к. все были x32. »

Так.

А потом, с появлением x64 решили, что называется "перегрузить" переменную и использовать её, в добавок с другой, в определении разрядности, как ОС, так и запущенного процесса. Так? »

Нет. Никто не предназначал её для определения разрядности ОС, ни изначально, ни потом. Значение x86 оставили в этой переменной окружения в случае исполнения x86-процессов под x64 ОС именно для совместимости, чтобы работали унаследованные приложения. А для возможности определения данного факта не для унаследованных, а современных приложений, добавили для этого случая новую переменную окружения — PROCESSOR_ARCHITEW6432.

То, что мы используем эти две переменные окружения для определения разрядности ОС — просто побочный эффект, который работает по вышеизложенной причине (и потому, что на пользовательском уровне не встретишь ни IA, ни ARM).