Not a Wine fork. Weave reimplements the Windows API in Rust.
Memory safe with default sandboxing and a clean architecture
that doesn't carry 30 years of C legacy.
Weave is a reference-first implementation of the Windows API for Linux. When a Windows binary calls kernel32.dll or ntdll.dll, Weave intercepts those calls and translates them to native Linux syscalls, written entirely in Rust, with no shared code with Wine. The result is a compatibility layer that speaks the same language as Windows applications without inheriting the weight of a legacy codebase. The Weave compatibility engine is distro-agnostic infrastructure, any Linux distribution can integrate it.
Wine works, and for most people it's the right answer today. Weave exists because Wine carries 30 years of accumulated C: memory unsafety, no isolation model, and architectural decisions made before modern Linux primitives existed. Weave's current codebase is roughly 5–10% the size of Wine's: a smaller, sharper surface that's easier to audit, easier to reason about, and far easier to sandbox correctly. That's not a limitation; it's the point.
Wine was the right architecture for 1993: the only way to get Windows apps running on Linux was a monolithic C codebase that did everything itself. Thirty years later, the host has caught up. Linux now has Rust for memory safety, Landlock for filesystem isolation, Vulkan for graphics, and PipeWire for audio. These are mature primitives Wine predates by decades. A from-scratch rebuild isn't a rewrite of Wine; it's a new architecture that delegates to modern host capabilities instead of reimplementing them. The same constraints that forced Wine's design no longer exist.
Weave Native: Pure Rust API translation. Every Windows call is mapped to native Linux syscalls, with graphics routed through DXVK/VKD3D over the host Vulkan stack. Weave Sandbox: Always active underneath. Landlock filesystem isolation is enforced before guest code executes, while the guest runs in a forked child process under a seccomp-BPF syscall filter and reaches host-side Win32 implementations through IPC over Unix domain sockets. The default sandbox path is proven for CLI and file-I/O workloads; GUI window creation and painting remain under active validation. There is no trade-off between compatibility and isolation.
Wine can't sandbox. The architecture doesn't allow it without breaking compatibility. Weave was designed with isolation as a requirement from day one. Before guest code executes, Weave applies Landlock rules that confine filesystem access. The guest then runs out-of-process in a forked child, where seccomp-BPF restricts the syscall surface and IPC proxies Win32 calls to the host runtime. A crash or memory corruption in the Windows app cannot directly reach host state. The default path is proven for CLI and file-I/O workloads; GUI window creation and painting remain under active validation. The difference is "running untrusted Windows binaries with structural containment" versus hoping nothing goes wrong.
Pre-alpha, actively progressing. The PE loader, ntdll gateway, and syscall dispatcher run real applications. The current gauge records 2,506 registered exports and 214 milestone-qualified implementations, with 8.5% unweighted and 55.3% milestone-weighted coverage. That is API implementation coverage, not application compatibility. Eight applications have validated workflows; Audacity, SumatraPDF, curl HTTPS, Electron targets, and parts of the preservation pipeline remain in progress or not yet validated. See the canonical status registry for the dated source of truth.
Windows has hundreds of thousands of applications. The goal isn't to test them one by one; it's to implement the API surface completely enough that the long tail runs without special-casing. Most apps that fail today fail for the same handful of missing calls. Fix those, and hundreds more start working at once. That's the leverage: each implemented function opens dozens of apps.
Windows API calls cross an isolated guest boundary into Rust translation crates,
then reach Linux host primitives through a typed IPC path.
The default sandbox path is proven for CLI and file-I/O workloads.
GUI window creation and painting remain under active validation; per-app network isolation remains on the roadmap.
Weave's growing foundation includes 2,506 resolver exports and 214 milestone-qualified implementations.
The table below shows the applications and capabilities currently being brought to Linux.
| Application | Category | Capability | Key Surface |
|---|---|---|---|
| 7-Zip | Supported | GUI extract + CLI round-trip byte-identical. M14 closed CI-green. Real-desktop validated. | kernel32 · shell32 · comctl32 |
| IrfanView | Supported | BMP/JPEG/PNG/GIF open, Save As PNG, folder nav. 7 CI-green milestones. Real-desktop validated. | gdi32 · gdiplus · kernel32 |
| Notepad++ | Supported | Syntax highlighting, editor save/reopen byte-match, plugin folder honored. Real-desktop validated. | Scintilla · comctl32 · gdi32 |
| PuTTY / Plink | Supported | SSH terminal + CLI: TCP connect, key exchange, remote exec, ExtTextOutW text rendering. All CI-green. | ws2_32 · kernel32 · gdi32 |
| wget | Supported | Plain HTTP GET to example.com, exit 0, stdout verified. Full Winsock stack exercised. | ws2_32 · kernel32 |
| curl | Supported | IAT resolution is proven. HTTPS download has not yet been validated end to end. | ws2_32 · crypt32 · secur32 |
| SciTE | Supported | Scintilla editor, Lua re-export EXE edge case, GDI text rendering, non-black pixels verified. | Scintilla · gdi32 · kernel32 |
| D3D9 via DXVK | Supported | D3D9→DXVK→Vulkan pipeline proven on NXEngine and testsprite2. M9 CLOSED CI-green. | D3D9 · DXVK · Vulkan |
| NXEngine-evo (Cave Story) | Supported | Full game via software + D3D9/DXVK paths and keyboard input. Audio validation is tracked separately. | SDL2 · D3D9 · DXVK · Vulkan |
| SDL2 testsuite (testsprite2) | Supported | Animated sprites in X11 window via SDL2 (software + D3D9). Pixel-check verified, 15s runtime. | SDL2 · X11 · kernel32 |
| Q-Dir | In Progress | Launches and populates the file pane; 541 IAT imports resolve. Broader file-manager workflows and drag-drop remain. | shell32 · comctl32 · kernel32 |
| SumatraPDF | In Progress | PDF rendering work remains under investigation. | GDI+ · GDI32 · COM |
| Audacity | In Progress | PipeWire audio infrastructure is proven. Application integration work continues. | ucrt · msvcp140 · kernel32 |
| SPSS Statistics | Partial | Launcher startup is validated. Full GUI/JVM integration is future work; 437 imports include the mfc140u surface. | mfc140u · kernel32 · comctl32 |
| DirectX 11 / 12 | Planned | D3D12 crate scaffolded. D3D11 via DXVK path exists but unvalidated. No active milestone. | D3D11 · D3D12 · DXVK · Vulkan |
| OBS Studio | Planned | Needs D3D11/DXVK, screen capture, audio, encoder pipeline. No work started. | D3D11 · DXVK · mmdevapi |
| Signal Desktop | Planned | Electron app. Decision: host in Weave. Requires named pipes, WinHTTP, DirectWrite, and child PE bootstrap work. | Electron · WinHTTP · DirectWrite |
| Obsidian | Planned | Electron app. Inherits Signal's blockers. Proprietary. Fixture OK, not bundleable. | Electron · Chromium · kernel32 |
| Git for Windows | Planned | CRT depth, MSVC runtime, async DNS resolution needed. No active milestone. | msvcrt · ws2_32 · kernel32 |
| Firefox (Win32) | Planned | Requires Electron/Chromium precedent. NSS, libuv depth not scoped. | NSS · ntdll · ws2_32 |
| Adobe Acrobat Pro | Planned | PDF redaction, OCR, forms, JavaScript. Heavy COM/OLE cliff. | COM · GDI+ · kernel32 |
| R + RStudio | Planned | Statistical computing, CRAN binaries, R kernel. Not scoped. | kernel32 · CRAN · gdi32 |
| PyCharm | Planned | Python IDE, remote interpreters, Jupyter. Java-based, relies on JVM Win32 surface. | Java · kernel32 · ws2_32 |
| Zotero | Planned | Reference manager, browser plugin, file watching, PDF annotation. Electron-based. | Electron · kernel32 · ws2_32 |
| Toggl Desktop | Planned | Time tracking, system tray, one-click timer, offline sync. | kernel32 · ws2_32 · shell32 |