@@ -80,8 +80,11 @@ Where...
8080
8181 - ``MacOS `` - for Apple Macintosh OS X universal or architecture-specific binaries
8282 - ``MacOS-x86-64 `` - *DEPRECATED *. Formerly used for Intel Macs during the transition from PowerPC.
83- - ``Win32 `` - for Microsoft Windows (compiled 32 bit)
84- - ``Win64 `` - for Microsoft Windows (compiled 64 bit)
83+ - ``Win32 `` - for Microsoft Windows (Intel x86, 32 bit)
84+ - ``Win64 `` - for Microsoft Windows (Intel x64, 64 bit)
85+ - ``Win-arm64ec `` - for Microsoft Windows (ARM64EC)
86+ - ``Win-arm64 `` - for Microsoft Windows (ARM64)
87+ - ``Win-arm64x `` - for Microsoft Windows (ARM64X)
8588 - ``IRIX `` - for SGI IRIX plug-ins (compiled 32 bit) (*DEPRECATED *)
8689 - ``IRIX64 `` - for SGI IRIX plug-ins (compiled 64 bit) (*DEPRECATED *)
8790 - ``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
107110top-level bundle name), but it should not be difficult for any plug-in
108111to merge multiple architectures into a single binary on MacOS.
109112
113+ Windows Architectures
114+ ^^^^^^^^^^^^^^^^^^^^^
115+
116+ As of 2024, Windows supports Arm64 CPUs. It uses two distinct ABIs,
117+ *Arm64 * for native code, and *Arm64EC * for x64/Arm64 compatibility, in
118+ which x64 apps running in emulation on Arm64 hardware can interoperate
119+ with x64 DLLs (also in emulation) or Arm64EC DLLs (which are native
120+ Arm64 code with x64-compatible calling conventions). Arm64EC apps
121+ cannot load native Arm64 DLLs, only Intel or Arm64EC.
122+
123+ Windows also supports an Arm64X "fat" binary PE format which
124+ contains both Intel/Arm64EC and Arm64 binaries.
125+
126+ Since apps built natively for Arm64 ("Arm64" abi) can only load Arm64
127+ DLLs, those apps should attempt to load plugins from the "Win-arm64x"
128+ folder first, then "Win-arm64". Arm64EC hosts (running on an Arm64
129+ system) should try the "Win-arm64x" folder first, then "Win-arm64ec".
130+ Arm64EC hosts can also use x64 DLLs, so they may try "Win64" as well,
131+ but should prefer the other folders to avoid running the plugin in
132+ emulation. An Arm64X host will be running either its Arm64EC branch or
133+ its Arm64 branch depending on how it's launched, so it should load
134+ plugins according to the above depending on the current mode.
135+
136+ Note that there is no "fat binary" format on Windows that contains
137+ Intel x64 *and * arm64 code.
138+
110139Future Architecture Compatibility
111140^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
112141
113142NOTE: this section is not yet normative, but informational.
114143
115- Note that Windows and Linux do not support universal binaries. Each
144+ Note that Linux does not support universal binaries. Each
116145.ofx file is for one architecture, so a host must check the proper
117- architecture-specific subdir.
146+ architecture-specific subdir. Windows on Arm64 processors is similar.
118147
119- When Windows and/or Linux support alternative processor architectures
148+ When OpenFX apps on Linux support alternative processor architectures
120149such as arm64, hosts should look in appropriately-named subdirs for
121- the proper .ofx plugin file. On Windows with arm64, ``Win-arm64 ``
122- should be used (vs. current ``Win32 `` and ``Win64 `` which are
123- Intel-specific). On Linux, hosts should look in the subdir named by
124- ``Linux-${uname -m} `` which for arm64 should be ``Linux-aarch64 ``.
125- Using ``uname -m `` rather than a hard-coded list allows for
126- transparently supporting any future architectures.
127-
150+ the proper .ofx plugin file. On Linux, hosts should look in the subdir
151+ named by ``Linux-${uname -m} `` which for arm64 should be
152+ ``Linux-aarch64 ``. Using ``uname -m `` rather than a hard-coded list
153+ allows for transparently supporting any future architectures.
128154
129155
130156Structure
0 commit comments