This archive document has been copied from its original text version without editing. It was written by Derek McDonald, author of McBBS, and remains in its original format.
(c)Copyright 1999, 2007, 2017 Derek E. McDonald & DMCS Technologies.
Distribution is limited to the non-commercial duplication of this document provided it is complete, unedited and contains this copyright notice.
The program BUSIDAT, a small program I devised to handle business matters such as letter writing and calculations, was abandoned all except for its "letter writing" software which would later be used for this BBS program. I have an interesting ability to program my computer by simply hearing how the programs interact with the hardware components by listening to the electrical currents. In older machines this was possible because of the small size, modular design and lack of shielding they often had. I knew what to listen for because of an enhanced hearing ability, something offered to me due to poor eyesight.
During this time I was still devising software for my Commodore-64 machine and I had my first hit with a program that re-aligned faulty floppy disk drives.
Using such programs as Spence-XP, EBBS and PCBOARD as inspiration I would devise my own BBS.
At that time the BBS was considered the highest form of programming that a hobbyist could do. The idea of programming Operating Systems, the internet and other advanced technologies had not yet filtered down to this level. Most software at home was written in the BASIC language on computers that either ran MAC-OS, DOS or the large number of independent machines and proprietary Operating Systems like the C-64.
By late 1987 the family moved to Waverley, Nova Scotia where I started my own BBS first called "The Community BBS" but the name stunk and within six months it was changed to "ASCII BBS". For some reason it was a name that stuck.
On the BBS program I was using at the time I had to redesign the answering system to run with my modem because it was designed to work with a competing chip brand; I did this by utilizing the program listening trick I told you about earlier. This basic answer system and the communication input/output procedure also discovered at this time would later be used, unchanged, in my BBS for some 8 years. But the program I used at the time also suffered from poor design and needed constant baby-sitting, something I couldn't put up with and would ensure never happened in my program!
The first telecommunications program was a simple one way (simplex) program called GRUESOME-DOG (named after my pet Cocker Spaniel, Gruesome). To my software evolution it served the same purpose that Sputnik did for the space race. The program didn't do much, just answered the telephone and transmitted a hard-coded software message to the remote user's terminal screen.
This program didn't last long, though, as its use was limited, but enough knowledge had been massed that in 1988 I began work on my own BBS program. The planning, alone, took more than a year and it wasn't until early 1989 that prototype communications programs of "MCBBS" were running.
(MCBBS is a contraction for "The McDonald Bulletin Board System". Because my last name is McDonald I thought it was a cute play on my name).
And so the coding began....
The first version (MCBBS v1.1) was not like you see it today. It was originally developed to operate on a Commodore 64, it had very limited message capacity (10 subject groups), drive compatibility (1 floppy disk), limited reliability and moderate speed.
The users of my BBS thought something was done that had finally done what few locals had done before:
This first version would sell for $20 CDN, however, being the first version not many sold.
Many detractors thought that the high school kid named Derek McDonald couldn't succeed with it - it was only the beginning.
As for v1.0 - there wasn't one. So many prototypes had gone that they would be collectively called v1.0 and the program was officially started at 1.1.
Several unique features were innovated on this version as well; it was with this version the "(R)everse Lines" message editing feature was introduced and it exists in all versions from this point on.
Special programming was needed to enable the program to do the primitive short-cut colour transmission that Commodore computers utilized. A new item called "Modules" (a.k.a. "DOORS") were required to allow the new user application and SysOp editing functions to work, these "modules" were loaded automatically by the BBS. Such division of the program was needed to allow the program with all its enhancements to fit into the small (64K) RAM that the Commodore had. This ability would be resurrected in later IBM versions.
This became one of the most popular BBS programs for the 64 in the area.
This program sold more copies and it would be several months before an update came out, at a time when the average for each update was about a month.
The Commodore had come to the end of its physical life. The machine used to program MCBBS was aging (a 1983 model) and had been expanded about as far as it could go. Many users were switching to Apple and IBM machines, anyway, which were incompatible to the now obsolete little C-64. Most Commodore users were not impressed with the newer machines Commodore (who would later go bankrupt) was offering so the decision to move and take the BBS along for the ride was not a surprising or unexpected one. The C-64 that started it all still works, however, and has been preserved and restored.
It required the GWBASIC language interpreter software to run and because of the structure of the IBM transfer protocols they had to be relearned so file transfers were removed from the program, until I could figure them out. The code was almost identical to that of the C-64 v2.6. Basically it was the old code translated for PC.
The SysOp and user log-in functions were no longer external “Doors” due to the increased memory capacity and speed of this new machine.
The program also operated in 80 column screen mode as opposed to the old 40 system utilized by the Commodore.
I programmed this version on a black and white monitor (I got a colour VGA 6 months later); this explains the unkind colour scheme of the program.
As far as technological advances and new features there weren't many except one: The program was now compiled into 80x86 (EXE) code, due to the abandoning the GWBASIC for a newer version written by a competing company (which no longer makes their language either). The result was the program ran faster than any previous version and could now fit into 70K of RAM (Smaller than any other program of its type).
It could now use PACKET modems, a Canadian invention that connects modems and radios together. MCBBS also had a much more extensive configuration and the manual was much larger and complete.
The BBS also, once again, supported file transfers and would load and execute ANY transfer protocol known. The protocols were not provided and coded for MCBBS though, they had to be obtained by the user separately but the program would interface with them. Though the loading system for such protocols was excellent it still lacked some features, like the ability to load a protocol's sending and receiving codes differently in some cases, but it was still a major step forward for the program and my knowledge.
The program now required almost 94K to operate, but it still maintained its traditional small size - a feature it would boast for years to come. In addition, several external utilities were supplied with the program to help the SysOp operate it better.
This version was the first to break out of its home community. Several BBS's across the country set up transfer bases exclusively dedicated to any software coded with the name "Derek E. McDonald".
The next big step forward was also in v3.3 with the parameter loading strings. Now one could load MCBBS and its new SysOp menu door (re-living what was done with the Commodore in the past) or bypass the BBS's auto-answer routines (run as a "Door" to another program) by typing a series of commands after the program's name when loading from DOS. Such features were added in an effort to encourage more people to support the program - and, indeed, many SysOps thinking of changing to MCBBS ran it from their existing system as a Door and got membership approval of it to replace their existing system full time.
3.3 was considered the "MCBBS of MCBBSes" and was over 10X more powerful than its ancestor MCBBS v3.1C.
THE SHOW GETS A SPIN-OFF
Just before MCBBS v3.3, COMTERM v1.0, the companion Terminal program was completed. The year was 1991.
COMTERM used almost 90% of MCBBS's code, including a modified version of its modem input/output routines. The terminal was something many supporters said should be done and it should be called "MCTERM" to accompany the BBS. The idea for the name was rejected because, in my own words, "it would be silly to call it MCTERM and sell it with MCBBS, it would make a mockery of the program's name and image". So COMTERM, an amalgamation of the words COMMUNICATIONS and TERMINAL, was chosen instead.
COMTERM was originally designed not as a terminal emulator but as a language translator. The prototype version kept indexes (dictionaries) of languages - in prototype version it was French and English. While one person types from one computer the receiver would receive the message already translated into his language. Instead of having to wait for the whole message then translate after, as was commonly done by many government agencies. There was two problems with this technology, however, it was slow (although on today's machines that would not have been a problem - but at that time it was) and obtaining exclusive use of this technology to market would be difficult.
Inquiries about patenting the technology was pursued but it was rejected at the first turn when the government representative said "you can protect software by copyright but rarely are patents given. The copyright only protects the software duplication but not the idea". It appeared that mankind was not prepared for this technology so COMTERM was stripped of this ability and became a standard communications emulator.
Later versions of COMTERM would feature the addition an auto-dial and enhanced transmitter (v1.0 & 1.1). V1.1 was the first program other than MCBBS I made since the creation of MCBBS to have new features released before MCBBS itself was fitted with them. Other features like the ability to file transfer using external protocols (v2.0), ANSI colour codes (v2.0), a supplied transfer protocol (EASCII), high speed modems (v2.5), transmit/receive sound via a special ANSI code set which was devised because no other terminal featured MCBBS's special ability to do this, internet/FIDONET E-mail address storage, auto-dial, auto-installation, high speed modems, etc. (v3.0). It ended with the bug-fix version v3.1, in 1999 where it would later be merged and sold with MCBBS by year 2000.
COMTERM's evolution is much simpler and with fewer versions than MCBBS. Each time a new MCBBS version with significant changes came, COMTERM was also updated to parallel that change. And so the two programs would feed off of one another's innovation, like brother and sister, until the end.
The SysOp Door from v3.3 was now put back into the program. The file transfer commands were updated slightly, errors were corrected.
The biggest improvements were the message search functions. Now the BBS searched for messages written TO or FROM the user, it could then display only these messages should the user request, instead of forcing the user to sift through other messages to find it.
Also a discovery was made! The wonders of programming beyond 64K which now allowed MCBBS to grow without restriction. MCBBS v3.3B was larger than any past version but ended off to be more efficient.
MCBBS was starting to come out of the wood work, it was growing up. Now new markets for it were opening up in Ontario (central Canada) and the Mid-West USA and v3.3 was exported to meet the demand.
V3.3 and 3.3B saw a revolution in Doors and utilities made for MCBBS. Printing utilities for the manuals and an updated configuration maker so you could now edit the configuration files instead of having to re-install the program when a configuration problem occurred, were added. An AUTO-VALIDATION DOOR was added and the UNIVERSAL DOOR LOADING module was updated.
This version also saw an experiment in two way compatibility unfold:
The Auto-Validation “door” was the first MCBBS “door” to be compatible to more than one MCBBS version. It was compatible to both MCBBS v3.3 and 3.3B. However, this experiment proved be a failure in future versions where changes were too much to predict well enough to make programs multi-version compliant.
Meanwhile a local friend of mine, Jeff Pazahanick, was learning programming and decided to try building for MCBBS. Essentially, he became the first 3rd party developer to MCBBS. He made several “Door” modules including off-line mail readers, XT answering systems and bulletin updating utilities. This relationship would prove to be short lived; most of these programs were lucky to get out of the prototype stage and none saw more than one version released.
However, since version 2, a customer had become a personal friend and one of the program's biggest supporters. Steve Hiscock routinely conducted software tests and extensively communicated during these years. He proved to be an excellent advocate, beta-tester and supporter. V3.3 & 3.3B also introduced the idea of networking and Steve played an important role in the testing of MCNET, the short-lived, message networking system used in MCBBS. This network would first appear in MCBBS v4.0. The test message transmitted was:
ASCII was a protocol that was messy to use and so it was streamlined with a user friendly window interface that looked and felt like other data protocols with real-time size counters and status bars instead of just raw text scrolling across the screen. For the traditionalist a standard design was also available by issuing a start-up parameter command.
EASCII would be installed and shipped with all versions of COMTERM 2.5-3.0 and MCBBS 4.0-5.1A and early versions of 5.5. After which, it would be replaced by a newer program "MAM.EXE".
On Oct 6, 1991 MCBBS v4.0 was released. It was the most progressive MCBBS ever devised, it was called "The next Generation of MCBBS". Now there was more colour, speed, capabilities and reliability.
It was on this version that the infamous DMCS title screen was seen again - a picture that had disappeared since MCBBS v2.6!
This time MCBBS came out with a whole new look. There was a new status bar for the SysOp and an extended help window, and these were multicoloured. The communication (COM) sub-routines were updated slightly, something that had never been done, the COM routines up until now had been the same since v1.1! The routines remained similar, just more streamlined. But the new communications routines would prove to be unstable and unreliable and would soon cause the demise of v4 - in tests it worked fine but proved to be unstable and failed after 6 months of release. V5 would see the reverting to the old transmitter, it wouldn't be until v5.1 that the transmitter was successfully upgraded.
MCBBS v4.0 also supported unlimited message holding and a primitive but useful network - the "MCNET". MCBBS's proprietary network.
The Door loader was also fixed in v4.0 so it now run up to third party standards and worked correctly.
The program now took over 140K of memory to store, but it ended off being smaller and more efficient than past versions like v3.1C and 3.3.
Unfortunately, just before the completion of MCBBS v4.0, I moved to Belleville, Ontario to attend college. This meant that my 4 year running ASCII BBS went down and MCBBS research was delayed by cutting off all of my contacts, testers and markets. But that was only a temporary setback.
It was now over a year and 3 months since the world saw another MCBBS, the longest elapsed time since the original v1.1! (That record of being the longest developed version would later be defeated by v5.5).
I was now a college student and time was scarce for MCBBS. Many other projects of mine were stopped or set aside temporarily so that MCBBS could get the most of the time.
There were many things that were supposed to be in v5 but never made it due to time. However, what did make it made the wait for MCBBS 5 worth it. Some of those features included: Bulletin page pausing, User Time limits had been achieved, spell checker for messages, improved network, improved transfers, unlimited message capacity, unlimited user capacity, faster user file access, color graphics had once again been introduced, this time more efficiently and using the ANSI codes.
The program now ran in size to 170K, due mostly to the special coding needed for graphics, but compared to most other systems this is small.
The installation program was in bad need of replacing since it could no longer support such a massive program, so it was replaced. No longer did a user have to face a gauntlet of technical questions, but instead a simple top down cursor key controlled and windowed interface made random and spontaneous changes simple and possible.
An on-line help program allowed the SysOp instant access to the user manual at the touch of a key and a new SysOp/Caller interface which set the program above its peers.
Even the off-line “Doors” could be configured with the BBS all in one place.
An update is what it got…
The first upgrade was the inadequate OML off-line mail system which worked fine but was not compatible in any stretch of the imagination to the new modern standards. V5.1 was built to settle these problems. A QWK off-line mail reader replaced the OML and solved the mail dispute.
The network (MCNET) was once again overhauled and a new network was introduced. The new network allowed MCBBS to be universally compatible with other BBS's and computers - It was called FIDONET, a network widely used by BBS's since 1981.
The first test fire with MCBBS on FIDONET was done in late 1993 with the help of a Belleville area SysOp sympathetic to the MCBBS project and one who had established a special transfer section strictly for MCBBS and related items. He allowed his node address for his "Observatory BBS", using a competing BBS program, to be used for packet transmission. He took the packets from MCBBS and sent them over the "Worldnet" - a FIDONET based network. These tests were meant to test if MCBBS was generating standard packets that could be read by any competing program. It was an amazing success! Within 24 hours the world was well aware that MCBBS had discovered world networking technologies and how to obtain (ahem… “borrow”) a node number!! It was the shot heard around the world; MCBBS's equivalent to the completion of the “Manhattan Project”! There were three such tests done and the last message of the last test read "Sorry to everyone on the Worldnet for borrowing this node number but I just had to do this test and get it off my chest".
MCBBS handled the technology very crudely, there was definitely room for improvement and there were limitations but like all past versions, the features improve with time. By the time v5.5 was released FIDONET replaced MCNET as the primary MCBBS network.
Other enhancements also included an improved ANSI controller better than that of v5.0, better screen designs, high speed modem control and moves toward modernizing the messages.
One other major advancement was the fact that in v5.1 the “modules” and “doors” were specifically designed so they could be changed without updating the entire BBS, which greatly helped in the correction of errors and reduce the wait time for fixes.
The program was no longer a simple project, it had ballooned into an enormous development combining many technologies into one.
MCBBS v5.1 was dubbed "The King of BBS's".
MCBBS v5.1 & 5.1A were a collage of technologies and languages. BASIC, C, PASCAL as well as small sub-programs and modules which helped the program conduct its activities had become common place. The basic MCBBS directory was a long list of little EXE encrypted files loaded automatically by MCBBS when needed. It also was the first version to be able to handle modems in excess of 9600 BPS. In fact the routine which handled this function was not native to the computer languages I was using as few programmers required that kind of speed (within a few years that would be a different matter). As a result I had to calculate the ROM BIOS BAUD devisors by hand and hard code these into the program as a table in Assembler, something most programmers would not like to handle even on a good day!
McBBS v5.1 also allowed multiple modems to be used with it at the same time, allowing for multiple connections or a dial-out with a dial-in. Problem is, other than the old "VERIFY" door program or the FIDONET/MCNET there was no true multi-user ability in MCBBS, rendering the feature useless for everyday. This all increased the size and complexity of the program but it was reliable and stable.
V5.5 was the first to be totally commercial, where-as in the past most were given away, or sold directly by me cheap, but now there was no way to get one without paying the $59.95 CAD price (still a bargain though on the only price increase in its history - past versions were $40.00)). It was also the first to be mass produced as in the past each one was hand done when an order was received. The initial production run was 50 units and each one was serial numbered using hexadecimal code and boasted a plain white label with black lettering neatly arranged in big bold letters:
Written by: Derek McDonald
(c)1996 DMCS Technologies.
I had moved back to Oakville and graduated from college this gave me more time to dedicate to the project, at least for the time being.
This was the most tested MCBBS in history, perhaps the most tested program in history. More than half of the time it took to develop and release the program was spent in testing. There was even a BETA-TEST version released! I was determined to ensure that the words "Quality" and "Reliability" were on people's lips when using MCBBS and that the embarrassing mistakes of the last few versions would not happen again. And they didn't; the program was as close to perfect as I could do. During its YEARS of operation only three small patches (called revision 1, 2 & 3) were done but no recalls were needed nor were these changes identified anywhere on the software label.
This version had several new features as well. The program was always Y2K but now that capability was tested and enhanced so that the computer running the program would also be compliant while MCBBS ran in the memory. The message bases and transfer bases were not unlimited due to a possible future of this feature discovered in v5.1A. Instead it held 16 million entries (virtually unlimited). A more extensive on-line help system for the SysOp not only included the user manuals and an updated HELP.EXE program but also an updated QWK off-line mail reader and error messages with useful, meaningful explanations as well as a special manual supplied on-line from the BBS itself for users/callers to use explaining all the commands in detail and support for CD & DVD ROMs.
Processor synchronization made the program run its most efficient on the wide variety of CPU speeds then available ranging from 10MHZ-333MHZ.
Improved ANSI code set and music code set allowing MCBBS to transmit both low-resolution graphics and sounds - something unique to it.
The “Music Code Set” was unique to MCBBS and essentially used an extension of the ANSI Control Code set. It only worked if the receiver has the COMTERM terminal software. A low-resolution, but nonetheless audible version of the William Tell Overture and Rolling Stone's "You Can't Always Get What You Want" hightlighted the feature's capabilities. The sound could be embedded with the video graphics.
V5.5 was also the first and only version to feature a separate DEMO edition, that functioned in every way except communication via the modem (it would simulate it).
V5.5 would also inherit the VGA text resolutions of v5.0, as well as the ability to flip between split-screen (showing user stats and activity on the same monitor allowing 50x80 & 25x80 text modes). This feature was "micky mouse", however, and rarely used. Likewise rarely used: MCBBS's so-called "multi-task" ability; in the end the program never did develop the true multi-task ability, but did allow file sharing if the OS (Operating System) handled the multi-task for it.
The door loading program was corrected fixing the problem that forced some doors to require the COMCONV data program writeen by MCBBS. Also an update to the on-line user command help file.
Rev 3: (A.K.A. "The Alliance Version")
Rewritten user manuals with much more descriptive material was introduced as well as the addition of a high-resolution graphical title screen announcing the 10th anniversary of the program and the inclusion of two new protocols XMODEM & YMODEM and a new version of ASCII as a replacement to EASCII.
This version saw MCBBS featured on the Emperor Multimedia music compilation disk The Alliance and on this disk, hidden away on the computer CD-ROM portion, was a copy of MCBBS v5.5 demo with all of the Rev.. enhancements. This enhanced version would immediately go into regular production as well by DMCS. This would be the first appearance by a BBS on a music recording and would also be MCBBS's first appearance on a CD-ROM.
Also, revision 3 finally had some proper OS tests done to it and it was discovered that a wide ranging group of users were able to use MCBBS. DOS, OS/2, all versions of Windows, MAC, UNIX and others. A large number of people and machines could now run MCBBS if they wanted to.
Rev.3 also had a "forced compliancy" that made modems designed to work with Windows but exclude DOS apps, work with MCBBS no matter what.
Unlike past versions, MCBBS v5.5 had a companion DEMO version. This was distributed free to anyone who wanted it and was exactly the same as MCBBS v5.5 except it did not come with any utilities except HELP and the INSTALL application (which was also updated between v5.1 & 5.5 in that it no longer relied on the OS for many housekeeping functions (like file copy), and it was smart enough to automatically detect the location of the modem, processor type, etc.). The program did everything else except telecommunicate. The program was rigged so that an internal bitmapped switch was set to off to disable the modem. If you wanted access to the modem and extra utilities you had to pay for the full version.
The same switch that disabled the DEMO from communicating could be reprogrammed at compile time to designate the program was BETA. The Beta was used before launch to test the BBS and several copies are known to exist, however, it is unlikely any of them are running because this switch causes the program to shut itself down at the designated date (3 months after the beta version was created). This feature would, however, lead to an interesting pirate control system for future releases.
Now MCBBS was available on CD-ROM (The Alliance) and standard magnetic disk (3.5" high density). However, in Jan. of 1999 it would no longer be available on 5.25" low density or 3.5" low density. If you wanted magnetic you had to take it on 3.5" high density or (by request) 5.25" high density. Future versions would all be on CD-ROM.
The spell check feature, however, was removed. MCBBS still retained another unique feature, however. It's programmers reference guide the "Technical Manual".
New marketing techniques had also been implemented. Now one could contact DMCS and get a detailed and professionally made sales and technical brochure on the product. Discount coupons were available and even retailers had been solicited. The US Post Office, Spar Aerospace and other such large operations were considering MCBBS for installation into their operations. Even a web site had been set up with a section featuring MCBBS. In fact, several web pages had links to MCBBS and even free demo FTPs were available there. There was even an attempt at getting computer manufacturers to pre-install MCBBS onto their machines or sell it with modems as a value added product. There was even a 3rd party distributor called BBSDirect.com that sold BBS's over the internet (including MCBBS).
A MCBBS user, JP. Barrette, who owned a small marketing firm in Mississauga, Ontario, Canada became a good friend and advisor and threw his marketing and business advice into the show as well. I became convinced that, if nothing else, he was an intelligent man, when he had figured out that in the manuals of MCBBS v5.1A & earlier, hidden amongst all the technical specifications and instructions were also my plans for the future of the program. He didn't figure it all out but he was the only person to have actually reported his findings in the User Manual - the only person to have figured it out near completely. In essence, he read my "manifesto" (sp?). Such references are no longer present in the manuals.
This little program was designed to allow old “Door” module programs to interface with the new version of MCBBS using a different language and different methods of handling the COM Port and BIOS. It was discovered that some “Doors” couldn't handle it. It was later discovered that a small change to one line of the MCBBS source could automatically correct this problem thus rendering this program obsolete - it was thus no longer shipped with MCBBS.
When EASCII had run its course and I learned more about transfer protocols a whole new ASCII protocol was developed. MAM (“MCBBS ASCII Modem protocol”) was developed to replace EASCII. MAM (and MAM1 (v1.1) - the update) looked and felt like the old EASCII except it was much faster, less clunky and had a new user interface. It also had a small ASCII terminal. It's appearance matched those of the rest of the protocols.
MCBBS X-Modem protocol utilized all the features of standard XMODEM and adopted them for MCBBS or any other general purpose COM program. It also featured X-MODEM CRC and X-MODEM-1K modes. MXM was developed before all the other protocols other then MAM and EASCII and it, as well as all others there-after (and the McBBS itself), featured a new data pump subroutine to handle the modem. The fastest ever for McBBS, and probably the fastest ever for any DOS based BBS of the day. Code-named "Sputnik", after the Russian satellite, McBBS's transfer protocols were now stripped down data transfer machines coded in 8086 Assember able to outstrip their competitors at almost twice the speed. There were three versions of MXM in total: v1.0, 1.1 & 1.2. It also had a small ASCII terminal. Its appearance matched those of the rest of the protocols.
MCBBS Y-MODEM protocol utilized all the features of standard Y-Modem and adopted them for MCBBS or any other general purpose COM program. It also featured Y-Modem-Checksum/CRC, Y-Modem-128/1K & Y-Modem-G. This program proved to be the fastest running I ever wrote up to this point and for some time after. There were 3 versions: (1.0, 1.1, 1.2). It also had a built in ASCII terminal. Its appearance matched those of the rest of the protocols.
This was a small program but took a long time to develop. As far back as 1992 I had envisioned a way for BBS's to connect to one another via standard modems. Each BBS would connect to the next and so on allowing the user to jump between systems. Between the time of conception and the time of creation, however, several years had passed and others had similar ideas. Some BBS's did a single jump system and even the internet came out with the World Wide Web and Telnet.
But in 1997 the resources were obtained to build test and market what should have been one of the first such jumping systems - MCCON.
But MCCON had one other innovation that was not seen by the user. It was the first "assembly line" BBS “door/module”. I had developed standardized working routines and components, i.e.: Disk I/O, Modem I/O, ANSI processor, etc. And developed a simple method of connecting these together but at the same time allowing the programmer to make subtle changes to suit the special needs of each “door” - basically build a shell and fill the middle like an apple pie - this allowed the program to be actually built, assembled and tested (after the research was done) in record time.
Another first innovation by MCBBS. This one will likely be unmatched for some time. The ability to force any competing proprietary program to run with your own product is a dream of many a software company but MCBBS was there first. The “Viking Scriptor” was launched in March of 1999 after more than a year of development and 3 years of planning and using the "assembly line" programming method. It allowed the user to program a script run by the VUDC interpreter that would rework the output of MCBBS to match that for the input program’s "Drop Disk" configuration files (a type of file left by almost all BBS expansion modules). In essence, making the other program think MCBBS was simply the host program by its own maker.
It worked well and the script was so powerful that it could execute many times faster than even standard scripts. A programmer could control screen text and colours as well as disk files and even run comparisons and procedural jumps "GOSUB" and "GOTO" 255 iterations deep, something few have ever seen scripts do. The language was so powerful that this one utility alone was called (incorrectly) "MCBBS 6" as it would prove to be so powerful it was speculated it would be the engine of a proposed script for the next version of MCBBS. Indeed, you could build a primitive BBS with it alone! Version 2 would have had better memory management and variable handling, but it was never completed.
This was just packages containing updated user manuals which were included with all MCBBS v5.5 rev. 3's. The manuals were drastically redone and were based on the planned book version for the MCBBS v5.5 “Deluxe” package. The package was completed, but without the book. The text was so large two were provided, an original segmented version for viewing via a word editor/processor and the HELP.EXE (".DOC") version for on-line viewing.
Program Information Files for making MCBBS run more efficiently on Windows. A COMTERM counterpart was also done.
Although MCBBS never ran native under MS-Windows (it executed as a DOS application), Windows icons for MCBBS were created for v5.5 and on. I had obtained an icon generator and immediately put it to use. A COMTERM counterpart was also done.
During “The Alliance” (rev. 3) upgrade I had figured out what made Windows program automatically execute from disk and so designed a script that, when installed correctly, would do the same for MCBBS. A COMTERM counterpart was also done.
Same as v5.5 Rev 3 but would also come with all utilities and applications (like MCCON & VUDC) that were sold separately and be on CD-ROM with a printed version of the user manual in book form. The manual had not been available in ANY printed form since v3.3; it was supplied only on diskette, MCBBS was one of the first programs to utilize this capability which today has become commonplace. JP and I approached several retailers and publishers but none would sponsor the idea. All remaining MCBBS copies left in storage at the demise of the project were converted to MCBBS 5.5 Deluxe but no printed manual was ever done.
MCFAX: This was a fax program that would allow MCBBS to accept and send faxes. It has a standard 9600 and advanced 14400 mode. At least that was the plan. The program prototypes did work but due to lack of development time and the fact that the answering system of MCBBS v5.5 would have to be redesigned to accommodate full fax integration it was never completed to market.
This was a proposed version that would enhance MCBBS v5.5 Rev 3 with such things as message & file transfer topic grouping (multi-level grouping), Telnet ability and improved FIDONET. It would also have multi-lingual prompts supplied to the BBS by a user programmable database. Also new software coding techniques were learned that would allow the program to be faster and smaller. It would also allow fax integration and message database compression. By this time MCBBS v5.5 was suffering poor sales and the time and expense in development could not be justified.
One change - recompile to be 16 bit. Idea was scrapped due to the fact that even coding the system in 16 bit would still render it obsolete in a 32 bit world. (McBBS was still compiled using 8086 code - 16 bit, but 8 bit compatible).
For many years Apple Macintosh users had been contacting me asking about a native Macintosh version of the MCBBS and offered the name MACBBS to play on the name.
By the time v5.5 had been released I seriously considered this notion and had begun the preliminary investigations. The Mac was not my native machine so I sought help from Apple corporation, at this time in its history Apple was not known for its service and completely ignored my requests, so the "MACBBS" never materialized.
By the time MCBBS v5.5 was launched Microsoft was soon to release new versions of their Windows product, (Win95). Although this product, in the end, would prove to be less then spectacular it was nonetheless popular. Most BBS's that had successfully converted to Windows ended off failing in the marketplace due to the fact that text based BBS didn't convert to graphics very well. I considered this for my program, however. I bought a computer language that could be scripted for the Windows environment and quickly discovered that it was needlessly complex and verbose and decided that it wasn't worth the effort. The “MCAURUN”, “ICONSM” & “MCPIFS” packages were the result of this research that did make it to market, however.
Only two versions of the on-line manual reader HELP.EXE were done. Both were identical except for internal programming changes but shortly after v5.5 I discovered a way to allow HELP to do the very same page formatting using mathematics instead of a mechanical marker placed in the text stream thus allowing ANY document to be read without the need of reformatting them.
Direct Video Transfer. This technology would allow the contents of one computer monitor to be directly transferred to that of another digitally by extracting the information direct from the video RAM. The theory was that it could obtain animation speeds and compete with the emerging video telephones. Thus far it has never been completed because computers weren't fast enough and an adequate compression for the data was needed and not found. Today, we have Skype – rendering this completely obsolete!
Direct Sound Transfer. This technology allows sound to be digitally transferred from one computer to the next. It was intended as an advancement to the old ANSI add on DMCS-MUSIC codes except this technology was DIRECT, i.e. it was not an interpreted set of instructions like the enhanced ANSI codes. It was not developed and is unlikely to be because of the advent of Real-Audio & Shoutcast for the internet.
MCBBS v6 (A.K.A. MCBBS-32):
With the surprising innovations of the VUDC a proposed script based MCBBS was suggested. This program would have little to no configuration; everything would be run with a set of scripts written by the operator. Essentially the MCBBS would simply be a script interpreter with communications ability. The script would allow the user to make MCBBS do just about anything he wanted even look and act like a competing program. It would also be coded in 32 bit and require a math processor, not because the technology needed that power but because I wanted to update my software to take full advantage of the new features available on newer machines. It would allow up to 5 (more in successive versions) callers and the SysOp to be on-line simultaneously as well as multi-nodes.
It would also be a modular program which would allow individual components to be updated as needed; a trend MCBBS was drifting toward anyway. This would virtually eliminate the need for a central processing program and drastically reduce the development time for the program - when a new technology by a competitor was innovated it would be weeks, not months for MCBBS to implement its own version and the MCBBS operator need only purchase a small upgrade kit and not the whole program at full price again. This wouild drastically decrease any advantage someone would have over MCBBS.
By the turn of the century, I had discovered the basics behind the logic & coding of operating systems and had actually obtained a book that listed the raw code for a DOS-like system. Modifications were made to the program, and to this day all that remains to be done on it is a directory/File Allocation system. Since MCBBS almost operated like an operating system to its utilities and “modules/doors” it was suggested that why doesn't it just become one in its own right. This idea also boded well because it would solve the problem of MCBBS having to be recoded when operating systems changed, if it had its own OS it would run regardless of what the latest fad that IBM or Microsoft decided the throw out at people. When the entire McBBS project was scrapped, this proposal went with it.
MCBBS ZMODEM protocol. After the successful completion of XMODEM, ASCII and YMODEM I started research into a Zmodem protocol. Zmodem is completely different and more advanced than the other two. The time just wasn't there to complete the job. Since there was a wide variety of 3rd party protocols available cheap and free this was/is not a priority.
There were spell checkers and language translators also proposed. Also an addition to the configuration file identifying not only the version but also revision number. This feature was successfully added, however, to COMTERM v3.1 (the last version).
Up until this time, since the beginning, all of the shareware and demo software were available on other BBS's, even over the FIDONET, now they were also on the Internet. But in late 1999 I stopped distributing my software over BBS's you could only get it direct, via a distributor or on the Internet. It was one cutback of many that would be made.
Many blame JP Barrette for the fall of MCBBS; they say his capitalistic ways turned a shareware experiment into a commercial enterprise for big business, they also blame him for some erred or bad advice. But in reality if it wasn't for JP, MCBBS would have ended on the launch pad of MCBBS v5.5 as I had declared I was finished with the program and it was "The final version". Because of JP, MAM, MXM, MYM, VUDC, MCCON and MCBBS v5.5 rev: 1, 2 & 3 were done. Further to that, MCBBS 5.6, 5.7 and MCFAX as well as MCBBS 6 were at least considered. In the end he personally may not have advanced the sales of MCBBS like he promised but he did encourage me to hang on a few more years to give us just a few more ideas. No, the problems were not with J.P. alone. There were many factors pushing the demise of MCBBS. MCBBS's sales were falling even though it's interest and technological advancements were the highest ever it its history.
So, what were the real reasons for the end to MCBBS?
As it is so with nations, industries and individuals also occasionally resort to spies to get them an edge up on their enemies and competition. History has shown that the Russians obtained the atomic bomb from documents slipped from US scientists after the second world war, Microsoft figured out both DOS and Windows from information obtained from outside sources, just to name two cases. Now not all spy work involves James Bond or breaking the law; much of it is legitimate research which was helped by some sympathetic people or circumstances.
MCBBS was no exception it was spied on and did some of its own. However, it is important to note that the evidence shows the bulk of the MCBBS program and its accomplishments were done without espionage and, indeed, were genuine research.
Most PC based BBS's of the time used the source code of a program called "WWIV" as their base of operations - they cheated. WWIV was a PASCAL encoded program whose source was widely available on the internet and when it changed so did most BBS's to match it. But MCBBS was one of the few unique programs that boasted its own source code 100% original. Not only that but it used both proprietary parts AND standardized parts thus successfully mixing the two for great compatibility results!
The only known breach in the technology contained in MCBBS was with v3.0, which was coded in GWBASIC and utilized primitive locks to keep eyes from seeing the program script itself. Unfortunately these locks were well known to avid BASIC programmers and were easily broken. The knowledge gained by the individuals, however, was useless, since MCBBS by this time was several versions beyond and no known technology by these third parties ever evolved.
However, the opposite is not so true. Although very few technologies were gained by spies those that were … were used. The most recent attempts at the MCOS for example, early prototype transmitters, FIDONET, etc. These items were not collected deliberately, however, but were slipped via "the back door" by supporters of the program.
At time of this original writing the future of MCBBS was being debated with the last ditch effort of getting MCBBS promoted by having it installed on “The Alliance” compilation disc. This, for the first time coupled it with the internet, put the program on CD-ROM and give people outside of North America the chance to sample the work. Should it fail there are two options being considered: Stop production of it or go ahead to develop EMCOM and end MCBBS. It succeeded in part but not enough to encourage a new version.
“EMCOM” was a whole new concept - it would pick up the pieces of MCBBS v6 and go all the way with them and then add more. It would be a multi-user, multi-caller communications environment that would run on several operating systems or feature its own. It would run from a script language, be able to interface with the internet and others of its own kind as well as be 32 bit and modular. COMTERM would no longer be an independent program but be a part of the huge EMCOM that would be sold on CD-ROM and feature printed manuals (something not seen on MCBBS for some time; MCBBS had electronic manuals long before most other software). But it would not be a BBS and unlike it's MCBBS ancestor it would not be compatible to all that came before it - it's a new beginning. The new company EMPEROR MULTIMEDIA will publish it (hence the name EMCOM (Emperor Multimedia Communications)).
It will have little to nothing to do with traditional BBS's which by the time of this writing are fading in popularity and by the admission of its own users is "mostly a hobby based endeavor". EMCOM will be a serious commercial undertaking.
[[Footnote after publishing: ECOM has been forgotten.]]
MCBBS was the underdog in the BBS world, and as such needed a helping hand. This helping hand came in the form of interesting ads posted on other BBS's. In the early Commodore days the most famous of which was the text message saying "McBBS: The little BBS that could", a spoof of the 1930's children's book "the little engine that could". In the PC days this would change to "McBBS: Big power in a small package", milking the program's compact size but robust abilities for all it was worth. Once MCNET was launched it would be, "Now, you can do more than just order burgers and fries with it", playing on the product's name! The most successful of which was the first two campaigns in reverse order.
On file at the Canadian Intellectual Properties Office is the original copyright certificate #458138 declaring MCBBS as being released Oct. 30, 1989 at Waverley Nova Scotia, Canada as a Literary (Computer Program) work. Even though such certificates were no longer legally required it was registered anyway to protect it legally AND for historical records.
In 1999 MCBBS earned its place in history by being submitted to the National Library of Canada archives for future historians to examine. It has been suggested it should also be sent to the Smithsonian in the USA; thus far it has not been.
[[ Footnote after publishing: In 2007 McBBS, along with the projects that succeeded it in the multimedia/music business including Alliance, Recorded History, and Polishing of Metal would get inducted into the United Nstion's "Great Librarty of Alexandria".
McBBS has also been featured at Wikipedia.
A classic computer user’s group in Ukraine contacted me to obtain a copy of MCBBS for use on their old PC computers. One problem, McBBS had no means of installation via an Internet download. It was patched in 2010 to accomplish this; that is the version you can download here – full “deluxe” version.]]
If there are no more MCBBS's beyond this point then it will, indeed, be a sad event. It would represent the ending of an era, a part of the closing of the golden age of computers and data-communications. It means that the pundits won in the end and corporations, not people, decide what modems shall transmit. We will at least have the comfort of knowing that one man worked on a dream and surprisingly got a long way with it and in doing so left us some really good technology, ideas and memories. It will give historians something to talk about when researching the 20th century and discover its byline. There is also a chance, a small one but one nonetheless, that somewhere a computer will still be running some long-time retired version of MCBBS.
"What do I do with it? Order fries and a hamburger?"
"It's too clunky."
"It doesn't look like the other programs."
"It will never fly."
"You can't do that."
They tried... Oh did people try to knock down the little program with the funny name - the name that everyone thought was silly - but they couldn't get it off their lips! But it had its supporters and it was the kind of program that either you liked or you didn't. Those who used MCBBS *CHOSE IT* it was never the latest fad or fashion. It was marketed at new and intermediate BBS operators and offered a no-frills approach to BBS's that the technology had long abandoned - it carved a small niche for itself and that was its market appeal. Those who didn't understand this - and there were many - completely missed the point of the project, indeed, of what the BBS hobby and technology was all about. But I, for the most part, ignored these people remembering the quote that a by-stander to one of these "mud-sligging fests" said in defence of the program, "Unless you can make something better you have no business complaining and MCBBS is a much better than I could ever do." Thank you for that memory I got a lot of mileage out of it...
MCBBS started off as a one off project just to see if it could be done and ended off transmitting its creator’s ideas for 10 years.
Time marches on...