/
OpenFX on Windows on ARM64: architecture and build notes (WIP)

OpenFX on Windows on ARM64: architecture and build notes (WIP)

Owned by Gary Oberbrunner
Last updated: Mar 02, 2025
5 min read

Here are some initial notes on ARM64 architecture variants with an eye to how to support them in OpenFX. This page is currently very much WIP; please comment if you have any info!

Resources:

  • Here's an “ARM64 boot camp” deep dive -- I had to read that twice.

  • Another good explanation of the arm64x PE format and how it's used is here, from Microsoft

Notes:

  • ARM64EC is an alternate ABI (application binary interface, i.e. a calling convention) for ARM64 which provides interoperability with non-native binaries (a.k.a "foreign binaries") compiled for 64-bit x64.

  • ARM64EC-built code is compiled in a way to make it is "Emulation Compatible", thus the name ARM64EC.  ARM64EC code can easily call emulated x64 code, and vice versa – all the heavy lifting is done seamlessly by the compiler, linker, C runtimes, and the OS. Native ARM64 code runs natively, at full speed, and x64 code is emulated. The ABI is based on x64, so existing x64 functions (running under emulation) don’t have to know anything about what’s calling them or what they’re calling. For instance, an emulated x64 app which calls into the C runtime or other Windows DLLs doesn’t know that those DLLs are all ARM64EC. The call is done with x64 conventions (stack, registers etc.) but then in the called DLL it switches to arm64-native. Arm64EC builds can also link in both x64 and Arm64EC libs. This way, you can build an ARM64EC app that is partly x64 and partly native, so it enables incremental conversion. The PE file format doesn’t change for ARM64EC; it’s just the x64 PE format but with some different code chunks.

    • Use link /dump /headers to check how an exe or dll is built. If you see 8664 machine (x64) (ARM64X) then it’s ARM64EC (or ARM64X). If you see (ARM64) and (ARM64X), then it’s Arm64X.

  • ARM64X is an ARM64 eXtension to the standard Windows PE (portable executable) file format allowing ARM64 code (pure-native non-x64-compatible ARM64) and ARM64EC (which can contain Intel x64 and/or ARM64EC) to interoperate with each other within the same binary - differentiating it from the "either-or" approach of a fat binary.  This is called a hybrid binary.  ARM64X format is backward compatible with older OSes such as Windows 10 for ARM and older debuggers and development tools, although the interoperability extensions will be ignored and only the ARM64 codebytes will be exposed. (Nobody really cares about this pure ARM64 interface anymore, I think – garyo)

    • Note: ARM64X is not a “universal binary” containing x64 and arm64! I don’t think an ARM64X binary will load properly on an x64 system.

  • Almost every 64-bit binary that ships in Windows 11 on ARM is built as ARM64X, allowing them to be used by both classic ARM64 applications and emulated x64 applications.

  • ARM64EC is plain Arm64 code, but with a specific ABI that enables calling to/from "foreign" (x64) code.

  • ARM64X is a hybrid binary containing ARM64 code and emulated x64 to interop within the same binary. Microsoft says ARM64X contains "both the classic Arm64 and Arm64EC code together." So this makes me think it wouldn't work on Intel. It does run on both Win11/arm and Win10/arm though. "This makes it ... a particularly good fit for middleware or plugins that may be used by both APIs."

    • But if the main EXE is arm64x, would a "plain arm64" binary work? I'd think so because it would be tagged as arm64 so would be called from the host properly. But it does appear to, with Resolve.

  • What I gather from the Microsoft doc is when an emulated x64 app is running and loads an arm64x DLL, it sees it as an x64 DLL; the entry points are x64-compatible. Then internally the DLL switches to running native arm64 (or ARM64EC?) code. But a native arm64 app (or arm64x running in native mode?) sees it as an arm64 DLL and just calls straight into the arm64 entry points.

  • The Microsoft doc says most apps won't be built as arm64x, because it's mostly useful for DLLs. Most apps will either be Arm64EC or Arm64. But the other doc contradicts that.

  • You can start a process either way using start /machine arm64 Resolve.exe (have to cd to the exe location first).

    • But Resolve won’t start with /machine arm64, only with /machine amd64. What does that mean? Maybe it’s running in emulation mode? Or maybe it just means it’s not “Classic ARM64”?

  • Classic x86 OpenFX plugins do run when loaded by DaVinci Resolve built for and running on ARM64 (when started from the start menu). This may make it more difficult to test whether a plugin is really built correctly!

  • I believe Resolve is ARM64X or maybe ARM64EC because Its PE signature looks like:

    • % dumpbin -headers "C:\Program Files\Blackmagic Design\DaVinci Resolve\Resolve.exe" File Type: EXECUTABLE IMAGE FILE HEADER VALUES 8664 machine (x64) (ARM64X)

    • 8664 is AMD64 (=x64). So is it really ARM? Task Manager reports for the running Resolve process "Arm64 (x64 compatible)" so clearly it is. The deep-dive doc says "it is legal to mark an ARM64X binary as either AA64 (Arm64) or 8664 (AMD64/x64). That determines how it is launched by default.”

  • and link -dump -loadconfig <path-to-Resolve> shows Arm64X hybrid metadata records, and mostly arm64ec code (210MB) and x64 (21MB of x64):

    • Hybrid Code Address Range Table Address Range ---------------------- arm64 0000000140001000 - 000000014000169B (00001000 - 0000169B) arm64ec 0000000140002000 - 000000014C91092B (00002000 - 0C91092B) x64 000000014C911000 - 000000014DD207AF (0C911000 - 0DD207AF)

Recommendations

  • I think no hosts are going to build as straight native ARM64. They will all build as ARM64EC most likely. This means plugins can/should be ARM64EC as well. ARM64X is safest since it could be loaded by a native ARM64 host.

  • Use the instructions here (Microsoft doc) to build ARM64 binaries. If you want to build ARM64X, you have to build twice: once as ARM64, then as ARM64EC which picks up the previous ARM64 entry points.

    • If you just want to build ARM64EC, which I think will be a good way to go, use these instructions (also Microsoft). Basically you just add /arm64EC to the compile flags.

  • A single DLL can’t run natively on both x64 and arm64 systems, as far as I can tell. Probably the best way to handle this is to make an x64 DLL the main one, then detect the architecture and forward calls to the arm64ec DLL when running on arm64. I have not tried this.

Related content