Reply to thread

Message: [QUOTE="Shamiso, post: 92436, member: 160"] Windows 11 on Arm can run both x86 and x64 desktop apps through Prism, but drivers still need native Arm64 builds. The split is worth understanding before treating the ASUS Ascent QN10 like a normal Intel or AMD mini PC. The [B][URL='https://goldmidi.com/community/threads/asus-reveals-ascent-qn10-with-snapdragon-x2-elite.77761/']ASUS Ascent QN10 Windows on Arm platform[/URL][/B] ships with Windows 11 for ARM64, so your usual Windows software is not automatically locked out. Everyday apps have become the easy part. Trouble tends to show up lower in the stack, where an old installer, driver, plug-in, security service, or hardware utility expects x86 Windows all the way down. [HEADING=2]Prism has closed the obvious app gap[/HEADING] Prism translates x86 and x64 user-mode code for Arm64 systems, and Windows 11 24H2 and newer can expose instruction support including AVX and AVX2 to emulated apps. A lot of older software that once failed on Windows on Arm can now simply install and run. Native Arm64 builds are still cleaner and usually more efficient, but emulation is no longer an automatic red flag. The engineering behind Prism sits in the same family of problems explored by [B][URL='https://arxiv.org/abs/2605.08419']cross-architecture binary translation[/URL][/B], where x86-64 code is converted for AArch64 execution. Translation adds work, even when the user barely notices it. Heavy apps, real-time workloads, and software doing unusual low-level tricks can expose the overhead far sooner than a browser or office app. Prism also has per-app compatibility settings when an emulated program behaves badly. Windows can hide newer CPU features or restore older emulation behavior for troublesome software, although those switches can cost performance or make an app less stable. Useful escape hatch. Not a magic compatibility button. [HEADING=2]Drivers remain the hard compatibility wall[/HEADING] Emulation only covers user-mode application code. Kernel-mode drivers need Arm64 versions, and this is where a perfectly ordinary-looking Windows program can still fail. The executable may launch under Prism while the driver it depends on still fails to load. Audio interfaces are a clean example. A DAW can run, the plug-in installer can complete, and the desktop can look completely normal, yet an interface still needs a Windows on Arm driver if its normal operation depends on one. The same limitation reaches printers, scanners, security software, VPN components, anti-cheat systems, capture hardware, USB tools, and other software that talks closely to Windows. Compatibility therefore belongs to the whole setup, not just the app name. Current Focusrite USB audio drivers support Windows on Arm, for example, while parts of the software bundled with those interfaces still vary between compatible and unsupported. Hardware compatibility does not guarantee compatibility for every bundled app or plug-in. Old peripherals deserve the most suspicion. A manufacturer can keep an x64 utility alive for years because Prism handles the executable, yet never rebuild the driver underneath it. No amount of CPU performance from Snapdragon X2 Elite fixes a driver the operating system cannot load. [HEADING=2]Plug-ins can break an otherwise working setup[/HEADING] Creative software adds another wrinkle because one application can load code from dozens of other companies. Windows supports Arm64EC, an architecture designed so native Arm code can coexist with x64 code inside a compatible process. Software built this way can keep large parts native while still loading certain older x64 components through emulation. Cubase and Nuendo use this route on Windows on Arm. Their current Arm versions can load many x86-64 VST3 plug-ins because the host uses Arm64EC, while VST2 is not supported there. Another native Arm64 host may have different rules because a standard Arm64 process cannot simply load an x64 plug-in. So “the DAW works on Arm” is only the first check. Your interface driver, plug-in architecture, copy-protection layer, control software, MIDI utilities, and any background service can each make a separate compatibility decision. Producers with ten plug-ins may sail through. Someone opening a fifteen-year-old project full of abandoned effects can have a very different night. The same logic applies outside music. A business app can run perfectly until it calls an old print driver, VPN filter, scanner package, or shell extension. Prism makes the visible executable surprisingly forgiving, while the invisible dependencies remain much stricter. Driver-bound software exposes the remaining boundary most clearly on the QN10. User-mode x86 and x64 programs can use Prism, Arm64EC can keep some mixed-code workflows alive, and native Arm64 takes the direct path. Software that installs a driver or injects code into another process sits outside the easy case, because Windows cannot simply translate those pieces around the way it does a regular desktop executable. [/QUOTE]

Name