For the x86 CPU os.machine() returns i686 instead of i386

[RareScrap]

Version

22.16.0

Platform

Microsoft Windows NT 10.0.19045.0 x86

Subsystem

os

What steps will reproduce the bug?

1. Run os.machine() in node x86 REPL

How often does it reproduce? Is there a required condition?

100% reproducible

What is the expected behavior? Why is that the expected behavior?

The os.machine() returns i386

What do you see instead?

The os.machine() returns i686 which indicates the x86 app running on x64 CPU (which makes no sense for a x86 CPU host)

Additional information

The main problem - there's no way to determine the true Windows host OS architecture in NodeJS (process.arch is not about it)

Workaround

You can determine the true Windows host OS architecture using the PROCESSOR_ARCHITECTURE environment variable:

function getWindowsOsArchitectureUsingPlatform(): NodeJS.Architecture | undefined {
    const osArchitectureEnvVar = this.getWindowsOsArchitectureEnvVar()
    const sanitizedOsArchitectureEnvVar = osArchitectureEnvVar?.toLowerCase()
    switch (sanitizedOsArchitectureEnvVar) {
        // Values listed in win32 docs:
        // https://learn.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details#environment-variables
        case "amd64": return "x64"
        case "ia64": return "x64"
        case "arm64": return "arm64"
        case "x86": return "ia32"
    }

    return undefined
}

function getWindowsOsArchitectureEnvVar(): string | undefined {
    // Despite its name, the PROCESSOR_ARCHITECTURE environment variable stores the architecture of the operating
    // system, not the CPU itself (e.g. for Windows on x86 on an x86_64 processor, the variable has the value `x86`)
    const osArchitectureEnvVar = process.env["PROCESSOR_ARCHITECTURE"]
    const sanitizedOsArchitectureEnvVar = osArchitectureEnvVar?.toLowerCase()
    // When running a 32-bit process (x86) on a 64-bit operating system (x86_64, arm64), the actual
    // value of PROCESSOR_ARCHITECTURE are contained in PROCESSOR_ARCHITEW6432
    // https://learn.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details#environment-variables
    const is32BitProcess = sanitizedOsArchitectureEnvVar === "x86"
    if (is32BitProcess) {
        const wowCpuArchitectureEnvVar = process.env["PROCESSOR_ARCHITEW6432"]
        if (wowCpuArchitectureEnvVar) return wowCpuArchitectureEnvVar
    }

    return osArchitectureEnvVar
}

[juanarbol]

Ping @nodejs/libuv

[saghul]

What processor do you have? I'd expect that to be correct if you are running the x86 windows version on a x64 processor.

[RareScrap]

What processor do you have?

It's not matter because I run Windows using VirtualBox with x86 CPU option

I'd expect that to be correct if you are running the x86 windows version on a x64 processor

Yep, this works as expected on Windows x64 hosts because os.machine() returns i686 for x86 apps

[JoCat]

Turns out I can't tell if the application is running on a 32 or 64 bit system

If I understand correctly, this call is used in such cases: https://learn.microsoft.com/en-us/windows/win32/api/wow64apiset/nf-wow64apiset-iswow64process2

UPD or read PROCESSOR_ARCHITEW6432 env

[tniessen]

I assume that this is specific to Node.js 22 since Node.js 23 and beyond do not support 32-bit Windows hosts as far as I can tell. Please let me know if this is incorrect.

[JoCat]

Yes, it looks like as of version 23, 32-bit versions of node.js are no longer being released

[bnoordhuis]

The return value reflects what the operating system thinks is the CPU architecture, in this case PROCESSOR_ARCHITECTURE_IA32_ON_WIN64.

If there is a bug (which I doubt), it's not a libuv or node bug, unless your expectation is that libuv returns "i386" for both PROCESSOR_ARCHITECTURE_IA32_ON_WIN64 and PROCESSOR_ARCHITECTURE_INTEL, but:

1. then you can't differentiate between the two, and, more importantly,
2. libuv has always behaved this way (or, at least, for as long as it has uv_os_uname) and that won't change for backwards compatibility reasons

For that reason I'm going to close this as a wontfix.