Weave Weave

A Windows compatibility layer.
Built in Rust. From scratch.

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.

214 milestone-qualified functions 2,506 registered exports 8 validated applications
🦀 100% Rust core
🔒 Sandboxed by default
🧩 Modular DLL crates
🏗️ x86_64 + ARM64
📜 GPL-3.0 licensed

Technical brief

What Weave is

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.

Why not just use Wine

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.

Why now, not 1993

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.

Two-layer execution model

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.

Sandboxing by default

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.

Current state

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.

The long tail

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.

How Weave works

Windows API calls cross an isolated guest boundary into Rust translation crates,
then reach Linux host primitives through a typed IPC path.

Weave runtime architecture A Windows application runs in an isolated guest process. Windows API calls cross an IPC boundary into modular Rust DLL crates, which translate them to Linux host primitives including syscalls, PipeWire, xcb or Wayland, and Vulkan. GUEST SANDBOX isolated process boundary Windows app PE binary / guest code PE loader IAT resolution + ABI setup guest process starts here Landlock + seccomp filesystem and syscall limits IPC boundary Unix domain socket typed call messages guest cannot call host APIs directly dispatches LINUX HOST stable primitives do the heavy lifting Modular Rust DLL crates kernel32 · user32 · gdi32 · ws2_32 · shell32 · ntdll · ... narrow translation functions Linux syscalls files · memory · IPC Host services PipeWire · xcb · Vulkan network isolation: roadmap translates
Weave runtime architecture A compact vertical view of Weave: a Windows app enters the guest sandbox, API calls cross IPC to Rust DLL crates, then reach Linux host services. Windows app PE binary / guest code GUEST SANDBOX isolated process boundary PE loader IAT resolution + ABI setup Landlock + seccomp IPC boundary Unix socket · typed call messages LINUX HOST stable primitives do the heavy lifting Modular Rust DLL crates kernel32 · user32 · gdi32 · ws2_32 · ... Linux syscalls files · memory · IPC Host services PipeWire · xcb · Vulkan

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.

What runs. What's next.

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
More coming soon.