If already know what white paper is, you can jump directly to the technical white paper example below. If you need a definition of white paper, a very abridged one would be: a piece of long-form content that is used as a sales, promotion, marketing, inbound marketing, or content marketing tool. White papers promote the products or services of a company. White papers shed light on the favorable benefits and pros of a product, service, or commercial outfit.
Their meat is the hard facts and data concerning the topic, giving the reader a substantial and actionable quantity of knowledge about the product or service they promote. They are also known as technical white papers. In this white paper example, you can also notice how the narrative style takes the backseat and how the technical details come to the fore.
This white paper example might be what you would call a Mickey Mouse technical white paper since it does not just touch an obsolete technology, but also touches a tech that, when it was current, was something that was more at the hobbyist level than the professional one. Please excuse me if you feel those two facts insult your intelligence, but the topic of the example wasn't as important as getting the format right for the example to be useful.
- Technical White Paper Example
For this technical white paper example. I wanted to thank my mentor Megga Hertz. The most thug-like artist of Remorse. Remorse is Acid’s ASCII art division. Acid Productions is the dominant outfit of the underground art scene. He imparted on me unselfish, indirect mentoring through the Tyrone e-zine. That must have been 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. To be accepted in the greatest ASCII art group of all time made me stay in the scene when I would otherwise have quit.
To BBS like it was in 1994, there are several options to run a board on modern hardware and operating systems. I’ll 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. I didn’t research the choices of contemporary BBS-hosting software for Mac.
But where is the fun of throwing by the window all the handsome BBS software of the past? One must get over the fact that BBS culture was current more than one generation ago. There is a living BBS scene. What was known before as scene BBSes are still here.
In this technical white paper example, in the first instance, I will take into account the time that the first phase of the project took. This variable will be factored in the Fun vs Drudge Equation. It will be done for every stage of the project’s tasks. Especially about how using legacy software can prove a time-sink. An obstacle in the implementation process.
The first live version of the BBS was a failure. It was a crippled take on streamlining old telecommunications applications with retro-gaming. It was a customized version of the BBS as front-end. A front end for a games server delivering single-player text adventures of the past. This first incarnation didn’t feature common BBS functionalities. It didn’t have messages, files bases, and the rest because I couldn’t make those work.
In a second instance, I will outline the steps I followed to make the BBS software of my choice (System/X) work. I was able to make it work at 99% 1990s-BBS-radness. 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. This time, almost all the features BBSes were known to have available back in the ’90s were supported.
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.
I used NetFOSS 1.04 as the BBS’s fossil driver (virtual modem).
I used Net2BBS as the BBS’s telnet server.
For the final deployment, I used System/X 1.5a for the BBS and Gamesrv 3.10.19b2 as virtual modem/telnet servers.
First Broadband BBS (2011 – 2012)
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. Desire was a tough BBS software to return to BBSing after a decade and a half. 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 that extra mile. The hardware I used as a petri dish from my experiments was old. It was an HP Vectra from 1997 running Windows 2000. 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 used NetFOSS as a 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. The switches and parameters of the modem’s .BAT file required minimum shell knowledge.
I got a sub-domain thanks to the free services of Afraid.org and began testing the server through it. Minor incongruities with the former installation were fixed. That’s when I found that the version of Desire I had, an unregistered copy, did not run doors. I decided to try the other already configured setup I had tweaked in 2004. It was System/X. It was the 1.5e Alpha Strike Eagle edition with dA bALHED’s undocumented add-on doors.
This customized version of System/X was released by the scene group Providence. It was available in warez BBSes around the time the software was released. It came with a large set of doors already installed.
This customized version had a problem. It was the lack of documentation for the doors that came bundled with it.
Also, there were many different doors for a single BBS task of which just one was installed. Still, it was kind of easy to bring the BBS up. The pre-configured 1.5e version was something great compared to the original, plain System/X 1.5a.
But the documentation was f 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.
During the first week of the research, I configured the BBS further. I tried to understand the poorly-written System/X documentation. Yet, R2D2’s manual-writing style was muddy at best.
A thing that took a lot of experimentation for me to understand. It was that I needed to create a directory with copies of all the doors and all the text files. It was necessary for it and other data files for each node that the BBS would 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. Imagine a scenario of two dozen nodes! To have twenty-four folders for each node, with equal copies of all the BBS data and executable files. Essential files like the screens the user sees, file bases, message bases, and doors. They 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. When a user was using the message bases or file areas, and a second user in another node accessed the same data. If they did it both at the same time, one of the two suffered a broken experience of the BBS.
I couldn’t narrow down the cause of this. My theory is that it has something to do with the obsolescence of the share.exe DOS tool. A bug was caused due to using a 16 bit DOS software and its tools on 32 bit Windows 7.
A normal installation of System/X on a computer running DOS or sixteen bits Windows should run better. It would require a simpler directory and node structure.
I guess that without the bugs and making correct use of the share DOS program, the software would work. It would run as it was intended to run. With a centralized section for messages, files, doors, menus, and bulletins. By centralized, I mean that they are all node independent. That System/X would somehow manage the accessing of that data by two users at the same time without issues.
I found only one way to make the BBS work as it should. It had to run natively, on Windows 7 with all the BBS data mirrored in each node. To achieve this I had to program additional batch script code. The batch files ran when the user logged out. They made sure that all the node-specific changes were reflected in all the other four nodes.
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\
There was another problem. The configuration was working, yet I was confronted with a new blunder. The first truly severe problem until that moment. A bug in the setup prevented, for some reason unknown to me, the text output of the BBS’s doors to display remotely.
When I used a command that loaded an external door, the output won’t show on the remote terminal. It will do in the server’s local BBS screen, though.
I lost around a day trying to fix this. I passed different switches and parameters to NetFOSS’ command line. Modifying the batch file that came with it. The file that fires up when the server receives a connection request. I think it was NF.BAT if my memory serves me right.
On the second day of frustration, I decided to ditch NetFOSS/Net2BBS.
The problem was the NetFOSS. I couldn’t redirect modem-based applications to virtual COM ports. Thus couldn’t redirect the output of the doors to TCP/telnet for it to show remotely.
I was advised on IRC against using Gamesrv. Yet, I wanted to give it a try. Because I couldn’t find any way to fix the doors’ output problem Gamesrv was my last resort. 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. 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. The next thing I knew was that the doors’ outputs were showing remotely the way they were supposed to.
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 a different theme to it. They supported all the features common to BBSes in their heyday.
To my dismay, I found that most of the other features, the core BBS ones, didn’t work. I wanted to believe that I wanted to strip my new BBS of the features that I thought didn’t age well. Namely message forums and file areas. In fact, that thought was a way to cope with my inability to make those features work.
I achieved this simply by disabling commands. I disabled uploads, message writing, and message reading. Also all the other commands and jobs related to these three tasks. Like the file area search, message search, and generation of transfers statistics bulletins.
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. Most delivered BBS text games. I found that many of today’s systems share at least one or two games in common with their competitors.
Second Broadband BBS (2014)
I installed System/x 1.5a and moved all the configuration and text files. Then I correctly configured the nodes. This time 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.
I was running System/X natively and 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. This kind of activity froze System/X.
The easiest, but not seamless, the solution I found was going back to Gamesrv. To use it as a login matrix.
In the 1990s, many BBSes had login matrices. Most of those that did were because the owner might have had restricted access to the system.
The login matrices served different purposes. Like applying for membership and checking the state of the membership application. 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. I edited the .exe file with a binary editor to remove the splash text with Gamesrv’s version. In this way, I got rid of the port scanners and brute force attacks.
Windows 7 32-bit
System/X v1.5 Final
System/X and Doorway worked natively were rather stable on Pentium M architecture. I wouldn’t have believed this if someone told me this.
My objective was to have something similar to the old thing. I wasn’t okay with adding the extra overhead that DOSBox would bring. Because of my stubborn approach, I achieved it. That BBS ran 24/7/365 for almost four years.
The first version, the one without full BBS functionality took nine days of six or more hours per day of work. I did it in the dog days of the summer of 2011 when I should be relaxing instead. On top of it, I started maintaining a backlog from the start and that became this white paper example.
All the legacy software I used in the implementation process was weird. It was unresponsive, and errors and malfunctions were the rules, not the exceptions. The software modality is a lack of performance, and the blunders were the stuff of digital nightmares. But I toiled and persevered. Still, it was hard to enjoy the journey.
It wasn’t fun, it was a chore, and I felt I was losing time with the obsolete software. Nine days is a long span of time. Compared to how much time it takes to deploy any game's front-end software in a Windows setup. A mere five to ten minutes and your server is online.
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 interested in it because I was who had created it. I think it would have not been popular with callers.
I guess I was doing it just to showcase my smartness at picking interactive fiction games. It was part of a thought process. A deluded idea that there wasn’t any interpreter-neutral front-end for IF games yet. What I had created could work as a sort of front end. I only need to push a key to load an interactive fiction game. The same for a totally different game and interpreter. I thought it was cool as an if-system-agnostic front end, for those who love horror, science fiction, and/or punk interactive fiction. And that it was okay to share it with others.
After a while, maybe two, three, or four months later the HP Vectra of the first incarnation died. In the two years that the BBS was down, a thought haunted me. The thought of having invested a considerable time in it, only for the project to fail. But I thought bygones should be gone.
But the fond BBS memories of my teenage years endured. After learning inter-networking in 2014, the first thing I did was pick up the project where I had left. I knew that it would be a cinch to set it up. With 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.
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. With all the BBS features in place and 99% functional, like I really wanted.
As of the updating of this white paper today in early 2018. I’m using Gamesrv v14. In the last years, Gamesrv evolved and now it has an auto-ban feature. A great feature to deal with the constant brute force attacks. This version of Gamesrv even has a 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. There was a publication with good content about which IF games were worthy of playing to. It was the “Society For The Promotion of Adventure Games” e-zine.
Thanks to it, I made a long list of IF games that I considered were the best exponents of their respective genres. Ninety percent of them were text adventures. Most were participants in the Annual Interactive Fiction Competition.
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. 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.
Some games didn’t display correctly. Irrespective of the parameters I’d pass to both Doorway and the interpreters. 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
The games to host were of the punk, horror, and science fiction genres (and sub-genres). Only Inform and Adrift format games were implemented.
Punkirita Quest 1 (Stevens, 1996) bizarre/fantasy
Punk Points (Munroe, 2000) punk bildungsroman
Adoo’s Stinky Story (Perry, 2003) punk
Slouching Towards Bedlam (Ravipinto and Foster, 1996) Victorian steam-punk (had to take it off, was not playable remotely)
The HeBGB Horror! (Mayer, 1999) punk
House of The Damned (McCall, 2000) horror
The Zuni Doll (Burneko, 1997) horror
Theatre (Wyber, 1995) horror
Requiem (Whyld, 2006) horror, mystery
Crypt (Herring, 1990) horror
Madame L’Estrange and The Trouble Spirit (Ball and Young, 1997) horror mystery, science fiction
Science Fiction Section
The Mind Electric (Dyer, 1995) science fiction
The Edifice (Smith, 1995) historical science fiction
Photopia (Cadre, 1998), surreal
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 Microsystems, Inc. NetFOSS 1.04 literature. Thousand Oaks, California: PC Microsystems, 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/]
White Paper Example ― Extro
Hopefully, this white paper example gave you a rounded idea of how to write a technical white paper. If you think this white paper example is lacking, please let us know in the comments.
Photo Credit: Monado
© Martin Wensley, 2012-2018 ― White Paper Example