VS Code 1.69.0 installs x64 node server onto Windows 11 ARM64 remote PC and identifies platform incorrectly as x64

[Colengms]

Version: 1.69.0 (system setup) Commit: 92d25e35d9bf1a6b16f7d0758f25d48ace11e5b9 Date: 2022-07-07T05:28:36.503Z Electron: 18.3.5 Chromium: 100.0.4896.160 Node.js: 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.22000

VS Code 1.69.0 (and Remote - SSH v0.83.2022070715) appears to be installing an x64 binary for node.exe onto Windows 11 ARM64 remote PC. Windows 11 can emulate x64, but is much faster at emulating x86. The x86 version of node.exe should probably be installed on Windows 11 ARM64 instead.

The worse part of this issue is that calling os.arch() from our extension identifies the platform as x64. Our extension has a check to ensure correct native binaries have been installed on the system, and it's now misidentifying Windows 11 ARM64 machines as x64 when used remotely, causing an error to be displayed (when the arm64 platform-specific VSIX is explicitly installed on the system). This only happens when using the machine remotely. os.arch() properly identifies the machine as arm64 when running fully locally on Windows 11 ARM64, with the arm64 platform-specific VSIX.

I don't see a Windows ARM64 version of node available for download from nodejs.org, but we do get the correct os.arch() when not remoting...

[Colengms]

Also, the user scenario of simply installing a platform-specific VSIX from the marketplace into the remote Windows 11 ARM64 machine, appears to install the x64 VSIX. This results in very bad perf. :/

[tanhakabir]

And just to clarify I assume this has been an issue for awhile or are you just seeing this behavior in the versions you listed above?

[Colengms]

Hi @tanhakabir . That was the first version(s) I noticed the issue in, but it still repros with the latest version(s), resulting in very bad performance when SSH remoting into ARM64 Windows hosts.

[tanhakabir]

Would you be able to verify for me if you're seeing this in VS Code versions < 1.69 and SSH extension <=0.82?

[Colengms]

I tried with VS Code 1.68.1, and 0.80.0 of the SSH extension, and that also installed the x64 binaries on the remote Windows 11 ARM64 PC.

[roblourens]

If this is still an issue, we check the arch just by reading $env:PROCESSOR_ARCHITECTURE, could you share the value of that variable from inside an ssh session? It might be that windows ARM64 uses a x64 sshd and so that's the value we get.

# https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details?redirectedfrom=MSDN
$p = $env:PROCESSOR_ARCHITECTURE
$arch = if (($p -eq 'AMD64') -or ($p -eq 'IA64')) { 'x64' } else { 'ia32' }

[davidkhess]

@roblourens it reports ARM64. That code you quoted doesn't account for that case and ends up using ia32 - which as of about a month ago is no longer being built which results in a "can't install VS Code server error".

Until VS Code can deliver an ARM64 native nodejs runtime, it probably needs to result in 'x64' for now so we can at least run via emulation.

Note, if you hack the extension and change that code to just always use 'x64', it will successfully run on Windows ARM 11.

[5he1n]

Prove me wrong but... It's a real bummer that vscode-server still doesn't play nice with Windows on ARM. I mean, the Darwin got their version, we even have Node for ARM64 binaries, so what gives?

Because of this, we're stuck doing some serious digital gymnastics, tweaking installation scripts and whatnot, just to get vscode-server to somewhat work on Windows on ARM by tricking it into running x64 builds. It's a hassle and, honestly, it's a bit of a letdown.

The whole thing's got me dragging my feet. The performance hit is so noticeable that I'm seriously thinking about ditching VSCode. Don't get me wrong, it's not like I'm making threats here; I'm just sharing what's going through my head after staring at my screen, waiting forever just for a file to save.

Figured I'd drop my two cents here since this is the latest issue on this topic.

Edit: I do remember the words "We'll bring this up in planning for our next iteration" (https://github.com/microsoft/vscode-remote-release/issues/9204#issuecomment-1836375383). But that's raises a question: Why only now?

Edit 2: Here's a cool trick for you. If you grab the Node binary for ARM64, swap out the one chilling in your .vscode-server folder, and then swap in the .node files from the VSCode ARM64 build into node_modules, you kinda hack your way into a working ARM64 vscode-server. It's a bit like performing digital surgery, but works for now. Sure, you might run into a few issues here and there one day, but so far, it's looking good.