Keeping older tools and newer Steam clients in their own lanes

Not every Windows program wants the same Wine setup. The October 13–16 work spent time on that problem from both ends: a changing Steam client and older 32-bit software that needed a more specific environment.

The Steam record is particularly useful because it includes what happened on the actual M2 test Mac. The stock October client helper produced a black sign-in window. After the exact measured helper was added to the existing compatibility policy, the form rendered, literal keyboard input appeared, and a clean client restart returned to the signed-in Library. That verifies a client workflow on that host; it doesn't certify gameplay across the library.

For older software, the Neverwinter Nights Aurora Toolset received a versioned, isolated runtime path. Repair preserved authored content and private configuration instead of recreating the workspace. Missing Wine system files could be bootstrapped without treating the user's work as disposable setup data.

There were also corrections to controller and graphics selection. Choosing controller Off disabled the Wine gamepad backends. Structured graphics imports took priority over optional backend strings, helping the analyzer avoid turning a stray reference into a hard requirement.

The common theme here is keeping a fix where it belongs. A tool-specific Wine build should help that tool. A Steam helper policy should recognize measured bytes. A controller preference should survive the preparation path that actually launches the game.

There's still more to verify whenever the runtime changes, but this gives us a much better basis for those tests. We can name the program, the environment and the observed result, then work on the next failure without losing the working configuration or the files someone created inside it.