Claude does not discriminate between solving valuable problems or getting an old video game to work.
Either way, it is relentless.
A few days ago, my girlfriend and I were talking about early computer games, and she mentioned Nancy Drew. Immediately all these hazy memories came flooding back to me. Stressed about quickly getting cold outside the lodge, playing a board game against an NPC to solve a puzzle… and cooking a lot? I was a bit hazy on the details. I remember playing them together on the family computer in our kitchen.
I called my sister and she had more specific memories — we got Nancy Drew: The White Wolf of Icicle Creek for Christmas in 2008. She was 15, I was 12. You’re Nancy, investigating sabotage at a snowed-in Canadian lodge. There’s a wolf lurking outside. Guests keep having suspicious accidents. My sister’s most vivid memory was also flipping burgers for the lodge guests.
I hadn’t thought about these games in years. I wanted to replay it immediately.
The only problem: it’s a Windows XP game from 2007, I’m on an M1 Pro MacBook, and there is no Mac port.
I’ve used Porting Kit to play Age of Empires 2 on my Mac, so I’m not a total stranger to running old Windows games. I briefly considered setting up a VM for windows but it seemed like a hassle, so I found a Wineskin wrapper for a different Nancy Drew game (The Final Scene) and bought White Wolf on Big Fish Games for $10. I swapped out the game files, launched it, and… nothing. No error, no crash, just nothing.
Using Claude
I’m primarily a web engineer, so I have basically zero experience debugging Wine, Windows, etc. So I pointed Claude Code at the Wineskin wrapper. I instructed it to use vanilla Wine so Claude could mess with the configuration directly, and then just… watched it go.
The process was surprisingly hands-off. Claude would launch the game, capture the Wine debug logs (thousands of lines), read them, identify the error, suggest a fix, I would approve it, it would apply, and try again. Each loop took a couple minutes. I mostly observed. A few things I watched:
It ditched the version I paid for. The $10 Big Fish Games copy had kernel-level DRM. Claude tried a few ways around it, then just said “we should find a clean version” and pulled the original retail disc images from Internet Archive. Is this legal? I don’t know.
It made binary edits to DLLs. At one point Claude found an assertion crash in Wine’s Vulkan code, located the exact byte offset in a 32-bit DLL, and patched it — changed two bytes from 75 17 to 90 90 (a jump instruction to two NOPs). Needless to say, I would not have considered it. But it sort of fascinated me and I respected its commitment, so I let it keep running.
It tried a lot of graphics engine configurations. Vulkan, OpenGL, DXVK 2.7.1, DXVK 1.10.3, different MoltenVK versions, disabling multithreaded rendering. Probably a dozen different combinations. Here’s the funny thing: OpenGL was the first renderer it tried. It failed immediately and Wine said “Disabling 3D support,” so Claude switched to Vulkan and spent hours fighting assertion crashes and shader compilation failures. After exhausting every Vulkan approach, it switched back to OpenGL… and it worked. It fell back to an older OpenGL version, but everything rendered. The fix was going back to the thing that failed on day one, and it probably only worked because of all the other fixes (filesystem, DRM, config changes) that had accumulated along the way.
It fixed the virtual filesystem. The game hardcodes a Z:\Program Files path that doesn’t exist on macOS. Claude created a directory with symlinks to both macOS system folders and the game files, and pointed Wine’s Z: drive at it.
Frankly, I was never sure whether any of these moves were correct. But I trusted it enough (and looked at the commands before approving) and let it continue.
I had to nudge it to focus a couple times — it went down a few rabbit holes with DXVK that weren’t going anywhere. But generally I just let it run. About six hours of debugging total (spread across a few sessions over a week, whenever I had a spare moment), ~400 tool calls, 10 dead ends.
A Wine expert could have probably solved this very quickly. They’d know the right settings, recognize the DRM on sight, understand the stack limitations. I don’t know any of that. But Claude gave me a run loop, and the magic was that it could churn through approaches way faster than I could Google them.
Playing it
It ran beautifully. Smooth, no crashes, no glitches. (Yes the game is dark.)
And the game is so fun. It completely holds up. The mystery is genuinely well-written — multiple suspects, red herrings, great pacing. You DO cook A LOT of meals for the lodge guests (and they complain if you mess up). You snowshoe around the property. The puzzles are genuinely challenging. The art and atmosphere are perfect - so many amazing details and delightful moments. We even pulled up ancient forum posts and an “Arglefunk” video at one point to get past a particularly quirky puzzle that had us stuck for half an hour, all part of the charm of a 2007 point-and-click.
Reflecting
For me, this experience was almost a perfect example of the current AI paradigm. Claude was decently smart and likely had all of the Wine docs and forums somewhere in its training data. But it was surprisingly dumb too, mistaking an error and ignoring OpenGL for most of the investigation.
But most of all, it was relentless in a way that I’m not sure I would have been about getting this game to work, which made all the difference. Its ability to try so many things faster than I could have made this type of investigation possible.
Open Questions
- Was it legal for Claude to use the iso it found on archive.org?
- Is it legal for me to send the full .app to my sister?
- What game should we try next? :)
Full investigation timeline
I asked Claude to pull its full session history - here it is on a timeline.
Session 1 — Late Night
00:17 Initial exploration ▶
00:18 Discovery First launch — nothing happens ▶
Activated=0 and State=4 in Wine registry.00:22 Discovery Stack overflow in wow64 ▶
err:virtual:virtual_setup_exception stack overflow 320 bytes. Wine's wow64 mode (32-bit x86 on ARM64) uses more stack than normal — the game's 1MB default wasn't enough.00:25 Dead end Tried patching the executable's stack size ▶
00:26 Breakthrough Registry-based stack fix works ▶
00:28 Discovery BCMDMCCP — a kernel DRM driver ▶
\\.\BCMDMCCP — a Big Fish Games kernel-mode DRM driver that doesn't exist in Wine. The string was obfuscated in the binary, constructed at runtime. Not patchable.00:34 Dead end BFG DRM is fundamentally incompatible ▶
00:40 Decision: find a DRM-free version ▶
Session 2 — Afternoon
13:22 Found the original retail version ▶
13:24 Downloading and extracting disc images ▶
bchunk and unshield via Homebrew. Extracted 4,996 files including a clean Game.exe.13:29 Breakthrough Verified: no DRM in disc version ▶
13:31 Setback Progress! But 3D is disabled ▶
err:winediag:wined3d_dll_init Disabling 3D support. Wine's OpenGL backend can't initialize on macOS (Apple deprecated OpenGL, wow64 incompatibilities).13:36 Breakthrough Switched to Vulkan renderer ▶
winevulkan.dll in the Wine build. Set Renderer=vulkan in registry. Translation path: D3D9 → wined3d → Vulkan → MoltenVK → Metal.13:38 Vulkan initializes, but game exits silently ▶
13:45 Discovery The Z: drive mystery ▶
Z:\Program Files (x86)\...\CIFTREE.DAT. Wine's Z: drive maps to / (macOS root) — but /Program Files (x86)/ doesn't exist on macOS! The game constructs this path internally through an unknown mechanism.15:28 Dead end 33,697 lines of registry debug — no answer ▶
+reg debug to trace every registry read. The game does NOT read the Her Interactive registry key at all. The Z: path is constructed internally by the game engine. Not from registry, CWD, module path, or config.15:38 Setback Redirected Z: drive — broke Wine entirely ▶
/ to ../drive_c. Wine couldn't find system files (fonts, etc). Wineskin config screen appeared instead of the game.Session 3 — Evening
19:29 Reverted Z: redirect ▶
/System, /Library, /Users for fonts, etc). Put it back to /.19:31 Breakthrough Invented a virtual filesystem root ▶
z_root/ — a directory with symlinks to macOS system directories AND the game's Program Files. Changed Z: to point to z_root instead of /. Now Z:\Program Files (x86)\...\CIFTREE.DAT resolves to the actual game files, while Z:\Users\... still reaches macOS.19:43 Breakthrough IT WORKS — game reaches splash screen ▶
20:10 Setback Vulkan assertion crash ▶
20:13 Dead end Tried DXVK 2.7.1 ▶
20:15 Dead end Tried DXVK 1.10.3 ▶
20:20 Dead end Tried disabling CSMT ▶
20:25 Dead end Tried upgrading MoltenVK to 1.4.1 ▶
20:30 Breakthrough Binary patched winevulkan.dll ▶
75 17 (jnz, triggers assertion) to 90 90 (NOP, skip the check). Game runs! Audio works! But the screen is completely black.20:35 Setback Black screen — 53,000 pipeline errors ▶
vkCreateShaderModule calls. Wine 8.0.1 bug.20:40 Dead end Tried DXVK + MoltenVK feature tolerance ▶
MVK_CONFIG_DEVICE_CREATION_TOLERATE_MISSING_FEATURES=1. MoltenVK creates the device but still returns an error code. DXVK checks the return code and rejects it anyway.Session 4 — Morning
06:30 Dead end Resumed — tried DXVK + tolerance again ▶
06:40 Dead end Checked for Apple Game Porting Toolkit ▶
06:45 Discovery Traced MoltenVK calls ▶
vkCreateGraphicsPipelines() IS being called by MoltenVK and succeeding — but wined3d fails at shader compilation BEFORE calling Vulkan. Confirmed: zero vkCreateShaderModule calls. The Vulkan renderer is fundamentally broken on this config.06:50 Breakthrough Switched to OpenGL renderer ▶
Renderer=vulkan to Renderer=gl. Translation path: D3D9 → wined3d → OpenGL → macOS OpenGL. Yes, Apple deprecated OpenGL. But it still works.
Loading comments...