Native Windows doors

A native door is a 32-bit or 64-bit Windows program that ProBoard starts directly. It receives the caller's connection through a DOOR32.SYS drop file (communication type 2: an already open socket handle). It needs no FOSSIL, no COM port and no DOSBox.

16-bit DOS doors are different. See DOS doors.

Setting up a native door

Unpack the door into its own folder, for example C:\PBDATA\DOORS\<DOORNAME>. Give every door a folder of its own. It is the door's work directory and holds the game data that all nodes share.
Add a block in Network > Door Configuration in PBConfig (this edits DOORS.PRO in Configs).
Make a menu item using the function Run a door, with the door's name as its data. The name is the word after door in the block, in any case, for example PIMPWARS.
Test with one caller, then with two nodes at the same time.

The Edit Door window

In Network > Door Configuration, Insert or Edit opens the Edit Door window. It is a form for the block described below.

Figure 1. The Edit Door window for a native door.

Field	What it is
Name	The door's name. This is the word after `door` in the block, and the data you give the menu item.
Door Type	Legacy (PBLegacy / DOSBox-X) for a 16-bit DOS door, or Native (Win32/Linux program). The fields below change to match.
Native Exe	The door's program. Use Browse to pick it.
Native Args	Command-line arguments.
Work Dir	The door's own folder.
Drop File(s)	Which drop file to write: `door32` for a Windows door.
Drop Dir	Where to write it. Leave it blank to use the node's own folder.
Delete the drop file(s) after the door exits	On by default.
Time Limit (min)	How long a caller may stay in the door.

The window also reminds you that Native Exe, Work Dir and Drop Dir may contain %NODE% (the live node number), and that Native Args may contain %DROPDIR%.

Settings in a native door block

door DARKNESS
   type        native
   nativeexe   C:\PBDATA\DOORS\DARKNESS\DARK32.EXE
   nativeargs  /N%NODE% /D1 /P%DROPDIR%
   workdir     C:\PBDATA\DOORS\DARKNESS
   dropfile    door32
   timelimit   60
enddoor

Setting	Meaning
`type native`	Marks the block as a native door.
`nativeexe`	Full path of the door's program. May contain `%NODE%`.
`nativeargs`	Command-line arguments (optional). May contain `%NODE%` and `%DROPDIR%`.
`workdir`	The door's folder. The door starts here. May contain `%NODE%`.
`dropfile`	Which drop file to write: `doorsys`, `dorinfo`, `door32`, `callinfo`, `chain` or `all`.
`dropdir`	Where to write it. Blank means `NODEDIR\NODE<n>` (one folder for each node, the default). `workdir` writes it into the door's own folder, the old behaviour. Or give a path (it may contain `%NODE%`).
`dropclean yes\|no`	Delete the drop file when the door exits. Default yes.
`timelimit`	Minutes. ProBoard closes a door that is still running five minutes after this.

Tokens. %NODE% is the node number. %DROPDIR% is the folder holding the drop files, without a trailing backslash, so %DROPDIR%\DOOR32.SYS is the full path of the drop file. The same folder is set in the environment variable PB_DROPDIR for doors that read one.

Choosing the drop file

Prefer DOOR32.SYS for any Windows door. It is the only format that carries the caller's socket handle, which is what lets the door talk to the caller. DOOR.SYS, DORINFO1.DEF, CHAIN.TXT and CALLINFO.BBS carry the caller's details but no usable connection for a Windows door.

Rules of thumb

A door that takes a drop-file folder (such as /P or /D) gets %DROPDIR%. A door that takes the drop file's full path gets %DROPDIR%\DOOR32.SYS. A door with no such option reads the drop file from its own folder: use dropdir workdir.
Anything shared (player files, databases) must live in the door's folder and be the same for every node. Only the drop file is per node.
Never give two nodes the same drop-file location, because DOOR32.SYS holds that node's socket handle. The default node folder takes care of this.
If you upgraded and a door that used to work cannot find its drop file, the default moved from the door's folder to the node folder. Either add /P%DROPDIR% (or the door's equivalent), or add dropdir workdir.

The node folder

Everything that belongs to one node lives in <data dir>\NODEDIR\NODE<n>, created the first time the node needs it. It holds the message editor's scratch files, the DOWN file (create it to take the node down after the current caller), ISDOWN, the node's chat buffer and the door drop files, which are deleted again when the door exits. The user file, message bases, the log and every configuration file stay shared.

Doors that are known to work

Door	Notes
Darkness 2.0	Multi-player fantasy door by Jay Phillips. Use `DARK32.EXE`. Run `DARK32.EXE /CFG` once to create `DARKNESS.CFG`, and set the drop file type to `DOOR32.SYS`. Switches: `/N` node, `/D1` drop type, `/P` drop folder. Multi-node.
Pimp Wars 1.53	Turn-based street game (Win32/Door32 version). No configuration. Arguments: the drop file's full path and the node number. The game creates its own player and message files; delete any left over from someone else's game before going live. Multi-node.
Ambroshia: Test of Time	Large fantasy role-playing door, shareware. Run `AMBLaunch.exe`; keep the whole folder together. Daily maintenance runs when the first player logs in; run `AMBLaunch.exe /TRYMAINT` from a nightly event to be safe. Daily backups go in `Backups`. `AMBConfig.exe` resets the realm: never run it on a live game. Multi-node.

Block examples for Pimp Wars and Ambroshia:

door PIMPWARS
   type        native
   nativeexe   C:\PBDATA\DOORS\PIMPWARS\PIMPWARS.EXE
   nativeargs  %DROPDIR%\DOOR32.SYS %NODE%
   workdir     C:\PBDATA\DOORS\PIMPWARS
   dropfile    door32
   timelimit   60
enddoor

door AMBROSHIA
   type        native
   nativeexe   C:\PBDATA\DOORS\AMBROSHIA\AMBLaunch.exe
   nativeargs  /N %NODE% /D %DROPDIR%
   workdir     C:\PBDATA\DOORS\AMBROSHIA
   dropfile    door32
   timelimit   60
enddoor