A guide for using Dosemu2 to play Door Games on Mystic BBS

As you can see, the process of getting Doors to work on Mystic BBS is really straight forward however, many of the "assumptions" have been lost to time.  For instance, most of the documentation from the late 90's made the assumption that the Sysop knew how to use DOS and how to configure the BBS.

With the rise of the Internet and dominance of Windows there was no reason to know how to use DOS and running a BBS translated to running a website, creating HTML, writing JavaScript and building dynamic apps using web enabled coding languages and back-end databases. 

The resurgence of Bulletin Board Systems is more of a Retro Nostalgia thing with hipsters trying to figure out what BBS culture is and ageing Gen-X'ers trying to get back some of their youth.  Some boards have a nice cult following while others are just out there.  There is virtually no reason for running a BBS anymore except for fun.

For me, running a BBS has been a great experience and isn't much different than running a members-only website.  My intention is to have the BBS as part of my Retro PC projects and YouTube videos while also giving me an excuse to create some nice ANSI graphics again.

When researching information for this article I discovered several things.  Some of them really don't matter while others are kind of funny and help to describe the community surrounding the BBS culture.  Since this article is based on Dosemu here are some of my thoughts and discoveries.

[rant]

Dosemu (1) was an emulator that relied on FreeDOS as its command shell, you could replace this shell with any flavor of DOS however, as I understand it, the group only supported FreeDOS.

Dosemu2 comes with its own command shell they call Comcom(64/32) and is required for the emulator to work.  The group has also developed their own version of FreeDOS called FDPP, (FreeDOS Plus Plus) which is also required to install the package.

Once Dosemu2 is installed you are given the opportunity to replace these command shells however, the process is largely undocumented, unsupported and based on comments from the package maintainer, creates more problems than it is worth.  I suspect this is 100% related to the aforementioned poor documentation and the nature of the people attempting to use it.

Personally, I have used comcom64 + fdpp and find that it works extremely well, boots fast and, is almost complete garbage from a usability standpoint.  The maintainers don’t separate their code so whenever they want to debug something you often get to debug with them.  Normally I am all for this but, I really have a problem when things are not consistent or when I get 10mb+ log files for no reason.  Debugging should be a switch you enable, not a stub that gets invoked at the code level.

I also find it interesting that *.deb packages are available but, only for Ubuntu and some other distros.  This is great if you are using Ubuntu as you can simply attach to the PPA and download the code along with everything else you may need. 

However, if you are like me and prefer Debian or Slackware you have two options.

1. For Debian, I found that *I* could not attach to the PPA but, was able to download the *.deb packages manually and install them from the command line.
   
   
2. For Slackware I found the problem that “this shit don’t compile”.  There are so many undocumented dependencies making the process literally more trouble than it was worth.   I did try to compile on Debian using their “Debian directions” and even that was a shit show.

Bottom line: the package maintainer appears to be an Ubuntu user, most of the people using Dosemu2 have been forced to use Ubuntu and, it shows.  There is nothing wrong with Ubuntu, it seems to be designed for the casual Linux user who knows just enough to be dangerous and is too timid to do anything about it.

[/rant]

If you choose to run Dosemu2 + fdpp the setup is almost identical with a few notable differences

• Drives are not mapped using the Lredir command in the batch file. Drives are mapped from the dosemu command line with -d. 
  Eg:  /usr/bin/dosemu -d"$NODE/" -I"video { none }" -I"serial { virtual com 1 }" -E"C:\\NODES\\TEMP$1\\$2" -o"$DROOT/dosemu_boot.log" 1>/dev/null  2>&1
• Remove the lredir command from the batch file generation
• Fossil and ansi drivers are added to “userhook.sys”

If you choose to run Dosemu2 + MS-DOS the setup is identical to FreeDOS except for the command shell

• Copy “command.com, msdos.sys, io.sys” to .dosemu/drive_c
• Create a DOS/ folder for system files
• Copy up “config.sys, autoemu.bat” from /usr/share/dosemu/dosemu2-cmds-0.3 and place them in .dosemu/drive_c

Why not generate external.bat in the Mystic local temp(x) directories

• From a workflow standpoint Mystic BBS will clear the drop files placed in temp when the Doors close. If we wrote external.bat file there it wouldn’t be part of the cleanup. 
• I also like the idea of going to the .dosemu folder for debugging. That way you can view the contents of the drop file and the external.bat we generated to run the door, check for syntax errors AND run it locally if needed.

But, the Dosemu2 D:  drive is mounted READ-ONLY why are you trying to get us killed?

• Ok, so that is a bit dramatic. From a workflow standpoint the only things accessing the dosemu/ symlink is the BBS via a shell script.  I don’t see any harm in that.  It isn’t a super secure sandbox but, neither is Dosemu2

Where is your github, the world uses github when creating awesome stuff

• As of this posting, I have no github. This article will be duplicated across my YouTube channel and this website.  Eventually there will be an archive posted on my BBS for download. 
• Ninjalane and Hardware Asylum have been online for the past 20+ with no real intention of closing up shop. Eventually I will post something on my BBS, until then you can simply use the information in this article as a guide and, if you want real code then check out the links provided.

Mystic BBS provides a /DOS switch when launching doors

• I noticed this and have also noticed that FreeDOS seems to be able to read the Mystic BBS drop files without the unixtodos conversion.   If you want to use the built-in functionality you can comment out the lines that trigger unix2dos. eg:
  
  unix2dos $NODE/DOOR.SYS 2>/dev/null
  
  Just be sure to add the DOS switch to your door launch command.

What about the Raspberry Pi??

• One of the reasons I wanted to figure out Dosemu2 was due to there being packages for the ARM64.  Sadly, it doesn’t work as well as you would think.  If you are using a Debian 12 based distro then Dosemu2 will install just like on an AMD64 machine.  If you are using an older version of Raspbian (The current default one) you are SOL.
• I was able to get Dosemu2 running on the Debian port of Armbian and works great until you want to use it with a BBS.  For some reason, Doors hang when invoked, which is annoying and shows that the maintainers generally focus on the AMD64 version.