Wing Commander co-op works by turning a dead loading message into executable code
Two brothers' reverse-engineering account follows the childhood wish through memory snapshots, function calls and a browser lobby.

The loading message had finished its job. Two brothers gave the memory behind it another assignment: fire the lasers.
The Wing Commander Together write-up describes an eleven-year path from sharing one cockpit as children to flying separate ships in the original DOS game. Daniel and Patrick wanted a wingmate with an actual craft, which is a reasonable upgrade from arguing over the afterburner.
The reverse engineering began with snapshots. A stopped ship produced one set of memory changes; moving straight produced another. Comparing the two helped distinguish position data from background activity. An empty stretch of space made the experiment easier to interpret.
The game kept arrays with 64 slots. The camera occupied hexadecimal slot 0x3D, while other slots held ships and temporary values. Finding a change in memory was only a lead: writing values back and watching the ship move established what that location did.
Laser fire proved harder than changing a position. The brothers needed to call the original game’s functions with the right arguments and return to the interrupted work. A dead string, “Loading WING COMMANDER,” supplied room for the injected trampoline. Loading had become a launch command.
The code also had to behave enough like the game’s compiled functions to survive its overlay machinery. Their account describes crashes caused by a missing stack frame and the fix that made the trampoline resemble a Borland function. The old program had house rules, even for uninvited guests.
Networking introduced a second problem. Each player’s ship occupied local slot zero, so the two machines did not agree on every object identifier. A server-to-local mapping let the same ship be represented consistently without forcing identical memory layouts.
The browser release now uses a room code and WebRTC transport. The author describes loading the user’s GOG installer into client-side browser storage. The project is at the playable browser page; the underlying account remains the source for how the patch works.
For someone interested in reverse engineering, the repeatable part begins before the clever code injection. Remove unrelated activity, change one input and compare observations. A memory difference becomes useful when an intervention confirms the connection, just as a suspicious light switch needs a lamp before it becomes a wiring diagram.
That method cannot promise every single-player game will become multiplayer. Hidden state, random behavior, identifiers and timing all have opportunities to disagree. This write-up is valuable because it exposes those disagreements and the repairs, rather than stopping at the first synchronized ship.
For players, the practical step is smaller: check the project’s current instructions, supply the required game files and try a short session with a friend. The browser reduces the setup burden, but the interesting test is still whether the mission stays coherent on both screens.
The loading screen got promoted.