From ca543acb140c96cc6912621bf46cf6ec7ea952d4 Mon Sep 17 00:00:00 2001 From: Gary Oberbrunner Date: Mon, 13 Oct 2025 13:36:06 -0400 Subject: [PATCH 1/2] Add Windows ARM64 plugin install locations with rationale Fixes #160, which see. Signed-off-by: Gary Oberbrunner --- .../sources/Reference/ofxPackaging.rst | 50 ++++++++++++++----- release-notes.md | 3 +- 2 files changed, 40 insertions(+), 13 deletions(-) diff --git a/Documentation/sources/Reference/ofxPackaging.rst b/Documentation/sources/Reference/ofxPackaging.rst index 9581662c..a3bfe857 100644 --- a/Documentation/sources/Reference/ofxPackaging.rst +++ b/Documentation/sources/Reference/ofxPackaging.rst @@ -80,8 +80,11 @@ Where... - ``MacOS`` - for Apple Macintosh OS X universal or architecture-specific binaries - ``MacOS-x86-64`` - *DEPRECATED*. Formerly used for Intel Macs during the transition from PowerPC. - - ``Win32`` - for Microsoft Windows (compiled 32 bit) - - ``Win64`` - for Microsoft Windows (compiled 64 bit) + - ``Win32`` - for Microsoft Windows (Intel x86, 32 bit) + - ``Win64`` - for Microsoft Windows (Intel x64, 64 bit) + - ``Win-arm64ec`` - for Microsoft Windows (ARM64EC) + - ``Win-arm64`` - for Microsoft Windows (ARM64) + - ``Win-arm64x`` - for Microsoft Windows (ARM64X) - ``IRIX`` - for SGI IRIX plug-ins (compiled 32 bit) (*DEPRECATED*) - ``IRIX64`` - for SGI IRIX plug-ins (compiled 64 bit) (*DEPRECATED*) - ``Linux-x86`` - for Linux on x86 CPUs (compiled 32 bit) @@ -107,24 +110,47 @@ binaries (since the plug-in .ofx file must always be named to match the top-level bundle name), but it should not be difficult for any plug-in to merge multiple architectures into a single binary on MacOS. +Windows Architectures +^^^^^^^^^^^^^^^^^^^^^ + +As of 2024, Windows supports Arm64 CPUs. It uses two distinct ABIs, +*Arm64* for native code, and *Arm64EC* for x64/Arm64 compatibility, in +which x64 apps running in emulation on Arm64 hardware can interoperate +with x64 DLLs (also in emulation) or Arm64EC DLLs (which are native +Arm64 code with x64-compatible calling conventions). Arm64EC apps +cannot load native Arm64 DLLs, only Intel or Arm64EC. + +Windows also supports an Arm64X "fat" binary PE format which +contains both Intel/Arm64EC and Arm64 binaries. + +Since apps built natively for Arm64 ("Arm64" abi) can only load Arm64 +DLLs, those apps should attempt to load plugins from the "Win-arm64x" +folder first, then "Win-arm64". Arm64EC hosts (running on an Arm64 +system) should try the "Win-arm64x" folder first, then "Win-arm64ec". +Arm64EC hosts can also use x64 DLLs, so they may try "Win64" as well, +but should prefer the other folders to avoid running the plugin in +emulation. An Arm64X host will be running either its Arm64EC branch or +its Arm64 branch depending on how it's launched, so it should load +plugins according to the above depending on the current mode. + +Note that there is no "fat binary" format on Windows that contains +Intel x64 *and* arm64 code. + Future Architecture Compatibility ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NOTE: this section is not yet normative, but informational. -Note that Windows and Linux do not support universal binaries. Each +Note that Linux does not support universal binaries. Each .ofx file is for one architecture, so a host must check the proper -architecture-specific subdir. +architecture-specific subdir. Windows on Arm64 processors is similar. -When Windows and/or Linux support alternative processor architectures +When OpenFX apps on Linux support alternative processor architectures such as arm64, hosts should look in appropriately-named subdirs for -the proper .ofx plugin file. On Windows with arm64, ``Win-arm64`` -should be used (vs. current ``Win32`` and ``Win64`` which are -Intel-specific). On Linux, hosts should look in the subdir named by -``Linux-${uname -m}`` which for arm64 should be ``Linux-aarch64``. -Using ``uname -m`` rather than a hard-coded list allows for -transparently supporting any future architectures. - +the proper .ofx plugin file. On Linux, hosts should look in the subdir +named by ``Linux-${uname -m}`` which for arm64 should be +``Linux-aarch64``. Using ``uname -m`` rather than a hard-coded list +allows for transparently supporting any future architectures. Structure diff --git a/release-notes.md b/release-notes.md index d6a2de84..bd7f1e95 100644 --- a/release-notes.md +++ b/release-notes.md @@ -17,13 +17,14 @@ This is version 1.6 of the OpenFX API. ## Key Features of OpenFX Version 1.6: -## Fixes in OpenFX Version 1.6: +## Fixes ## Deprecations ## Detailed List of Changes - Add `kOfxImageEffectPropNoSpatialAwareness`. Allows the host and plugin to coordinate a render that ensures no spatial changes to the image. +- Add plugin install locations for Windows Arm64 # Release Notes - 1.5 From fc02647447de13cfb2e5731cb0cfcf521a825371 Mon Sep 17 00:00:00 2001 From: Gary Oberbrunner Date: Fri, 9 May 2025 14:39:42 -0400 Subject: [PATCH 2/2] Switch Windows dll dir search order: most-specific first Signed-off-by: Gary Oberbrunner --- .../sources/Reference/ofxPackaging.rst | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Documentation/sources/Reference/ofxPackaging.rst b/Documentation/sources/Reference/ofxPackaging.rst index a3bfe857..e90e6eaf 100644 --- a/Documentation/sources/Reference/ofxPackaging.rst +++ b/Documentation/sources/Reference/ofxPackaging.rst @@ -123,15 +123,16 @@ cannot load native Arm64 DLLs, only Intel or Arm64EC. Windows also supports an Arm64X "fat" binary PE format which contains both Intel/Arm64EC and Arm64 binaries. -Since apps built natively for Arm64 ("Arm64" abi) can only load Arm64 -DLLs, those apps should attempt to load plugins from the "Win-arm64x" -folder first, then "Win-arm64". Arm64EC hosts (running on an Arm64 -system) should try the "Win-arm64x" folder first, then "Win-arm64ec". -Arm64EC hosts can also use x64 DLLs, so they may try "Win64" as well, -but should prefer the other folders to avoid running the plugin in -emulation. An Arm64X host will be running either its Arm64EC branch or -its Arm64 branch depending on how it's launched, so it should load -plugins according to the above depending on the current mode. +**Search Order**: Since apps built natively for Arm64 ("Arm64" abi) +can only load Arm64 DLLs, those apps should attempt to load plugins +from the "Win-arm64" folder first, then "Win-arm64x". Arm64EC hosts +(running on an Arm64 system) should try the "Win-arm64ec" folder +first, then "Win-arm64x". Arm64EC hosts can also use x64 DLLs, so they +may try "Win64" as well, but should prefer the other folders to avoid +running the plugin in emulation. An Arm64X host will be running either +its Arm64EC branch or its Arm64 branch depending on how it's launched, +so it should load plugins according to the above depending on the +current mode. Note that there is no "fat binary" format on Windows that contains Intel x64 *and* arm64 code.