💾 Archived View for gemini.spam.works › mirrors › textfiles › magazines › BTN › btn008.txt captured on 2022-06-12 at 10:31:28.
-=-=-=-=-=-=-
BTN: Birmingham Telecommunications News
COPYRIGHT 1988
December 1988 Volume 1, Issue 8
Table Of Contents
-----------------
Article Title Author
Policy Statement and Disclaimer................Mark Maisel
Editorial Column...............................Mark Maisel
The EZNET System...............................Tim Straughn
The Sex Life Of Guppies And It's Relationship
To Telecommunications....................Co-SysOp One, Channel 8250
A Tutorial Of Unknown, Unpredictable Length....Blake Miller
E-Mail.........................................Barry Bowden
The New Look: Graphics Interchange Format.....Gary Steven Godsey
The Realm Of Tarot BBS: An Overview...........Dean Adams
ProFile: Tim Straughn..........................Chris Mohney
Reader Survey..................................Barry Bowden
My BBS.........................................Joe Kearley
Message Board..................................Barry Bowden
Known BBS Numbers..............................Mark Maisel
-----------------------------------------------------------------------
Disclaimer and Statement of Policy for BTN
We at BTN try our best to assure the accuracy of articles and
information in our publication. We assume no responsibility for
damage due to errors, ommisions, etc. The liability,if any for BTN, its
editors and writers, for damages relating to any errors or ommisions,
etc., shall be limited to the cost of a one year subscription to BTN,
even if BTN, its editors or writers have been advised of the likelihood
of such damages occurring.
With the conclusion of that nasty business, we can get on with our
policy for publication and reproduction of BTN articles. We publish
monthly with a deadline of the fifteenth of the month prior to
publication. If you wish to submit an article, you may do so at any
time but bear in mind the deadline if you wish for your work to appear
in a particular issue. It is not our purpose to slander or otherwise
harm a person or reputation and we accept no responsibility for the
content of the articles prepared by our writers. Our writers own their
work and it is protected by copyright. We allow reprinting of articles
from BTN with only a few restrictions. The author may object to a
reprint, in which case he will specify in the content of his article.
Othewise, please feel free to reproduce any article from BTN as long as
the source, BTN, is specified, and as long as the author's name and the
article's original title are retained. If you use one of our articles,
please forward a copy of your publication to:
Mark Maisel
Editor, BTN
221 Chestnut St.
BHM, AL 35210-3219
We thank you for taking the time to read our offering and we hope that
you like it. We also reserve the right to have a good time while doing
all of this and not get too serious about it.
-----------------------------------------------------------------------
Editorial
by Mark Maisel
We have run a bit behind this month and we apologize for it. We hope
that you will have found this month's issue to be well worth the wait.
This issue abounds in great educational and humorous content. The real
story behind EZNET is our feature this issue and I am sure that it will
be of interest to everyone who uses our local boards. For those of you
who would like to learn more about the C programming language, look into
Blake Miller's tutorial on the subject. With any luck, you readers and
I may be able to convince Blake to continue the tutorial with
regularity. For those of you who have trouble understanding his typing,
I translate each word into English before it gets into BTN. What about
GIF pictures? What indeed! When you finish reading what Gary Godsey
has discovered, you will know all about it. Our ProFile victim this
month is Tim Straughn and we invite you to see how our resident
interviewer shreds, er, converses with his victim. We have two SysOps
who have written to entice you to visit their systems and give you some
highly entertaining background on their systems and themselves. Barry
Bowden is conducting a reader survey and we would definitely appreciate
all the participation we can get. We are extremely interested in
finding out more about you. There are many other things in this issue
that must remain a surprise for you to find so happy hunting!
I would like to close by wishing everyone a safe and happy holiday and
new year! Don't do anything I wouldn't do. No, scratch that. I might
do anything. What the heck? Do it anyway and just don't get caught.
Bye until next year!
-----------------------------------------------------------------------
THE EZNET SYSTEM
A Brief History and Description
by
Tim Straughn
Copyright Nov. 20, 1988
EzNet. Most of us have seen it, some of us know what it is, and a few
of us are actually taking full advantage of it. Yet there are still
those out there that haven't figured out why they see a message on a
system that they left on another system. Where did this come from, who
developed it, and what in the author's wildest dreams made them think
that it would be successful? I hope I can answer all the above questions
as I was one of the instigators of the system, and played an active role
in the design and implementation of the system.
First of all, perhaps I should explain the EzNet system. The EzNet
system is a set of programs set up to link message bases between several
of the boards around Birmingham with both private and public mail
privileges, open to the general public, with selective registration so
that any user may register for private mail on any system, and the mail
will go there only, and not all over the place just making the message
base larger on the other systems. These programs include a pretty
complicated batch file to take care of the processing of archived blocks
of messages, both arcing them and unarcing them, (here's the pitch) with
PKARC utilities, and automatically calling Procomm supplying the script
for calling the system serving as a host, logging off and then appending
the incoming mail in the message base of a PCBoard 12.1 system. Believe
it or not, the whole process only takes about 10 minutes on the remote
systems, and about 3-5 minutes of connect time to the host. How does
this affect you the user? Well, let's say that you call several boards
around town, and are active in the message bases. One of those boards
is having a peak night when you decide to call and check for a reply to
a public cry for help with a specific program that you left on that
system. If you left it in EzNet, then all you have to do is try another
board which is running the EzNet system if you left the message two
nights before. If someone replied to it in the EzNet conference, and
left it public, then the reply will be posted in 5 other places, giving
you 5 other boards to try to call and find out if the reply exists. Now
for the fun part. Suppose you want to communicate privately about most
any topic with someone who has severe problems calling a particular
board, and you have problems calling the particular board they want to
use. If you have registered for private mail on the board of your
choice, and the person has registered for private mail on the board of
their choice, then the message will go to their chosen board no pain no
strain. It does slow things down a bit, but, at the same time, it might
just speed things up a bit as well if there is a peak on all systems
running EzNet and you are in a hurry to get in touch with the other
person. At most, it will add 1 day to the process, and this is
something I am working to solve. The topic of registering for private
mail on a particular system is discussed in further detail later in this
article.
How did the EzNet system originate? Well, quite frankly, it never was
intended as a public system in the beginning stages. I went to Ed
O'Neill, Randy Hilliard, (both of which I would like to thank for all
their help in getting my system off the ground), David Alge, Michele
Cahoon, and several others and asked them if they would like to spiff up
the Sysop's conference that all of us seemed to have, and all of which
seemed to be hurting for activity. Nearly all systems run a sysop's
conference for visiting sysops, but none of the sysops of busy boards
seem to have time to call other systems. Yet, we were all in agreement
that we needed a way to exchange information about board structure,
users, and general information about telecommunications, but weren't
quite sure about how to go about it. Well, Ed pipes up and says
something about a program called PCBECHO, which `only' costs $300. I
don't know about the rest of the sysops, but I am not interested in
blowing 300 bucks to chat with 4 or 5 other people. Fred McMaster had
left an announcement of a party to all of the aforementioned parties,
and then some, mentioning something about some extracurricular
activities involving goats, Clydesdales, and various and sundry other
farm animals at his place in the backwoods of Shelby County. I wound up
cooking, later to be joined by a somewhat inebriated Ed O'Neill, and
Randy, and all of us ate and drank until the brisk air of February ran
us all inside to Fred's living room in his trailer. There were 20+
people in this crackerbox, so Fred saved a bundle on the heating bill
that night with all the hot air associated with the sundry mixture of
sysops, users, and programmers. A discussion was initiated between
Randy, Ed, and myself, and I almost forgot, the illustrious and funny Ty
Ros concerning my wishes to network and incorporate several of the local
bulletin boards. Ty had to leave a little earlier than the rest of us
due to school or something, so the discussion group concentrated into
people who knew the structure of PCBoard. Later, the conversation
reduced to three people including Randy, Ed and myself, and began to
pick up the pace toward a solution to the networking problems. We all
got back to the point we could drive again, and headed for home, with me
anticipating the following weekend being spent with Ed coding the new
net for sysops.
Two nights later, a somewhat groggy Ed called me and demanded my
presence at his place as he had something he wanted to show me. Lo and
behold the rascal had the program written and debugged to pass public
messages and it was working like a charm between his AT and his XT using
Lan software. So, I took a copy of the code home with me and installed
a new conference on my system which only I could get in and began
tinkering with batch files for the remote system. I loaded up Procomm
and started writing the scripts for calling Ed's board and going through
the process of getting the file from his system. Plugged in a few
commands in the EVENT.SYS file, and we had a working system. This was
all well and good until Ed's sliding event ran past the time for my
event one morning, and I got all my own messages back. Ooops! Can't
have that. So, Ed came up with a new user account, a batch to run on
his end on demand, and removed the process from his event. Ahhhhh. Now
we're cooking with gas. A few modifications on my end, and BINGO!, no
repeat messages. We ran the thing 3 or 4 weeks passing messages back
and forth between ourselves, and adding a few chosen ones to help us
beta test the beast, refining the thing as we went. One day, I found
messages from other users in Ed's system, and a final note that he was
making the system public. Hmmmmm. Not a bad idea at that. Another 2 or
3 weeks of public beta testing couldn't hurt, and it certainly helped. A
couple of users then came in requesting private mail service, and so Ed
and I wound up with some more brain storming to do. So, thanks again to
my wife Lisa, I arranged a dinner for Ed and a general flurry of paper
and Turbo Basic code and PCBoard message bases ensued. We hashed it
out, and later that week, here comes the new code with new instructions,
and all the improvements requested, with the exception of one. At
present, there's not much way to handle that problem with independent
message bases running amuck, and the reference message numbers being so
different. Thanks to the users who inspired the private mail option.
Currently, the message base incorporated in EzNet is just like any other
message base on a PCBoard 12.1 system, and the actual operation is
nearly transparent to the user. (It becomes intuitively obvious to the
innocent onlooker.) The advantages of being able to send a message from
one system to four others with a single entry is not without merit, nor
is the routing of mail to someone who may not even use the board that
you are currently on. For instance, Ray Willingham may enter a single
message on any system advertising for Roebuck Typewriter, and not have
to call each individual board to do it. This is particularly useful if
Ray needs to do something fast and doesn't have the time to call all the
boards he wants the message posted on. Or local user groups may post
announcements of their next meeting so that members may be more likely
to see the announcement if they only call one system. Or, another use,
though to the chagrin of some other users, Girl-meets-Boy-meets-Girl
romances get initiated. The uses of a publicly echoed message base are
actually boundless, and though perhaps not always the best of messages
gets echoed, the purpose of the system is to get information across town
with the least amount of downtime on each associated system.
Though the system has Private mail capabilities, I am surprised to find
that few have used the capabilities. Now, there are even complaints
about the return to sender message generated by the system and the
accidental entry of public registration requests. The problem is that we
cannot make the system too complex for the user, nor can we produce a
door that will reliably register each user who wishes to use the private
mail feature. Currently, the procedure for registering for private mail
is quite simple, and the system even provides feedback to the would-be
registrant if he/she doesn't quite get it right. The whole process of
getting registered for private mail on a particular system is as simple
as entering any message. The steps are outlined below:
1. Enter a message to EZNET CENTRAL. If the system has
receiver checks turned on and does not have a user record for
EZNET CENTRAL, then the person will be prompted to continue or
re-enter the user name. Simply continue.
2. Make the subject of the message REGISTER ME. This special
topic will prompt the host system to add the name in the FROM
field of the message header to the index of private mail users
if one more condition is met.
3. The third and final criteria for getting registered is to
make the message receiver only. This is only to keep other
users from having to read some silly garbage which may or may
not be an actual message, and also serves as the second flag to
set on the host system, telling it to send feedback to the
registrant that they are now registered.
If any of the three criteria are not met, then the host system will
respond with a message to the originator that the addressee is not
registered for private mail, that EzNet Central is not registered for
Private mail, or some other message to let the user know that he/she
didn't do something quite right. The solution is simple. Try again.
Actually there is one more criteria. The message has to be entered in
the EzNet conference, but this sort of goes without saying.
Ed O'Neill spent a good deal of time making this thing work, and I hope
to enhance it with a few more options at a later date. For those of you
wanting to exchange long text files which compress so well, I hope to
even add attachment capabilities to the system. This will not come easy
though, and will have to have a lot of checks against abuse. I have
already begun to enhance it for the sysops to make it easier for me to
implement a door which is both security level and password protected,
and also make the operation of it quicker because of the added memory
allowed by unloading the PCBoard code. This also allows me to run my
system from RAM disk and provide for faster turn around time to the
normal users, and much less hard disk access for loading the PCBoard
code when executing doors. Another feature this adds is it allows me to
strategically place messages in the log file generated by the script
file used for Procomm which will enhance the troubleshooting procedures
for newly added nodes.
The primary contributors to the EzNet system from the users standpoint
have been Blake Higdon, Blake Miller, Sohail Rabbani, Osman Guner, Ty
Ros, and Omega Ohm to name a few, and if I missed your name and there is
an improvement in EzNet which was your idea, then I apologize. With the
suggestions from the users, EzNet has grown into a very efficient system
with virtually no restrictions other than the requests of the sysops who
help run the system. We all have very little stipulation regarding the
use of the EzNet system, but most of it is common sense regarding
aspects of social behavior. Due to the fact that EzNet actually works
with PCBoard messages, other doors which allow archiving the messages
for download, such as ProDoor, will work just as well. Ed and I tried
to keep it as close as possible to the message utilities built into the
PCBoard code in order to not adversely affect any other program which
works with the PCBoard message bases.
Hopefully, in the future, there will be a version of the system for any
and all BBS software. I would love to expand it to include Genesis,
WildCat, and RBBS to name a few, but this will take some considerable
work which may require a leave of absence for the Bus System so that I
can have the programming time necessary to develop the code to allow
configuration of the program around any BBS system. Adaptation of the
code for version 14 PCBoard is already under way, and I hope to include
the various boards which have already upgraded to the Beta version of
14. Converting back and forth between the various message base formats
will be a challenge indeed.
Next time you are on a system using EzNet, register for private mail,
start a new topic thread that you feel is of importance, or drop a
friendly hello to someone that you know frequents one of the other
systems. EzNet was designed to enhance the telecommunications community
and bring us all together for the common good of sharing ideas and
opinions. I even like folks that disagree with me about my opinions. It
gives me something to argue about. Drop your public announcements in
the mail box, post that for sale ad, that want ad, or that cry for
desperately needed help. Use EzNet, it will make life easier for getting
out public messages faster. If you don't know where to get in touch
with someone on one of the other systems, drop a note in EzNet. Chances
are they use one of the five systems supporting the net, and will catch
up with you sooner.
-----------------------------------------------------------------------
The Sex Life of Dead Guppies and It's Relationship to
Telecommunications.
By Cosysop One
Channel 8250
The last reasonably full meeting of the infamous BTN writers
occurred at the home of our editor-in-chief, Mark Maisel. About a dozen
of us showed up and we managed to get a lot of writer-type business
accomplished: we consumed great quantities of beer, we BSed about
everything, we even invited one of the writers to dance on the coffee
table. I might also mention that even though some of the BSing was
political, Ed and I managed to restrain ourselves and not stand in the
chairs screaming at each other; the other writers were disappointed.
Mark prefaced the meeting by saying that he would be handing out
assignments to various authors for articles for the BTN but declined to
discuss it further at the moment. Later in the meeting I discovered
that I had ran out of cigarettes and went out to the truck for another
pack. Upon re-entering the room Mark gleefully informed me that they
had voted while I was outside and that the article I was to write was:
The Sex Life of Dead Guppies And It's Effects on Telecommunications. A
survey of the room at this time netted about 11 gleefully, smirking
faces, the one abstention was mine. Somewhat befuzzled (read potted) I
sat down and pondered the situation; both the pondering and the
situation seemed to be a hopeless cause.
When we left Mark's house that night there was enough aluminum in
the vicinity of the garbage cans to have built a Cadillac (would you
believe a Subaru?); Mark either has a very understanding wife or he
cleans up well before she gets home. I wonder how he explained the
broken furniture?
The next day gifted me with a nearly terminal hangover so I
temporarily shelved the topic. The day after, I researched the topic
somewhat morosely without success, (even IQUEST on COMPUSERVE couldn't
offer any help) so I tabled the article for it to mature (read
fossilize) while keeping my eyes open for any material that might relate
to it. A month passed without a glimmer of hope. I became desperate.
In my brief forays into the telecommunications world I'd noticed
that Mark, our beloved editor, had been noticeably absent since the
meeting so I asked another writer about it. I was told that one of
Mark's two guppies had died and that Mark was so down in the dumps he
hardly turned his system on nowadays. This set me to thinking ...
In the somewhat distant past I had taken a Philosophy course
(Philosophy, the study of that great Irishman, Phil O'Sophy) in Symbolic
Logic. The course boiled down to taking a set of arguments and
developing a conclusion from them. I developed a set of arguments and
worked on them till I came to a conclusion:
1: Mark was enamored of his two guppies.
2: Anyone who has had guppies knows that they do only two things:
swim and have sex (otherwise why would they be so prolific?).
3: One of Mark's guppies died so the other refused to have sex with
it.
4: This upset Mark so much that he temporarily lost interest not
only in his computer but in telecommunications.
Conclusion: For some individuals (such as Mark) there is a
correlation between the sex lives of their guppies and their
telecommunications activities. Mark has since replaced the dead guppy
with a live one and has rejoined the telecommunications community.
While in the conclusion category I would like to mention a few
others I surmised from the last BTN meeting...
38 cents is not enough money to get a writer to dance on the
tabletop.
Never... and I mean never, leave the room when you are about to be
assigned an article. Especially if the room is filled with inebriated
writers (and editors).
And last but not least:
Don't ever get drunk at a friends house an pour your warm beer into
his guppy tank. I did and look what it got me.
-----------------------------------------------------------------------
File: BASTOC01.TXT
Creator: COPYRIGHT 1988 Blake Miller
ALL RIGHTS RESERVED
Version 1.00 November 1988
Purpose: Article explaining some C string handling routines.
This is the first article in a tutorial series of unknown,
unpredictable length.
DISCLAIMER
----------
The suggestions and source code provided in this series of articles
is not guaranteed to do a darn thing or be of any practical utility at all!
You might want to read these articles while you are in a good mood,
especially if you are a BASIC programmer. Moreover, I have tried
this code out and have found it to work on the system I use, but remember
that not all C compilers are alike. The code is written to work with
QuickC from Microsoft. You might have to make some slight
adjustments to the names of some functions. Without further do-while
let us begin!
I apologize for the lighthearted attitude taken here,
but I would not be doing this if I wasn't having fun. After all,
there is plenty of time to get serious, once I am being paid...
And for those of you who love technical writing, don't bitch at me for
changing person in this article. One must always realize that I am
writing this for all of us so that we can learn something from it.
One more thing. I do not claim that these routines use the fastest,
gee whiz, algorithms around. My reasoning in optimization goes something
like this. Writing in C instead of BASIC is optimization. Writing in
Assembly Language instead of in C is insane! But sometimes, a little
careful thought will speed up even your C code, so some consideration
will be made.
SERIES INTRODUCTION
-------------------
There are those out there in La La Land who would argue that
the string handling routines in BASIC are more powerful than
those available in C. Well, this is partially true, since there
are only a few routines available in C. The ones C doesn't provide
you must write yourself!
It will be the purpose of this series of articles to
explain how you write string handling routines in C.
DEFINITIONS IN C
-------------------
The first thing to do is to define some constants that will be
used throughout these functions. The use of the #define command equates
a value to a symbol within the file in which it is included. Generally,
these definitions are known throughout the entire source file in which they
are included, but anything you define you can undefine. Here, we
will leave the definitions defined throughout the entire file, so they
will be placed near the beginning of the source code. These are similar
in utility to the CONST statement in the QuickBASIC language.
#define TRUE 1
#define FALSE 0
#define NUL 0
#define EOS 0
STRINGS IN C: A Definition
--------------------------
By definition, a C string is a sequence of bytes terminated by a
byte with the value zero (0). From Kernighan and Ritchie we learn that
"a string is an array whose elements are single characters. The compiler
automatically places the null character \0 at the end of each such string
so programs can conveniently find the end. This representation means
that there is no real limit to how long a string can be, but programs have
to scan one completely to determine its length."
GOALS
-----
Several useful string utilities can be written to deal with different
operations upon strings. Some of these call the built in C string handling
functions in order to perform their work. Others are independent of
the built in C functions. By building small functions that do only
a simple string operation, debugging is facilitated. This also makes it
easy to write other more powerful functions by merely combining
the simpler string functions.
When working with strings, there are several things we might want to
do to them. Text editing functions come to mind. For example, we might
want to insert, overwrite, or delete the character at the current
'cursor' position. Other possibilities are to delete to beginning,
the end, or the entire string.
A list of C string handling routines follows:
int sedit_creplce(int, int, char *, int); /* replace character */
int sedit_cinsert(int, char *, int, int); /* insert character */
int sedit_cdelete(int, char *, int); /* delete character */
int sedit_cowrite(int, char *, int, int); /* overwrite character */
int sedit_cdeleos(int, char *, int); /* delete end of string */
int sedit_cdelbos(int, char *, int); /* delete beginning of string */
int sedit_cltrim(int, char *, int, int); /* left trim string */
int sedit_crtrim(int, char *, int); /* right trim string */
int sedit_sltrim(int, char *); /* space left trim string */
int sedit_srtrim(int, char *); /* space right trim string */
void sedit_stoupper(char *); /* convert to upper case */
void sedit_stolower(char *); /* convert to lower case */
DECLARING STRING VARIABLES
--------------------------
Well, you might now be asking yourself what is the difference
between a BASIC string and a C string. A C string is a sequential set
of bytes terminated by a 'zero' valued byte. We usually refer to this
as the NULL byte, or NUL, as it is defined above, or as '\0' as it
is referenced as a 'character' within a C program.
When declaring a BASIC string, you do something like:
NAME$
and Voila! There you have a string variable capable of holding
something like 32K of characters, which is referenced by NAME$. In C,
on the other hand, you must declare all variables before their use in
a program. A C string variable is an array of bytes with a defined size.
If you wanted the equivalent of NAME$ as a C string, you
would declare the variable as a character array with a
specified length, such as:
char name[8];
which would allow a 'name' string to hold 7 characters plus the
trailing '\0' which is required for C to locate the end of string.
Okay. So now I would think you know that a C string is an array
of characters ending with a zero byte. It is important to remember
this zero byte is required when writing programs. For example, if
you want last_name to hold 16 letters, then you must declare it with 17
bytes, so that there is room to hold the trailing zero byte:
char last_name[17];
To reference a string variable in C, you merely use the name,
just like you would in a BASIC program! For example, to
put a capital 'L' in the first position of last_name you can use the
array form of referencing the position:
last_name[0] = 'L';
Notice that C arrays begin with a zero as the first position? Just
think of ALL C arrays as BASIC arrays with an OPTION BASE of 0!
So, the last position of last_name is position 16! And there had
better be a zero byte somewhere between the first byte and
the last one or else most C string routines will go zipping through
memory until they find the first zero byte. Many strings operate this
way by default. No small wonder, since C strings are defined to end
in a zero byte.
Now, the name of a C array, including a char array, actually translates
to the address of the array. So the variable last_name actually represents
the address at which the variable resides. That is, it is the address
of the first byte in the character array last_name.
OUR FIRST EXAMPLE
-----------------
Right.... Well, let us now look at an example. For our first
example, we will try to convert a string into all upper case characters.
The pseudocode, which will be in Sort-Of-English, is:
While not at end of string
If character is lower case
Upper Case It
Else
Do nothing
Increment string pointer
End
There are two ways to do this. One of them uses array referencing,
and is perhaps the easiest one to understand at first. The other method
uses pointers, and is faster, but is more confusing to the novice.
I will show the array method, and the ambitious amongst you can write a
pointer routine to be checked against my answer for next time.
Okay, so we need to get the string to the routine in the first place!
Easy enough, we pass the address! So the function is declared as:
void sedit_stoupper(char s[]);
Please note that I have a preponderance for adding a LOT of comments.
The more the merrier! That is, the more comments I add in the first place,
the merrier I am when I have to read the code five months later and
figure out what I did!
So the function is defined as below:
/* -- String To Uppercase --------------------**