Technical White Paper Example

By in portfolio on January 17, 2018

BBSing Today — Obsolescence vs Coolness

 

Wensley Evolo

01-12-2018

CONTENTS

    1. Acknowledgements
    2. Abstract
    3. Methodology
      1. First Incarnation (2011 – ’12)
      2. Second Incarnation (2014)
    4. Conclusion
    5. Appendix A — If Interpreters
      1. Games Choice
    6. Appendix B
      1. How to Connect to a BBS in the Web 2.0 Age
          1. SyncTERM
    7. Bibliography

 

Acknowledgements

I wanted to thank my mentor Megga Hertz, of Acid’s Remorse, the dominant outfit of the ANSI/ASCII art underground scene, for the unselfish, indirect mentoring he imparted on me through Tyrone, in or around 1996.

I must also thank my only IRC companions, my peers at #Remorse on EFnet (c. 2000), for accepting me into the fold.

With the broadband explosion that was going on in those years, BBSing was dying and to be accepted in the greatest ASCII art group of all time made me stay in the scene when I would otherwise have quit.

 

Abstract

When it comes to BBSing like it was 1994, there are several options to run a BBS on modern hardware and operating systems. To give three examples, there is Synchronet for Windows and *nix, Mystic for Windows, DOS, OS/2, OS X and *nix,  and DayDream for Amiga and *nix and I guess there have to be also a significant choice of contemporary BBS-hosting software for Mac too.

But where is the fun of throwing by the window all the handsome BBS software of the past? If one can appreciate the beauty and get over the fact that BBS culture was current more than one generation ago, there is still a living BBS scene, so why not using old — and rad — BBS software?

In this paper, on a first instance, I will take on account the time that the first phase of the project took as a factor in the Fun vs Drudge Equation for every stage of the project’s tasks; especially about how using legacy software can prove a time-sink and obstacle in the implementation process.

The first live version of the BBS was a crippled take on streamlining old telecommunications applications with retro-gaming. To use a customized version of the BBS as front-end, and a games server to serve single-player text adventures of the past.  This first incarnation didn’t feature the common BBS functionalities of message, files bases, and the rest because the sysop couldn’t make those work.

On a second instance, I will outline the steps I followed to let the BBS software of my choice (System/X) functioning at 99{0bc93539f1061688bfec0a90fc32a2acba3e45380d8bf45202d582a7f0edb817} 1990s-BBS-radness working order. The second phase, more than two years later, was a new start. A clean installation of the vanilla version of the BBS software. I managed to make it work on a server running Windows 7 32 bits, with almost all the features BBS were known to have available back in the ’90s.

 

Methodology

As starting samples I used Desire 1.5 and System/X 1.5e (1.5 Alpha Strike Eagle edition) for the game server front-end BBS. And NetFOSS 1.04 and Net2BBS as fossil driver (virtual modem) and telnet server respectively.

For the final deployment, I used System/X 1.5a for the BBS and Gamesrv 3.10.19b2 as virtual modem/telnet server.

 

First Incarnation (2011 – ’12)

At first, I used an already configured version of Desire 1.5 on Windows 2000 professional. I configured this setup of Desire 1.5 somewhere in 2004 on Windows 98 on a non-networked computer. Operating system-level compatibility issues were not present.

I was expecting to take advantage of Desire’s compatibility with System/X  (version 1.5e) to make use of the varied door collections available for both systems. I don’t remember exactly the issue, but Desire was a tough BBS software to return to BBSing; after more than a lustrum of, as I was back then. The issue might have been a crash on load-up kind of problem because I don’t remember spending much time with it.

Desire or any old BBS software can be put to use with the help of DOSBox.

I’ve visited BBSes running legacy BBS software that ran on DOSBox. I just didn’t want to go the extra mile, knowing that the hardware was old and that if it broke it would be a hassle to migrate the BBS. Also, I didn’t know how much overhead running the BBS on DOSBox would add to that old computer I was using as server (it was an HP Vectra from 1997, running Windows 2000).

I used NetFOSS as virtual modem and Net2BBS as the telnet server. The telnet server package included these two utilities. It worked right from the first try. The setting up of it was through a simple .ini file and the command line of NetFOSS’ batch file required just basic shell and batch script knowledge.

I got a sub-domain thanks to the free services of Afraid.org and begun testing the server through it.

After minor incongruities with the former installation were fixed I realized that the version of Desire I had, an unregistered copy, did not run doors and decided to try the other already configured setup I had tweaked in 2004 which was System/X 1.5e Alpha Strike Eagle edition with dA bALHED’s undocumented add-on doors).

This customized version of System/X, released by the scene group Providence, which was available in warez BBSes around the time the software was released, came with a large set of doors already installed.

The problem with this customized version was the lack of the documentation for the doors that came bundled with it.

Also, there were many different doors for a single BBS task of which only one was installed and there were moments that the lack of any information on which was which made me feel at a loss pertaining the supposed goodness of this pre-configured 1.5e version as opposed to the original,  plain System/X 1.5a.

As a matter of fact, if any of the many doors it came with had a READ-ME.1ST, it sure wasn’t of any use. The only thing I had was the BBS software manual, a 116kB plain text file in the System/X folder.

I must have configured and tried to get the meaning of poorly-written System/X documentation during the first week of the research, but R2D2’s manual-writing style was muddy at best and, thanks to it, one of the things that took me the most experimentation to understand was that I needed to create a directory with a copy of all the doors and of all the text files (and to keep other data files) for each and every node that the BBS will host.

Today I’m still not sure if this was the way that it ran on MS-DOS.

This way of managing nodes was a mess, in my humble opinion. I implemented just five nodes, but imagine a scenario of two-dozens nodes, to have to have twenty-four folders for each node, with equal copies of all the BBS data and executable files (screens the user sees, file bases, message bases, doors) which are in the neighborhood of three-hundred per node. That would tax the server to no-end.

I found a problem with the full-fledged BBS setup: if one user was online, say, browsing and using the message bases, and a second user in another node happened to be accessing the same data at the same time, one of the two would have a broken experience of the BBS.

I couldn’t narrow down the cause of this, but my theory is that it has something to do with the obsolescence of the share.exe DOS tool, caused for using a sixteen bits DOS software and its tools on 32 bits Windows 7.

I think that a normal installation of System/X on a computer running DOS or a sixteen bits Windows would require a simpler directory and node structure.

I guess that without the bugs and making correct use of the share.exe DOS resident program, the software would work as it was intended to be, with centralized message, file, door, menu, and bulletin bases. By centralized I mean that they are all node independent and System/X would somehow manage the accessing of that data by two users at the same time without issues.

The only way to make the BBS work as it should, natively, on Windows 7 that I found was having all the BBS data mirrored in each node. To achieve this I had to program additional batch script code to, once a user ends a session, synchronize the node-specific changes in all the other four nodes.

Like so:

:node1

copy /Y c:\BBS\NODE1\CONF1\MSGBASE\*.* c:\BBS\NODE2\CONF1\MSGBASE\
copy /Y c:\BBS\NODE1\CONF2\MSGBASE\*.* c:\BBS\NODE2\CONF2\MSGBASE\
copy /Y c:\BBS\NODE1\CONF3\MSGBASE\*.* c:\BBS\NODE2\CONF3\MSGBASE\

copy /Y c:\BBS\NODE1\CONF1\MSGBASE\*.* c:\BBS\NODE3\CONF1\MSGBASE\
copy /Y c:\BBS\NODE1\CONF2\MSGBASE\*.* c:\BBS\NODE3\CONF2\MSGBASE\
copy /Y c:\BBS\NODE1\CONF3\MSGBASE\*.* c:\BBS\NODE3\CONF3\MSGBASE\

 

Besides the nodes/directories problem, when I had a (seemingly) working configuration I was confronted with a new blunder. The first truly severe problem until that moment. Using Net2BBS with NetFOSS prevented, for some reason that escapes my knowledge, the text output of the BBS’ doors to show in a remote terminal screen.

The problem was that when I used a command that entailed the firing up of some door, the door’s output won’t show on the remote terminal program that I was using to connect; it will do in the server’s local BBS screen, though.

I lost around a day trying to fix this by means of passing different switches and parameters to NetFOSS’ command line in the batch file that came with it; the one that fires up when the server receives a connection request, NF.BAT if my memory serves me right.

On the second day of frustration, I decided to ditch NetFOSS/Net2BBS.

The problem escaping my knowledge was the incapability of NetFOSS to redirect modem-based applications to virtual COM ports and redirect to TCP/telnet for the output of the doors to show remotely.

I was advised on IRC against using Gamesrv but I wanted to give it a try since I couldn’t find any way to fix the doors’ output problem. At first I fiddled with the latest version, but soon found it too difficult to configure; actually, the user-sensitiveness I expected wasn’t there at all, in the latest version.  Still, I was sure that the software was of use for what I wanted to do because a few days before I connected to a BBS running on PCBoard with Gamesrv as a call-answering and login matrix.

I installed Gamesrv 3.10.19b2 and configured it, a task that might have taken barely five minutes to complete and the next thing I knew was that the doors’ output was showing remotely they way they are supposed to do it.

I ran many BBSes in the past, about half-dozen of them. I used Remote Access, PCBoard, and Waffle and each of my four or five boards had each a different theme to it. They were all traditional in the sense that they supported all the features common to BBSes in their heyday.

But that is as far as coolness would go at first, because most of the other features, the core BBS ones, didn’t work and I made myself believe that I wanted to strip my new BBS of the features that “didn’t age well at all,” namely: message forums and file areas. In fact it was a way to cope with my inability to make those features work.

I achieved this simply disabling the commands for uploads, message writing, message reading and all other commands and jobs related to these three tasks, for example file area search, message search, and generation of transfers statistics bulletins, among others.

My idea was to create a text games server based on what was considered the rad system that System/X used to be.

For the games, the approach was to create three different areas of the BBS for each genre: punk, horror, and science fiction.

I did a fast overview of what contemporary BBSes were offering in the way of BBS text games and found that, sadly enough, many of the systems online at present share at least one or two games in common with other competing, contemporary BBS.

 

Second Incarnation (2014)

I installed System/x 1.5a, moved all the configuration and text files, and configured the nodes in the correct way and the BBS worked well. At least all of its features worked, unlike the first time around, with the customized one.

Instead of using Gamesrv again, I gave a fresh new try to NetFOSS and Net2BBS. They seemed to run okay for a while, but a new problem came up.

Since I was running System/X natively, I was using its answering mode, just like it was done in the past when it was through the telephone line.

Net2BBS just passed the telnet carrier to System/X and login was achieved.

This worked, but there was a problem. The telnet server began receiving connections from port-scanning spiders and this kind of activity froze System/X.

The easiest and, despite not being seamless, solution I found was going back to Gamesrv and using it as a login matrix.

In the 1990s, many BBSes had login matrices. Most of those that did, it was because the owner might have had restricted access to the system.

The login matrices served the purpose of applying for membership and checking the state of the membership application, among other things that login matrices did. They also had features like paging the sysop right from there. Some were like a mini-BBS that the user could use even before login into the BBS proper.

I configured Gamesrv to mimic a minimalist login matrix and edited the .exe file with a binary editor to remove the splash text that tells the user that he logged to Gamesrv and which version. In this way, I got rid of the port scanners and brute force attacks.

Software Used

Windows 7 32-bit
Gamesrv v13.07
System/X v1.5 Final
Doorway 2.22

Who could have known that System/X and Doorway would work natively an be rather stable on Pentium M architecture? I wouldn’t have believed it if told so. I wanted to have something similar to the old thing, not to add the extra processing and overhead that DOSBox would bring.

 

Conclusion

The first version, the one without full BBS functionality took nine days of six or more hours per day work. I did it in the dog days of the summer of 2011 when I should be relaxing instead.

I toiled with the incredible unresponsiveness and weird errors and malfunctions all the old software produced in the implementation process.

It wasn’t fun, it was a chore, and I felt I was losing time with obsolete software. Nine days is a long span of time if taken into consideration how much time takes to deploy any games front-end software in a Windows setup; a mere five to ten minutes and you are playing.

While in the first instance I was willing to conform to the maimed BBS experience I created. I believed that no one else other than me could be interested in the thing, but I knew it wasn’t satisfactory nor cool. I was just being dishonest with myself.

To rationalize that I was doing it just to showcase my smartness at picking interactive fiction games was part of a thought process that went a little like this: “there isn’t any interpreter-neutral front-end for IF games yet, so I did this to have a sort of front end where I only need to push a key to load an interactive fiction game and just the same for a totally different game and interpreter. And what better than to share it with others.”

After a while, maybe two, three or four months later the, HP Vectra I used to host the BBS died. In the two years that the BBS was down, the thought of having invested a considerable time in it, only for the project to fail, ate me. But I thought it wasn’t worth the pain.

But the fond BBS memories of my teenage years endured, so much, so that the first thing I did after learning inter-networking in 2014, was picking up the project where I had left. I knew that it would be a cinch to set it up — even with the lag, but the benefit, of not having to type in the laptop I used as the server — with my newly acquired knowledge. I did all the 2014 BBS work remotely, using TightVNC.

When I picked it up again, somehow I exhausted all the documentation, something that I don’t remember doing but I think also did the first time.

With that, plus the ease granted by newly acquired inter-networking knowledge, in about three days, my stubborn resolve to get a BBS working bore fruit.

I did it the way I wanted to do it, running natively on Windows 7 x32, without the help of DOSBox and with all the BBS features in place like I really wanted.

As of the updating of this white paper today on early 2018, I’m using Gamesrv v14.09.10. In the last years Gamesrv evolved and now it has an auto-ban feature, which is great to deal with the brute force attacks (which are constant) and this version of Gamesrv even has text-mode waiting screen, like in the good old days!

 

Appendix  — IF Interpreters

Years ago, probably in 2005 or so, I did research the best IF (Interactive Fiction) games available for free. To do this I studied a couple of IF games review magazines and other documents. The publication that provided me with the most information about which IF games were worthy of playing to was the “Society For The Promotion of Adventure Games” e-zine.

Reading the e-zine’s reviews I made a long list of IF games that I considered were the best exponents of their respective genres, and about ninety percent of this list were of text adventures that were participants on the Annual Interactive Fiction Competition (ifcomp.org).

I had thirty-four games in the original list, of which I chose nineteen to add to the game server. To do that I used Dudley Marshall’s Doorway v2.11. It took me several hours to get right the switches and parameters of the batch file for each door.

I found that the two most easy to implement IF formats were Inform and Adrift. In the list of games I chose to host there were other formats, like AGiliTy, TADS, and Glulxe, but these gave me so much trouble to set up with Doorway that I decided to just use Inform and Adrift games. GlkDOS 0.19.1 and Frotz 2.43, both for DOS, were used as the interpreters for the Adrift and Inform games.

I found out that no matter what switches I’d pass to both Doorway and the interpreters, the game just won’t display correctly in 80 by 50 lines of text. Because of this, the original list of around nineteen games was reduced to a dozen.

 

Frotz command line:

c:\bbs\node1\conf1\doors1\doorway.exe COM1F /H /M:48 /G: /F /O: /P:c:\bbs\node1\conf1\doors1\frotz.exe -d 0 -i -Z 0 <game>.z5

 

GlkDOS command line:

c:\bbs\node1\conf2\doors1\doorway.EXE COM1F /O: /V:D /G: /H: /M:48 /F: /P:c:\bbs\node1\conf2\doors1\GLKSCARE.EXE <game>.TAF

 

Games Choice

The games to host were of the punk, horror and science fiction genres (and sub-genres). Only Inform and Adrift format games were implemented.

 

Punk Section

  1. Punkirita Quest 1 (Stevens, 1996) bizarre/fantasy
  2. Punk Points (Munroe, 2000) punk bildungsroman
  3. Adoo’s Stinky Story (Perry, 2003) punk
  4. Slouching Towards Bedlam (Ravipinto and Foster, 1996)  Victorian steam-punk (had to take it off, was not playable remotely)
  5. The HeBGB Horror! (Mayer, 1999)

 

Horror Section

  1. House of The Damned (McCall, 2000) horror
  2. The Zuni Doll (Burneko, 1997) horror
  3. Theatre (Wyber, 1995) horror
  4. Requiem (Whyld, 2006) horror, mystery
  5. Crypt (Herring, 1990) horror
  6. Madame L’Estrange and The Trouble Spirit (Ball and Young, 1997) horror mystery, science fiction

 

Science Fiction Section

  1. The Mind Electric (Dyer, 1995) science fiction,
  2. The Edifice (Smith, 1995) historical science fiction.
  3. Photopia (Cadre, 1998), surreal

 

Bibliography

Marshall, Dudley. Doorway 2.11 literature. Knoxville, TN 1987, 1988, 1989. Data World BBS, 1990.
Monfort, Rick. Twisty Little Passages: An Approach to Interactive fiction. USA 2003. MIT Press 2005.
Parrish, Rick. Gamesrv 3.10.19b2 literature. USA: R&M Software 2001. [available online: http://gamesrv.ca/documentation.php]
PC micro systems, Inc. NetFOSS 1.04 literature. Thousand Oaks, California: PC micro systems, Inc. [available online: http://pcmicro.com/NetFOSS/guide/]
R2D2. System/X Bulletin Board Software – Version 1.5a literature. UK: Fairlight and Hologram, 1995.
Squizzy. Desire Boardsystem version 1.5 literature. The Netherlands: xROADS, 1997.
Sadofsky, Jason Scott. GET LAMP. USA 2010. textfiles.com, youtube.com 2010. [available online: http://www.getlamp.com/]
Wilson, Kevin. SPAG e-zine. USA 1994-2011. David Monath, 2011. [available online: http://www.sparkynet.com/spag/]

 

© Wensley Evolo, 2012-2018.

Comments are closed.