Daniel and Patrick grew up sharing a single cockpit in Wing Commander — one kid on the stick, the other on weapons. The dream was always to fly as wingmates, not as a two-headed hydra. In 2015, Daniel realized the entire game state fit in 640K of addressable DOS memory, and the project began with a deceptively simple question: which bytes hold the player's X, Y, Z coordinates? The method is forensic differencing at its purest. Fly into empty space (after deliberately getting wingman Paladin killed to remove his entity from the data segment), stop the ship, dump memory twice. Fly forward without turning, dump again. XOR the snapshots: 253 bytes churn even when stopped, 650 change during movement, only 413 satisfy both conditions. Cross-reference with the chase camera and you're down to 132 candidate bytes across 35 clusters. Position lands at 13D3:A9C2. Velocity at CAE2. The technique is elegant because it's systematic — no guessing, just set theory applied to raw memory. Orientation proved harder. Wing Commander stores direction vectors as 32-bit integers where 256 equals 1.0, meaning small rotations change only a single byte. The breakthrough came from a probable programmer joke: the camera entity sits at slot 0x3D in a 64-slot array — '3D' in hex for the 3D camera. This placed the camera copy predictably relative to the player slot, and a lucky overwrite during experimentation hit the forward vector, causing the starfield to visibly shift. From there, memory watchpoints traced the call stack from vectoradd through per-ship physics to the main loop. The real architectural challenge was Borland's overlay system. Wing Commander was compiled with one overlay per C++ source file, dynamically loaded to different addresses depending on the player's path through the game. You can't hardcode function addresses when the code relocates every run. The solution: read the jump-far thunk tables at known stub addresses to resolve live segment:offset pairs at runtime. Function calls like fireAllGuns or dodamage live in overlays loaded through the EMS page frame, and the DOSBox hook reads the thunk bytes to find them wherever they land. To actually invoke game functions from outside the normal execution flow, the brothers built a trampoline system — injecting machine code into known dead strings in the data segment. The 'Loading WING COMMANDER' string at 13D3:0187 and the misspelled error string at 0395 ('Sorry, an error has occured while %s') become executable trampolines. DOSBox pushes CS:IP to the stack, redirects the instruction pointer to the string address, and executes the injected pushf/pusha sequence before calling into the resolved overlay function. It's simultaneously hacky and precise. This is not a quick mod or a clean-room reimplementation. It's eleven years of intermittent work — months-long gaps between breakthroughs, September 2016 spent writing automated snapshot comparison tools, November resuming after directionality proved harder than expected. The pace is honest about how this kind of deep reverse engineering actually works: bursts of insight separated by long stretches where the problem is simply too hard to hold in your head alongside a day job. The result is cooperative Wing Commander running in a browser, the childhood dream realized through techniques that read like a masterclass in DOS-era binary archaeology. Every step — the XOR/XNOR memory differencing, the slot-array discovery, the overlay resolution, the dead-string trampolines — is a transferable technique for anyone working with opaque legacy binaries.
