Historical Information for
Data General Software
in MindPrint's Software Archive

This document serves to provide some back ground for getting the Data General software working. The information provided herein should be considered recalled opinion from events over a decade ago and not necessarily pure historical fact (although every attempt has been made to remain neutral, objective, and relay facts as accurately as possible.

In looking at the source code for SMail, Galaxy, HDG, and others, it is apparent that some really odd things are happening. If you're asking yourself, why would anyone code this way, you'll see there were certain circumstances that influenced the code's design. Virtually every problem was political in nature, not technical.

Compiled BASIC was choosen because of several reasons. First, the C compiler was not readily made available, and PASCAL had some flukes. It was perceived BASIC was harmless, and that was the only language really given full exposure to students. Additionally, BASIC had a nice mechanism for calling low-level system calls. With good design, it was possible to make very powerful programs that blocked, so that our programs were not a CPU hog.

Equipment and Accedemic Environment

The software that is presented on these pages was written by Walt Stoneburner Roanoke College (1986-1990).

At the time, Roanoke College had started using Data General MV/10000 with DG200, DG210, DG220, and DG410 terminals scattered all over campus.

Hence, a lot of the software is hard-coded to work with these terminals. We found no equivalent to termcap or ncurses available for our use.

Like most educational institutions at the time, faculty and staff were given preferential treatment over students, and dialin access was not easily obtained except for special purposes.

Students had no special privileges (with the exception of a few trusted students that worked as assistants), disk space was limited to about 2500 blocks (which was about as much as one 1.44 floppy), and didn't have access to all the system facilities and applications the college staff did.

There was, however, sufficient online help to learn about how the system worked, and that allowed a few of us to set our Acccess Control Lists to share our directories, efffectively making use of our distributed quotas by pooling our resources together.

Consequently, much of the software will reference a splattering of directories for what appears to be no particular reason. This is because there was not enough room to store everything in one directory.

Additionally, the computer staff on hand was quite paranoid at the projects we were working on and frequently locked our accounts blaming the group of us for various system level crashes.

In the four years we developed software, it was shown that we never were responsible for a single system crash. Although we let the administration believe what they wanted for short durations, partly because of the air of mistique is gave us, and mostly because it was amusing to see them chasing ghosts.

Humor Sidebar. We weren't above arousing suspicion, but we vowed never to do anything distructive or harmful. Anything. Ever. The only "crime" would be to educate regular users how to wore more efficiently and provide them tools to do so.

One day, when my account was disabled, I walked into the computer lab, and this caught the eye of the head person working there. She eyed me intently.

I flipped on the terminal. Punched a few keys. And everyone else in the room stopped typing. I turned off the terminal and left, hearing wailing and complaints that "I just lost my document!" and "What the heck just happened?!" and so forth.

Frustrated, they started cursing and exiting until the computer room was empty.

...where, we all met in the hall and went to dinner. The whole event was staged; I filled the room with shrills.

The massive pratical joke was pulled off, and for days the computer staff searched through logs trying to figure out how I might have gotten on the system, especially without creating a log entry, and in a second stopped everyone from working. Since it was all acting, there was nothing to find, a handful of the users weren't even signed on the computer.

Such events are good all around, in an amusing, reflective kind of way... It built unity with the students, it kept the staff focused on something other than students, it was something fun to do when login privleges were removed, and it provides an amusing story after the fact. Most importantly, it did nothing destructive.

About the Software: SMail replaces CEO

The college's Data General came with a program called Central Electronic Office (CEO) ... or something like that. I don't know much about it because student's weren't readily authorized to use it. Supposedly it allow you to compose documents, send email, and do a little calendar tracking.

I managed to get access to it in the early days, and gave it a whirl. It took me no more than 3 minutes to determine that I hated it, and with a passion.

Number one, access was granted out only to professors and special students. This meant you couldn't send mail to the guy sitting next to you without going through a lot of red tape.

Number two, you could only compose an email message of 6 lines or less. Any more, and you had to write a document and email it as an attachment.

Number three, email took over two minutes to deliver, and that was when it was running quickly.

Number four, it was slow and not only that it consumed HUGE resources. We determined that if any more than six people were running it at once, the system would slow to a crawl and all non-CEO users would be bumped to such a low priority that it would take minutes to see system response.

Hence, I decided to write my own mail program.

SMail originally stood for Stoney-MAIL. Since Stoneburner was too long for the account name, it was abbreviated to STONEY. SMail has no relationship to smail for Unix.

SMail had many advantages which made it popular.

  1. It ran as a shell that allowed you to define your own commands easily.
  2. You didn't have to enter the complete command, it looked and felt much like a VAX's command line.
  3. It could be customized to some degree.
  4. All of our programs were hooked into it, thus you didn't need to use paths. (This was useful when we didn't have a shared area for binaries).
  5. We requently changed the welcome messages to teach about new system commands and discoveries. I suspect we started the Tip of the Day.
  6. You could send infinitely long messages to any user and have it delivered instantly.
  7. You could use it to see who was on the system.
  8. You could monitor the system with it.
  9. We provided a revsere mapping so you could tell where someone was logged in.
  10. There was a facilitiy to braodcast a message to another user.
  11. We could supress, enhance, or show the header for broadcast messages.
  12. You could turn on and off your ability to receive messages.
  13. SMail remembered your settings.
  14. There was a CB (citizen-band radio) simulator, just like GEnie's (but with more features) built in for group discussions.
  15. SMail maintained a directory of system users.

SMail became the social communications hub of the system. Typically, a user signed onto the system, got into SMail, and acted as if they were at the system shell. Then they'd logout.

SMail made you feel as if you weren't an isolated user, but rather part of a community. And in a situation where student's have hardly ever used a computer, this was reassuring.

SMail's program was stored in one user's directory, the help in another, the mail in another.

About the Software: HDG

One problem that SMail had was that it didn't facilitate group discussions by email. Hotel Data General (HDG) provided a forum where users could sign on, create topics, and discuss them. Whenever you signed on you were told about new groups and new activity in groups that you were interested in. In some ways this is similar to Internet Newsgroups.

However, the system was written to behave similar to the Participate (PARTI) system that I had seen [for only moments] at William & Mary.

For fun, HDG mimiced a Hotel. (Hotel California was a running gag, with "You can logoff anytime ya want, but you can never leave.")

What made HDG great was the feeling of power it gave to it's users.

  1. Any user could create a topic.
  2. When the user was inside that topic, they were the SysOp -- and had commands other users didn't.
  3. A topic could have any number of messages.
  4. A message could be of infinite length.
  5. Any message could have an infinite number of sub-topics.
And so this massive recursive tree structure was made. As topics got stale, they were deleted. And thus you always had the most active and oldest things at the top of the list, with the most newest at the bottom. There was a churning of activity.

Additionally, topics could be passworded, which meant cliques of users could be formed.

HDG also introduced topical chat rooms, much different from SMail's CB.

About the Software: GALAXY

Galaxy was our multi-user StarTrek. Users could create one or more ships and, using several terminals, fly them around and shoot the snot out of other players doing the same.

We stuck a few surprises around for people to find, and it was possible to find prbiting planets and conquer them. However, if you left for lunch or dinner, it wouldn't be too surprising to find that someone had come by and conquered you!

Galaxy was unique in that it was not a running deamon, but the game continued to progress even while it wasn't running.

About the Software: Other Software

We had Wumpus, an Adventure Generator, a specialized Adventure game, the game of Cookie (for visiting kids), and several others. These weren't as big as the others, but they provided all kinds of system amusements.

Account Conventions

You may need to change some special account names that are encoded in the software.

Many of the accounts are labeled as eng.name, 150a.name, or per.name.

These represent english 101, computer science 150, and personal accounts.

Because the accounts were prefixed with some tag, it was very easy to tell who someone was.

It would be beneath a professor or computer operator to prefix a student prefix to their account; thus we detected this and sometimes the program would operate differently when it would see such things.

Most of the time, it would be in displaying the copyright message or in just not running.

By the second year, over 1/3rd of the college's student staff was now using the computer for uses beyond class. For instance, the English 101 student might actually use a math package to do chemistry homework, before this was unprecendented. Incidently, this in no way taxed the Data General's resources (we kept close tabs on that).

A number of utilities and games had been written, and before you were allowed to use our software, you got a little ediquette training first. Things like how to measue the system load and make an informed decision about whether your should be playing or not. You'd be surprised how helpful and kind a community of users is, when they understand why and how.

The name WWCo started getting used all over, and the faculty wasn't quite please [at first] in the growing community revolving around the software.

So, to lessen this distress, we made the software display a copyright message of CompuLink when started by a staff account. This bogus name had no "fear" associated with it, since they were unfamiliar with it, and the software was seen for what it was... a set of useful tools, and not a subversive plot to hurt the machine.

If you see the fake copyright, now you know why.

Eventually, the [non-computer] staff grew to like and use the software, especially for communicating with students.

The Software

The Data General software was obtained at the last few minutes before the system it was on was shut down. I happened to have a Mag Tape and got a dump of my files. Unfortunately, due to the distributed nature of the software, some of it resided under other student accounts.

The system operator would not allow me to have a backup of other student files, and as a result, some documentation and help screens were lost.

Most can be reconstructed by looking at source or from old files. However, it's a shame they could not be preserved.

For the most part, the code was written on a PC, put on a floppy disk, and a laptop was taken to the computer room and the terminal's serial port was disconnected from the terminal and plugged into the laptop.

Source code was uploaded into a file by sending character by character, making it look like it was all being typed in.

Once compiled (and quickly tested), the source was removed from the system and the binaries were placed in a common area.

Luckily, I managed to do a little volunteer work for a professor who was trying to get RS-232 working. For me, it allowed access to move source and files around; eventually the shared information about how to hook up terminals to PCs led to a new computer wing allowing PCs to be connected to the mainframe.

Everyone benefitted.

The college started providing copies of SmartTerm to provide terminal emulation. Eventually I wrote a program called Mupet which provided better emulation, faster speeds, full keyboard compatability with Word Perfect, a huge scroll back buffer, and terminal extensions allowing for color.

I held onto the tape for more than a year before finding someone in a Data General user's group that could read it. They promised that a friend of a friend would load the tape, put the software in the user group, put a copy on floppy, and send me the floppy and the mag tape.

I got the floppy, but I never got my mag tape back.


The software located for this page is available at the Wizard Workshop and Company Software Archive

This page last updated 07-Mar-1999 11:27:09.