Doors
ENiGMA½ supports running local BBS door games through several approaches. In addition to the many built-in door server modules (DoorParty, BBSLink, etc.), local doors run directly on your server.
Choosing an Approach
Section titled “Choosing an Approach”| Approach | Module | Best For | External Requirements |
|---|---|---|---|
| Native v86 Emulation | v86_door | DOS doors, no emulator on server | FreeDOS disk image |
| External DOS Emulators | abracadabra | DOS doors, full graphical setup | QEMU or DOSEMU installed |
| Scripts & Native Binaries | abracadabra | Native terminal apps, shell/Python scripts | None |
| Z-Machine Interactive Fiction | zmachine_door | Zork, Adventure, Photopia, and hundreds of free IF games | None (pure JavaScript) |
Quick Guide
Section titled “Quick Guide”-
Running a classic DOS door game and want zero server dependencies? → Native v86 Emulation. ENiGMA½ boots FreeDOS in a built-in emulator; no QEMU or DOSEMU required on the production machine.
-
Already have a QEMU or DOSEMU setup, or need a full graphical DOS environment for image configuration? → External DOS Emulators. Raw disk images are compatible with both approaches, so you can configure with QEMU and run with v86.
-
Running a native terminal application, a shell script, or a Python-based door? → Scripts & Native Binaries. The
abracadabramodule launches any local process that speaks stdio and bridges I/O over stdin/stdout or a TCP socket. -
Running a Z-Machine interactive fiction game (
.z3/.z5/.z8)? → Z-Machine Interactive Fiction. Classic Infocom-era text adventures and modern IF competition winners — Zork, Adventure, Photopia, Anchorhead, Lost Pig, etc. — run natively in Node.js with no emulator, no drop file, and cross-platform support.
Drop File Types
Section titled “Drop File Types”All local door approaches in ENiGMA½ support these drop file types:
| Value | Description |
|---|---|
none | No drop file needed |
DOOR | DOOR.SYS |
DOOR32 | DOOR32.SYS |
DORINFO | DORINFOx.DEF |
BBSDEV | BBSDEV.DRP, abracadabra only |
BBSDEV.DRP is a newer format. It is UTF-8, it names the terminal’s character set and the board’s language, and it states the communications mechanism exactly instead of leaving it to convention. A door finds the file through the BBSDEV_DRP environment variable rather than a command-line argument, so only abracadabra writes one: a v86 guest never sees the host’s environment, and the format’s serial modes name a host descriptor rather than the guest’s COM1.
Every format states how much time the caller has left today, from their daily time budget. The legacy formats carry it in a 16-bit field, so the figure is capped at 546 minutes — a little over nine hours, the one documented ceiling in the BBS literature, and 546 × 60 = 32760, which fits a signed 16-bit integer. The cap applies to every value, so a caller with no limit is simply told the ceiling rather than a sentinel. It errs downwards: the door under-reports and ENiGMA½ is what actually enforces.
The figure is whole minutes, because that is the unit the budget is kept in — time is billed a minute at a time. A door told “5 minutes” therefore has between four and five real minutes, depending where in the current minute it started. ENiGMA½ does not shave a minute off to hide that, the way current WWIV does, because the pre-check that decides whether a door may start at all works from the same number and the two would then disagree.
Each of the older formats carries a field naming the connection the door has been handed — DOOR32.SYS comm type and socket handle, DOOR.SYS comm port, DORINFO serial port. ENiGMA½ writes them to match how the door is actually launched, defaulting to local (stdin/stdout). Only abracadabra setups where an emulator or bridge sits in between need to say otherwise; v86 reports serial on its own, since it bridges the caller to the guest’s COM1.
See Also
Section titled “See Also”- Door Servers — DoorParty, BBSLink, and other hosted door services
- Telnet Bridge
- Scripts & Native Binaries
- External DOS Emulators
- Native v86 Emulation