packaging functions - Support ARM architectures

[ferventcoder]

Packages currently select 32bit or 64bit as two architectures. We need to add ARM architectures as first class citizens to what can be passed as part of the package functions.

Follow on and related to #1800.

[ferventcoder]

I believe you would still need the Win32 emulation for choco.exe to run, but at least this would allow you to have the ARM type software installed through this method so not everything is through emulation.

[jkunkee]

Yes, full .NET is only x86 on ARM64 devices, so any .NET applications will have to run emulated (though .NET Core supports native ARM64). Fortunately between CHPE, emulator JIT caching, and NGen, their perf isn't too bad.

[AdmiringWorm]

@ferventcoder from a package maintainers perspective, how should ARM then be specified in packages?

Just normally through something like UrlARM and FileARM?

[ferventcoder]

@AdmiringWorm That's what this issue is about - discussion on that. I think we'll want to create installer urls and other things for both ARM architectures.

[virzak]

Any chance of addressing this? Recently my colleague switched to Windows ARM on parallels with his latest MacBook Pro and our choco installation script installed x64 which turned out to be incompatible with ARM64 processor, most notably imagemagick.app.

Or perhaps, the maintainer could provide bullet points of what would need to be changed for people unfamiliar with choco inner works?

[TheCakeIsNaOH]

Any chance of addressing this?

This is currently marked as backlog, so it is planned to be addressed at some point.
I have looked at this, but I don't have access to Windows on ARM currently.

Or perhaps, the maintainer could provide bullet points of what would need to be changed for people unfamiliar with choco inner works.

I'm not on the Chocolatey team, so I can't give an official go ahead, but here are some pointers if you wanted to work on this:

1. The functions are located in https://github.com/chocolatey/choco/tree/develop/src/chocolatey.resources/helpers/functions
2. You probably would want to fix ARM64 now has x64 emulation #2172 first, as that would be necessary to test between 32 and 64-bit windows on arm.
3. It probably makes sense to add a Test-IsArm or similar helper to check if running on x86/amd64 or if on arm. That way, the code can be centralized for that check. And maybe even a single helper with a check for what url/file to use (x86-32 or x86-64 or arm-32 or arm-64) that also accounts for --forcex86 usage.
4. The helpers to change are Get-ChocolateyUnzip, Get-ChocolateyWebFile, Install-ChocolateyPackage, Install-ChocolateyInstallPackage, Install-ChocolateyPowershellCommand, and Install-ChocolateyZipPackage. They would need parameters added, those parameters passed to other functions as needed (e.g. Install-ChocolateyPackage calls Get-ChocolateyWebFile), and the internal logic adjusted when selecting what parameter to use to account for the new parameters.
5. So if there is a url and url64, then a urlArm and urlArm64 should be added (or similar naming convention), same with checksum and checksum64, or file and file64
6. A decision about what to do when --forcex86 is used on an arm64 machine should be made. Does it mean use x86-32 bit, or does it mean use arm 32 bit? Is there a potential breaking change from the current behavior needed for Chocolatey v3?
7. There is a contributing doc here: https://github.com/chocolatey/choco/blob/develop/CONTRIBUTING.md

[virzak]

This is currently marked as backlog, so it is planned to be addressed at some point. I have looked at this, but I don't have access to Windows on ARM currently.

Other than using my colleague's MacBook I gain access to ARM machine on Windows through:

az vm create -n $VmName -g $Group --image MicrosoftWindowsDesktop:windows11preview-arm64:win11-22h2-pro:latest --size Standard_D8pds_v5 --public-ip-sku Standard --admin-username $UserName --priority Spot

It costs very little, especially if you don't forget to turn it off.

I'm not on the Chocolatey team, so I can't give an official go ahead, but here are some pointers if you wanted to work on this:

This is awesome

3. It probably makes sense to add a Test-IsArm or similar helper to check if running on x86/amd64 or if on arm. That way, the code can be centralized for that check. And maybe even a single helper with a check for what url/file to use (x86-32 or x86-64 or arm-32 or arm-64) that also accounts for --forcex86 usage.

The only fast and reliable way I found of doing it is through:

$isArm = $null -ne $(wmic os get osarchitecture | findstr /c:"ARM" 2> nul)
Write-Debug "Test-IsArm: returning $isArm"
return $isArm

$Env:PROCESSOR_ARCHITECTURE returns AMD64 on an ARM vm from Azure.

6. A decision about what to do when --forcex86 is used on an arm64 machine should be made. Does it mean use x86-32 bit, or does it mean use arm 32 bit? Is there a potential breaking change from the current behavior needed for Chocolatey v3?

One thing to consider here is that 32-bit Arm support is being removed from Windows 11

[geraldcombs]

The only fast and reliable way I found of doing it is through:

$isArm = $null -ne $(wmic os get osarchitecture | findstr /c:"ARM" 2> nul)

You can also get the native architecture via the IsWow64Process2 call in the Win32 API. GetNativeSystemInfo won't work since it will lie to you on Arm64.

[necrose99]

Chocolatey package itself...
Tools/$targets, ie /x64 /x86 arm /arm64 /riskv /riskv64 /$future??? ie 7zip cli.. blobs
Thier are native born arm64 installations of 7zip , 7zip cli.. anyways for bootstrapping Chocolatey, could have the 7zip it includes in $targets by architecture might be a suggestion..

https://www.7-zip.org/a/7z2301-arm64.exe

Orangepi 5/ 5 plus or the like soon launching 32 gig boards on Amazon etc, and visual studio should run on native arm64.. of late
Though getting Realtek drivers or embedded drivers initially might prove.. a pain via woa setup.. usb ie 1tb drive will work.. also
usb 3 c dongle arm64 drivers for a wifi usb or usb nic might prove useful , ntlight might be of use for slipstream of drivers into arm64 iso

[jaraco]

I don't have access to Windows on ARM currently.

If you're on an ARM-based Mac, you can use UTM. The performance is excellent (boots in ~15 sec). I've found it a great way to test my projects on Windows.

[rfay]

SO many new ARM Windows machines have been announced for delivery in June, 2024. It's time for Windows vendors to start providing arm64 for everything...

[mdgreenjr]

Any progress on this? I purchased Chocolatey to support it and didn't realize this was an issue. My main device at the moment is a windows 11 arm device. I have been kind of bouncing between chocolatey, winget, and scoop. Then I pin stuff in chocolatey so that it doesn't try to update it.

[pauby]

There are no updates on this. This isn't something we are currently working on or have any short-term plans to do so.

[rfay]

With all the new arm64 computers coming out this summer, it's going to rise in priority I'd think. Lots of buzz around that. I'm looking forward to trying out one. Docker Desktop is now supporting ARM64 on Windows. WSL2 has been there for years. I think Chocolatey and NSIS will be the only things in the way of DDEV support for Windows ARM64. I don't have much hope for NSIS.

[chadlwilson]

This is really unfortunate. As a package maintainer, occasional community contributor who literally only has an arm64 machine in which to use, support and maintain windows software/chocolatey packages on Windows 11 arm64 (a Mac as host), it's quite frustrating not having a path forward here.

As a user having to manually install and upgrade basic software outside chocolatey that is not well suited for emulation (Java runtimes, NodeJS etc) feels like a step backwards.