517 lines
29 KiB
Plaintext
517 lines
29 KiB
Plaintext
WWIVNEWS Volume 1, Issue 1
|
||
January 1991
|
||
|
||
|
||
Table of Contents
|
||
~~~~~~~~~~~~~~~~~
|
||
The Official History of WWIV.................................Random 1@1
|
||
The Amazing 4.12 Disappearing G-Files...............East Bay Ray 1@9964
|
||
Multi-line WWIV: Myth or Reality?...................East Bay Ray 1@9964
|
||
Submitting to WWIVNEWS...................................WWIVNEWS Staff
|
||
The DGROUP Saga......................................Lord Elric 1@18251
|
||
The Pending File.........................................WWIVNEWS Staff
|
||
The Editor's Corner.................................East Bay Ray 1@9964
|
||
=======================================================================
|
||
|
||
|
||
The Official History of WWIV
|
||
by Wayne Bell
|
||
Random 1@1
|
||
|
||
WWIV started around December 1984, when I first put up a BBS. It
|
||
was run on an IBM-PC with a 10 meg hard disk and a Hayes 1200. I was
|
||
running WWIV v1.0, which was in interpreted BASIC. It crawled along
|
||
quite slowly, and did not have a whole lot of features.
|
||
About the only other BBSs I was competing with at the time were
|
||
run on Apple II's, also running in interpreted BASIC. Of course, there
|
||
were RBBSs and the like, but I do not recall ever having called one.
|
||
Soon the 64k limitation of IBM interpreted BASIC became apparent. I did
|
||
some pretty strange stuff with memory allocation and string storage,
|
||
but I had pretty much reached the cutoff point. When you try typing in
|
||
30 lines of a message and the result is an "out of memory" error, you
|
||
know it is time to go on to something better.
|
||
The better thing was Turbo Pascal 2.0. Turbo 2.0 did not have ANY
|
||
support directories (all file I/O was within your current directory
|
||
only). I also had quite some trouble getting comm routines working.
|
||
With the release of Turbo 3.0, I put up WWIV v2.0. Soon after that I
|
||
got REAL interrupt-driven comm routines, and things started moving
|
||
along.
|
||
I had to go off to UCLA, and was forced to take the BBS down.
|
||
Around December 1985 on Christmas vacation, I decided to put the BBS
|
||
back up for some reason. I did some major revamping at some time around
|
||
then, and called it WWIV v3.0. Still in Turbo Pascal 3.0, though.
|
||
Around this time (December), I got around to putting in a file section.
|
||
It took quite a bit of work getting xmodem working, and I had to go
|
||
back and re-format my data files to allow for file descriptions. Since
|
||
I had never actually been on any other IBM-type BBS, I had no clue as
|
||
to how the file section should work, so things turned out pretty
|
||
randomly.
|
||
On January 1, 1986 I finally released WWIV v3.0. It ended up
|
||
going through quite a few revisions, especially in the first week or
|
||
two after being released. And, to make things even more fun, I had to
|
||
resume classes at UCLA, so I ended up pretty much writing WWIV without
|
||
running a BBS. As you may guess, this caused a few unfortunate bugs to
|
||
slip by me, but that's life.
|
||
Sometime around June 1986, I had decided to put in ANSI color and
|
||
call it WWIV v3.2. This involved re-formatting the user list (to store
|
||
the user's color selections), and a few other little fun things, so I
|
||
decided to put up a BBS again. This was only for a week because I had
|
||
to move back up to UCLA after that time for the summer session. You
|
||
might think that not many people would end up calling a BBS that is
|
||
pretty much stated as only being up for a week, but it managed to get
|
||
some pretty good activity. To make this week even more fun, for about
|
||
half of it I was not there. I had a friend of mine, Stephen Davis, call
|
||
up and remotely take care of this experimental BBS. It even managed to
|
||
make it without crashing.
|
||
After releasing that, it turned out that I had a pretty bad bug
|
||
in the Y-Modem routine. The BBS would read in a block of data, and THEN
|
||
seek to the right place in the file instead of FIRST seeking then
|
||
reading. So I came out with 3.20a rather quickly. Around January 1987 I
|
||
put up the BBS again, running 3.21d.
|
||
Then around June 1987 I started writing WWIV v4.0. Naturally,
|
||
since I had a summer job, things did not go so fast. Also, the fact
|
||
that I had never written anything in my life in C before did not help.
|
||
I eventually got the hang of things. Finally, on Dec 1, 1987, I put up
|
||
4.0 as my BBS for testing in real life. Among my big promises of how
|
||
great it would be, I said it would support networking among systems. I
|
||
thought this sounded like a good idea, only I had no clue as to how I
|
||
would go about implementing it at the time. So I relegated that to
|
||
"don't hold your breath" status, secretly thinking I might never get
|
||
around to it.
|
||
Surprisingly, I did get around to it relatively soon. By that
|
||
time, everyone had already installed the BBS on their computers, so I
|
||
was stuck with the format I had dreamed up a long time ago when I had
|
||
no clue how it would work -- a number 1-65535 indicating which system
|
||
was which. I ended up trying to design a network around that, although
|
||
it was not quite the optimal solution (as if is such a thing). I was
|
||
bored one day and had been talking with someone about a network, so I
|
||
decided to start writing a program to send files between computers.
|
||
There was no planning at all, I just pretty much sat down and typed it
|
||
in. That developed into the NETWORK.EXE program.
|
||
Of course, there was more to it than that. It was actually after
|
||
I had the NETWORK.EXE program mostly working that I started thinking
|
||
about how the systems would connect together. I originally started with
|
||
the idea of having it pretty much hierarchial, with a local-system list
|
||
for all systems to call directly any systems that were local. After
|
||
talking with Stephen Davis about this for a while, I decided to pretty
|
||
much have it grid-like, with an amorphous structure. That does not,
|
||
however, prevent some structure from being applied to it. Without any
|
||
software changes, it can be easily changed over to a straight
|
||
hierarchial structure. All I would have to do is set up the hierarchy,
|
||
change one file, and send out an update of that.
|
||
Well that pretty much brings me up to the present time. Future
|
||
expansion? Who knows. One thing that keeps appearing is a multi-line
|
||
WWIV. That just is not practical. WWIV depends upon many external
|
||
programs (chains, FSED, archiving programs) and you can NOT,
|
||
practically, have the BBS run external programs without running under a
|
||
multi-tasking operating system. To put it simply, PC-DOS was not
|
||
designed with multi-tasking in mind.
|
||
=======================================================================
|
||
|
||
|
||
The Amazing 4.12 Disappearing G-Files
|
||
by Jeff Garzik
|
||
East Bay Ray 1@9964
|
||
|
||
The release of WWIV v4.12 brought many new features, such as
|
||
Zmodem batch downloads, almost 100k of memory savings with TC++
|
||
overlays, an upload event, and much more. WWIV v4.12 also brought with
|
||
it a hideous bug. In v4.12 the G-Files section had disappeared, and a
|
||
new one could be not created. As you might have guessed, this created a
|
||
stir almost immediately on both Amber and WWIVnet. You see, Wayne made
|
||
a small typographical error in XINIT.C, where he told the BBS to look
|
||
for the G-File data in the GFILES directory This was a mistake, because
|
||
the GFILE.DAT file goes into DATA, not GFILES.
|
||
This problem is very easy to fix. When you first run your BBS,
|
||
copy GFILE.DAT from your DATA directory to your GFILES directory.
|
||
Whenever you edit it with //GFILEEDIT (or 'G' from WFC screen), copy it
|
||
over to the GFILES directory. If you have registered to get the source
|
||
code, you may apply this small mod to XINIT.C to remove the
|
||
disappearing G-File problem altogether. Search for this line in
|
||
XINIT.C:
|
||
|
||
sprintf(s,"%sGFILE.DAT",syscfg.gfilesdir);
|
||
|
||
and replace it with this:
|
||
|
||
sprintf(s,"%sGFILE.DAT",syscfg.datadir);
|
||
|
||
That will stop your G-Files from disappearing. If you still need
|
||
help with this problem, you can contact 1@9964 for assistance.
|
||
=======================================================================
|
||
|
||
|
||
Multi-line WWIV: Myth or Reality?
|
||
by Jeff Garzik
|
||
East Bay Ray 1@9964
|
||
|
||
Current technology has opened up new worlds in BBSing. One of
|
||
those is the capability for a single BBS to have more than one user on
|
||
the BBS concurrently. RBBS, PC-Board, TBBS, and many others already
|
||
have this capability, but WWIV does not.
|
||
There are many solutions to the problem of adding multinode
|
||
support. One of them is using a LAN (Local Area Network), where several
|
||
computers are available, one for each phone line. Another solution,
|
||
sometimes used in conjunction with a LAN, is the user of a commercial
|
||
multitasker such as Desqview, DoubleDOS, or MS Windows. These multi-
|
||
taskers allow the use of more than one program concurrently, at the
|
||
price of program speed. The final solution is for a BBS to multitask
|
||
using its own routines.
|
||
A BBS multitasking using its own routines is usually the most
|
||
efficient solution, because it causes the least program slowdown. This
|
||
also removes the author from dependence on another company's product.
|
||
Drawbacks of this include the author not having access to all the
|
||
resources a large commercial has.
|
||
The LAN method requires a lot of hardware (it involves a computer
|
||
for each node; 4 nodes = 4 PCs), but it is generally the accepted
|
||
method for large BBSs. LANs, however, are sometimes notoriously slow.
|
||
The commercial multitasker method is the general choice for the
|
||
hobbyist-sysop. It allows multiple nodes on a single computer by
|
||
running 2 or more programs at the same time. This does slow the
|
||
individual programs down, because a single processor is handling the
|
||
load for more than one program at a time. Processor slowdown is not
|
||
really a problem on fast machines, such as an 80386 at 33 Mhz.
|
||
That is a little about multiple node BBSs in general. Wayne Bell
|
||
summarily declared a few years ago (see the closing statements of "The
|
||
Official History of WWIV") that WWIV is not going to be a multinode BBS
|
||
system. He has, in my opinion, weakened in his position since then, but
|
||
he has not wavered visibly. I think there WILL be a multinode version
|
||
of WWIV, but it is still a long way off, and there is a possibility
|
||
that it will not be written by Wayne at all (the multinode portion). A
|
||
multiple node WWIV, for now at least, is a myth and not reality.
|
||
=======================================================================
|
||
|
||
|
||
Submitting to WWIVNEWS
|
||
by WWIVNEWS Staff
|
||
|
||
Submitting Tips/Letters to WWIVNEWS
|
||
-----------------------------------
|
||
To submit a letter to the editor (to be published in later
|
||
editions) or a tip, simply send e-mail to 1@9964. Tell me in the letter
|
||
that it is to be published in a later edition of WWIVNEWS. Letters
|
||
submitted immediately become the property of Jeff Garzik, and he
|
||
reserves the right to edit any tip or letter (letters will be edited
|
||
only for size limitations and clarity). Tips and letters will be no
|
||
longer than 1,000 bytes. The letter or tip must include express
|
||
permission to print your tip or letter. If not, it will not be
|
||
published. All unpublished or unacceptable submissions will be deleted,
|
||
possibly without notification of the author or submitter.
|
||
|
||
|
||
Submitting an Article to WWIVNEWS
|
||
---------------------------------
|
||
|
||
Listed below are the requirements for submissions (all this must
|
||
be included in a single letter addressed to user 1@9964).
|
||
|
||
1) The title of the e-mail you send to 1@9964 should be something to
|
||
the effect of "WWIVNEWS submission". It helps to know your letter has
|
||
something to do with WWIVNEWS, because that will really speed up
|
||
processing.
|
||
|
||
2) Article title of no more than 40 characters.
|
||
|
||
3) Real name, such as "Jeff Garzik". If this line is not included, or
|
||
you use an alias, then the submission will be rejected.
|
||
|
||
4) Your preferred alias, such as "Filo", "East Bay Ray", etc.
|
||
|
||
5) Your main WWIVnet or WWIVlink node address.
|
||
|
||
6) Double-space and then include a one or two line summary of your sub-
|
||
mission. An example might be:
|
||
|
||
This article is about the problem of DGROUP, a description
|
||
of what it is, and recommendations on how to solve this problem.
|
||
|
||
7) Double-space again. You will now enter your article. I would suggest
|
||
that you limit your article to between 3,000 and 5,000 bytes. This
|
||
should be more than enough for a decent sized article. If space
|
||
requirements become more constraining in the future, the maximum size
|
||
(5,000 bytes) may be lowered.
|
||
|
||
NOTE: All submissions immediately become the property of Jeff Garzik,
|
||
and he reserves the right to print and edit the submissions as he sees
|
||
fit. If substantial changes need to be made, WWIVNEWS will probably
|
||
contact you at the WWIVnet address supplied. All WWIVNEWS issues are
|
||
kept for permanent storage, and all other non-published submissions
|
||
will be subsequently deleted.
|
||
=======================================================================
|
||
|
||
|
||
The DGROUP Saga
|
||
by Wayne McDaniel
|
||
Lord Elric 1@18251
|
||
|
||
One of the most often asked questions by WWIV modders is "I get
|
||
this DGROUP error. What can I do?" This article should explain what the
|
||
error is, what causes it, and how to prevent it.
|
||
First, some background information is needed. The DGROUP error is
|
||
a direct result of the architecture of the 8088 chip. The 8088 chip has
|
||
a 16 bit word length. Using 16 bits, only 64K of memory is addressable.
|
||
So, how can you have over 64K in your computer? The chip uses 2 16-bit
|
||
variables (known as "words") to store the address.
|
||
The two words are called the segment and the offset. Each segment
|
||
contains 64K. Segments start on even 16 byte boundaries. So, the first
|
||
segment starts at memory location 00h, the next at 10h, the next at
|
||
20h, and so on. The offset is then added to the segment to generate the
|
||
exact address.
|
||
So, the exact formula for a memory address is (segment * 16) +
|
||
offset. In hex, conveniently, this involves shifting the segment one
|
||
position to the left. Here is a sample address in hex and how they
|
||
would go together.
|
||
|
||
1111:2222 = 11110 <- shift the segment left, fill in a zero
|
||
+ 2222 <- add the offset
|
||
--------
|
||
13332 <- final memory address
|
||
|
||
Anyway, what has all this got to do with DGROUP errors? Well, let
|
||
me explain. DGROUP is the name Turbo C gives for a particular group of
|
||
segments. To be more specific, the _BSS and the _DATA segments are both
|
||
lumped into DGROUP. Maybe this map will show you a bit more...
|
||
|
||
Map of a C program, Large memory model
|
||
|
||
Low CS ->---------------------------------------
|
||
: Code from one file : Each chunk of code
|
||
: --------- : is 1 segment, so
|
||
: code from another file : you can have
|
||
: -------- : multiple chunks.
|
||
: code from another file :
|
||
DS ->---------------------------------------
|
||
: _DATA : _DATA and _BSS
|
||
: initialized data : are collectively
|
||
:-------------------------------------: known as DGROUP.
|
||
: _BSS : 64K limit for
|
||
: uninitialized data : both combined.
|
||
SS ->---------------------------------------
|
||
: free space : The stack can be
|
||
: : up to 64K.
|
||
Current SP->:-------------------------------------:
|
||
: stack (grows high to low) :
|
||
Start SP->---------------------------------------
|
||
: : Heap is all the
|
||
: heap (grows low to high) : remaining memory
|
||
: : all the way up to
|
||
: : the 640K boundary.
|
||
---------------------------------------
|
||
High
|
||
Address...
|
||
|
||
As you can see, the DGROUP segment consists of the static data,
|
||
both the initialized (_DATA segment) and the uninitialized (_BSS)
|
||
segment. Since the _DATA segment and the _BSS segment both have to fit
|
||
in the DGROUP segment, this limits you to 64K total. Getting the DGROUP
|
||
error simply means you have too much data in the DGROUP segment. First
|
||
lets take a look at what kind of data this is, so you know what to pull
|
||
out. The _DATA segment consists of global variables which are
|
||
pre-initialized. This would be something like:
|
||
|
||
int myvar ={25};
|
||
|
||
which would declare an integer myvar, and initialize it to 25 at the
|
||
start of the program. The major part of the _DATA section is not pre-
|
||
initialized variables, but text. Plain and simple text.
|
||
|
||
pl("Press a key to continue");
|
||
strcpy(s,"Some more text examples");
|
||
|
||
In these samples, anything between the quotes is going into the
|
||
_DATA portion of DGROUP. The other section of DGROUP is _BSS, or the
|
||
uninitialized data. And, thats what it is, any global or static data
|
||
which does not have a constant or pre-defined value has to fit into
|
||
_BSS. One way to check how much DGROUP data you have is to consult the
|
||
map file, which will tell you just exactly how much DGROUP data you
|
||
havem and where it comes from. If you are compiling with the integrated
|
||
environment, turn detailed maps on. If you are compiling with the
|
||
command line compiler, add "/s" to your call to tlink.
|
||
|
||
The first section of the map file looks like this...
|
||
|
||
|
||
Start Stop Length Name Class
|
||
|
||
00000H 00E2EH 00E2FH _TEXT CODE
|
||
00E2FH 03FDFH 031B1H BBS_TEXT CODE
|
||
|
||
. . .
|
||
|
||
3863BH 38670H 00036H WHEREXY_TEXT CODE
|
||
38680H 40CADH 0862EH _DATA DATA
|
||
40CAEH 40CB1H 00004H _EMUSEG DATA
|
||
40CB2H 40CB3H 00002H _CRTSEG DATA
|
||
40CB4H 40CBBH 00008H _CVTSEG DATA
|
||
40CBCH 40CD3H 00018H _SCNSEG DATA
|
||
40CD4H 485B7H 078E4H _BSS BSS
|
||
485B8H 485B8H 00000H _BSSEND STACK
|
||
485C0H 486A5H 000E6H _STACK STACK
|
||
|
||
The addresses here have the segment and offset already combined.
|
||
The two most important lines are near the bottom of this section, the
|
||
one for _DATA and the one for _BSSEND. Take the hex value for the start
|
||
of _BSSEND and subtract the starting value of _DATA to find out how
|
||
much DGROUP data you have. So, I am using 485B8H-38680H = FF38. Since
|
||
FFFF is the maximum allowed, I have FFFF-FF38, or C7, or 199 bytes
|
||
left. In other words, not much.
|
||
|
||
The next part of the map breaks down the segments a bit more, so
|
||
you can see just exactly what makes up _DATA and _DGROUP.
|
||
|
||
Detailed map of segments
|
||
Address Size Class Segment Group Module name ????
|
||
0000:0367 0000 C=CODE S=_TEXT G=(none) M=FLAGS87 ACBP=28
|
||
0000:0367 0260 C=CODE S=_TEXT G=(none) M=FPEXCEP ACBP=28
|
||
|
||
3868:0000 0093 C=DATA S=_DATA G=DGROUP M=C0L ACBP=68
|
||
3868:0094 07F5 C=DATA S=_DATA G=DGROUP M=bbs.c ACBP=48
|
||
3868:088A 1100 C=DATA S=_DATA G=DGROUP M=bbsutl.c ACBP=48
|
||
|
||
3868:8654 0000 C=BSS S=_BSS G=DGROUP M=C0L ACBP=48
|
||
3868:8654 7331 C=BSS S=_BSS G=DGROUP M=bbs.c ACBP=48
|
||
3868:F986 00CD C=BSS S=_BSS G=DGROUP M=bbsutl.c ACBP=48
|
||
|
||
So, you can see that the initialized data and text for BBSUTL.C
|
||
takes up 1100H bytes, or 4352 bytes in decimal, or even better, 6% of
|
||
the space in DGROUP. Add them all up, and you wind up with text
|
||
accounting for almost 50% of the DGROUP space.
|
||
|
||
Now you know what the DGROUP error is and why it occurs. What can
|
||
you do about it? Well, the obvious thing to do is to cut down on text
|
||
in the source code. Instead of "Oooh baby, tickle my keyboard" use the
|
||
smaller "pause". That may seem insignifigant, but that is 24 bytes of
|
||
DGROUP space you just saved. Find little used text, comment it out,
|
||
copy it to a text file, and then use printfile to pull it off the disk.
|
||
This is only recommended if the text is fairly large. For example,
|
||
change:
|
||
|
||
pl("Please Re-enter your user number when prompted");
|
||
pl("and write down your password");
|
||
pl("Waste some more DGROUP");
|
||
|
||
to
|
||
|
||
/*
|
||
pl("Please Re-enter your user number when prompted");
|
||
pl("and write down your password");
|
||
pl("Waste some more DGROUP");
|
||
*/
|
||
printfile("newuser1");
|
||
|
||
Now all the text is stored in the gfiles directory under
|
||
NEWUSER1.MSG, and not in DGROUP.
|
||
One mod to look for is the External Strings Manager by Caramon
|
||
Majere. He has written a program to read strings in from a file and an
|
||
editor to maintain the file. One problem, however, is speed. It will
|
||
slow the BBS down (the slowdown is usually only noticeable on slow
|
||
computers or hard drives), so I suggest only using the infrequently
|
||
accessed lines, and I would also suggest a disk cache. Up to 500 lines
|
||
of string data may be taken out of your code using his program, and if
|
||
you figure even 100 strings with an average length of 40 bytes that is
|
||
4K of extra space. If you take out 500 strings with an average length
|
||
of 4K, you just saved 20K. A good method for doing that is to comment
|
||
out the line, but leave it in the source, so later when you are reading
|
||
your source code you can still search for the string to find that
|
||
section of code. Such as:
|
||
|
||
/* pl("Please enter name or number"); */ /* now string 27 */
|
||
get_string(27);
|
||
|
||
I hope this file has at least helped you to understand what the
|
||
DGROUP error is, and has given you some hints. Mostly, remove the
|
||
string text. String text accounts for 40%-50% of your DGROUP data
|
||
usually. The other option is to remove some of the static and global
|
||
variables. However, since you need almost every one of them, it would
|
||
be hard to do. If you have any further questions, I can be reached at
|
||
812-877-3488, The Kingdom of Melnibone.
|
||
=======================================================================
|
||
|
||
|
||
The Pending File
|
||
(WWIV & WWIVnet Tips, Tricks, and News)
|
||
by WWIVNEWS Staff
|
||
|
||
If you find a message in one of your extended net logs (NETDAT0.LOG -
|
||
NETDAT2.LOG in your GFILES directory) informing you that WWIVnet does
|
||
not know what "8/0" is, and that you don't have a "de2" program, don't
|
||
worry about it. It is a test of an upcoming WWIVnet feature, being
|
||
conducted by Black Dragon 1@2380 and Random 1@1. It will not affect
|
||
your system in any way.
|
||
|
||
For those of you who have Richard Ruffner's program SUBEDIT, do not use
|
||
it. It is incompatible with the new multiple-BBSLIST format introduced
|
||
in NET20. Both Filo 1@5252 and East Bay Ray 1@9964 have released new
|
||
sub editors, and either of these should be used in place of the
|
||
original SUBEDIT.
|
||
|
||
For those who use NETEDIT, version 1.25 is out. It is now separately
|
||
compiled for faster execution if you have an 80287 or 80387 math
|
||
co-processor. The filename is usually NETEDIT.ZIP, and it can be found
|
||
on Amber and Black Dragon Enterprises (the author's BBS).
|
||
|
||
As many are aware, a program called NetZip II was released into
|
||
WWIVnet, plagued with dozens of problems and bugs. It has now been
|
||
fixed and has been working for several weeks. The filename is
|
||
NETZIP26.ZIP.
|
||
|
||
For those who are having problems with DSZ data overruns and are using
|
||
US Robotics' HSTs, try putting "ha slow" on the command line.
|
||
|
||
If anyone has ever seen the message "corrupted, not processing", then
|
||
they know that particular feeling of frustration. After Wayne Bell
|
||
(almost) lost a 2.3 meg packet, he decided to implement some sort of
|
||
recovery for corrupted packets. LNET and NETWORK1 will now split
|
||
corrupted packets as to isolate the corrupted part, and process the
|
||
rest.
|
||
|
||
Also, as a result of continued debate, Wayne declared in a piece of
|
||
global mail that all illegal activities, such as pirating, phreaking,
|
||
hacking, and other like undertakings which are carried over WWIVnet are
|
||
outlawed and forbidden. Further policy and discretion is left to the
|
||
individual Group and Area Coordinators.
|
||
=======================================================================
|
||
|
||
|
||
The Editor's Corner
|
||
by Jeff Garzik
|
||
East Bay Ray 1@9964
|
||
|
||
This section is for any notes, notices, or changes in policy
|
||
regarding any aspect of WWIVNEWS. It may also contain some sort of
|
||
editorial, or information regarding articles in upcoming issues. Since
|
||
this is the first issue of what I hope to be a tradition in WWIVnet,
|
||
there isn't really any news (because the whole thing is new(s)!).
|
||
I also want to clear the air about a couple things. First,
|
||
reviews ARE accepted, but they must be objective AND they must cover a
|
||
major utility, such as NETEDIT. I also prefer that the author review
|
||
the product, but this is not set in stone, per say. As many people
|
||
know, I am fairly well known as both a programmer (some say of ill
|
||
repute) and as a modder. I will do the utmost to keep advertisements,
|
||
and any other related material (excepting announcements which I think
|
||
benefit the network as a whole) away from WWIVNEWS. I will also keep
|
||
all "fights" between sysops or factions away from this magazine unless
|
||
it affects a majority of the net. An example of an exception to this
|
||
rule might be the WWIVlink crisis. If people wish to call my bulletin
|
||
board, my number is listed in the BBSLIST (group 5) along with my
|
||
maximum baud rate. I also want to point out that I try to keep my name
|
||
out of it as much as possible. If there is a suitable place, I will
|
||
exchange "East Bay Ray" for "WWIVNEWS" or "WWIVNEWS Staff".
|
||
Some people might be scared away but such things as the tech-
|
||
nicality of having to submit an article. I am very lenient, and as long
|
||
as the article comes with the basic information I won't, for example,
|
||
remove yours outright simply because it is missing a double space in
|
||
the recommended place. Far from from it! I want to encourage, not
|
||
discourage, submissions. Bug reports (as long as they are supported
|
||
with evidence, and are reproducible) are accepted and welcomed also.
|
||
Finally, a word about the accuracy of this document. It is not
|
||
spell-checked at all, only proofread by myself. I am human, and I do
|
||
make errors. In the future, this will hopefully change, but until then,
|
||
I will stick with the human spell checker, the Turbo Pascal Editor
|
||
Toolbox text editor, and RightWriter grammar checker.
|
||
=======================================================================
|
||
|
||
|
||
The End
|
||
|
||
|