Running Several BBSes on One PC

By the end of September 21, 2026, I had four boards answering telnet on my PC: the restored Amiga board (CNet PRO 3.05d in WinUAE), a second emulated Amiga with a fresh C-Net install, Synchronet, and Mystic. A fifth, ABBS on a third emulated Amiga, rings but doesn’t answer yet. I called all four working boards at once and each answered with the others running.

Later update, October 2026: On October 17 the Windows installs moved again, to D:\bbs\win-sync and D:\bbs\win-mystic. win-sync is still eight characters, and the move took the same steps described below: Synchronet’s CtrlDirectory and SBBSCTRL, Mystic’s stored paths, and firewall rules that again name the old folders. Both boards answered local calls from their new folders on October 19: Synchronet on 2323 and Mystic on 2324. Both were stopped again after the checks. The PC now also runs a Docker copy of the restored board on 2328, a copy on AmigaOS 3.2 on 2345, and Renegade under DOSBox-X on 2330. ABBS still rings without answering.

Since October 19, another copy of the Inn also runs under Amiberry in Docker on a second machine at home. It took calls from this PC through a relay on October 20. Access is restricted while testing continues; it isn’t open to the public.

The port layout was straightforward. Moving the installs turned up a few less obvious problems.

Give each board its own port and folder

Each board has its own process and folders. It also needs a port that none of the others is using. Here’s the layout as it stood on September 21, 2026, before the additions in the October update above:

The emulated Amigas take calls through SerialTCP, which listens on the port set in each Amiga’s S:serialtcp.conf. WinUAE’s bsdsocket_emu lends each Amiga the Windows network stack, so those ports open on the PC itself, just like the native boards’ ports. Two emulated Amigas copied from the same drives will both try the same port, so change the copy’s listen line before you boot it.

I also renamed the native boards to Autumn’s Harvest Inn II and III, so a caller, or I, can tell which one answered. Synchronet shows its name in the login banner, which made that easy to check.

To test, I used a small script that opens a connection to every port at once and prints the first thing each board says. That’s quicker than opening five terminal windows.

Keep Synchronet’s path short

Synchronet runs 16-bit DOS door programs, and those need 8.3-compatible paths. Windows normally gives a long folder name a short alias, but that can be switched off per drive, and it was off on my D: drive. So the folder name itself has to fit in eight characters. I moved Synchronet to D:\bbs-sync; D:\bbs-synchronet would have broken DOS doors.

You can check a drive without admin rights by asking for a folder’s short path, for example with PowerShell’s Scripting.FileSystemObject. If ShortPath comes back as the full long name, the drive isn’t making aliases.

Moving an install is more than moving the folder

Both Windows boards remembered their original location in places a folder move doesn’t touch.

Synchronet looks for its control folder through the SBBSCTRL environment variable, which the installer sets machine-wide, and through CtrlDirectory in ctrl\sbbs.ini. Both need the new path. Changing the machine-level variable needs admin. A user-level SBBSCTRL overrides it for your own account in the meantime. The uninstaller’s registry entry also keeps the old path, so don’t run it until that’s fixed.

Mystic keeps absolute paths inside its binary data files: mystic.dat (eleven of them), data\mbases.dat and data\fbases.dat for each message and file base, and mutil.ini. They’re Pascal short strings (a length byte, then the text) in fixed 80-character fields, with the layout documented in Mystic’s own docs\records.112. I rewrote them with a small script that updates each length byte along with the text and refuses any path that wouldn’t fit.

Windows Firewall rules name each program’s full path. After a move, the old rules no longer match, and new rules for the new path can appear alongside them. Local calls work either way; callers from other machines are blocked until the rules point at the new path.

I kept a copy of every file before changing it, and a short script for the parts that need admin.

Two start-up surprises

• Mystic’s server needs an argument on Windows. mis.exe on its own exits straight away. mis.exe server starts the servers and keeps a status window open.
• An unlicensed C-Net stops at a licence requester at every boot, and nothing answers until someone clicks Ok. My fresh-install machine only took calls once it had a licence file.

Before any of it faces the internet

The boards and ports listed here are on the Windows PC, with no port forwarding. The separate home-server copy described in the October update has restricted access through a relay and a browser connection, but isn’t open to the public. Before making any board public:

• Change stock passwords. Mystic ships with a default sysop password. Change it in mystic.exe -cfg before its port goes anywhere.
• Close what you don’t use. Synchronet had rlogin enabled on port 513 with no reason to be.
• Check the ports that should be listening. Synchronet’s SSH on 2222 was configured but wasn’t listening, which I only noticed by checking each port.