Wine-NX Switch
Status: experimental — GPU compositor proven on a demo target; full Notepad app still software-rendered and slow.
A native ARM64 Wine port running directly on Nintendo Switch homebrew — no Linux layer, no x86 translation, with real GPU-accelerated rendering.
Wine-NX runs AArch64 Windows PE programs inside a Switch .nro, talking straight to Horizon OS via libnx — no Switchroot L4T, no Box64, no second kernel underneath. Windows GDI content is composited and presented through a real GPU pipeline (deko3d) instead of a linear CPU framebuffer. Two different numbers matter here, and they measure different things: the compositor itself is hardware-confirmed at 60fps in an isolated smoke test (device/ queue/present, real shaders and 3D geometry, no Wine involved); the full Win32 GUI pipeline that feeds it — message loop, GDI drawing, Wine's client/server IPC, all upstream of the compositor — is a separate, still-CPU-bound layer currently at a hardware-confirmed 8fps end to end. See "What's new in this fork" below for both.
Originally started by dantiicu as an early Horizon/libnx Wine bring-up — the loader, initial win32u driver, and NTDLL substrate are his foundation. This fork continues that work.
What's new in this fork
A real GPU compositor (deko3d), hardware-confirmed at 60fps in isolation — device/queue/swapchain, texture upload, shader-driven 3D geometry, replacing the original software framebuffer path. This is the presentation mechanism, proven fast on its own; it's not yet what limits real GDI app framerate today (see the next bullet).
The Vulkan/NVK question, settled with evidence, not assumption — checked directly against the real toolchain: Mesa's NVK driver (the only Vulkan implementation anywhere in that toolchain) depends on Linux's nouveau DRM kernel driver, which Horizon OS doesn't have — Switch homebrew talks to the GPU through Horizon's own nvhost/nvmap IPC instead. NVK specifically can't run here; deko3d is the real, working path.
The same class of performance bug, independently found in six different subsystems — diagnostic logging, syscall tracing, and GDI's own dispatch layer each turned out to unconditionally fflush() to the SD card on every call, silently taxing every app on this port. Fixing all six (plus a provably-safe redundant-IPC-call skip in update_now()) took the software-rendered GDI test target — the actual Win32 message loop feeding the compositor above, not the compositor itself — from 2fps at the start of this investigation to a hardware-confirmed 8fps today, still CPU-bound rather than GPU-bound. These numbers are pulled directly from on-device trace logs, not eyeballed off a screen.
A full host-side development loop — build and test the presentation/ input code on macOS or Linux with zero Switch hardware required.
The GPU compositor above runs against a test/demo target today, not yet the full Notepad app — see "Current Status" below for where the main Notepad milestone stands.
Current Status
As of the latest runtime work, the project can build and stage a Switch NRO runtime that launches Wine PE targets from:
sdmc:/switch/wine
Notepad is the main real-GUI test target right now. It can launch far enough to show the main window, frame, menu bar, menu popups, text rendering, and touch driven menu interaction. It is still experimental and not production usable: responsiveness is poor, presentation is software-heavy, and several real-app subsystems remain incomplete.
https://github.com/devrim-yildiz/wine-nx
Firstly I forked dantiicu's wine-nx project (github.com/dantiicu/wine-nx) which is an early, stalled (I think he stopped coding it) attempt at running Wine directly on Horizon OS via libnx, no Switchroot L4T, no Box64 translation layer. His work laid the real foundation: the loader, the initial win32u driver, the NTDLL substrate.
The biggest milestone was replacing the software rendering path with a native deko3d (alternative to Vulkan) backend. The renderer now creates its own device, queue, swapchain, shaders and texture uploads, reaching 60 FPS the compositor test on real hardware. (The spinning Cube in the Video)
Some interesting findings during development:
Why even do this instead of Linux? The idea is to run Wine natively on HorizonOS instead of an entire Linux userspace and graphics stack. That means lower overhead, direct access to the Switch's native APIs, tighter integration with the system, and ultimately a much cleaner architecture for a native homebrew port.
I'd also really appreciate contributions. If you're interested in Wine internals, libnx, deko3d, or Switch homebrew development, feel free to open a PR or reach out.
(x/twitter: voricabi)
https://www.reddit.com/r/SwitchPira...inenx_first_attempts_on_a_native_wine_answer/
Status: experimental — GPU compositor proven on a demo target; full Notepad app still software-rendered and slow.
A native ARM64 Wine port running directly on Nintendo Switch homebrew — no Linux layer, no x86 translation, with real GPU-accelerated rendering.
Wine-NX runs AArch64 Windows PE programs inside a Switch .nro, talking straight to Horizon OS via libnx — no Switchroot L4T, no Box64, no second kernel underneath. Windows GDI content is composited and presented through a real GPU pipeline (deko3d) instead of a linear CPU framebuffer. Two different numbers matter here, and they measure different things: the compositor itself is hardware-confirmed at 60fps in an isolated smoke test (device/ queue/present, real shaders and 3D geometry, no Wine involved); the full Win32 GUI pipeline that feeds it — message loop, GDI drawing, Wine's client/server IPC, all upstream of the compositor — is a separate, still-CPU-bound layer currently at a hardware-confirmed 8fps end to end. See "What's new in this fork" below for both.
Originally started by dantiicu as an early Horizon/libnx Wine bring-up — the loader, initial win32u driver, and NTDLL substrate are his foundation. This fork continues that work.
What's new in this fork
A real GPU compositor (deko3d), hardware-confirmed at 60fps in isolation — device/queue/swapchain, texture upload, shader-driven 3D geometry, replacing the original software framebuffer path. This is the presentation mechanism, proven fast on its own; it's not yet what limits real GDI app framerate today (see the next bullet).
The Vulkan/NVK question, settled with evidence, not assumption — checked directly against the real toolchain: Mesa's NVK driver (the only Vulkan implementation anywhere in that toolchain) depends on Linux's nouveau DRM kernel driver, which Horizon OS doesn't have — Switch homebrew talks to the GPU through Horizon's own nvhost/nvmap IPC instead. NVK specifically can't run here; deko3d is the real, working path.
The same class of performance bug, independently found in six different subsystems — diagnostic logging, syscall tracing, and GDI's own dispatch layer each turned out to unconditionally fflush() to the SD card on every call, silently taxing every app on this port. Fixing all six (plus a provably-safe redundant-IPC-call skip in update_now()) took the software-rendered GDI test target — the actual Win32 message loop feeding the compositor above, not the compositor itself — from 2fps at the start of this investigation to a hardware-confirmed 8fps today, still CPU-bound rather than GPU-bound. These numbers are pulled directly from on-device trace logs, not eyeballed off a screen.
A full host-side development loop — build and test the presentation/ input code on macOS or Linux with zero Switch hardware required.
The GPU compositor above runs against a test/demo target today, not yet the full Notepad app — see "Current Status" below for where the main Notepad milestone stands.
Current Status
As of the latest runtime work, the project can build and stage a Switch NRO runtime that launches Wine PE targets from:
sdmc:/switch/wine
Notepad is the main real-GUI test target right now. It can launch far enough to show the main window, frame, menu bar, menu popups, text rendering, and touch driven menu interaction. It is still experimental and not production usable: responsiveness is poor, presentation is software-heavy, and several real-app subsystems remain incomplete.
https://github.com/devrim-yildiz/wine-nx
Firstly I forked dantiicu's wine-nx project (github.com/dantiicu/wine-nx) which is an early, stalled (I think he stopped coding it) attempt at running Wine directly on Horizon OS via libnx, no Switchroot L4T, no Box64 translation layer. His work laid the real foundation: the loader, the initial win32u driver, the NTDLL substrate.
The biggest milestone was replacing the software rendering path with a native deko3d (alternative to Vulkan) backend. The renderer now creates its own device, queue, swapchain, shaders and texture uploads, reaching 60 FPS the compositor test on real hardware. (The spinning Cube in the Video)
Some interesting findings during development:
-
deko3d cannot coexist with libnx's default framebuffer console. The console claims the display during startup, so Wine has to own the display exclusively (similar to Borealis).
-
The GUI renderer initially ran at ~2 FPS. Most of that turned out to be diagnostic logging (fflush()after every trace written to the SD card), not GPU performance.
-
After fixing the logging overhead and removing a redundant IPC call, the Win32/GDI demo now runs at ~7–9 FPS. At this point it's clearly CPU/IPC-bound rather than GPU-bound.
Why even do this instead of Linux? The idea is to run Wine natively on HorizonOS instead of an entire Linux userspace and graphics stack. That means lower overhead, direct access to the Switch's native APIs, tighter integration with the system, and ultimately a much cleaner architecture for a native homebrew port.
I'd also really appreciate contributions. If you're interested in Wine internals, libnx, deko3d, or Switch homebrew development, feel free to open a PR or reach out.
(x/twitter: voricabi)
https://www.reddit.com/r/SwitchPira...inenx_first_attempts_on_a_native_wine_answer/
