Behind the ports
doskit is the open toolkit behind the ports: the tools that analyse a DOS game's programs and check an independent implementation against the original, and the parts every port needs, whatever the game. It is nothing to install to play a port. It is the workshop, and this page says what is in it and why it exists.
Every DOS game is different, but the work of porting one is much the same each time. The game's program has to be mapped and understood in detail, then its behaviour reimplemented in a form today's computers can run. And every port needs the same things around the game: a window, sound and music, the keyboard and game controllers, a way to find your copy of the game, a place for your settings and saves.
An earlier port solved all of this for one game. doskit is what was left when everything that belonged to that one game was taken out: the parts a next port can use again. So a new port does not start from nothing, and what one game teaches makes the kit better for the next.
It also keeps the ports alike. What every release must give you is written down in the kit: download, unpack, double click; your game found by itself; your settings and saves kept outside the program, so a new version cannot lose them; new versions looked for only if you say yes. A release that falls short of that is not made.
Tools for taking a game apart and checking the work, and the shared parts a port is built on.
Tools that turn a game's original program into readable analysis source and reconstruct the same program from it. A byte-for-byte match shows that this working representation accounts for every part. It is separate from the C implementation released in a port.
A simulated 1990s PC that runs the original game step by step, the same way every time. It is used to look inside the original and to check the port against it. It is never part of a port.
Tools that put the port next to the original at the same moment of the game and show every difference, so each part of the new implementation is known to behave as the original did.
Picture, sound and music, keyboard and controllers on Windows, macOS and Linux; finding your GOG release; a setup screen in the look of a DOS setup program; the new-version check that asks first.
A new port is set up from the kit for a game installed from GOG, with the rules, the checks and the packaging for Windows, macOS and Linux already in place.
The kit tests itself on a small program made for the purpose, so no game is needed to know that it works.
The game's program is turned into analysis source that reconstructs the same bytes. It is a reference for understanding the program, not the C implementation released to players. What the tools cannot work out by themselves is added as notes.
Each part of the program gets a name and a description, checked by running the original in the simulated PC.
The behaviour is reimplemented part by part in C. Its state and behaviour are compared with the original at matching points, then it is set on the shared parts so it runs on today's systems.
Every package is downloaded, started on its system and played before a release is announced. The playing is my part.
doskit, like the ports, is written and used entirely by AI agents (Claude, by Anthropic). When a game needs something the kit cannot do yet, the kit is extended, with a test of its own, rather than the one port, so the next game gets it too.
I decide what the kit is for and what a release must give the player, choose the games, and play what comes out.
doskit's source is public on GitHub because it is part of what the ports are built from. Players do not need to install it: what they download are the finished ports.
The kit holds no code or data of any game, and neither does a port made with it. The game comes from the copy you own.
The simulated PC is used only for analysis and checks. Each port runs its own C implementation directly.
So far it has been proven on game programs written by hand in assembly language, as many DOS games were. Games made in other ways will need it to grow.