What Is Bulletin Board System And Its History

[Rohan Ramanath 0]

Notice from Jeigh:

This was all taken from http://en.wikipedia.org/wiki/Bulletin_board_system. Posting material from other sites is considered spam and will not be tolerated

 

B.B.S

 

A bulletin board system or BBS is a computer system running software that allows users to dial into the system over a phone line and, using a terminal program, perform functions such as downloading software and data, uploading data, playing games, reading news, and exchanging messages with other users. During their heyday (from the early 1980s to the mid 1990s), many BBSes were run as a hobby free of charge by the "SysOp" (system operator), while other BBSes charged their users a subscription fee for access.

......

.....

Edited April 11, 2006 by OpaQue (see edit history)

[evought 0]

<lots of quoted stuff>

I started out with the WWIV and early telegard systems in the eighties. Telegard, and later Renegade, was an attempt to rewrite and ceanup a lot of the old WWIV code which was extremely buggy and full of backdoors. They were all written in Turbo Pascal. Late Telegard systems were the first to include OOP with the Object Pascal compilers. We connected to the Fidonet backbone for mail and news exchange. Most BBSes had scheduled downtime where they called the next hub in the network. Even with all that, getting news or mail from one end to the other was not long, about as fast or a little faster than the postal system.

The beauty of the old Telegard systems is the configurability of the menu system. It was very easy to set up good looking and fast rendering menus, add Doors (exits to external programs like games), and program in upload/dwnload handling (such as scanning, converting, and moving archives). Several of the later systems had what was essentially workflow management where new uploads would go through a series of automatic and manual steps before being published. Archive systems (zip, ARJ, etc.) and serial protocols (e.g. ZModem compression) improved at a fantastic rate and this was a big challenge to get the best compression on slow modems and keep up with the changes in software.

I did Pascal (and some assembly) programming for a number of area SysOps in exchange for system privileges. Most of the Pascal work was general cleanup and security fixes. I would just walk through the code, figure out what it was doing, and refactor as I went, encapsulating records in objects, splitting long routines, combining routines which did the same thing. I would also monitor boards to see how people were getting in or get reports from Sysops and try to find the backdoor in the code. Buffer overflows were not common since one of Turbo Pascal's strengths was its length-checked string operations, something that still is not common in C programs.

The availability of the Turbo Vision Source code which Borland included with their compiler was a godsend. having two bodies of code, one horribly written, badly commented, and disorganized, and one well-organized, elegant, and well documented gave me guide posts for re-organizing Telegard. It also developed my coding style to be tight, safe, and compact. I think any programmer starting out needs exactly that: a horrible program to maintain and a good program to look at.

The assembly work was either performance tuning or, mostly, FOSSIL work. The FOSSIL layer was a set of interrupt handlers and assembly routines to replace DOSes insane and badly broken interrupt routines. FOSSIL drivers were supposed to be easily portable (and in practice were--- the top-level routines and API/ABI could be ported to, say, the Motorola chips without much headache) and *re-entrant*. Re-entrant code was critical to multi-line BBSes. Re-entrant means that more than one process could run interrupt code at the same time. DOS had many different functions all tied into one interrupt and none of them could happen at the same time, say monitoring keyboard states and ansering a modem ring. BBSes were multi-line by running completely different copies of the BBS program and very carefully avoiding executing the same low-level routines --- by blocking until the other was done. Reentrant FOSSIL drivers allowed much finer grained multi-tasking, until, by college, a BBS running under Desqview X could almost be said to be threaded.

One of the things I worked on in my pre-college and early college days was squeezing the last bit of BBS performance and efficiency out of the machines of the day. This meant working with overlays (loading and unloading portions of the code to fit in 640K, early on to disk, later to high memory), and a locking memory management model. Before accessing an object, you lock it for use, it is loaded if needed, then when unlocked it can be swapped out following an LRU or pre-emptive swapping model. Most of this work became unnecessary as newer OSes (like OS/2, Desqview X, and Linux: notice I do not mention Windows here) took most of this burden away from the programmer. As 386/486 processors came on the scene, some of the OS load was taken on by the processors MMU, and flat memory models like in OS/2 Warp or Linux eliminated the need to manage your 640K main memory area, far pointers, etc., entirely.

By this point, the Internet was popular and the hey days of the BBS (per se) were gone. More people began using email, Usenet news, and the Gopher network (pre-WWW). now, BBSes and blogs are coming back into style as the Internet becomes more community-communication oriented.