Vscode: Support ARM64 build for Windows

[77]

New devices are coming to market in a couple months. These are ARM64 devices running the Windows 10 OS. Can we get an officially supported build of VS Code that runs native on ARM64?

[rcjsuen]

Electron would have to support ARM binaries on Windows first, which it currently does not.

[77]

Now that Microsoft released the ARM64 compilers in the SDK we can move forward on this.

[shiftkey]

For reference, you should follow along with the Electron issue https://github.com/electron/electron/issues/9456 as well as the upstream Chromium issue https://bugs.chromium.org/p/chromium/issues/detail?id=893460 as these are both blockers for VSCode to be able to run on Windows for ARM64..

[driver1998]

As an update, somebody successfully built VSCode for Windows ARM64.
http://github.com/ljsabc/Code-OSS-Win32-arm64

[pponaldo]

As I know, electron started to support windows 10 on arm64 in stable version. Is there an official support of vs code?

[conioh]

@rcjsuen @joaomoreno
Official Windows ARM64 Electron release: https://electronjs.org/blog/electron-7-0
https://github.com/electron/electron/releases/tag/v7.0.0
https://github.com/electron/electron/pull/20112

[voronoipotato]

Surface Pro X is released (I'm using it now), is there any timeline for VS Code for Windows Arm64?

[Chirishman]

I tracked down their booth and asked them about it at Ignite, they would not give a timeline but basically said that the primary blocker at this point is having the man hours to run the testing to make sure that it works as expected with all of the third party extensions.

[voronoipotato]

That's a fair concern but I'd rather have vscode with no extensions than no vscode.

[driver1998]

Sure having ARM64 might make current extensions incompatible, but we need native VSCode to kick start native extension development isn't it?
People can always install both x86 and ARM64 vscode if they have to.

[5A4B48]

Just Checking on this, purchased a surface pro X and super excited about vscode on this device but would rather have ARM64 than x86

[voronoipotato]

Same is there anything we could do that would help?

[brion]

Note that if you have a WSL-based workflow, the remoting server in VS Code Insiders now supports ARM64 Linux. This allows using the official x86 frontend app with ARM64 Linux extensions running in the WSL environment, and works well for my PHP+JS projects for now.

However as with a potential ARM64 Windows frontend, not all extensions work yet. I found that the Rust (RLS) and PHP intellisense extensions work ok, while the C/C++ one explicitly fails out saying it's without support for ARM64 Linux.

[voronoipotato]

How are you testing an arm 64 windows front end? I can use a terminal based workflow if I can use vscode Win Arm 64.

[hmartinez82]

@brion @voronoipotato How did you even get an ARM64 front end? _Teach me_

[voronoipotato]

Surface Pro X, it's pretty great actually. The major hurdle is just the software side, but otherwise it's very good.

[brion]

I'm still using the x86 frontend in emulation, so only the extensions inside the WSL Linux sandbox are running natively ARM64 for me. But I've heard some folks have had success manually building the frontend for ARM64?

[voronoipotato]

https://code.headmelted.com/ aka https://github.com/headmelted/codebuilds Perhaps this is a good starting point.

[awakecoding]

+1, I would love to use VSCode on my Surface Pro X

[soapdog]

Any news on this? Both electron and nodejs are building in Windows for ARM now.

[dsugiyama]

For anyone interested, I've put some instruction on how to build vscode for Windows/ARM64, and also a prebuilt binary package of version 1.41.1. Use this until Windows/ARM64 build becomes officially supported.
https://github.com/dsugiyama/build-vscode-win-arm64

[sunipkmukherjee]

With WoA getting pushed by MSFT shouldn't this be a priority? I as a dev would love to have a sleek arm machine running VSCode.

[awakecoding]

@sunipkmukherjee I agree with you, because if vscode is correctly ported to WoA, then it becomes a real good option for development when combined with vscode remote development. I've been using the 32-bit intel build of vscode for the past two weeks on my Surface Pro X + remote development over SSH to macOS, Linux and Windows, and it works, but it does crash about once every few days, unfortunately.

[voronoipotato]

@awakecoding perhaps we should be filing issues for those to Microsoft support I guess? At least then it could get fixed. It appears that the Code team may be understaffed. I'm not seeing any indication that we will be getting vscode for arm64 any time soon, the pull request appears to be completed and it's not being reviewed/merged. I believe the reason is they aren't sure they have the manpower to review, test and support WoA. While completely understandable from a peer to peer relation (I don't blame vscode devs at all), it's very hard to understand in terms of a customer to corporation relation. This is a tremendous disappointment to me, especially because the surface pro x is a fantastic laptop for the current crisis. We all figured that some apps wouldn't be compiled for it, but it's a bit crushing that Microsoft's own flagship development applications aren't being compiled for it, especially when there is a build ready. Seems like a truly astronomical amount of work and love just being set on fire because of a lack of coordination within Microsoft. By contrast the dotnet core team is building an WoA installer and have a build already available. Why does it appear there was nobody tasked with making sure this initiative was followed through, and resources allocated to make it attainable across the business? It seems like they just said "We're doing WoA" and then tried to put pressure on the devs as though they weren't already doing a job. Maybe they didn't even bring it up with other teams as a thing that mattered.

Who knows... I feel really sad. Sorry to be a bummer in here, I know we're all really excited. I still love my surface pro x, but I'm not convinced that Microsoft feels the same way.

[77]

Despite the lack of activity on this thread the ARM64 client is in progress. Maybe it will be released in time for the three year anniversary of my opening this ticket. 😀

[voronoipotato]

Thank you for having greater patience in 3 years than I had in 3 months haha. I suppose all we can do is keep our chin up.

[rayfoss]

My jaw is dropped with what Edg/Chromium are doing on a Snapdragon 850... Got one of these surprisingly unquirky ARM64 convetible tablets. Still figuring out how to properly get git working here... Im normally a linux die hard, but this thing is so nice lol

[joaomoreno]

Just spitting out what needs to happen here.

This process has many steps:

1. Build: This has been somewhat achieved in https://github.com/microsoft/vscode/pull/85326, still some work to be done on our side.
2. Test: We have a test machine (Surface Pro X) on the way, so this will happen soon. I'll post results as soon as possible.
3. Integrate: This is the hardest part. We rely on Azure DevOps for building and there aren't any hosted ARM64 build agents. A few options here: roll our own build agent or cross-compile this on x64.
4. Collaborate: We've seen this happen when we released remote for ARM64: our partner extensions are not prepared for this. These are extensions which rely on native components to operate (C#, C++, Rust, etc) and they need to release those components for the ARM64 architecture. We should do a better job this time and let them know ARM64 for Windows is coming, otherwise we're just dumping an onslaught of issues on them as soon as we release. This might take a while.

[awakecoding]

@joaomoreno for step 3 - integrate, it should be much easier than you think, since the best approach would be to keep your intel x64 build agents and cross-compile to ARM64 using the MSVC build tools. I am not familiar with your build process but for me it was just a matter of modifying my build container to add the MSVC ARM64 components, similar to how you add x86 or x64 build components.

[joaomoreno]

It's not only a matter of compilation but of running as well. We want to run all our test suites on the built bits.

[awakecoding]

@joaomoreno that's a good point, maybe the upcoming Hyper-V support on Windows ARM64 support (currently in the insider preview) could help instead of using physical hosts to run the tests.

[richard-townsend-arm]

What Electron do is they run the Azure DevOps device runner in x86 mode - seems to work fine for them and they use that to test the ARM64 binary.

[conioh]

Thanks for the update. A few questions:

Just spitting out what needs to happen here.

This process has many steps:

1. Build: This has been somewhat achieved in #85326, still some work to be done on our side.
2. Test: We have a test machine (Surface Pro X) on the way, so this will happen soon. I'll post results as soon as possible.

I have a machine. Can we get an officially-built VSCode for ARM64 (even an "alpha"/preview/whatever version) to test too? My machine is from a previous generation (Asus NovaGo, SD835) and I'd like to see that it works there too.

(If you have a test suite you'd want me to run I think I could do that too, if you don't have special environment requirements.)

1. Integrate: This is the hardest part. We rely on Azure DevOps for building and there aren't any hosted ARM64 build agents. A few options here: roll our own build agent or cross-compile this on x64.
2. Collaborate: We've seen this happen when we released remote for ARM64: our partner extensions are not prepared for this. These are extensions which rely on native components to operate (C#, C++, Rust, etc) and they need to release those components for the ARM64 architecture. We should do a better job this time and let them know ARM64 for Windows is coming, otherwise we're just dumping an onslaught of issues on them as soon as we release. This might take a while.

I don't know how this works now, with VSCode being available for Windows, Linux and macOS, but assuming you have some method of specifying platform and extensions bring the appropriate native components for each platform, sounds like all you need to do is to add win-arm64 to win-x86-32, win-x86-64, linux-x86-64 and macos-x86-64.

What's the difference? It's completely expected that _certain_ extensions will only work on certain platforms. A WPF designer will only work on Windows. A Swift extension will work on macOS and Linux, but not Windows. That's fine. I don't think any reasonable person expects all extensions to work on all platforms. I'd be satisfied with extensions with native components that can't run on a certain platform to give an early error before downloading and trying to install.

That sounds like something that should already be in place. I don't see why we should wait for extensions X, Y and Z to support ARM64 when other things are already working.

[joaomoreno]

I don't know how this works now, with VSCode being available for Windows, Linux and macOS, but assuming you have some method of specifying platform and extensions bring the appropriate native components for each platform, sounds like all you need to do is to add win-arm64 to win-x86-32, win-x86-64, linux-x86-64 and macos-x86-64.

We don't build the C#, C++, Rust extensions. Our partners do that. Extension authors have to be onboard, otherwise their features will just be broken. This has happened before when releasing the ARM64 remote for Linux. We don't have to wait for that to happen, but we should to a better job at _collaborating_ with them to let them know a torrent of issues is about to fall on top of them.

[tuanle07]

@joaomoreno : It would be great if Microsoft could release the Win Arm64 version of VS Code soon. Having it working on Surface Pro X would be the last program I need on this machine to make it 100% usable for my daily work. Pls make it happen soon. Many thanks.

[voronoipotato]

@joaomoreno To be clear the x86 emulation is good enough their extensions will "work" provided it pulls x86 instead of x64. I agree though that it is up to the extension authors and their community (us) to help update everything for ARM should we need to.

[rayfoss]

@joaomoreno To be clear the x86 emulation is good enough their extensions will "work" provided it pulls x86 instead of x64. I agree though that it is up to the extension authors and their community (us) to help update everything for ARM should we need to.

Clarification, Windows on ARM supports emulating x86_32, but does not support emulating 64 bit x86_64 apps. Native apps are either ARMv8_64 or ARMv7_32 apps, publishing ARM32 is usually unnecessary... unless you're targeting older Raspberry Pi's which don't have the memory to run VS Code properly anyway or Windows RT which is dead. Windows 10 on ARM doesn't come in a 32 bit variant.

[hwchong]

It's not only a matter of compilation but of running as well. We want to run all our test suites on the built bits.

Would it help if a Qemu Windows ARM64 environment was set up to run the tests?

[dennisameling]

What Electron do is they run the Azure DevOps device runner in x86 mode - seems to work fine for them and they use that to test the ARM64 binary.

I wanted to understand how exactly the Electron team did this, and it seems like they literally set up a Surface device (I guess a Surface Pro X) which they use for Azure DevOps. Like @richard-townsend-arm mentioned, they should be running the self-hosted x86 Azure DevOps agent as there's no arm64 version for it, but it works for them apparently.

I'm working on adding Windows ARM64 support to GitHub Desktop and wanted to try the same, so I installed the Azure DevOps x86 agent on my Surface Pro X and created an Azure Pipeline. So, the setup is:

• Windows 10 ARM64 host (Surface Pro X)
• 32-bit NodeJS + VS Build Tools (ARM64 build for NodeJS is in the works)
• Set npm_config_arch=arm64 and TARGET_ARCH=arm64 so that ARM64 binaries (like Electron ARM64) are downloaded

This seems to work well. An ARM64 build is created without issues, I only need to make sure that the tests will also pass, but that's unrelated to ARM64 specifically.

Would it help if a Qemu Windows ARM64 environment was set up to run the tests?

That might work, but I expect it to be incredibly slow. Running on a native ARM64 device already timed out after 1hr because the 32-bit emulation on Windows ARM64 slows things down significantly. Also, there's no Windows 10 ARM64 ISO files available via Microsoft's official channels AFAIK, so you'll need to do some magic yourself :) Instructions to create a Windows 10 ARM64 ISO can be found on this page, just ignore the Raspberry Pi-specific bits.

[joaomoreno]

@dennisameling That is pretty much my plan as well, once we get that Surface Pro X. Glad to know you had success. Good news for this feature item.

[joaomoreno]

🚀 And... we have liftoff: https://twitter.com/joaomoreno/status/1266005299661545474

• User Setup: https://update.code.visualstudio.com/latest/win32-arm64-user/insider
• System Setup: https://update.code.visualstudio.com/latest/win32-arm64/insider
• ZIP: https://update.code.visualstudio.com/latest/win32-arm64-archive/insider

[joaomoreno]

Special thanks to @richard-townsend-arm for pushing this forward in https://github.com/microsoft/vscode/pull/85326 👏

[joaomoreno]

@deepak1556 Care to verify this one?

[deepak1556]

Sure happy to 👍

[danieldjewell]

FWIW, perhaps the team at Microsoft can look into Microsoft-made extensions and ARM support... -- e.g. https://github.com/microsoft/python-language-server/pull/2073