573 lines
31 KiB
Plaintext
573 lines
31 KiB
Plaintext
WWIVNEWS Volume 1, Issue 2
|
||
February 1991
|
||
|
||
|
||
Table of Contents
|
||
~~~~~~~~~~~~~~~~~
|
||
WWIV v4.20: A New Twist In Modem Handling....................Random 1@1
|
||
WWIV and Zygote: The Dynamic Duo......................Tony Godfrey 1@18
|
||
NetZip II Revision 6................................East Bay Ray 1@9964
|
||
Thoughts on a Multi-Line WWIV..........................John Wash 1@8403
|
||
Bug in the Main Menu Prompt....................The Dunghill Fowl 1@2371
|
||
The Pending File.........................................WWIVNEWS Staff
|
||
Letters to the Editor...........................................Various
|
||
Official Jargon..............................................Random 1@1
|
||
The Editor's Corner.................................East Bay Ray 1@9964
|
||
Acknowledgements.........................................WWIVNEWS Staff
|
||
=======================================================================
|
||
|
||
|
||
WWIV v4.20: A New Twist In Modem Handling
|
||
by Random 1@1
|
||
(Originally captured from Amber: Dec 1, 1990)
|
||
|
||
The text at the end of this article is my first cut at a modem
|
||
configuration file. You first notice that it is in ASCII text, for ease
|
||
of editing by users, and it is much easier to expand upon later. In the
|
||
final release, there will be a configuration file such as the one
|
||
below. configurations for will be: USR HST/V.32/DS, Hayes compat. 300,
|
||
Hayes compatible 1200, Hayes compatible 2400, plus slightly modified
|
||
versions of the Hayes compatible ones for modems that have timing
|
||
problems.
|
||
Here is a description of the file. Comments are lines that begin
|
||
with a #. Blank lines are ignored. The first four characters on a line
|
||
(followed by a colon) describe what type the line is. The first section
|
||
has a couple of strings that are sent to the modem (INIT, SETU, ANSR,
|
||
PICK, HANG, DIAL). The SETU string will be sent to the modem when the
|
||
BBS first starts up, setting up various modem parameters. The INIT
|
||
string will be sent to the modem after each user loggs off, the same as
|
||
the current init string. The other strings should be self-explanatory.
|
||
The next part of the file deals with result codes and several
|
||
switches that can be set. It tells what state the modem is in based
|
||
upon the result codes received. These are listed at the top of the file
|
||
for your reference. The first few "state switches" tell what state the
|
||
modem is in (NORM, RING, RINGING, ERR, DIS, CON). The next few set
|
||
various other options, modem speed, com speed, asymmetrical baud rates
|
||
(such as for the USR HST protocol), error correcting protocols (MNP2-4,
|
||
LAPM) and data compression protocols (MNP5, V.42bis). Also, flow
|
||
control is thrown in there, although most likely that will not change
|
||
based on result codes. The "DEFL" line defines the default modem
|
||
switches, which are set before the modem init string is sent. It mostly
|
||
just tells flow control and the com port speed to use.
|
||
The rest of the file defines the result codes or partial result
|
||
codes. A result code from the modem can be split up into numerious
|
||
partial result codes. For example, from the HST, you can get a result
|
||
code such as "CONNECT 2400" as well as "CONNECT 9600/ARQ/V32/LAPM/
|
||
V42BIS". The "SEPR" definition defines which characters to use. It
|
||
separates the full result code into partial result codes. It can be
|
||
nothing, in which case there aren't really any "partial result codes".
|
||
Another possibility is that the characters could not be present in the
|
||
string, in which case the full result code is a "partial result code".
|
||
Here is a working example. Suppose the modem is sitting there at
|
||
WFC, and it gets a string from the modem ("RING"). It finds no "/" in
|
||
it (the SEPR character), so searches the result code listing for
|
||
"RING". It finds it, and finds the state switch "RING", meaning the
|
||
phone is ringing. It then sends the ANSR string, answering the phone.
|
||
At this point, say it gets "CONNECT 2400". It finds no "/", so
|
||
searches for that string, and finds it. It sets the description to
|
||
"2400", sets the modem speed to 2400, the com speed to 2400, and
|
||
notices that it is now connected. At this point, it continues with the
|
||
logon.
|
||
Suppose that it got "CONNECT 9600/ARQ/V32/LAPM/V42BIS". It
|
||
notices a couple slashes, so interprets all the parital result codes
|
||
("CONNECT 9600", "ARQ", "V32", "LAPM", and "V42BIS") one at a time.
|
||
First it finds the CONNECT 9600, so it sets the description to "9600",
|
||
sets the two baud rates to 9600, and notices that it is connected. It
|
||
does not actually consider itself connected until it has processed all
|
||
the partial result codes from the full result code, so it continues.
|
||
Next is "ARQ", meaning we have an error correcting connection (EC=Y).
|
||
Also, the way the modem is configured for all ARQ connections, the com
|
||
port baud rate is locked at 38400. It will set the com speed to that.
|
||
Next comes "V32". This is a symmetrical protocol, so AS=N. Since AS=N
|
||
is the default (as defined at the top of the file), this is not really
|
||
necessary to put in, but puttting it in is clearer that way. Also, the
|
||
string '/V.32' is defined. This is in SINGLE QUOTES, so the "/V.32" is
|
||
added on to the description instead of overwriting it (as would be the
|
||
case if it were in double quotes). The desription is now "9600/V.32".
|
||
Next we get 'LAPM', which adds "/LAPM" on to the description, and sets
|
||
EC=Y again, which is not really necessary. Again, it is clearer that
|
||
way. Finally, "/V42BIS". Adds the string '/V.42bis', and sets DC=Y,
|
||
indicating data compression is in use.
|
||
It is now done with the full result code, so it recognizes that
|
||
it is connected (due to the CON), and continues with the logon. Now we
|
||
notice that the switches are set: MS=9600, CS=38400, EC=Y, DC=Y, AS=N,
|
||
FC=Y. This means:
|
||
The modem is talking at 9600 to the other modem, while we are
|
||
talking to the modem at 38400. Also, we are using flow control (FC=Y).
|
||
This is what we would know using the current setup for the result
|
||
codes. We also get additional information informing us that we are
|
||
using error correction, data compression, and that we have a
|
||
symmetrical baud rate (9600 in both directions). The description at
|
||
this point is "9600/V.32/LAPM/V.42bis".
|
||
In addition to being more free form and more easily extensible,
|
||
we get three additional pieces of information: whether error correction
|
||
is being used, whether data compression is being used, and if we have a
|
||
symmetrical baud rate setup. The symmetrical/asymmetrical flag can be
|
||
used in the BBS to determine if BiModem should be used or not (same
|
||
with the net software), and error correction can be used to determine
|
||
if protocols like YMODEM-G should be allowed.
|
||
So that is the way it will be implemented in INIT, instead of
|
||
entering the modem info and result code info as you do now, you'll get
|
||
a menu of known modem types, and be able to pick one. It will then
|
||
parse through the file and create a machine-readable format for the BBS
|
||
(and net software) to use.
|
||
|
||
#
|
||
# NORM normal state of modem
|
||
# RING phone is ringing
|
||
# RINGING remote phone is ringing
|
||
# ERR error encountered
|
||
# DIS disconnected (No connection)
|
||
# CON connection established
|
||
# MS= modem speed
|
||
# CS= com port speed
|
||
# AS= asymmetrical baud rates (Y/N)
|
||
# EC= error correcting (Y/N)
|
||
# DC= data compression (Y/N)
|
||
# FC= flow control (Y/N)
|
||
|
||
NAME: "USR Dual Standard"
|
||
|
||
# some strings sent to the modem
|
||
INIT: "ATB0H0M0{"
|
||
SETU: "ATC1E0F1H0M0Q0V1X6&A3&B2&C1&D2&H1&I0&K2&N0&R2&S0S0=0S2=1{"
|
||
ANSR: "ATA{"
|
||
PICK: "ATH1{"
|
||
HANG: "ATH0{"
|
||
DIAL: "ATB1DT"
|
||
|
||
# separator in result code for partial result codes
|
||
SEPR: "/"
|
||
|
||
# default settings of switches
|
||
DEFL: MS=38400 CS=38400 EC=N DC=N AS=N FC=Y
|
||
|
||
# list of partial (or full) result codes from modem. Descriptions in
|
||
# double quotes ("") overwrite the previous description, those in single
|
||
# quotes ('') append to the previous description.
|
||
#
|
||
# RESULT CODE DESCRIPTION SWITCHES
|
||
#
|
||
RESL: "OK" "Normal" NORM
|
||
RESL: "RING" "Ring" RING
|
||
RESL: "NO CARRIER" "No Carrier" DIS
|
||
RESL: "ERROR" "Error" ERR
|
||
RESL: "NO DIAL TONE" "No Dial Tone" DIS
|
||
RESL: "BUSY" "Busy" DIS
|
||
RESL: "NO ANSWER" "No Answer" DIS
|
||
RESL: "RINGING" "Ringing" RINGING
|
||
RESL: "VOICE" "Voice" DIS
|
||
|
||
RESL: "CONNECT" "300" MS=300 CS=300 CON
|
||
RESL: "CONNECT 1200" "1200" MS=1200 CS=1200 CON
|
||
RESL: "CONNECT 2400" "2400" MS=2400 CS=2400 CON
|
||
RESL: "CONNECT 4800" "4800" MS=4800 CS=4800 CON
|
||
RESL: "CONNECT 7200" "7200" MS=7200 CS=7200 CON
|
||
RESL: "CONNECT 9600" "9600" MS=9600 CS=9600 CON
|
||
RESL: "CONNECT 12000" "12000" MS=12000 CS=12000 CON
|
||
RESL: "CONNECT 14400" "14400" MS=14400 CS=14400 CON
|
||
|
||
RESL: "ARQ" EC=Y CS=38400
|
||
RESL: "HST" '/HST' AS=Y
|
||
RESL: "V32" '/V.32' AS=N
|
||
RESL: "MNP" '/MNP' EC=Y
|
||
RESL: "LAPM" '/LAPM' EC=Y
|
||
RESL: "MNP5" '/MNP5' DC=Y
|
||
RESL: "V42BIS" '/V.42bis' DC=Y
|
||
RESL: "NONE" EC=N
|
||
RESL: "SYNC"
|
||
=======================================================================
|
||
|
||
|
||
WWIV and Zygote: The Dynamic Duo
|
||
by Tony Godfrey 1@18
|
||
|
||
One of the nice things about a registered WWIV is that you can
|
||
modify the source code to your heart's content. Sysops modify their
|
||
boards to make WWIV easier to use for themselves and the users. Some
|
||
modifications spice up the board by adding more color, or more ANSI-
|
||
extensive routines. This can decrease the speed of WWIV by a fairly
|
||
large amount, and speed is one of WWIV's strong points.
|
||
Zygote Term is a terminal program on the PD/Shareware market. It
|
||
isn't quite as popular as Telix or Procomm, but it is gaining popu-
|
||
larity every day. Each new version of Zygote contains new features that
|
||
surpass other term programs many times over. The best thing about
|
||
Zygote is that it has special features accessible by a WWIV BBS. On any
|
||
other board, Zygote would act as any other terminal program would
|
||
(except with a few more features that cannot be found on other term
|
||
programs). When Zygote is used on a WWIV BBS that makes use of Zygote's
|
||
features, however, a whole new realm of BBSing is entered.
|
||
The Zygote/WWIV Multitask Chat is the first of these features to
|
||
be released. WWIV currently comes with two chat modes: standard, and
|
||
two-way. Zygote/WWIV Multitask Chat looks much like two-way chat,
|
||
except chatting takes place on one half of the screen. In the other
|
||
half, normal BBS functions can be performed. While the sysop and a user
|
||
are chatting, either the sysop or the user can switch between chat
|
||
window and BBS window. In the BBS window, functions such as reading
|
||
messages, listing files, writing messages, moving, sorting, removing
|
||
files, editing users, etc. can all be performed while the chat window
|
||
remains intact. This is especially useful if you want to discuss a
|
||
certain message or look for a certain file and chat about it, or to
|
||
have something else to do while the chatter rambles on. Version 1.0 of
|
||
this modification was released in October 1990, and version 1.1 is
|
||
scheduled to be released in late December 1990 or early January 1991.
|
||
A new feature still in the testing stages, but very close to
|
||
release, is the Zygote/WWIV Binary Screen Feature. This modification
|
||
gives WWIV a complete facelift. Any part of the BBS can be made into a
|
||
full-screen ANSI picture. With regular terminal programs, WWIV would
|
||
have to send an ANSI picture over the modem, and then send codes to
|
||
place prompts on the screen. With Zygote, WWIV simply tells it which
|
||
binary screen (an ANSI screen saved in binary format) to display, and
|
||
in less than 2 seconds, a full screen ansi is displayed on both ends,
|
||
ready for input. Positioning of the cursor still has to be done, which
|
||
WWIV then takes care of. Since binary screens are only 4000 bytes in
|
||
size, having several of these binary screens on disk would not consume
|
||
a large amount of disk space. If either the BBS or the Zygote user does
|
||
not have a matching screen, then WWIV will simply display the screen
|
||
normally (albeit much slower than the speed of binary screen display).
|
||
WWIV sysops will see this modification released in modules. Each
|
||
module will contain documentation on what part of the board to modify
|
||
as well as a standard WWIV binary screen. The first modules to be re-
|
||
leased will be logon and message bases. Binary screens can be custo-
|
||
mized, but at the same time the customizer must know where to position
|
||
the cursor and make the necessary changes. These features are just the
|
||
beginning in a series of featues to be released. Zygote continues to
|
||
grow, as does WWIV, and these features make them both 10 times as
|
||
powerful as any other term program or BBS.
|
||
|
||
Zygote Term by Miguel Sanchez a.k.a. My Nguyen
|
||
=======================================================================
|
||
|
||
|
||
NetZip II Revision 6
|
||
by East Bay Ray 1@9964
|
||
|
||
Many people who have seen how other networks, such as FidoNet,
|
||
use compression to make their net packets smaller. They have been doing
|
||
this for years with the help of SEA's ARC program and PKWare's PKZIP
|
||
program. WWIVnet now has the same opportunity. NetZip, written by East
|
||
Bay Ray, provides network compression for any node in WWIVnet or
|
||
WWIVlink.
|
||
This idea is not a new one to WWIVnet. There were two previous
|
||
tries by Alph 1@8403 and Benny Hill 1@7400. They both were stopped by a
|
||
strange bug that would produce a Divide Overflow on some computer
|
||
systems, but not on others. East Bay Ray was also previously stopped by
|
||
a conflict with Wayne's ZIP routines that resulted in lost mail. At
|
||
last, however, a version was found that worked.
|
||
Installation of NetZip is quite easy. An INSTALL batch file does
|
||
most of what minimal work there is (thoughtfully provided by Filo #1
|
||
@5252). All that is left, after running INSTALL, it to create
|
||
ZIPSYS.NET. This is a plain text file which contains a list of nodes
|
||
you wish to use NetZip with (they must also have NetZip installed, or
|
||
be using NET22). It is that simple.
|
||
How does NetZip work internally? NetZip first takes the un-
|
||
compressed Sxxxx.NET file and renames it to a P*.NET file (one higher
|
||
than the last existing P*.NET file in the current archive). Then it
|
||
adds this to Sxxxx.ZIP. The Sxxxx.ZIP is then renamed to Sxxxx.NET, and
|
||
CONTACT.NET is updated to reflect the adjusted sizes of each Sxxxx.NET
|
||
file that was compressed. If you wish to see the ratio of compression,
|
||
all you have to do is view the Sxxxx.NET with PKZIP or PKUNZIP. NetZip
|
||
is an excellent, which has finally been purged of the bugs present in
|
||
the previous versions, along with the stigma of Revision 3, which lost
|
||
mail. If you have a chance, download it and share it with your
|
||
neighbors. It will save you a lot of transmission time. Over long
|
||
distance lines, it will save money also.
|
||
=======================================================================
|
||
|
||
|
||
Thoughts on a Multi-Line WWIV
|
||
by John Wash 1@8403
|
||
with input from Richi Shinn 4@8404
|
||
|
||
Before I get started, please note that this article was written
|
||
in response to an article of like subject, written by Jeff Garzik
|
||
1@9964, that originally appeared in WWIVNEWS Vol. 1, Issue 1.
|
||
First, I wholly agree with Jeff on possible solutions: You can
|
||
either make the program itself single-tasking but multi-user, or you
|
||
can run it in a multi-tasking -- and optionally a multi-user -- envi-
|
||
ronment.
|
||
At this point, though, I begin to differ with Jeff. A LAN would
|
||
indeed be an expensive solution (as he said, "4 nodes = 4 PCs"), but it
|
||
would NOT be a slow one. The standard in PC networking today is
|
||
Novell's Netware, a distributed-processing system. In a LAN
|
||
implementation, you have a server system and client systems. The server
|
||
controls the shared resources of the LAN--storage, printers, modems,
|
||
etc.--and each client (or workstation) uses its own resources--a local
|
||
hard drive or a local printer, for example. A multi-line WWIV running
|
||
in a Novell Netware environment, and sharing data files with other
|
||
nodes by storing them on the server's drive, would not be noticeably
|
||
slower than individual PCs running individual BBSes--that's the entire
|
||
idea behind distributed processing, and part of the reason that
|
||
educated administrators choose Netware as a networking solution rather
|
||
than packages that run on the server and treat client systems as
|
||
dependents rather than autonomous entities.
|
||
If you MUST run PC-DOS, it is possible to have multiple WWIVs
|
||
running concurrently with, as Jeff said, a "commercial multitasker"
|
||
such as Windows 3.0 or Quarterdeck's DESQview. However, they're going
|
||
to be individual copies of WWIV, sharing perhaps only the FILES in the
|
||
transfer and G-File sections.
|
||
What needs to be done to WWIV is a total re-write. Wayne Bell
|
||
knows this. He hinted at it when he suggested that he wouldn't port
|
||
WWIV to UNIX. He stated that would re-write it for UNIX.
|
||
Internal multi-node capability would not be that difficult to
|
||
implement. If you have handlers processing I/O for all com ports as
|
||
well as the console, half of your battle is over. It remains, however,
|
||
that you have no facilities for file and record locking, an integral
|
||
part of almost any multi-user system.
|
||
So why go the extra step? Don't bother making WWIV multi-line.
|
||
Instead, make WWIV support file and record locking. You'd save oodles
|
||
of memory, because you wouldn't have to allocate a chunk to store a
|
||
.SUB file, a .DIR file, or anything like that. If you wanted a user's
|
||
record, open USER.LST, lock the record, read the record, unlock the
|
||
record, and close the file. If you wanted to read a message, or upload
|
||
a file, or anything that requires file I/O, you would do basically the
|
||
same thing. If you get file and record locking working properly, there
|
||
would not be any need to "make WWIV a multi-line BBS"-- you'd just need
|
||
a copy of MS-Windows 3.0, or Novell Netware, or PC-MOS, or
|
||
DESQview/386, a good machine and some patience in getting it set up.
|
||
This is my opinion on multi-line systems. Summing it all up,
|
||
making WWIV talk to several com ports at once is a waste of time. Worry
|
||
about file sharing and you'll be set. If anyone would like me to
|
||
discuss file and record locking in a future issue of WWIVNEWS, drop me
|
||
a note at 1@8403 and I'll see what I can do.
|
||
|
||
(About the author: John Wash is a professional UNIX zealot and a
|
||
full-time social irritant.)
|
||
=======================================================================
|
||
|
||
|
||
Bug in the Main Menu Prompt
|
||
by The Dunghill Fowl 1@2371
|
||
|
||
This problem only happens if you are on a board where you have
|
||
access to all 32 Subs (I don't know about boards with the 64 Sub Mod).
|
||
While at the main menu prompt, at sub #31, if you hit the plus key (+),
|
||
instead of going to sub #32 it will jump to sub #1. However, hitting
|
||
the minus key (-) at sub #1 will bring you to sub #32. For example:
|
||
|
||
T - 00:32:48
|
||
[31] [Fred's Fried Fish Sub]:+ <--- Hitting plus from sub #31
|
||
|
||
T - 00:32:26
|
||
[1] [General Messages]:- <--- Skipped sub #32, hitting minus key
|
||
|
||
T - 00:31:53
|
||
[32] [Underwater Basket Weaving]: <--- Now at the long lost sub #32
|
||
|
||
Ok, that's all there is to it, it isn't that big of a deal, but it's
|
||
there...
|
||
|
||
[This only occurs on the aforementioned sub numbers EXACTLY. I easily
|
||
spotted the problem in the code, and I notified Wayne about it. - Ed.]
|
||
=======================================================================
|
||
|
||
|
||
The Pending File
|
||
(Tips, Tricks, and News)
|
||
by WWIVNEWS Staff
|
||
|
||
The next WWIV release will be v4.20. It HAS NOT been released, nor will
|
||
it be released any time soon. Wayne has not set a release date.
|
||
Features will include batch uploads, BiModem support, a complete
|
||
rewrite of the modem handling routines, and several other smaller
|
||
features. For more information on the modem handling routines, see the
|
||
earlier article in this issue.
|
||
|
||
WWIVnet also has a new SUBS.LST coordinator. 1 @7100 now receives the
|
||
new information for subs and sends out regular SUBS.LST/SUBS.1 updates.
|
||
Do NOT send any e-mail to 1 @6860 regarding sub list changes.
|
||
|
||
Intel is offering a Sysop deal on their 9600EX high speed modem. It's a
|
||
V.22, V.32, V.42/42bis compatible, and will connect to standard v.32 /
|
||
v.42 modems at speeds up to 38,400 Baud. It WILL NOT connect to a USR
|
||
HST at any speed higher than 2400 Baud, so there is a downside. It's a
|
||
good deal if you can't afford a $699 USR DS or a $675 Microcom, but
|
||
"let the buyer beware." (Charles Boyer 1@9962)
|
||
|
||
NETEDIT v1.27 by Black Dragon #1 @2380 has just recently been released.
|
||
It fixes a potential bug in v1.26. v1.26 (which was not annouced in
|
||
WWIVNEWS) makes a couple improvements over v1.25, including handling of
|
||
NET22's partial updates, and a technical correction on one of the
|
||
menus. (Black Dragon 1@2380)
|
||
|
||
WWIVNEWS has some competition on WWIVlink. WWIVlink now distributes a
|
||
newsletter much like this one, called "The Link Post". These will also
|
||
be made available on my board as I get them.
|
||
|
||
My new program, NETPURGE, goes through the specified network pending
|
||
data file (defaults to DEAD.NET) and deletes all non-e-mail. It returns
|
||
all E-mail of types 1-0, 2-0, 7-0, and 8-10 to the originator with a
|
||
few extra lines in the header telling the originator what type of
|
||
E-mail he sent, to whom, and that it was undeliverable.
|
||
(Black Dragon 1@2380)
|
||
=======================================================================
|
||
|
||
|
||
Letters to the Editor
|
||
|
||
|
||
WWIVNEWS,
|
||
I noted with interest the appearance of WWIVNEWS.NET in my data
|
||
directory today. It's an interesting idea, and I hope it works out to
|
||
the benefit of WWIVnet sysops. However, I have a couple of suggestions
|
||
for distribution:
|
||
|
||
1. Announce its presence. I had no earthly idea that WWIVNEWS was
|
||
going to be distributed along with updates. I'm not complaining,
|
||
just suggesting that you flaunt it a little bit more than you have.
|
||
|
||
2. Change the name. I assume will to come out once a month, and I
|
||
also assume that volumes change once a year. With that in mind,
|
||
perhaps I can suggest another naming convention:
|
||
|
||
a. Do it Fido-nodelist-style. Call it WWIVNEWS.<num>, where
|
||
<num> is the number of days into the year on which that issue
|
||
was released.
|
||
|
||
b. Do it Another Way. If you are only going to have 16 volumes
|
||
and 12 issues per volume, then use hexidecimal format. For
|
||
example, WWIVNEWS.1-1 would be volume 1, issue 1, and
|
||
WWIVNEWS.A-3 would be volume 10 (0Ah), issue 3. Or provide 256
|
||
issues per volume: WWIVNEWS.AFF (volume 10 (0Ah), issue 255
|
||
(FFh)).
|
||
|
||
c. Here is yet another possibility. How about this:
|
||
0006-0010.NWS (Volume 6, Issue 10, WWIVNEWS).
|
||
|
||
What this boils down to is that I don't want to lose WWIVNEWS
|
||
every time a new one comes out, and why not make provisions to keep 'em
|
||
rather than having me COPY 'em?
|
||
John Wash #1 @8403
|
||
|
||
[All of these are excellent suggestions. My favorite idea overall is
|
||
naming it WWIVNEWS.v-i (v = volume number in hex, i = issue number in
|
||
hex). However, it will stay the same way basically because Wayne
|
||
already put it in the code that way, and he is reluctant to change it
|
||
so quickly after its birth. I do, however, provide on my board back
|
||
issues for anyone not collecting them. -Ed.]
|
||
=======================================================================
|
||
|
||
|
||
Official Jargon
|
||
by Random 1@1
|
||
(Wayne's All-Mail for January)
|
||
|
||
A couple things:
|
||
|
||
1. When you wish to be removed from distribution for a subboard, please
|
||
do >NOT< post a message about it on the subboard. The correct thing to
|
||
do is to email the host of the sub and inform him/her that way.
|
||
|
||
2. NET22 apparently has some problems receiving net updates. I am not
|
||
precisely sure why this did not also happen in NET21, but it apparently
|
||
doesn't. So, for now, it would be a good idea to use the network2.exe
|
||
file from NET21. NET23 (which fixes that problem) should be out about
|
||
January 27th or so.
|
||
|
||
3. Also about January 27th, we will be going to multiple CONNECT files.
|
||
In addition to the CONNECT.0 file, you will find CONNECT.1 through
|
||
CONNECT.12 files in your DATA directory (with the exception of
|
||
CONNECT.6, as there is no group 6). The network will continue to
|
||
function the same, however. This should not affect anyone except GCs
|
||
and maybe ACs.
|
||
|
||
Due to the way the connection updates will be handled, it is now
|
||
REQUIRED that AC's forward connection updates to the GC. You will NOT
|
||
be able to send connection update requests directly to me. So, to
|
||
reiterate, for anything in the network (connection update, bbslist
|
||
update, complaint, etc), the correct order is to first contact your AC,
|
||
then your GC and finally the NC (me). if you have been unable to
|
||
resolve A few people have come to me with things that they should have
|
||
contacted their GC about and I have simply referred them back to the
|
||
GC. Going directly to me tends to slow things down, not speed them up.
|
||
|
||
4. Starting with WWIV v4.20 (for which a release date has not yet been
|
||
set, but will be in a few months), the source code to WWIV will also be
|
||
distributed (to registered sysops ONLY) on certain select WWIVnet
|
||
systems. It will work like this:
|
||
|
||
a. About 5-10 WWIVnet systems will be selected as source distribution
|
||
points.
|
||
|
||
b. I will make up a list, based on inputs from registered WWIV users,
|
||
of which users on those systems are, in fact, registered WWIV users.
|
||
Those users, and only those users, will be able to download the source
|
||
code to WWIV from those systems.
|
||
|
||
c. The sysops of the source distribution points will have a special
|
||
file transfer section for WWIV source distribution. The file section
|
||
will have a specific DAR. Only the users listed on the 'master list'
|
||
will have that DAR, and hence be allowed to download the source code.
|
||
|
||
The list will look something like:
|
||
|
||
Reg num Accounts
|
||
1 Random #1 @1, Random #2 @1234
|
||
90999 Hector #123 @1, Hector #22 @1234, Hector #67 @1177
|
||
90888 Dude #321 @1, Dude #198 @1177
|
||
|
||
Where @1234 and @1177 are the source distribution points.
|
||
|
||
We are now at step "a": selecting source distribution points. If you
|
||
are a registered WWIV sysop, have been registered for over a year, have
|
||
been in WWIVnet for over a year, would like to be a source distribution
|
||
point, and agree to release the source code to users only on the list,
|
||
then please reply and tell me you are interested. Remember, there will
|
||
only be around 5-10 distribution points, and I'd like to have them in
|
||
various areas of the country, so if 20 people reply from Rhode Island,
|
||
only one of them will actually be selected.
|
||
=======================================================================
|
||
|
||
|
||
The Editor's Corner
|
||
by East Bay Ray 1@9964
|
||
|
||
|
||
One of the several network subs to investigate this month is the
|
||
"Alternative SysOp's Sub", sub type 9999, hosted by John Hardman @9954
|
||
(send mail to 2@9954 for speed answering), the GC of group 5. It boasts
|
||
less flames than other sysop subs. Check it out, it might make a nice
|
||
Valentine's gift for yourself.
|
||
Observant people will notice that the text is no longer justified
|
||
to the right margin. I wanted to be able to fit more text into less
|
||
space, so the decision was made. Thanks are due to Omega Man for his
|
||
suggestion regarding that one.
|
||
I also decided that I would stop publishing real names unless so
|
||
requested. I thought about it a while and came to the conclusion that
|
||
aliases were for people to hide their real names. I will continue to
|
||
publish their net addresses.
|
||
There has been some flak about my policy on the ownership of the
|
||
articles printed in WWIVNews. I thought the original policy was fair,
|
||
but apparently some people did not. I have modified it, so now my
|
||
position on the ownership of WWIVNews article is that all articles,
|
||
unless copyrighted by the author (whether stated copyright or official
|
||
copyright) become my property. If the article is copyrighted, then the
|
||
article's author retains full ownership and distribution rights of that
|
||
article. He MUST, if the article is copyrighted, give me specific
|
||
written (electronic or otherwise) permission to print the article in an
|
||
upcoming issue of WWIVNews.
|
||
=======================================================================
|
||
|
||
|
||
Acknowledgements
|
||
|
||
WWIV (c) 1988 by Wayne Bell.
|
||
NetZip II (c) 1990,1991 by Jeff Garzik.
|
||
PKZip, PKUnZip, and PKLite are registered trademarks of PKWare, Inc.
|
||
ARC is a registered trademark of SEA Enhancement Associates.
|
||
BiModem (c) 1988-90 by Erik Labs.
|
||
USR, USR HST, and USR Dual Standard are trademarks of US Robotics, Inc.
|
||
Hayes is a registered trademark of Hayes Microcomputer Products, Inc.
|
||
MNP (Microcom Networking Protocol) is a trademark of Microcom, Inc.
|
||
Windows is a trademark of Microsoft Corporation.
|
||
DesqView is a trademark of Quarterdeck Office Systems, Inc.
|
||
PC-MOS is a trademark of The Software Link.
|
||
NetWare is a trademark of Novell Data Systems.
|
||
All other products mentioned are either registered trademarks or
|
||
copyrighted by their respectives manufacturers.
|
||
=======================================================================
|
||
|
||
|
||
The End
|
||
|
||
|