Opus-CBCS

From Just Solve the File Format Problem
Revision as of 02:48, 15 January 2013 by Dan Tobias (Talk | contribs)

Jump to: navigation, search
File Format
Name Opus-CBCS
Ontology
Released 1985

Opus-CBCS (Opus Computer Based Conversation System) is a bulletin board system (BBS) program that runs under MS-DOS. It was popular from the mid-1980s through the 1990s.

Contents

Overview

Opus was created by Wynn Wagner as a FidoNet-compatible BBS program, designed to be compatible with Fido (the program that originated FidoNet) so that sysops of existing Fido boards could easily switch to Opus and preserve all their content, configurations, and user records. Thus, the files used by Opus are almost entirely the same as those of Fido, though over time some of them diverged in later Opus versions (e.g., the conversion of file lists from flat text files to a database format).

Opus rapidly gained popularity by supporting everything Fido did, plus some enhanced features such as the use of color in menus (for users with terminal programs supporting one of several protocols that supported this), and some new and improved data transmission protocols which made more efficient use of modems.

Later on, though, it lost ground to other BBS software which had greater support for such things as online games and multi-user chatting. There was a long delay between the release of versions 1.20 and 1.70 (they skipped the version numbers in between), with the only word on possible release dates being "When It's Ready", and many people switched away during that time, leaving a few hard-core Opus fans sticking with it.

Opus was one of the few FidoNet-capable boards that supported built-in network mail (and Echomail, the FidoNet answer to forums or newsgroups); other BBS software generally required an add-on front-end to support these features. Many Opus sysops, however, still used front-ends on their boards to do netmail/echomail, since those programs had more features in this area.

Opus has always been free software, with the author requesting that those who like it enough to want to pay for it send money to an AIDS research charity instead of to the author.

According to Wagner, Opus is not named after the cartoon penguin, but after the Latin word for "work". The plural of "opus" is "opera", but there is no apparent connection between Opus and the web browser Opera.

Control files

The standard control file is called BBS.CTL. Often it is split into multiple parts referenced in the main control file with "INCLUDE" statements; usually these parts have a .CTL extension as well. These files are ASCII-based, containing a series of configuration directives which are documented in the Opus sysop and technical manuals found in the file areas linked below. After modifying the control file, the sysop then needs to run a utility called NACL (from the chemical formula for table salt) to compile the control file into a file BBS.PRM which was used directly by Opus. Another utility CAYENNE would make the conversion in the opposite direction, generating a BBS.CTL file from the BBS.PRM file.

Menu, help, and other displayable text files

Message files

Continuing the structure used in the Fido BBS, message areas are stored in one directory per area, with each message in a separate file named with the .MSG extension and a name that represents the number of the message within the area (e.g., 123.MSG for message #123). There were some utilities for renumbering message areas when some of the messages in an area were deleted, since gaps in the numbering would slow down access.

A message file consisted of a 190-byte binary header followed by the plain text of the message body. There was no way of indicating Character Encoding, but messages were generally in ASCII; perhaps non-ASCII characters from an IBM PC code page might be encountered, but such use wouldn't be reliable since BBS users might be using non-PC systems or PCs with different internationalized code pages. Lines starting with Ctrl-A (01) were control lines, e.g. with routing information used in FidoNet transfer, and were intended not to be displayed in normal BBS use.

Mesage header

The binary header was similar to the one used in FidoNet message packets, but not exactly the same.

It consisted of elements in this order:

36 bytes containing the 'from' name (null-terminated string). In this and other null-terminated strings, the bytes after the null character might contain arbitrary content, perhaps left over from other data used by programs processing the message; this was ignored.

36 bytes containing the 'to' name (null-terminated string).

72 bytes containing the subject line (null-terminated string).

20 bytes containing the date/time of the message in a human-readable ASCII string. In an Opus source-code header file (found in one of the file sets linked below), this is indicated as "obsolete/unused", but it still seems to have a correct date string in it (at least in some versions of Opus).

2-byte unsigned integer (word) containing the number of times the message has been read. (Words/integers are little-endian.)

2-byte integer with the destination node number (the 'node' part of a FidoNet address of the form zone:net/node.point).

2-byte integer with the origination node number.

2-byte word with unit cost (in cents) charged to send the message (intended for boards that required accounts with balances, whether paid with real money or 'funny money', to send messages; remember, in those days there were real long-distance phone costs involved in sending remote messages).

2-byte integer with the origination network number (the 'net' part of the FidoNet address). Note that the nodes are stored destination first then origination while the nets were quirkily in the opposite order.

2-byte integer with the destination network number.

The next 4 bytes consist of the timestamp of when the message was written, used by Opus in place of the ASCII timestamp above. In Fido, these bytes were unused and were set to null (00). Now, the format of this gets a bit tangled. The header file has a comment claiming them to be a Unix timestamp, but it isn't; the same header proceeds to define the format instead as two words representing the date and time in turn. No indication is given about how these date/time words translate to actual dates and times, but some detective work on sample files reveals that they are segmented bitwise as follows:

The first 2 bytes (date) are taken as a little-endian unsigned integer, then its bits are grouped starting with the highest-order bit (which, given the little-endian format, is actually in the second byte):
First 7 bits represent the year minus 1980, so that 1980=0, 1981=1, and so on. This will work for years up to 2107.
Next 4 bits represent the month (1=Jan...12=Dec)
Final 5 bits represent the day (1-31)
The last 2 bytes (time) are grouped like this:
First 5 bits represent the hour (0-23)
Next 6 bits represent the minute (0-59; or perhaps 60 during a leap second?)
Final 5 bits represent the second divided by 2 (as a rounded integer) (0-30)

The next 4 bytes contain the timestamp of when the message arrived online, in the same format as above.

The next 2 bytes are a word containing the message number this one is a reply to.

The next 2 bytes are a word with attribute flags.

The final 2 bytes are the number of the next message in the thread.

File areas

Log files

Other files

Traditionally, the batch file to invoke Opus is named NERF.BAT, apparently the result of an inside joke to do with the bats used on Nerf balls.

Sample files

Software and documentation

Other links and references

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox