You remember the games that nobody else remembers. The ones that came on shareware floppies, that ran in 16 colors, that crashed when you pressed the wrong key combination. The ones your friends never played because they weren’t on the shelf at Electronics Boutique. They were yours.
Every piece of software is a time capsule — but most time capsules are buried in formats nobody can open anymore.
That’s what happened to Ducks. A DOS real-mode game from an era when x86 assembly was king and SDL didn’t exist. It ran on a platform that effectively doesn’t exist anymore. The operating system that birthed it is a museum piece. The hardware it was compiled for is landfill. The game was, for all practical purposes, dead.
So I did what any reasonable person with reverse engineering skills would do: I brought it back.
I ported Ducks to modern SDL, running on x86_64 Linux. It lives again. You can compile it, run it, play it. The pixels move the way they moved decades ago. The gameplay is intact. But here’s the catch that keeps me up at night.
You can’t save a digital artifact without first destroying what made it run.
To preserve Ducks, I had to fundamentally change it. The original ran in DOS real mode — a memory model that modern operating systems don’t even pretend to support anymore. The original used direct hardware access, interrupt vectors, VGA register manipulation. All of that had to be ripped out and replaced with SDL calls, modern input handling, a completely different graphics pipeline. The soul of the game — the gameplay, the visuals, the feel — survived. But the body? The body is new. It’s a Ship of Theseus problem wearing pixel art.
This is the paradox that every digital preservationist runs into and most don’t talk about. We say we want to preserve the ‘unadulterated original.’ But the original was never just the code. It was the code running on a specific chip, talking to a specific video card, rendering to a specific CRT monitor with specific phosphor glow. You can preserve the binary. You can even preserve the source. But you cannot preserve the runtime environment without building a time machine.
So we make choices. We port. We emulate. We reimplement. We keep the experience alive by accepting that the implementation must change.
But here’s where this story takes a turn I didn’t expect.
When I finished the port, I felt something I wasn’t prepared for. The code worked. The game ran. And yet it felt incomplete. Not technically — the build was clean, the tests passed. It felt incomplete because there was a hole in the story. The person who made this game — Tim Furnish — was out there somewhere, or maybe not. The people who had played it, modded it, preserved it in their own ways — Kieran Millar, Stan Stoyanov — were names attached to fragments of history with no way to reach them.
The code was never the point. The people were.
I started searching. Old forums, archived newsgroups, WHOIS records, email addresses that might bounce. The hunt for Tim Furnish became the real project. Because here’s what I realized: digital preservation isn’t a technical challenge. It’s a social one. The value of Ducks isn’t in its assembly instructions or its sprite data. The value is in the fact that a person made it, other people played it, and a community formed around it — however small, however forgotten.
When you reverse engineer an old game, you’re not just recovering software. You’re recovering a relationship between a creator and an audience that time nearly erased. Every abandoned DOS game is a conversation that got cut off mid-sentence. The port is the technical work. Finding the author — that’s the human work. And it’s the part that matters more.
Think about what gets lost when we treat preservation as purely technical. We get perfect binary copies of games nobody can contextualize. We get faithful emulations of software whose creators have vanished from the record. We get the bytes without the stories. And bytes without stories are just noise arranged in patterns.
Preservation isn’t a museum behind glass. It’s a conversation across decades.
The comment on my project that hit hardest was simple: ‘I have a ton of nostalgia towards making what is old new again, but still the unadulterated original.’ That tension — between new again and unadulterated — is the whole game. You can’t have both. You choose resurrection or you choose purity, and purity means death. A game that can’t run isn’t preserved. It’s entombed.
So here’s where I land. If you care about old software — really care, not just theoretically — then learn to reverse engineer. Learn to read disassembly. Learn to port. Learn to reimplement what can’t be emulated. The tools are accessible. The knowledge is out there. The games are dying while we debate the philosophy of preservation.
And if you’re Tim Furnish, or Kieran Millar, or Stan Stoyanov — or anyone who knows them — there’s a game waiting for you. It still runs. Someone still cares. The conversation isn’t over.
FAQ
Q: Isn't emulation enough? Why port instead of just running DOSBox?
A: Emulation works for many cases, but it's a layer of indirection that eventually breaks. Emulators themselves become obsolete. A native port ensures the game survives even when the emulator doesn't. Porting is harder, but it's permanent in a way emulation never is.
Q: What does this mean for anyone who isn't a reverse engineer?
A: It means old software is dying faster than we think, and the people who can save it are rare. If you care about digital history, support preservation projects, document what you remember about old games, and help connect coders with the original creators before those trails go cold.
Q: Doesn't changing the platform destroy the 'original' experience?
A: Yes, and that's the point. A perfectly preserved binary that can't run isn't an experience — it's a corpse. The original experience is already gone because the hardware is gone. The question isn't 'original or changed' — it's 'changed and alive, or pure and dead.' I choose alive.