A Windows game, a Mac, and six separate bugs stacked on top of each other — only one of which was the one everybody was talking about. A case study in directing a debugging effort, and in how often an error message points away from its own cause.
PEAK is a Unity 6 game that only runs on Windows. I wanted to play it on my Mac with friends. The usual answer is Wine — free software that translates Windows programs so they run on other systems — wrapped in an app called Whisky that makes it manageable.
The game launched. It rendered. The cursor moved and menus highlighted under it. But no click ever did anything. Keyboard fine. Mouse movement fine. Clicks: nothing.
Even the paid commercial alternative didn't fully solve it. Getting there meant finding six distinct problems, spread across every layer between the game and the screen.
Every box is a translation step. A Windows game speaks Windows; a Mac doesn't. Each layer converts one thing into another, and each one had somewhere to hide a bug.
A previous attempt had asked: is this rebuilt library the same as the one that ships? It compared the library's exported functions — the list of things it offers to other programs.
exports: 504 vs 504 → "identical, theory eliminated"That comparison could not possibly have found the difference. Exports are a library's public menu. They're declared in a list, and they don't change based on what you leave out when building. Comparing them proves almost nothing.
The right question was the opposite one: what does this library need from others? Its imports.
imports: 164 vs 118 → 46 missing, including the entire font systemAn entire subsystem had been silently left out of the build. The check that said "identical" and the check that revealed the truth were both one command long. The difference was knowing which question to ask.
Building the fix produced its own set of problems. Not one of them said what it meant.
| What it said | What it actually was |
|---|---|
| C compiler cannot create executables | A space in a folder name split one argument into two. The compiler was fine. |
| Your bison version is too old | The modern version was installed — deliberately hidden from the default path, so a 2006 copy won. |
| Build died generating fonts | macOS security silently strips certain settings when one program launches another. |
| (nothing — build succeeded) | A library name was mis-read into an unusable string. Failed only later, at runtime. |
| (nothing — all checks passed) | The missing search path above. |
The pattern is worth keeping: when an error describes something that should obviously work, stop debugging the thing it names. Check paths, versions and environment instead.
I didn't write the fix. The mouse implementation is CodeWeavers' work, published as open source because its licence requires it. What I did was direct the effort — and the parts that mattered were mostly about process.
Research before trial and error. Free software only. Prefer whichever fix survives future updates. Explain it to me well enough that I understand it. Those constraints shaped every decision that followed.
I was told the commercial software had already fixed right-click. I knew it hadn't, because I'd played the game and it didn't work. I had no way to evaluate the technical argument — it came with disassembled machine code attached. I pushed back anyway, on the strength of what I'd seen.
That forced a re-verification, and the earlier analysis turned out to have been incomplete. Deferring to the confident technical answer would have been the wrong call.
Backup scripts were multiplying — restore this, restore that. I suggested version control instead. The scripts weren't the problem; they were a symptom of not having the right tool.
Once it worked, I went back in and changed every setting I could find that might break it — windowed, fullscreen, resolution, launching from different places. That's how bug 2 was caught: it only appears when you launch the game a particular way.
Full technical write-up, with the evidence for every claim: the project repository.