Table of Contents
Instructions for installing external online programs (a.k.a. doors) into the Synchronet BBS for use by users of the Terminal Server.
BBS “doors” are external online programs, often games, that may be installed on a BBS system for its remote terminal users to use interactively. Doors are usually 16-bit DOS programs from “back in the day” and can be challenging to get working on the computers and operating systems of today. A little patience and the use of pages like this one can usually get them working however.
Supported External Program Types
The following table should help you to identify what types of online external programs (doors, external editors, file transfer protocol drivers) are supported by Synchronet and in what environments:
|I/O Method||Description||Examples||Typical Drop File Types||OS|
|FOSSIL||16-bit DOS BBS doors and external editors||TradeWars 2002, GlobalWar, LORD, FDSZ||DOOR.SYS and DORINFO#.DEF||Windows|
|COM/UART||16-bit DOS BBS doors and external editors||DSZ, NukeWars||DOOR.SYS and DORINFO#.DEF||Windows|
|DOS Console||16-bit Synchronet and WWIV doors and external editors||Food Fight! Rigor Mortis, Dragon's Hoard, SBJ/SBL v2.x||CHAIN.TXT and XTRN.DAT||Windows|
|TCP/IP Socket||Native TCP/IP BBS doors and external editors||DoorMUD, PimpWars/Win32, Darkness/Win32, SBJ/SBL v3.x||DOOR32.SYS and XTRN.DAT||Windows and *nix|
|Standard||Native stdio/console programs (traditionally, UNIX)||PimpWars/Linux, Lord/X, “scfg -d”, cmd.exe, bash, pico||DOOR32.SYS||Windows and *nix|
Through the use of Deuce's
CIOXTRN.EXE program (similar to the old 16-bit DOS DoorWay program), DOS and Windows-native console I/O programs not intended to run on a BBS can also be run on Synchronet for Windows.
Doors are usually installed into a sub-directory of the Synchronet
xtrn directory. Example:
doorname is a short (8 characters or less) abbreviation of the door's name.
Tip: do not install DOS doors into a directory with a long name (more than 8 characters) or with spaces or other special characters in the directory name or the door program may not work.
Some doors may require the sysop to run some sort of setup or initialization program before the door can be used, so be sure to read the door's documentation files (e.g.
*.doc, etc.) first. Remember that most door documentation was written in the 1990's (or earlier), so take some instructions (specifically those referring to FOSSIL drivers) with a grain of salt.
If the door you're installing is listed in the following How-To Install pages, that might be all the instructions you need.
Runtime error 200
Some 16-bit DOS programs (including many old doors) which were written and compiled with Turbo Pascal will have a problem (divide by zero) running on faster computers. The error will show itself upon execution of the door something like this:
Runtime error 200 at 345A:0091
This is a well known problem (often referred to as “RTE200”) and there are several programs
which you can use to 'patch' the
.EXE files to fix the problem.
Which patch works seems to depend upon the program in question.
This is an entire page on the subject matter with links to several patching programs.
You may need to patch the
.EXE files before you can even install or setup the door.
With Synchronet on 32-bit Windows operating systems, you do not need to install a FOSSIL driver (Synchronet comes with its own). There is a free 3rd party FOSSIL driver for Windows NT-based operating systems called NetFoss, but you should not need it and installing it will only complicate matters. The old 16-bit DOS FOSSIL drivers (e.g. BNU, X00) will not work either.
This 16-bit DOS component of the Synchronet FOSSIL driver for Windows (all flavors) is called
DOSXTRN.EXE and it is located in the Synchronet
exec directory. This program will not work with 64-bit versions of Windows since Microsoft does not include a DOS virtual machine (NTVDM) with those versions of Windows.
The kernel component of the Synchronet FOSSIL driver for Microsoft Windows 95-based operating systems is called
sbbsexec.vxd and it is loaded when needed by Synchronet automatically. This FOSSIL driver is not actively maintained but has worked well for many sysops and their BBSes for many years. This FOSSIL driver implements the FOSSIL interface only (i.e. does not emulate a physical UART or COM port), so the doors must support and be configured to use FOSSIL interrupts for input and output.
The kernel component of the Synchronet FOSSIL driver for Microsoft Windows NT-based operating systems (this includes XP, Vista, and Windows 7) is called
sbbsexec.dll and it is loaded when needed by Synchronet automatically.
This FOSSIL driver is also a virtual UART driver so that external DOS programs that require COM/UART access for input and output (i.e. do not support FOSSIL), can still be used on the BBS. When supported, doors should be configured to use a FOSSIL interface instead of COM/UART for input and output (for better performance and compatibility).
This FOSSIL driver can be configured (tweaked) for the specific needs of your system or a particular DOS door program by editing your
Add the program in SCFG Online Programs under
Available Online Programs... in a new or existing Online Program Section.
The most critical SCFG configuration options for successful installation of an online program (door) are:
Enter a descriptive name for the program, but try not to be redundant (the words “door” and “game” and not likely useful in the name). Some sysops choose to include the version of the program as well as the name.
Enter a short (8 characters or less), unique name for the program which Synchronet will use for internal reference purposes.
The chosen internal code may not be the same as any other installed external program.
Start-up Directory should normally be the directory where the door was installed (e.g.
If the door was installed in a subdirectory of your
xtrn directory, it is recommended that you use a relative path (e.g. starting with
../xtrn/) rather than an absolute path (e.g.
/sbbs/xtrn/doorgame) as this will allow you to move the Synchronet directory tree to another drive or to another directory hierarchy without requiring modifications to your external program configurations.
On Windows, the
Start-up Directory may use forward-slashes (
/) or back-slashes (
\) as path separators, but for compatibility with other OSes, it is recommended to use forward-slashes (e.g.
../xtrn/doorgame/ instead of
Start-up Directory may or may not end in a trailing path separator (slash).
Start-up Directory is specified, the current working directory when the program is executed will be your Synchronet
An invalid (e.g. non-existing)
Start-up Directory will cause Synchronet to log and display an error message and not attempt to execute the program.
When executing an in-process Baja module (
.bin file), the
Start-up Directory is not used.
.js file), the
This is the command to be executed when a remote user launches this external program.
Some programs may require command-line switches or options to enable specific behavior (e.g.
/F to enable FOSSIL support) or specify the path to the BBS drop file.
As part of the command-line, you may use Synchronet Command Line Specifiers. These are variables which will expand to useful dynamic values before the command-line is executed.
The most commonly used Specifiers for use with external program command-lines are:
|Path to the drop file created by the BBS for this external program execution (e.g.
|Path to the current node directory (e.g.
|Current node number (1-255)|
|Current socket descriptor|
|User's time remaining/available, in seconds (e.g.
The path to the module and the
.js file suffix/extension is not required.
Clean-up Command Line
This is an optional command-line to be executed after the program has returned control to the BBS.
Clean-up Command Line may contain Command Line Specifiers.
Most external programs do not require a
Clean-up Command Line to be specified.
This optional value is the number of credits to deduct from the user when executing this program.
This is the optional Access Requirements String (ARS) which specifies which users may see this program (default: all users).
This is the optional Access Requirements String (ARS) which specifies which users may execute (run) this program (default: all users).
If you are host BBS nodes on multiple OSes and this program is only compatible with a subset of those OSes, you may want to specify the compatible ARS OS keywords here (e.g.
Multiple Concurrent Users
If this program supports execution by multiple simultaneous users, then this option should be set to
Note: for multiple-user programs, it is highly recommended that the BBS drop file be created in the
If this program requires the BBS to intercept standard console input and output operations, then this option should be set to
- Most BBS doors will require this option be set to
- BBS Doors that use FOSSIL I/O must have this option set to
- BBS Doors that use COM/UART I/O must have this option set to
- BBS Doors that use Socket I/O must have this option set to
Intercept I/O option is not used.
If this program is native to the host operating system (e.g is not a 16-bit DOS program), then this option should be set to
- BBS Doors that use FOSSIL I/O are inherently 16-bit DOS programs and must have this option set to
- BBS Doors that use COM/UART I/O are usually 16-bit DOS programs and should therefore have this option set to
- BBS Doors that use Socket I/O are native (32-bit or 64-bit) programs and must have this option set to
Native Executable option is not used (all modules are native).
Use Shell to Execute
If this program requires a command shell (e.g. it's a *nix shell script,
.sh file, or Windows
.cmd file), then this option should be set to
Modify User Data
If this program supports modification of the user's data via drop file, then this option should be set to
Execute on Event
If you wish for this program to be automatically executed based on specific user operations, you may select those events here.
The available events are:
- New User
- Message Posted
- File Uploaded
- File Downloaded
If an event is selected, you may also specify that the program may be executed only on that event and not purposely selected by the user from a menu for manual execution.
Normally, this option is set to
No for most door programs.
Pause After Execution
This option may be useful if you wish to debug a problem with a program which is displaying text just before quitting and the screen is being cleared (and you don't have scroll-back capabilities).
Normally, this option is set to
No for most door programs.
BBS Drop File Type
Most BBS door programs require a drop file to be created by the BBS in a predetermined format and often with a predetermined filename.
This menu option allows you to select the proper drop file format, name, and case (sometimes important on non-Windows systems) and whether or not to include the user's alias or real name in the drop file.
The available drop file formats are:
Place Drop File In
If the path to the drop file (e.g.
%f) is included on the
Command Line, then it may not matter where the drop file is created.
However, for multiple-user programs, it is highly recommended that the drop file be created in the
node directory to avoid collisions and race conditions between nodes.
This sub-menu allows you to specify certain time constraints and monitoring behavior while the program is being run by the user.
Time Options settings are: