BBS Era MUDs checklist for MUDs

Compare file hashes against known archives like the IF-Archive or BBS software repositories to ensure no bit-rot or unauthorized modifications.

Identify all external DLLs, VBX controls, or FOSSIL drivers required for the executable to launch on the target OS.

Scan binaries and configuration files for hardcoded C:\ drive paths and map them to the current environment using logical drives or symlinks.

Run legacy binaries through modern heuristic scanners to detect dormant viruses common in 1990s BBS shareware distributions.

Verify if the game is a standalone multi-user executable or a door game requiring a BBS dropfile (e.g., DOOR.SYS or DORINFO1.DEF).

Configure DOSBox or vDMSound to limit CPU cycles, preventing game logic loops and movement timers from running too fast on modern hardware.

Verify XMS and EMS memory allocation settings in the emulator's configuration to match the original system requirements.

Test the display output using a terminal emulator that supports CP437 to ensure high-ASCII art and color codes render correctly.

Map virtual COM ports to TCP/IP sockets for games that expect modem communication rather than direct telnet.

Install and configure BNU or X00 emulation if the MUD relies on standard BBS serial communication drivers.

Verify the server correctly handles IAC (Interpret As Command) sequences to prevent garbage characters during login.

For multi-node BBS games, verify that record locking (file sharing) is active and preventing data corruption across nodes.

Configure firewall rules to redirect standard Telnet port 23 to the high-port used by the emulation layer.

Set keep-alive intervals to prevent modern routers from dropping idle connections to the legacy game engine.

Implement a translation layer if the BBS game outputs CP437 but the intended audience is using UTF-8 terminals.

Verify the game can create new user records and save progress to the .DAT or .DBF files without permission errors.

Automate the execution of 'cleanup' or 'maint' scripts required by many BBS MUDs to reset daily events and purge inactive players.

Implement a scripted backup of the entire directory structure every 24 hours to allow for rollbacks in case of database corruption.

Sync the host system clock with an NTP server to ensure game-time events trigger at the correct intervals.

Ensure the system captures sysop logs and error logs, and rotates them to prevent disk space exhaustion on the host.

Include scans or text files of the original 'sysop.doc' and 'manual.doc' in the distribution folder.

Verify the login screen or 'about' command correctly credits the original developers and BBS systems.

Create a README.txt documenting the specific version number, compile date, and any patches applied during restoration.

Submit a copy of the stabilized codebase and configuration to the Internet Archive or a dedicated MUD preservation project.

Record a raw text log of a full gameplay session (session log) to preserve the 'feel' of the interface for future researchers.