Add ARM64EC as an available Windows architecture

[zsliu98]

Given the current status of Windows on ARM, perhaps we should distinguish between ARM64 format and ARM64EC format.

[kmturley]

Not familiar with this architecture type. Google summary:

ARM64 is the standard 64-bit ARM architecture, while ARM64EC (Emulation Compatible) is a special Windows ABI (Application Binary Interface) that runs ARM64 code at native speed but also allows seamless, direct interoperability with emulated x64 code on Windows 11 on ARM, using the same underlying instruction set but differing call conventions (like x64 register usage) for compatibility, enabling incremental porting of apps. Classic ARM64 code is incompatible with x64, requiring separate binaries, whereas ARM64EC blends them within the same process, making it easier to transition existing x64 apps to ARM.

ARM64EC is not the same as a Mac Universal Binary, but they both aim to help applications run across different architectures, with Universal Binaries bundling separate native ARM and x64 code in one file (either/or), while ARM64EC (Emulation Compatible) allows mixing native ARM and emulated x64 code within the same process on Windows 11 for ARM, using a special ABI to call emulated code seamlessly. Think Universal Binary as one fat file for native Intel or ARM, whereas ARM64EC lets an ARM app call x64 code directly.

ARM64EC is specifically designed to run on ARM-based systems (like Windows on ARM), allowing native ARM performance while interoperating with emulated x64 code; it doesn't run on an x64 (Intel/AMD) system, but rather, it helps ARM systems run your x64 apps better by letting you gradually port parts of them to native ARM64EC code, with the OS handling the x64 emulation for the rest.

If I read this correctly, couldn't the binary be tagged as arm64 in the registry? Users don't need to know whether a binary is running emulated code or native arm64 code?

[zsliu98]

The biggest problem is:

Without bridging or out-of-process hosting, ARM64EC hosts cannot load ARM64 plugins, and ARM64 hosts cannot load ARM64EC plugins.

Unfortunately, those major DAWs do choose different formats here. AFAICK, Reaper & Cubase choose ARM64EC while Fender Studio Pro & Bitwig choose ARM64 (Bitwig can host plugins out-of-process so it is not a problem here).

The situation is quite confusing for users & developers :(

[kmturley]

Options

A) Add Support for arm64ec and arm64x
ARM64EC (Emulation Compatible) is specifically designed for the scenario where a native host (like a DAW) needs to load legacy x64 plugins.  Add arm64ec: This allows you to tag plugins that are specifically recompiled to work in the "Emulation Compatible" ABI, which is the current bridge for Windows 11. Encourage arm64x: This is a "fat" binary that contains both arm64 and arm64ec code.

• Pros: It mirrors what major DAWs like Steinberg Cubase/Nuendo and Cockos REAPER are doing. By supporting this architecture value, your registry remains relevant to the majority of Windows 11 Arm users who still rely on x64 VSTs.

• Cons: It is a Windows 11-only feature. However, since Windows 10 on Arm is essentially deprecated and lacks the performance of the newer Prism emulator, targeting Windows 11 is the only viable path for pro audio.  

B) Support Native arm64 Only

• Pros: This is the "clean" future. It avoids the overhead of the Prism emulation layer and ensures maximum stability and battery efficiency.

• Cons: You would exclude a massive "long tail" of plugins. Many high-end plugins (especially those requiring iLok, which has had a slow transition to Arm) would be invisible to users of your registry, making the project feel "empty" for new Copilot+ PC owners.

The transition period in pro audio is notoriously long (look at how long VST2 lasted). Supporting arm64ec now provides immediate value to Windows 11 users without preventing a move to pure arm64 later.

@DropSnorz I would like your input, whether we should add support for arm64ec and arm64x architectures. As they will need to be handled in StudioRack and OwlPlug if we open this door.

[DropSnorz]

Supporting arm64ec / arm64x would be great. Even if it's a transitve thing, it might stay for some time. Here are my toughts and how i would handle the problem based on my understanding.

OwlPlug and terminology

In OwlPlug, Platforms are identified as a tuple(operating system, architecture), in a similar way as it's designed in the open-audio-stack registry with systems and architectures metadata.

The difference is that operating system and arch are coupled.

A package in OAS registry can be defined as :

{
    "systems" : ["windows"],
    "architectures" : ["x64", "arm64"],
}

This get translated in OwlPlug as Platforms:

{
    "platforms" : ["win-x64", "win-arm64"]
}

The Host / User platform

This is the end-user platform. Usually, Managers (like OwlPlug or StudioRack) can detect the underlying platform, but they are cases where it's not in sync with user DAW:

• Running an x64 Manager on an macos arm64 M1 chip under Rosetta emulationn but using a native arm64 DAW.
  • Manager detects (macos, x64)
  • User requires (macos, arm64)
• Running an arm64 manager + Using an arm64ec DAW that can load only x64 plugins.
  • Manager detects (windows, arm64)
  • User requires (windows, arm64ec)
• ...

Anyway, this is not a major problem, we can let the user choose it's desired platform and not rely on the computed one for filtering and compatibility display.

Package Declared platform

It's a declarative data provided at distribution time that should describe best the package capabilities. A package has one or more declared platform. A multi-arch / bundle package, containing different native binaries could define.

This is fully part of OAS specifiction with Package.systems and Package.architectures field.

Compatible platforms

This is a metadata inferred by Managers based on a set of rules. Depending on Managers needs and queries, relations can be hold by Package or Host entity.

On User Host (windows, x64), we can load packages compiled for (windows, x86)

Host (windows, x64) ----- can load ---> Package(windows, x86)

A (windows, x86) package can be executed on a (windows, x64) Host.

Package(windows, x86) ---- is compatible -----> Host (windows, x64)

Of course every platform have a host/package mirror rule:

Host (windows, x64) ----- can load ---> Package(windows, x64)

Platform aliases

This is equivalent platforms, such as x64 and amd64.

arm64x

As I understand arm64x bundles can contains :

• arm64 native slices
• x64 native slices
• arm64ec native slices

No strong guarrantee to always have arm64ec or arm64 or x64 executable slices packaged inside.
So i'm not sure we can infer compatible platforms just from the arm64x flag in metadata.

I would not add arm64x as arch in Package metadata. It's a packaging detail, but not a promise regarding effective capabilities.

arm64ec

I would add arm64ec as a new value for Open Audio Stack Package.architectures[] array.

To me, if a Package (archive, or installer) contains an arm64x bundle, we should define multiple Declared Platforms based on capabilities and natives slices provided:

• arm64
• arm64ec
• x64

Then, the only 2 compatibility rules we can infer are:

Host (windows, arm64ec) ----- can load ---> Package(windows, x64)
Host (windows, arm64ec) ----- can load ---> Package(windows, arm64ec)

If we go that way, maybe we will have to clarify few things in Managers spec:

• How Managers can detect the Runtime Platform by default, but let the Users change it for a Desired Platform
• How Managers filter compatible Packages for a Runtime or Desired Platform by executing rules and by adding these rules in the base specification.

[kmturley]

Thanks for your detailed write-up, very good insights. Summary:

If DAW is...	Can load x64 Plugin?	Can load ARM64EC Plugin?	Can load ARM64 Plugin?
x64 (Emulated)	✅ Yes	✅ Yes	❌ No
ARM64EC (Native/Hybrid)	✅ Yes	✅ Yes	❌ No
ARM64 (Pure Native)	❌ No	❌ No	✅ Yes

Which means we have to have x64, arm64 and arm64ec architectures supported in the Registry.

Regarding Manager logic:

If Plugin Manager is native ARM64, but DAW is emulated x64, installing a native ARM64 plugin will result in the DAW failing to see or load the plugin. The compatibility rules depend entirely on the Host (DAW).
Plugin Manager cannot always rely on the system's "Runtime Platform" (which would be ARM64 for a native app) because the user's DAW might be running in a different mode.
the best practice is to allow users to manually set a Desired Platform.

Which means we update the documentation and Managers to support Desired Platform, which defaults to current architecture/OS but can be overridden.

I will draft up the changes!