Test and build for Windows 10 ARM

[rvagg]

With ARM Windows support becoming a proper consumer-level thing we really should start discussing how we might deal with it. Node binaries will run in emulated x86 mode on these things but that's not going to be optimal.

Node for dev toolchains and Node underneath Electron for all of its various desktop apps being the two primary use cases I think. tbh I reckon these new low-power tablet/laptop hybrids with ARM + Windows 10 look pretty sweet and would make a nice portable dev machine.

I can't imagine that we're going to have big challenges with native builds as the compiler should be doing everything we need. But we really should be testing and possibly releasing builds for this platform. Unfortunately Windows 10 on Arm doesn't do virtualisation yet so we're going to either need to run cross-compile and / or emulated or have some physical hardware in place for this.

Who should we be looping in on the Microsoft side for this discussion @joaocgreis?

[joaocgreis]

Does V8 already support Windows ARM? (cc @nodejs/v8)

We already build node-chakracore for ARM, so we have the infra for compiling ready. I don't think we have Windows ARM machines on any cloud provider yet, so testing is not straightforward.

[hashseed]

I had the impression that Windows ARM does not offer the API to make memory pages executable. That was at least the case with Windows RT. That basically means that V8 cannot run on Windows ARM.

[rvagg]

OK, so it sounds like this is off the cards for now. Good to know. If people come asking then our official answer is simply that you have to use it emulated or download node-chakracore which is kept pretty much up to date.
At some point we're going to need to have more discussion about the status of node-chakracore and if/how we bring it closer in to the fold rather than just have it sitting off to the side, managed by different people, infra and processes. I feel like the discussion around "vm neutrality" conveniently stalled once node-chakracore started making releases via nodejs.org.

[jkunkee]

Hey @rvagg, I happen to work on the ARM64 Windows project at Microsoft, mostly on the emulation side of things. Just a few thoughts:

Windows RT was definitely limited on what it allowed Store apps to do.

Windows 10 on ARM is decidedly NOT Windows RT, especially now that the host OS is ARM64.

• Overall announcement: Windows 10 on ARM | Build 2017
• Q&A including SDK mentions: Always Connected PC - January 2018 | Windows Community Standup

We do have plans for shipping an ARM64 Win32 SDK, as mentioned under "Drivers" here on our docs site, but it's not ready yet. (If the vague future isn't enough now, pay close attention to the community comments at the bottom of that page.) Note that the API surface may be missing some legacy bits, but it’s nothing like RT-vs.-Desktop; memory reprotection is certainly not a problem. I expect Node.js to run fine once V8 knows how to emit ARM64-Win32 ABI glue. (That was the hardest part when a few friends and I made a hackathon attempt at getting the Go compiler to generate ARM32 Win32 binaries.)

If you have any more questions (say, about hardware availability, timelines, or specific API bits), please do contact the address listed on that page (woafeedback at microsoft dot com). (That goes for you, too, @hashseed!)

[rvagg]

Had a few private conversations about this and this news just popped up today so perhaps we are getting close?

https://arstechnica.com/gadgets/2018/11/microsoft-joining-qualcomm-and-google-to-bring-chrome-to-windows-on-arm/

[jkunkee]

Yes, yes we are.

Port

I'm working on this now. The pain points so far have been:

1. OpenSSL 1.1.0j lacks ARM64 Windows build support
   A small change to a config file fixes this, but only if no-asm OpenSSL is OK. Enabling ASM will be lots more work in grokking the Node.js and OpenSSL build systems, ensuring the ASM doesn't use x18, a platform-reserved register on Windows, and seeing if armasm64.exe will work with the .S files already in use in the ARM64 Linux build.
   I'll try and upstream the config tweak, but I may have to settle with maintaining a fork.
   OpenSSL ~1.2+ already has (untested) ARM64 Windows support, as does boringSSL.
2. v8 in tip-of-tree Node.js is 7.1.302. The first v8 version with full ARM64 Windows support is 7.2.479.
   I'm trying to use the nodejs/node-v8 repo to work around this, but this is inherently unsupported and doesn't even build right for x64.
3. The v8 build's task bytecode_builtins_list_generator builds an ARM64 build target EXE and then generate_bytecode_builtins_list attempts to run it on the AMD64 build host.
   GYP knows it's a cross compile, but this behavior persists. Since the v8 build system is GN, I suspect this is a design flaw somewhere in the v8 GYP vcbuild.bat realm. The '#host' designations in the GYP files looks like the host/target distinction is already present, but if so it isn't honored.

I'll be reading up on the Node.js contribution guidelines to get a feel for how this community flows so I can ask questions in the right places. I'm happy to have any help with this anyone can provide.

Build

VS 2017 15.9+ has full ARM64 target support. This should be paired with Windows SDK 17763 or greater.

VSTS/Azure DevOps has agents that have the right VS and VC versions, though the Windows SDK needs to be updated. I believe this can be done with a little extra Azure Pipeline YAML.

Test

My team is weighing a number of options for enabling CI/CD workflows that target Windows 10 on ARM. I don't have much to share...yet.

Purchasing or borrowing existing retail devices (Asus NovaGo, HP Envy x2, Lenovo Miix 630, Samsung Galaxy Book2, Lenovo Yoga C630) is still the easiest way go to. Happily, emulation means that installing a self-hosted VSTS Build Agent should be straightforward, but I haven't tried it yet.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[jkunkee]

All of my changes have been merged, so what's in the repo should have Experimental support for ARM64 Windows. @joaocgreis has done some amazing work to keep it working and last I heard has alpha builds coming out. This issue can probably be closed until Joao has the resources to move support to Tier 2.

[richardlau]

FWIW ARM64 Windows builds are available from https://unofficial-builds.nodejs.org/ for Node.js 12 up to v12.15.0 (they're missing for v12.16.0 and v12.16.1). AFAIK they've never been available for Node.js 13.

cc @joaocgreis

[sxa]

[EDIT: Discussion appears to be ongoing in https://github.com/nodejs/node/issues/25998 ]

@richardlau What would it take to update the unofficial-builds site with new builds? (Not sure who produced the old ones) and I presume given @jkunkee's comments that the code made it into the head stream? Are the alpha builds mentioned in a previous comment around anywhere @joaocgreis?

[richardlau]

[EDIT: Discussion appears to be ongoing in https://github.com/nodejs/node/issues/25998 ]

@richardlau What would it take to update the unofficial-builds site with new builds? (Not sure who produced the old ones) and I presume given @jkunkee's comments that the code made it into the head stream? Are the alpha builds mentioned in a previous comment around anywhere @joaocgreis?

I think @joaocgreis was manually producing the old ones (nodejs/unofficial-builds#2).