DosBridge

The TCP-socket-to-terminal-writer bridge that lets DOS doors running
inside DOSBox talk to a user connected via Telnet / SSH /
Web Terminal.

Architecture

+-----------+  bytes  +-----------+  TCP  +-----------+
|  user     |  <--->  |  BBS      | <---> |  DOSBox-  |
| terminal  |         | session   |       |  staging  |
+-----------+         | (DosBridge)|       | (door exe)|
                      +-----------+       +-----------+

The BBS session opens a TCP connection to DOSBox's nullmodem
serial1=nullmodem server:<port>. Two async tasks copy bytes in
both directions:

• terminal → socket: user keystrokes go to the door
• socket → terminal: door output reaches the user

Why TCP?

Earlier versions tried serial1=stdio. That stopped working when
DOSBox-staging dropped stdio passthrough; the bridge would see
zero bytes through the door. TCP nullmodem is the supported path
since v279.

Lifecycle

1. BBS launches DOSBox as a subprocess.
2. BBS opens the bridge socket (or waits for DOSBox to connect,
   depending on server: vs client: mode).
3. Bridge runs until any of: door exit, user disconnect, idle
   timeout, or the watchdog fires.
4. Teardown closes the socket, then waitpid on DOSBox, then
   kills Xvfb if running headless.

Cleanup contract

• Never delete files inside the door's working dir on shutdown
  — see Doors#don-t-touch-the-door-s-working-dir.
• Do clean up tempfiles in /tmp/dosbridge-<pid>-*.
• Do reap the DOSBox process — orphan Xvfb processes are a known
  bug class.

See also

• LORD Setup for a concrete example
• Door Setup for registering a door in the admin UI