HOW DOORS WORK

The Drop File and the Door

When a BBS user selects a door game from the menu, the BBS does not simply hand over its keyboard and screen — that would tightly couple the door to every BBS platform in existence, making portable door games impossible. Instead, the industry settled on a clean, elegant standard: the drop file.

How It Works

When a user requests a door, the BBS:

1. Writes a drop file to a known location on disk containing the user's details
2. Redirects terminal input/output to the door process (or passes a socket descriptor in modern systems)
3. Launches the door program, which reads the drop file to learn who it is serving
4. Waits for the door to exit
5. Resumes normal BBS operation when the door returns

The door program operates independently of the BBS. It knows nothing about BBS internals — it only knows what is in the drop file. This design is what made the door ecosystem possible: any BBS that could produce a compatible drop file could run any door written to read that format.

Drop File Formats

Two drop file formats dominated the BBS era:

DOOR.SYS — the most widely used format. A plain text file with fields on separate lines covering COM port, baud rate, user name, security level, time remaining, and other session details. Almost every BBS platform could produce a DOOR.SYS, and almost every door could read one.

DORINFO1.DEF — the older format, originating with Remote Access BBS. Less detailed than DOOR.SYS but equally ubiquitous in its era. Door authors typically supported both formats to maximise compatibility.

Other formats existed — BBSINFO.DEF, CHAIN.TXT (used by WWIV), numbered DORINFOx.DEF variants — but DOOR.SYS became the effective standard. When you see a door advertised as supporting "all major BBS software," it means it can read DOOR.SYS and DORINFO1.DEF at minimum.

The FOSSIL Driver

On DOS systems with real serial ports, door programs needed a standard way to communicate with the modem line. The FOSSIL driver (Fido-Opus-Seadog Standard Layer) provided exactly that: a hardware abstraction layer between door programs and the serial hardware.

Doors that used the FOSSIL interface would work with any FOSSIL-compliant driver, regardless of the actual hardware — crucial when COM port implementations varied across PC manufacturers. A door game compiled once could run on any system with a FOSSIL driver installed, without recompilation or per-platform adjustments.

The name reflects its origins: FOSSIL was developed collaboratively by people active in FidoNet (Fido), Opus-BBS (Opus), and Seadog mailer (Seadog) development. The BBS software community and the FidoNet community were largely the same people.

I/O Redirection in Practice

On DOS systems with serial-port BBSes, the BBS would pass the COM port number to the door via the drop file. The door would then read input from and write output to that serial port directly, communicating with the caller as if the BBS were not present.

Modern BBSes running on TCP/IP networks emulate the same mechanism. The terminal connection (a TCP socket) is handed off to the door process, often via a virtual COM port driver like tcpser — software that presents a virtual serial port to the door while actually communicating over a network socket. Some platforms pass the socket descriptor directly for doors designed to use it.

The key principle remains identical across eras: the BBS writes the drop file and surrenders the connection. The door reads the drop file, handles the user, and returns control. The BBS resumes as if the door was never there.

DOOR32.SYS

As 32-bit Windows doors became common in the late 1990s, a new drop file format emerged: DOOR32.SYS. It extends the traditional format to handle socket descriptors directly — passing the actual TCP socket handle to the door rather than a COM port number — eliminating the need for virtual COM port emulation on Windows systems.

DOOR32.SYS reflects the transition from the serial-port BBS world to the TCP/IP world while preserving the drop file architecture that made door games portable.