SPONSORED LINKS

What is this?

This is a patch that integrates support for the Linux DOS emulator into the Synchronet BBS software written by Rob Swindell.

The purpose of such integration is to enable the sysop to install new DOS doors in a simple and straightforward manner, and to be able to easily work around the inevitable emulation-related problems that will occur.

Getting Started

CVS flavor

If you are setting up a new BBS, follow the instructions in sbbsunix.txt that can be found at the Synchronet homepage to get a fresh copy of the source code for the BBS using CVS.

* Once you have the source code, grab the diff from the files section, and apply it like so:

$ cd /usr/local/sbbs/src/sbbs3
$ patch xtrn.cpp < /home/somewhere/sbbs-dosemu.diff

The patch should apply without any problems as of 03/05/2003. (xtrn.cpp v1.124)

Next, build the BBS (make -f GNUmakefile) and complete the initial configuration according to the instructions in sbbsunix.txt.

SBBSINST flavor

If you are using the SBBSINST program to bootstrap your Synchronet installation, follow the instructions above starting at "* Once"... However, the default symbolic link for the sbbs executable links to src/sbbs3/gcc.linux.exe.release, whereas the newly built executable resides in src/sbbs3/gcc.linux.exe.debug. Simply change the link exec/sbbs3 to point to src/sbbs3/gcc.linux.exe.debug/sbbs instead, relative to your Synchronet base dir. Example:
# ln -sf /usr/local/sbbs/src/sbbs3/gcc.linux.exe.debug/sbbs /usr/local/sbbs/exec/sbbs

Setting up a DOS BBS door

Few requirements first off:

To configure a DOS BBS door in scfg:

You probably want to also add the door's setup program as a standard I/O program (see below for details on standard I/O programs).

When you set up the door, point it to D:\ for the dropfile path. Also, generally it would be a good idea to tell the door to use a fossil driver, unless it doesn't work or produces strange results (like missing lines or dropped characters), in which case you can use the internal comm routines of the door.

The door's actual directory will be mounted on E:\ with the root of E: being the parent directory of the door. So if your door is in /usr/local/games/tw2002 on the Unix side, it will be in E:\tw2002 on the DOS side. Make sure the door's directory conforms to the DOS 8.3 file format! /usr/local/games/tw2002 would be okay, but /usr/local/games/TradeWars2002 would not. The symptom of a non-conforming directory is a "file not found" when Synchronet tries to change to the DOS door's directory inside DOSEMU.

Make SURE that if the door is started with a .bat batch file, that you explicitly name it as such in the "Program Name" field. For instance, LORD's "start.bat" command would be entered as "start.bat %#", not just "start %#". Failure to do this will cause the session to be hung inside DOSEMU when the user exits the door. (You can still exit by blindly typing exitemu, but...)

The default dosemu.conf and emusetup.bat should be in your ctrl dir. These will be used if the door's directory does not contain a dosemu.conf and/or emusetup.bat. If the door's directory contains either one, it will override the default global ones that are in the ctrl dir. This way you can set up a default config that works for most doors, and then work around problematic doors easily by creating a custom config for each of the problem doors. (Example: emusetup_tw2002.bat)

Setting up a non-door DOS program as a door

Basically, setting up a non-door DOS program is done following the same procedure as a door. The key difference is that you set Redirect STDIO to Yes for a program that is not designed specifically to run as a BBS door.

You can also set up timed events (e.g. door daily maintenance programs) in this same manner. Just make sure Native Program is set to "No" and it will work fine.

It would probably be a good idea to set up command.com as an external, so that you can get access to a DOS shell through the board. From there, you can do things like the initial unzipping and setup of door software with ease.

Known Problems

File locking is dysfunctional with the DOSEMU 1.0.2.x stable releases. File locking problems will manifest themselves as strange error messages related to file opens, long pauses and/or hangs, game data corruption, and other fun stuff. Note that you do not have to be running a multinode BBS to be prone to these issues; most programs detect DOSEMU as a multitasker and thus initiate their lock management regardless of whether or not multiple sessions of the game will be in use. DOSEMU 1.1.4.x development release does not have this issue, so you might be better off just to compile and use that.

There is a fix from Bob Newell which is detailed in this document. Included is a fix for slow screen draws due to incorrect idling that will occur in some games such as Planets TEOS.

Here is a precompiled version here that may or may not work on your machine. (It was compiled from the Debian sources.)

If you are having other problems:

Miscellaneous info: