Add support for Windows on ARM

[rmartin16]

What is the problem or limitation you are having?

Briefcase can currently only target Windows on x86. With the growing support for Windows on ARM, Briefcase should support targeting ARM.

Describe the solution you'd like

The current stub should be built for ARM and the Visual Studio template should support targeting ARM.

The embedded Python should be the arm64 version. Although, this is only available back to Python 3.11.

Describe alternatives you've considered

Similar to macOS on Apple Silicon, Windows can run x86 binaries on ARM. I still need to actually try it but this may allow a Briefcase app built for x86 to run on ARM.

Additional context

No response

[freakboy3742]

Also worth note: Github has introduced native Windows ARM runners; they're not available on free tier yet, but if the experience with macOS ARM runners is indicative, they might be available on free tier later this year/early next year.

[rmartin16]

To confirm, after installing the MSI for an app packaged for x86, the app does run on ARM (albeit virtualized):

However, the zip package logs an error; perhaps unrelated to x86 on ARM since the same thing happens when I try to run the zip on another x86 install...maybe #1890 is related...

  File "\app_packages\toga_winforms\__init__.py", line 1, in <module>
    import clr
  File "\app_packages\clr.py", line 6, in <module>
    load()
  File "\app_packages\pythonnet\__init__.py", line 143, in load
    func = assembly.get_function("Python.Runtime.Loader.Initialize")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\types.py", line 94, in get_function
    return ClrFunction(self._runtime, self._path, name, func)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\types.py", line 58, in __init__
    self._callable = runtime._get_callable(assembly, typename, func_name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "\app_packages\clr_loader\netfx.py", line 47, in _get_callable
    raise RuntimeError(
RuntimeError: Failed to resolve Python.Runtime.Loader.Initialize from \app_packages\pythonnet\runtime\Python.Runtime.dll

Hello World-0.0.1.zip

[Deepak6546kumar]

I read that Windows/ARM can emulate x86/64 environment to run traditional apps. So my guess is that HeidiSQL already runs on ARM. But I'm curious:

did you made a test running HeidiSQL? how's the performance? Delphi does not provide a compiler for Windows on ARM yet. Probably this is one of the next features the Embarcadero people invent.

[mhsmith]

I expect the performance penalty for HeidiSQL will be about the same as any other emulated code, but since we haven't tested this, we can't say how bad it would be.

[freakboy3742]

Windows ARM on Github Actions is now in GA, using windows-11-arm runners.

EDIT: This is GA on the free tier.

[mhsmith]

installing the MSI for an app packaged for x86, the app does run on ARM (albeit virtualized):

This has been significantly improved in Windows 11 24H2. Like Rosetta on macOS, it uses just-in-time binary translation, and doesn't require any hardware virtualization support. This means you can run both x86 and x86-64 apps on Parallels on an ARM64 Mac, and I find the performance is perfectly acceptable.

[mhsmith]

However, the zip package logs an error; perhaps unrelated to x86 on ARM since the same thing happens when I try to run the zip on another x86 install...maybe https://github.com/beeware/briefcase/issues/1890 is related... [...] RuntimeError: Failed to resolve Python.Runtime.Loader.Initialize from \app_packages\pythonnet\runtime\Python.Runtime.dll

I'm getting the same error when I try to run a Toga app under Parallels on ARM64 using briefcase dev or briefcase run. Running the .exe from Windows Explorer is the same.

The strange thing is, if I package it as an MSI and install it, then it works fine, both from the Start menu and by opening the .exe directly, even though this should theoretically be the same as briefcase run.

[freakboy3742]

Update: Briefcase now uses WiX 5, so native ARM64 support should now be possible.

[rmartin16]

RuntimeError: Failed to resolve Python.Runtime.Loader.Initialize from \app_packages\pythonnet\runtime\Python.Runtime.dll

I'm getting this error when I try to run a Toga app

For another data point, same for me (with qemu virtualized Windows on arm hardware). MSI install runs, though.

Update: Briefcase now uses WiX 5, so native ARM64 support should now be possible.

(This all may have been implied but... :) ) I believe this was all possible with WiX 3 as well; however, we'll still need an arm64 stub app, updates to visualstudio template, and Briefcase will need to be updated to support running on Windows for arm.

[freakboy3742]

(This all may have been implied but... :) ) I believe this was all possible with WiX 3 as well; however, we'll still need an arm64 stub app, updates to visualstudio template, and Briefcase will need to be updated to support running on Windows for arm.

Agreed that all the other steps also exist.

However, I thought the limitation with WiX 3 was that they didn't provide an ARM64 binary for WiX. I guess that's not an issue if the binary-JIT-conversion approach works (and produces valid ARM64 MSI/binaries), but I'd guess it will be more reliable now that we have access to native WiX ARM64 binaries.

[rmartin16]

However, I thought the limitation with WiX 3 was that they didn't provide an ARM64 binary for WiX.

Ahh, I see. ok. Then, along those lines, I think it would be good to consider support for arm64 builds on x86. The VisualStudio build anyway should provide a "relatively straightforward" path for this. Otherwise, devs would only be able to produce such a build in CI or something.

[freakboy3742]

Agreed that cross-architecture support is definitely something worth investigating, and implementing if it's not too much trouble.

[mhsmith]

I'm getting this error when I try to run a Toga app

For another data point, same for me (with qemu virtualized Windows on arm hardware). MSI install runs, though.

Is this an ARM64 version of Windows running under qemu on Linux?

however, we'll still need an arm64 stub app, updates to visualstudio template, and Briefcase will need to be updated to support running on Windows for arm.

And all of this will need to be tested, and re-tested whenever it changes. So unless we get a lot more demand for native ARM64 support, I'm inclined to avoid it for now and instead depend on the Windows 11 JIT functionality, which seems pretty good. I was able to implement the whole of the WiX 5 upgrade on an ARM64 Mac with Parallels using the x86-64 WiX release, the x86-64 Briefcase stub binary, and the x86-64 Python 3.9 release from python.org.

We just need to work out what's going on with pythonnet. My understanding is that in an x86-64-to-ARM64 JITted process, most Windows APIs will simulate an x86-64 architecture. Maybe pythonnet is bypassing this in some way, detecting the underlying ARM64 architecture, and then refusing to load an x86-64 DLL. But I still don't know why it would make a difference whether it was installed through MSI or not.

[mhsmith]

For completeness, let me also record something I used to misunderstand myself. An MSI is not an executable file – it's a SQL database whose content is interpreted by the msiexec tool on the target machine. However, it does have an architecture indicator, and msiexec will only install an MSI of an architecture which that version of Windows can run. That means that an x86-64 MSI can be installed on an ARM64 Windows which is new enough to have the JIT capability, but an ARM64 MSI cannot be installed on an x86-64 WIndows.

[rmartin16]

Is this an ARM64 version of Windows running under qemu on Linux?

Correct; I'm running tiny11 for arm64 in qemu on a raspberry pi 5.

[...] unless we get a lot more demand [...], I'm inclined to avoid it for now and instead depend on the Windows 11 JIT functionality

Yeah, makes sense for now to me.

[rmartin16]

We just need to work out what's going on with pythonnet. My understanding is that in an x86-64-to-ARM64 JITted process, most Windows APIs will simulate an x86-64 architecture. Maybe pythonnet is bypassing this in some way, detecting the underlying ARM64 architecture, and then refusing to load an x86-64 DLL. But I still don't know why it would make a difference whether it was installed through MSI or not.

This is our old friend "Mark of the Web" (see #1890). Setting Unblock and creating the Hello World.exe.config file got the ZIP working for me.

[mhsmith]

I wasn't using a ZIP, I was running the .exe from the build directory. But I think you might be right, as I do remember seeing the Unblock check box, though I misunderstood it and thought that unchecked meant unblocked.

I don't know why things in the build directory would sometimes get marked as unsafe. And for some reason I can't reproduce the problem now – the .exe in the build directory starts fine, even after re-running briefcase create, and the .exe and .dlls don't even show the unblock checkbox.