I like a good board game. However, Risk is not one of those. If you’ve played it you’ll know it takes a long time before anything happens. The setup is tortuous. And woe betide you if you accidentally knock the table and cause all the little pieces to go flying. Worse, it’s often clear you’ve lost long before the game slowly grinds to the inevitable conclusion.
But I have a Windows 3.1 version (written back in December 1992 by Steve Stancliff - if you ever happen to read this, thank-you - I’ve thoroughly enjoyed your game over the years) that I rather like. Somehow the game works far better on the PC than in real-life.
The oceans run red
Unfortunately, the game is bugged. When you click on a country to choose it that country should turn to your player colour. But often the colour "leaks" out of the country and floods the oceans. The oceans can, and often do, run red (or green) in this version of the game! And once the oceans have flooded the game is broken.
The bug seems intermittent, but my guess is that it’s display driver specific - the wrong display driver or resolution makes it more likely. Interestingly my Win16 emulation repros it too - we must be doing something right if original bugs repro in the emulator :).
Anyway, this is what the game should look like:
And this is when the oceans run red:
Enter Astra
Then I had an idea. Could Astra find and fix the bug? I don’t have the original source - just the binary. But…
I suspect you know how this story goes by now. For a model family that is adept at finding zero days, escaping sandboxes and whose descendent solved Navier-Stokes, this is probably small beer. And it was.
In a couple of hours Astra had a patched binary that, well, just worked. The diagnosis?
When a country is coloured, the game does a "flood-fill" of the country. The boundary is set by the black outline of the country. Sometimes the code uses an off-screen bitmap. Sometimes (presumably for perf) it uses the copy on screen.
But the version on screen can get mangled as it gets converted to screen co-ordinates by whatever display driver is being used. And that mangling sometimes opens up gaps in the black outlines. And the gaps mean colour can escape into the oceans.
The fix? Always use the off-screen drawing path when updating countries. A simple update. But one that has fixed a 34 year old bug.
And my role? Not a lot. I explained the bug, gave Astra my hunch that it was display driver related and left it alone. Cool.
Recreating the past
Bah, I hear you say. The fix was just three small changes to change some function calls. We need a harder challenge.
OK. So what about Geoff Crammond’s Grand Prix (F1GP)? Earlier this year I got it running under my PC emulator - and then added linked modem support too. These days it runs very nicely - it’s smooth and responsive. Here we are at Suzuka in 1994, running on the emulator on my MacBook (it’s probably clear why I was never a F1 driver…)
How about reimplementing that?
The original exe is ~300KB. But that’s compressed (back in the 90s it was common to compress exes - disk space was expensive); unpack it and there’s actually 600KB of hand written, optimised, assembler. Over the years various very smart folks have decompiled parts of the game - some of the data structures are well understood. There are car livery and track editors. However, the physics and drawing code are not understood.
But if we had a modern reimplementation, then more options open up. We could add new tracks. Tweak the physics. Add support for, err, battery charging. Or maybe not. Maybe a nice V12 instead.
Right from the start I was confident this would work. We’ve got an excellent oracle (the original game) and a way of running it (the emulator). It’s easy to record inputs as I drive a race. Then we can replay those into the original and the new version - and diff the screen outputs. And the models these days, well, they are good enough to do this.
After that it’s just a matter of being patient while the models grind away for days until everything matches.
Here’s an early screen capture. It has, err, room for improvement…
And this gives an insight into the diff approach:
I’d be lying if I said this was entirely hands-off. We went on a major detour early on where the agents decided that it was too much effort to reimplement the original game. Instead they decided to implement an alternate, much worse, game. I got them back on track (boom, boom), but then they decided to leave out large chunks of function. Another car overtaking, or going into the pits, or having a marshal appear would cause the game to abruptly exit with an "unimplemented function" error. Clearly those are things that rarely happen so we don’t need them…
But, little by little, the original game emerged.
And here’s the result. 210kloc of Rust. I left in a little display bug on the dashboard at the bottom right just in case you don’t believe this is a port :).
Impressive what the latest models can do isn’t it?
Except this wasn’t Astra. Or Fable 5.1. This was a joint effort between Opus 5 and Luna-5.6 with Sol-5.6 and Fable 5 providing an occasional consult. Almost all the work predated Astra.
And so?
I probably could have fixed the bug in WinRisk before now. But it would have taken me days. So I didn’t bother. There are lots of other bugs like that which we’ve lived with for years.
Take Microsoft Outlook. It’s full of bugs. Depressingly so given it’s over twenty years old. The weird bullet reformatting bugs where the indenting changes for no obvious reason. The bug where the font changes to small caps. Random lockups…
But now - could I start patching some of those? (As an aside, I knew Outlook was buggy, but didn’t realise quite how bad it was until I asked ChatGPT - there’s a long list of what Microsoft call "design limitations"- seemingly a euphemism for "won’t fix").
Or maybe I just reimplement it from scratch. Outlook isn’t that different from F1GP. In some ways it’s easier - it’s almost certainly compiled C/C++. Compilers tend to have specific ways of implementing common code patterns - and only use a subset of the instruction set (Outlook probably uses only 10-15% of the x86-64 instruction set). I’ve already reimplemented the RDP client. Why not Outlook too? Or Word?
Of course, I’m weird - most people won’t reimplement their applications. But we don’t need everyone to do that - just a few. And, anyway, at what point does Claude start offering to fix and reimplement for me? If I go to future Claude asking about an Outlook bug, will it offer to replace Outlook for me rather than try to find a workaround? A few years ago that seemed bonkers. But today it doesn’t seem so far-fetched…
Oh pleeeeeze, please fix Outlook pretty please! And then fix Windows 🤣