Treat ARM64 Windows like x64 Windows

[jkunkee]

This change allows the installer to run successfully on Windows 11 on ARM by treating it as x64 Windows.

With the advent of x64 emulation on ARM64 (introduced in Windows 11), x64 usermode applications like Visual Studio Code
run unmodified on ARM64 Windows. This includes the entire IDE stack.

Without this change the installer fails with:

System.Collections.Generic.KeyNotFoundException: The given key 'Invalid' was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at WPILibInstaller.ViewModels.VSCodePageViewModel.DownloadSingleVSCodeFunc() in D:\a\WPILibInstaller-Avalonia\WPILibInstaller-Avalonia\WPILibInstaller-Avalonia\ViewModels\VSCodePageViewModel.cs:line 329

On Windows 10 on ARM it will fail with an error about the architecture not being supported, which will lead the user back to the
documentation that clearly states it is not supported.

[jkunkee]

I should have a chance to validate this all the way through uploading to the RoboRIO this coming week or next.

To my (relatively new) understanding, the only aspect of the entire FRC environment that might not work via x64 emulation on ARM64 is the RoboRIO USB interface. Depending on how that is done, it may just work (WinUSB or class driver), may be as easy as adding NTarm64 to an INF (class driver with specialty VID/PID), or it may require significant work (full .sys driver).

I'm happy to talk about this in depth since it's adjacent to my day job. Azure-hosted ARM64 VMs are generally available if CI coverage is needed.

[ThadHouse]

Its not possible to get any of the NI stuff working (I spent a few hours trying). You're right about the driver, but the bigger issue is the DS is a 32 bit app compiled with a higher level of SSE then the x86 32 bit emulator supports. And in modern versions of LabVIEW, its not possible to disable this SSE support. And since its a 32 bit app, I highly doubt anyone at Microsoft would be willing to fix this, especially since arm32 and x86 32 support has been slowly dying in the last few years. Our best bet is for when the DS updates to 64 bit hopefully in the future.

However, all the WPILib stuff should work, and you should fully be able to deploy to a robot over Ethernet. Another fun thing is if you run Arm64 WSL, the Arm64 version of the linux WPILib stuff works fantastic.

The reason for not having native arm64 windows support is Gradle doesn't support Arm64 targets on Windows. There are PR's open for this, but they just keep getting ignored by the Gradle team.

[jkunkee]

I'll pass that on. NI is technically breaking the ABI by not doing feature checks, but their users aren't yelling at them about it. Fun fact: this means they're probably broken on some Surface Go and similar low-spec devices too; that's how the CPU floor got picked. Do you happen to know what SSE features they're expecting?

Hmm. I'll ask about Gradle too. Ecosystem work is a world unto itself... :)

[ThadHouse]

They actually do use a feature check, so it doesn't crash, but instead properly prints out an error message.

https://lavag.org/uploads/monthly_2022_01/396244017_VIPackageManageronAppleM1usingParallelsandWindows11.png.d0eafd8f636d96c32f7ea4ca768de76e.png

It sounds like the features should be supported, but how they do the check isn't correctly emulated.

As for Gradle, its entirely on them. People are willing to do the work, they just let PR's sit in limbo for months. Its just simple things like finding the arm64 compilers. Thats all that would actually be needed to get cross compilation working. And then another similar change to find the arm64 host compilers, which would get host builds working.

gradle/gradle#21780

Also, I bet thats a cool team to work on at Microsoft. I used to work on the Corenet team working on QUIC until I moved to Meta last year.

[ThadHouse]

If thats something you want to debug, you can't run the game tools installer on arm64 because of the driver, which fails to install. However, you can install the 2020 LabVIEW runtime, which will install. Then you can copy the DS binary folder (Program Files (X86)/FRC Driver Station) from an Intel system to the same place on the Arm system, and it will run far enough to spit out that error.

[jkunkee]

Well, that's actually fantastic to hear--as much as I whine about doing proper CPU feature checking, it is fiddly and folks tend to take shortcuts. Kudos to them for having a proper error path.

That said, yeah, from that screenshot they're asking for SSE2, which the emulator definitely supports.

And yeah, it's a fun team. I'm not quite sure where Corenet is in relation to me; I'm on the Mixed-Architecture Computing team adjacent to the kernel team(s). Crazy smart people everywhere. :D

If you bump into any MS compiler people over at Meta, tell them I say hi. ;)

[jkunkee]

Chasing down drivers is a supply chain thing as much as anything. The actual changes are usually quite small, but getting the change accepted, the package signed, and the installer enlightened is where I've usually seen it bog down.

[ThadHouse]

Agreed. Luckily the driver part of the NI stuff is not roboRIO specific, so if any internal contacts existed, it'd probably get possible to at least get a start there, since it affect most of NI's devices, and not just the FRC stuff. But even then, not sure how much their user base needs arm64.

However, it would be awesome to run the DS on arm64. So if its a bug in the emulation layer causing wrong detection, I'm sure a fix for that would be greatly appreciated.

[jkunkee]

It would help to have a contact at NI that knows how their CPUID handshake works. It's a bit tricky and even Steam was getting parts of it wrong (since fixed).

[ThadHouse]

I can ping a few people next week and see if I can get an answer to who would be contacted. I'm sure they'd be happy to get a bit of help.

[jkunkee]

I remember that TTD for x86 works on ARM64 with a couple of tweaks (disable Hybrid Execution in App Compat settings), so it is probably tractable to look at alone--but it's always easier with the actual product owner involved. :)