# Giving Back to Open Source with Bourbon

> An update on Bourbon-OSS: shared recipes and tools, seven new contribution drafts, and the validation still ahead.

Canonical page: https://pyrosoft.pro/blog/giving-back-to-open-source-with-bourbon

Published: 2026-10-26

It's been a little while since I shared an update on the open source side of Bourbon, so I wanted to put everything in one place. We've published another batch of work, and there's quite a bit in the repository now beyond the original compatibility recipes.

Bourbon depends on years of work from the Wine and Mac gaming communities. Wine, DXVK, DXMT, MoltenVK, UTM, and QEMU make a lot of this possible, along with CodeWeavers' work on Wine and CrossOver and the community around those projects. As we work through problems in Bourbon, I want the useful fixes, tools, and findings to make their way back into that community.

That's what Bourbon-OSS is for. Anyone building a launcher, troubleshooting a game, or putting together their own Wine setup can look through it and reuse the parts that help.

## What we've already shared

The repository started with Smart Play recipes and compatibility data. Those files describe game-specific configuration choices, fixes, and known limitations in a format other tools can read. We've also shared runtime and renderer reference data, save-location rules, anti-cheat information, and lists used to organize compatibility testing.

The published game-fix snapshot includes 528 Steam entries and 67 GOG entries, along with umu and name-based records. Those are catalog entries, not a claim that we've independently fixed or tested that many games. The catalog combines Bourbon-specific work with attributed information from other community projects.

We've published the tools behind that data, too. The fix miner reads sources such as umu-protonfixes, the Whisky book, and Lutris installers, then filters or translates settings for macOS. That matters because a useful Linux workaround can depend on components that don't exist in a Mac Wine setup. Another tool brings together compatibility information from Apple Gaming Wiki, Are We Anti-Cheat Yet, ProtonDB, and MacGamingDB, with the source of that information kept visible.

There are a few smaller pieces that came directly out of troubleshooting:

- A Steam webhelper shim developed for the black Steam UI problem under Wine on Apple Silicon. It forwards to the real helper and changes the main process's compositing options. It's a workaround for affected client setups, so the source is there for people who need to understand or adapt it.

- An experimental Direct3D 9 patch and build helper for an older version of Gcenx's DXVK-macOS. It addresses device-creation and shader-translation problems on MoltenVK. It also has rendering limitations, including reduced sampler behavior, that matter when deciding whether it's appropriate for a particular game.

- Small Direct3D 11 probes that draw a clear window or a cube. When you're investigating a graphics problem, a tiny program with a known result makes it easier to tell whether the basic rendering path works before adding a whole game to the test.

- A ROM metadata tool that matches titles against the No-Intro catalogs in Libretro's database and retrieves matching artwork from the community thumbnail repositories. The database and artwork belong to those projects; our contribution is the tool that connects them to a library workflow.

That work is all in Bourbon-OSS alongside the recipes and catalogs. The original code, community data, and third-party patches retain their respective licenses and attribution.

## The latest batch

We've now added seven more contribution drafts: three code fixes, three Wine diagnostic tools, and a reusable piece of our Coherence work. Their source and test records are public in Bourbon-OSS. They're prepared locally for review, but no upstream PRs or merge requests have been opened for this batch yet.

### Wine and ARM64EC memory ordering

One candidate addresses how Wine selects its acquire/release memory helpers for ARM64EC. ARM64EC defines an x86-64 compatibility macro, which was sending these helpers through a path intended for x86. The resulting ARM instructions were missing the acquire/release ordering those operations require.

The focused compiler checks make the difference visible. The baseline fails ten ARM64EC cases across integer widths and pointers. With the candidate change, all 60 checks across ARM64EC, AArch64, and x86-64 pass. A full Wine build and runtime threading tests are still part of getting that patch ready for upstream submission.

### MoltenVK shader caches

The cache work came out of our related macOS VM testing. Two compiler options weren't being preserved when shader configurations were saved, which could stop a loaded cache entry from matching the configuration that created it.

The draft adds those options to the serializer in steamac's patched MoltenVK stack. The matching dependency versions matter here: this change belongs with steamac's pinned MoltenVK and SPIRV-Cross combination. Three isolated round-trip checks fail before the change and pass afterward.

We also retained earlier GPU test results from the previously tested version of this fix. Those runs showed correct compute output and all 16 shader-stage cache hits on repeated warm runs. Separate timestamp tests still failed. The updated draft needs a fresh driver build and GPU validation, so those earlier results remain labelled with the version they actually tested.

### Safer memory exports in virglrenderer

Another candidate checks for missing Vulkan memory-export functions before trying to call them. An unavailable entrypoint should produce a handled failure rather than a renderer crash.

The isolated tests execute the actual export function with controlled device interfaces. The baseline crashes in both missing-function cases. The candidate passes all eight cases, including successful exports and driver-reported errors. Full renderer and guest testing are the next checks for this one.

### More useful tests for existing Wine work

Three of the new tools support proposals that other Wine contributors already have open:

- An OpenGL context-transition probe for investigating window and context freezes.

- A multichannel WASAPI audio probe that plays labelled channels individually, including the center channel that often carries dialogue.

- A cursor probe that records frame intervals and mouse movement while comparing visible, hidden, and transparent cursor modes.

All three compile as Windows x64 executables. Their runtime comparisons are still pending. The OpenGL probe also needs the reported mixed Metal/OpenGL trigger before it can establish coverage of that specific deadlock.

The existing fixes remain their authors' work. What we're adding is a set of smaller tools to help reproduce behavior and collect useful before-and-after evidence.

### A reusable piece of Coherence

We've also extracted the calibration and coordinate helpers from Bourbon's experimental Coherence work. These handle the mapping between guest windows, Mac screen coordinates, and cropped capture surfaces.

There are some easy details to get wrong there. The captured image and CALayer crop coordinates use different origins. Window borders, display scaling, and a partially covered calibration image also affect where the guest's pixels belong. The extracted helpers include native Swift checks for those cases.

This release is the geometry component. Capture, guest communication, authenticated input, and the rest of the window-remoting integration still have their own work around them.

## Where this goes next

I like contributions that leave someone else with something they can actually use: a configuration they can inspect, a small program that shows a problem, or a patch with a clear explanation of what changed.

The next step for the new drafts is to finish their remaining validation and work through upstream review. Publishing the source now makes the progress, test results, and remaining questions available in the meantime.

Thank you to the people maintaining the projects Bourbon builds on, and to everyone sharing fixes, testing games, and documenting what works. A lot of the progress in Mac gaming comes from people taking the time to make the next person's setup a little easier.

You can find the code, data, tools, and the new contribution drafts in Bourbon-OSS:
https://git.pyrosoft.pro/pyrosoft/bourbon/bourbon-oss