Sanely adding value to Wine, leveraging Rust.

A G’spritzter is wine cut with soda — same wine, just easier to get along with. SpritzWine is that, for the other Wine: take the Wine your games already run on, mix in Rust exactly where the C has been quietly ruining afternoons — parsers, descriptors, unwinders — and leave the rest in peace.

This is the superproject — where the Wine fork and the Rust workspace are developed together. Not what you install to play a game: that is Prater.

The approach Source on Codeberg The gate: does the game boot?

The approach

Think big, act small.

The ambition is real: Wine is a thirty-year-old C codebase, and large parts of it are exactly the kind of code that benefits from stronger guarantees — parsing untrusted bytes, walking descriptors, unwinding stacks. There is value on the table.

The method is deliberately unambitious. Start where it brings real value in safety, performance or correctness — one subsystem at a time, each one shipped and proven on real games. A subsystem is not converted until it is pure; it is converted until the remaining C has stopped being a problem. Then you leave, and go find the next place where the bugs actually live.

Nobody upstream asked for any of this, and nobody’s inbox is being campaigned at. The code sits here — LGPL, working, played on — and if a piece proves itself and somebody wants it, it’s theirs. Demonstrating beats lobbying.

Rust is a means, not the goal. This is not “rewrite Wine in Rust.” Nobody needs that, and nobody would finish it. Rust goes where C is genuinely hurting.

Prove it where it hurts. The destination is upstream Wine. But the proving ground is Valve’s tree — the only one anti-tamper titles boot on — so that is what ships first.

Games are the test suite. Wine’s conformance tests are necessary and not sufficient. The gate is a game booting, not a suite passing.

Under the hood

Soda in, spritzer out.

The Rust code lives outside the Wine tree. Wine’s configure.ac finds the crates via $SPRITZWINE_RUST_DIR; the Wine fork carries only build glue and the C-side bridges. That split is the load-bearing one.

The fork itself is generated, not hand-maintained: the changes are authored once as thematic soda-* tiers and replayed onto a stable Wine base to produce a consumer branch. Where the two disagree, the base wins. The fork is designed to be peeled off.

One syrup, two glasses — and since spritzwine-11.13-3, both of them poured. spritzvalve is what makes it provable — Valve's tree is the only one anti-tamper titles boot on, and a game booting is this project's real test suite. So the vehicle shipped first. spritzwine is the point, and it now exists: the full mix on upstream Wine, tagged and pinned. The long version →

What ships today

The current pour.

Not everything written is wired in — the tier decides what lands in a consumer, and there are two pinned glasses now. The one Prater is built from (spritzvalve-11.0-3 = build + core + branding, on Valve's tree) links Rust into these:

In the glass Prater pours from
Module	What’s in Rust
`hidparse.sys`	the HID report-descriptor parser — a driver, kernel-pool backed
`hid.dll`	the `HidP_*` value engine — extracting fields out of report buffers
`avrt.dll`	MMCSS — thread scheduling classes
`comdlg32.dll`	the file chooser, via the XDG desktop portal — WoW64-thunked, so 32- and 64-bit apps both get it

Two of those four are literally “parse a byte blob a USB device handed you and index into it,” and a third is a protocol client. That is not a coincidence — it is where you land when the goal is fewer bugs, not more Rust.

The threadpool, the SEH unwinder, LZNT1 compression, battery reporting and DualSense rumble are no longer workshop pieces: in spritzwine-11.13-3 — the upstream consumer the superproject now pins — ntdll and winebus.sys link Rust too, six DLLs in all, with Valve’s futex in-process sync vendored in via soda-fsync. The boot gate doesn’t judge that glass — spritzwine isn’t for games. Its proof is ordinary Windows software, and it holds: as a Bottles runner it runs everyday programs cleanly. The games’ gate stays on the Valve base, which is why Prater pours the thin mix.

grep -l lwine_ dlls/*/Makefile.in in the wine tree answers this question for whatever you have checked out. Trust that over this table.

The house toast

„Man bringe den Spritzwein!“

— Michael Häupl, Mayor & Governor of Vienna (1994–2018). Take the work seriously, take yourself a good deal less so, and there is always time for a G’spritzter.

Which glass do you want

Pour it yourself.

To play games Prater — the Proton distribution. That is the download.
To trace one beisl — the performance tracer. Wine-agnostic on purpose.
To hack on it this repo — the Wine fork, the Rust workspace, the pins.

The default branch is rust; there is no main. The supported environment is the Fedora dev container under .devcontainer/ — Rust toolchain, the {i686,x86_64}-pc-windows-gnullvm targets, clang, lld and libclang, preconfigured. Everything is LGPL-2.1-or-later: cherry-pick it freely, no permission needed. Source and issues at codeberg.org/SpritzWine/SpritzWine.

# the superproject: the wine fork + the rust workspace
git clone --recursive \
  https://codeberg.org/SpritzWine/SpritzWine.git

# one-shot: wine (new-WoW64, graphical) + the crates
./build.sh

# -> a relocatable tarball, installer inside
./packaging/package.sh

# what is really Rust in the tree you have:
grep -l lwine_ wine/dlls/*/Makefile.in

Fresh from the cellar

Release notes.

Read the current release notes on Codeberg.

The house

SprıtzWıne Prater beısl

Three Viennese siblings, one joke: the drink, the funfair, the pub. The superproject that mixes Rust into Wine, the Proton distribution you install to play, and the tracer that vets the frametimes — anyone’s frametimes, ours included.