synchro.net/synchro.net.tar/synchro.net/main/TEXT/WWIV9306.TXT

Text File | 2001-07-30 | 137.9 KB | 2,739 lines

               ┌┐┌┐┌┐┌┐┌┐┌┐┌────┐┌┐  ┌┐┌─┐ ┌┐┌────┐┌┐┌┐┌┐┌────┐
 ╔═════════════││││││││││││└─┐┌─┘││  │││ └┐│││┌───┘│││││││┌───┘═════════════╗
 ║   Volume 4  ││││││││││││  ││  └┼┐┌┼┘│  └┘││└───┐│││││││└───┐  June/July  ║
 ║   Issue 2   ││││││││││││  ││   ││││ │┌┐  ││┌───┘││││││└───┐│    1993     ║
 ╚═════════╤═══│└┘└┘││└┘└┘│┌─┘└─┐ └┼┼┘ ││└┐ ││└───┐│└┘└┘│┌───┘│═══╤═════════╝
           │   └────┘└────┘└────┘  └┘  └┘ └─┘└────┘└────┘└────┘   │
           │   The Electronic Forum for WWIVNet Sysops & Users!   │
           └──────────────────────────────────────────────────────┘

                          ┌─────────────────────┐
                          │This Issue's Features│
┌─────────────────────────┴─────────────────────┴───────────────────────────┐
│ Random Factors...................................Wayne Bell (1@1)         │
├──────────────┬─────────────────────────────────────────────┬──────────────┤
│              │    WWIVNews Feature Topic: The UU Debate    │              │
│              └─────────────────────────────────────────────┘              │
│ Introduction to the UU Debate....................Omega Man (1@5282)       │
│                                                                           │
│ Editorial Contributors...........................The Menace (1@4071)      │
│                                                  Redman (1@16950)         │
│                                                  Sleepy (1@3085)          │
│                                                  Snorkel (1@3459)         │
│                                                                           │
│ Technical Contributors...........................Deltigar (1@1052)        │
│                                                  Snorkel (1@3459)         │
│                                                  Tolkien (1@3456)         │
├───────────────────────────────────────────────────────────────────────────┤
│ Filo's Mod of the Month..........................Filo (1@2050)            │
│                                                                           │
│ Type 0 Forum.....................................Omega Man (1@5282)       │
│                                                                           │
│ WWIV-Compatible Networks List....................Red Dwarf (1@6264)       │
│                                                                           │
│ TechnOTES........................................WWIVNews Staff           │
│                                                                           │
│ Dateline: @#$*()#!...............................Omega Man (1@5282)       │
└──────────────┬─────────────────────────────────────────────┬──────────────┘
               └─────────────────────────────────────────────┘

───────────────┬─────────────────────────────────────────────┬───────────────
               │               Random Factors                │
               │   Creative Commentary by Wayne Bell (1@1)   │
               └─────────────────────────────────────────────┘

Quite a few things to discuss this issue, so let's get started:

NET33 BUG:

Yes, NET33 does have a bug where the 'BAD PW' SSM lops off the last digit of
a node number. That's because i had strlen(s+1) instead of strlen(s)+1. This
has been fixed for NET34, and the current one is still usable as an error flag
If you see there's a bad PW, you can always look at NET.LOG and see which node
is having connection problems.

NET34:

NET34 should have multiple nets in the same callout, although I haven't
started coding that part of it yet. As usual, there have been a few minor bug
fixes since net33. No major changes have been done yet, though. I (obviously)
do not have a release date set yet.


NEW DE1.EXE:

As most of you saw in the last mail_to_all_sysops, I've sent out a new
DE1.EXE. (If you haven't installed it, then you won't be reading this.)This
was sent as a UU encoded .ZIP file. To use this, you need to UUDecode it,
unZip it, then overwrite your current WWIVNet DE1.EXE with this. You should no
longer use the old DE1.EXE (the one in NET*.ZIP).

There have been those on some of the Sysop subs that have shown concern
whether the UU'd file did in fact originate from @1, despite the source
verification flags. If you're one of those who are still worried about this,
take a look at the archive once you've decoded it. If PKZIP reports the CRC as
331fe474, then you have an authentic copy.

If you are in more than one network, make sure you overwrite the correct
DE1.EXE. Your DE1.EXE is probably in your WWIVNet data directory, or if not
there, probably in your main WWIV directory.

This new DE1.EXE utilizes compression (PKWare Data Compression Library) to
reduce the size of net updates, and hopefully decrease network costs. This
also means it is slower than the older version.

An aside note to the AC's and GC's: Please make sure that new systems joining
the network receive this new DE1.EXE. It's also suggested that you make it
available for download by those sysops who are either unfamiliar or
uncomfortable with the use of the UUDECODE procedures.


WWIV v4.23:

WWIV v4.23 is being worked on now. No, I do not have a preliminary date set
for its release yet. I will let people know when a date is set, so please do
not email me to ask. Unlike previous releases, though, v4.23 will have some
significant portions of the new/upgraded code installed by other people.
Tolkien (@3456) has installed a number of new features, augmented existing
ones, and has made a lot of cosmetic changes. Jim Wire (@3950) is in the
process of installing multi-instance (multi-line) code, and that should be
being tested by the time this WWIVnews is released.

v4.23 already has multi-languages supported (although most of the code for
that was in v4.22 also, and not many non-English language .str files are
available yet). Shakespear (2@2050) is currently working on a FidoNet
implementation, which should work more elegantly than existing interfaces
(which require "fake" fidonet node numbers (@6xx)).


UU'D FILES & WWIVNet:

As has been made clear in the mail-to-all-sysops before the one containing the
DE1.EXE update, files should >NOT< be sent through WWIVNet, except if you have
the permission of all intervening systems. This covers not only UUENCODEd
files, but also PACKSCAN files, and any other method that may pop up.

Yes, many times it may be convenient to use WWIVNet to send files to someone.
However, by sending them through the net, you make other people pay for your
convenience, which is not fair. If you have a need currently to send files to
someone on a continuing basis, the best way is to set up your own mini-
network, and then send files (uuencoded or via PACKSCAN) on your own network.
That leaves the convenience for you, does not cost other people anything, and
will not end up routing normal WWIVNet traffic between your systems (as would
be the case if you simply added a WWIVNet connection between systems). I know
some systems in the St. Louis area have set up their own separate network for
this very purpose.

Some people have complained to me about the no-file policy, saying things like

"But I already pay $xx a month for dues to the server."  Yes, but that is for
just ONE server. messages of any type on the net tend to go through many
intervening systems, not just the one server. Files also tend to be much
larger than normal net traffic, and server dues are based upon normal traffic,
not based upon the few people who want to send large files. In any case, in
the relatively near future (no, no date yet), there will be an FREQ-type
program available for WWIV systems, which will allow direct transfer
of files between WWIV systems, not using any network. This will end up being
(I believe) the most convenient method, and will limit the costs to those
actually doing file transfers.

Rules and policies regarding this matter will be covered in detail in the new
WWIVNet policy docs that will accompany the release of NET33.ZIP. Any
questions regarding the FREQ utility should be directed to the author, 2@2050.


REGISTRATION & MULTI-LINE WWIV:

Prior to this writing, I've received several E-Mails regarding the per-line
registration deal. I would like to take a somewhat more mellow attitude about
it right now, than what these people seem to think is the situation.
Basically, explaining what the situation is, why changes are necessary, and
what we're currently proposing, and why. This opposed to taking the attitude
of "This is it, love it or leave it."

Previously, the license agreement has not explicitly addressed the issue of
running a multiple line WWIV, as until recently, it has only been possible to
run it on one line (and even so, not many people have been going multi-line
with it so far anyway). Since more and more people have become interested in
running multi-lines, and since v4.23 will probably support multiple lines,
obviously the license should be modified to explicitly address the multi-line
issue. That much, everyone should agree with.

The real issue, therefore, is in what way should multi-lines be handled (in
the license)?

A long time ago, someone (I'm sure) wanted to run two WWIV's. Not multi-line,
but two separate BBS's. The question therefore came up, "Do I need one or two
registrations?"  If someone could run two BBS's with one registration, then it
would also be possible for someone to say, "Yes, I run two BBS's - one at my
house, and one at my friend John's house" as a way to try to get John's BBS to
count as registered for "free."  Also, other DOS-based licenses (eg, BC++)
don't work that way - the license is for one copy on one computer. In any
case, as I understand copyright law (and they just gave a big lecture at work
on this), the standard license is for one copy on one computer. Anything
beyond that has to be explicitly granted by the license agreement.

So, obviously, if someone was running two BBS's, he needed two registrations.

That "decision" also expanded when someone wanted to run two separate BBS's on
the same computer (under DV, say). It therefore came to be "one registration
per phone line." I'm almost certain I've posted that on at least one sysop's
sub.

Currently, that also applies to one person running a two-line BBS.

Yes, I agree that's not perfectly fair, but it's all I could come up with. If
I went with anything less restrictive than that, it would become possible for
people to 'cheat' on it (although I don't think most people would intend to do
that).

"But," I hear people saying, "I can mod my BBS however I want, and I choose to
mod it to handle multiple lines."  Actually, that's not accurate. What people
have done to handle multiple lines is modify the BBS so that multiple copies
can be running simultaneously, not that one copy can handle multiple lines
(that is, the difference between having one BBS.EXE running, and having more
than one BBS.EXE running). So, even though it is one computer handling two
phone lines, it is still two BBS.EXE's running at the same time. That's two
copies. Thus the need for two registrations.

Let me explain the difference there a bit more. Modifying your BBS to handle
multiple phone lines would mean that you would have one BBS.EXE running on
your machine, which would have the multi-tasking code built into it, and it
would be the same BBS.EXE that was handling all users (on the same CPU). What
people have done is to have the BBS.EXE's lock files, and gracefully allow
multiple BBS.EXE's to access the same files almost concurrently.


Unfortunately, since DOS machines can typically handle only one user at a
time, DOS people have never encountered real multi-user licenses. In other
environments (eg, UNIX, which is what I use at work), where multi-user
machines are common, the typical licensing agreement is for a set number of
concurrently running copies. For example, FrameMaker (a word-processor type
program) has a "license server" program running on one machine in a network.
Whenever a user (on that machine or on another) wants to run FrameMaker, their
copy of FrameMaker gets a "license" from the license server. The server
ensures that no more than the set number of licenses are active at a time. If
you need to run more than that, then you pay more money for more licenses, and
they send you a new keyfile or password to enable the greater number of
licenses (the keyfile/password is based upon the machine name/serial-number/
ethernet-address, to ensure that you don't use the same key/pass on more than
one machine).

So, in response to all this, the WWIV license is being changed to be less
restrictive. Instead of having to have a separate registration for each phone
line, people will now be able to (legally) run a multi-line WWIV paying much
less than $80 per line.

Hopefully this clarifies matters a bit.


UTILITY.WW4:

Finally, Filo (1@2050) is in the process of compiling a comprehensive list of
utilities for WWIV, to be included in the documentation package. If you wish
to have your utility (or utilities, as the case may be) the following
information should be submitted:

FILENAME.EXT, Author's Name, ID, Description

   ^      ^       ^          ^   ^
   :      :       :          :   :...Description MUST not be longer than
   :      :       :          :       102 characters including spaces.
   :      :       :          :       If it is available only at a fee
   :      :       :          :       then include the fee in the
   :      :       :          :       description.
   :      :       :          :
   :      :       :          :....... Use PD, SW, or CM as ID to
   :      :       :                   indicate Public Domain, ShareWare
   :      :       :                   or commercial.
   :      :       :
   :      :       :.................. Self Explanatory
   :      :
   :      :.......................... Type of Compression used
   :
   :................................. Filename used as identification

Submissions can be sent to the following addresses:

WWIVNet:  1@830
WWIVLink: WWIVNet #1 at 830 @2050
IceNET:   WWIVNet #1 at 830 @2050

That's all for now. See you next issue.

───────────────┬─────────────────────────────────────────────┬───────────────
               │        Introduction To The UU Debate        │
               │            by Omega Man (1@5282)            │
               └─────────────────────────────────────────────┘

Transmission of UU encoded files over WWIVNet has been a topic of debate for
as long as the net has been in operation. The arguments for and against the
use of UU encoding have periodically turned sysop subs across the net into
heated flamefest arenas, producing lots of hurt feelings and very few real
answers to the questions raised.

The questions raised were simple ones with complex answers. Was the UU method
actually more efficient than a file request network relying on direct hookups?
Were UU'd files containing archives actually larger than the archives by
themselves? Should text files be UU'd? Do servers and pass-through nodes have
the right to scan network packets and purge UU'd files regardless of size or
content? Does the WWIVNet as a whole have the responsibility to bear the
costs involved in sending such large files, or does it have the right to
take steps as a whole to prevent this perceived abuse of resources?

Oddly enough, while it appeared the majority of WWIVNet was against UU'd file
transmissions, many of those opposed also expressed their doubts against any
sort of absolute rule against their use. At the same time, those in favor of
few or no controls on UU transmission were also some of the more outspoken and
persuasive members of WWIVNet, and what they lacked in acceptance among their
peers they made up for with tenacity and aggressiveness.

In an effort to help present all sides of this serious issue, WWIVNews placed
a Call for Articles on UU encoding. There were quite a few submissions for
editorials, as well as several reviews and technical articles regarding the
various utilities designed to manage - and even eliminate - network packets
containing UU'd files.

However, as this issue was being compiled, WWIVNet 1@1 issued what can best be

described as "The Last Word" on UU transmissions. As a result, several of
those who submitted editorials on this topic requested that their submissions
be dropped from publication. The reason cited was the same in all cases: Wayne
had rendered the debate a moot issue, and the forthcoming release of a File
Request netutil simply added the final nail to the coffin.

Still, there were some views that were allowed to be expressed. The following
editorials, technical papers, and product reviews are the remainder of the
30+ submissions on this topic. While the matter has arguably been settled,
for future reference the WWIVNews staff came to the consensus to publish the
remaining submissions, as presented below.

─────────────────────────────────────────────────────────────────────────────
The Menace (WWIVNet 1@4071)
─────────────────────────────────────────────────────────────────────────────

As of late there has been a controversy concerning UUENCODED files being
transferred across WWIVNet. A UUENCODED file (UUE) is coded with a special
program called UUENCODE, a program common to the UNIX world. By UUE'ing a
file, WWIVNet is capable of sending it across the network as a message. This
encoding is done since WWIVNet and WWIV itself, does not have the capability
of transferring files between nodes of the network. Upon receipt of this
encoded file, you would use UUDECODE to transform it back to it's original
usable/readable state.

The issue seems to reside in the cost of the network connects. When these UUE
files are transferred across the network, and distributed amongst the some
5000 BBS's in WWIVNet, each system must endure the extra cost and time, in
addition to the normal cost associated with a normal network transfer. This
issue may not seem like a concern to many, but there are those who abuse the
freedom that WWIVNet offers. Occasionally sending a UUE file is not the issue,
it is the constant transfer of packets containing large UUENCODED files
created by rather lazy users. Most of these Sysops are accepting the increase
in phone charges without a charge to the users. Most Sysops start a BBS
because it is fun, and the idea behind WWIVNet was the free flow of
information. These UUENCODED files in net packets, increase the cost of
running a BBS and are tarnishing the charm of being "networked".

In addition, some users and/or Sysops have been sending Non-Public Domain
files (NPD) across the net in a UUE fashion. This exchange of illegal files is
somewhat alarming to the Sysops who do not wish to associated with that part
of BBS'ing community. The possibility of legal action being taken against a
sysop on a network who has packets containing NPD software could be a major
detraction to those that only wish to use the network as a message medium.

A few users have compared WWIVNet to FidoNet, where files from other sites are
allowed to be transferred and housed by your system. WWIVNet is a different
medium all together. That feature was built into FidoNet by its creator, not
much unlike the way it was left out by the creator of WWIV. Wayne wanted a
message based BBS to exchange ideas and information, not files.

My opinion, although it will probably anger many, is to come up with a simple
across-the-board policy/standard. I think we should disallow ALL UUENCODED
files from being transferred across WWIVNet. I feel that we can not compare
apples to oranges anymore. We must decided together what the policy for the
network is. In this decision, there should be fair consideration to all, no
matter who they are or for what reasons they run their BBS. This approach
seems fairest to everyone involved.

I have heard talk of a feature in an upcoming release of WWIV, where you would
be able to send a file directly to another node by aid of the BBS list. This
way the cost would be incurred directly to the system who intends to send the
file. This seems to be a wise solution, if it is possible to implement. The
Sysop of the originating system could be notified about the file for transfer,
and have final say as to whether he should let the file be transferred
directly to the intended receiver node. Much like the NET VALIDATION option in
the netted WWIV subs, this would help sysops to regulate the network into an
orderly manner for all, yet maintain a high degree of fairness. Sysops would
have a say in how their systems would be used....

─────────────────────────────────────────────────────────────────────────────
Sleepy (1@3085)
─────────────────────────────────────────────────────────────────────────────

There has been more than enough discussion on the transfer of UU'd files
across WWIVnet. It seems to me that some of the more obvious (not to mention
Important) reasons against them have been completely ignored. That is what
prompted me to offer my opinion for everyone to read. One more thought before
I get to it, please remember that this is only my opinion, backed up with a
few facts that are available to all WWIVnet SysOp's, the only thing I did was
Read The Docs...

Here is a partial quote from the WWIVNET.DOC Introduction, which *everyone*
should have read. This quote maybe considered superfluous by a lot of you
however, everything and everyone *Must* start somewhere.

"WWIVnet is a voluntary association of bulletin boards using WWIV software,
and participating in a network by calling one another to facilitate the
transfer of electronic mail (e-mail) and message bases (subs)..."

"Through this network, a user of any of the bulletin boards that are members
may send e-mail to a user of any other board. A User may also post on a
message base which may be read by the users of systems which subscribe to that
message base;...Because this system of Communication  read by others and
because it has an effect on systems other than the one on which it originates,
a spirit of cooperation must prevail. Out of this spirit grows a system of
organization and regulation which are discussed in the pages that follow."

After reading the above documentation there is only one intelligent
interpretation:  Data (be it messages or files) transferred on WWIVnet *MUST*
be WWIVnet Message Subs posts or WWIVnet e-mail. IMHO if nothing else common
sense should have turned a light on somewhere.

Since we are all only human, and as such have responsibilities, some with
families, but all with the same feelings that are too often hurt. We should be
able to afford one another common courtesy. Common Courtesy is easily given
and should be extended to everyone in the same manner and

degree that we should all like to expect to receive. I don't run up your phone
bill so don't you run up mine. We have all agreed to incur the costs necessary
to transfer WWIVnet to and from our connects, some connects are fortunate
enough to be local to one another. But there are some out there that must pay
to transfer their packets.

I don't mean to sound condescending, I honestly believe that all of us were
taught manners by our parents. Everyone wants to be liked and wants to like
everyone in return. However when Joe Blow on AbracadrabraNet will send
anything and everything over his network, that does not mean that Wayne Bell
allows the same. What matters is what is fair. Plain and simple, you don't use
Sally's phone to do Sam's business nor can you expect others to incur charges
for something that has nothing to do with what they are interested in. Would
you pay for you neighbor's newspaper, say the daily East Palooka Extra?  Oh
that isn't the newspaper that you wanted to read?  So sorry, but it is already
here so what can you do???
It is impossible to run a board without expecting it to cost money. But the
normal expenses are high enough without having to pay for another board's
interest in a network that you have no interest in. And saying that sending
"Mod" files is not fair because other files cannot be sent is completely
unfair. The "Mod" files that are sent are for a Message base (which is in the
Documentation as legit data) and the majority of SysOp's in WWIVnet do benefit
from the Mods.

I truly believe the whole UU'd discussion took place only because the file's
being sent could be considered "unsolicited junkmail". I'm not calling
anyone's Network Junk...I along with I'm sure 99% of the other WWIV SysOp's,
don't begrudge success to anyone in any project they wish to pursue. We just
don't want to foot the bill. Most of us have already agreed that we don't what
unsolicited e-mail, so the same would (IMHO) be true of files that have
nothing to do with WWIVnet.

Although I do not believe that UU'd files should be completely banned, but
once the guidelines are abused the abuse will continue. Most of the SysOp's
that I know fairly well have no problems with WWIVnet files being UU'd and
sent. If someone wants a file bad enough they should pay for it. Whether they
are paying for a Commercial file or for the toll charges for a Shareware
download.

We should all care about each other's feelings, boards and pocket's. We are
all in it for the same reason....FUN!  We know just how hard we all have to
work at keeping our boards running. Have a little respect for your fellow
SysOp's and you'll get a lot in return.


─────────────────────────────────────────────────────────────────────────────
Redman (1@16950)
─────────────────────────────────────────────────────────────────────────────

The practice of sending a UUE of your net package through another net is not
a very good idea. This is not a practice that other nets should follow. To
start with there was a reason for your starting your own network. And I am
sure that one of the reasons was that you felt you had something better to
offer.

Therefore, having started your own net, it would only be proper that you do
not send your net startup package, nor updates through another net. In my
opinion you should either call that board or have the board that wants to
join, call your board for the package. But to send a UUE of your net package
for any reason is not right.

I am sure that there is a reason for the UUE's. Otherwise the program would
not have been made. But to use it for one network to send your net package
over another network (Even if it is just one {this time}) is not right. You
and I both know that it is not a 1 time thing. I am sure that many updates
(startup) packages are being sent.

I am the AC of DEADnet and I WILL NOT SEND the initial package or even an
upgrade on someone else's network. Other networks were set up (more then
likely) because WWIVnet did not quite suit your needs. Therefore you MUST be
obligated to either a) pay for calling the board that wants to join your net,
or b) have them call you. Seams BLACK AND WHITE. Reason being that I would not
want another network to be sending their updates or start up packages through
my net.

Look at it this way, those that have set up nets did so with the understanding
that their net would be used for their net, not for other networks. Would you
like to set up a net and have other networks tieing up all of your members
boards sending their network through yours? I do not think so!

And to think that you can send it in UUE and then complain because it was
deleted is moronic. It plainly states in the doc's that UUE's are allowed for
the MOD sub ONLY. Reasoning behind this was so that those that program would
be able to send ( small ) exe's and com's in a mod. Plus the big boys of WWIV
have set a size limit for UUE's as well. I would venture to say that this was
to help prevent huge phone bills for the LD connections. This purpose was for
the benefit of most network users.

So now you are thinking, "Why only allow UUE's for the MOD sub". Well even
I can figure this out. The mods are a benefit to all that use them. And I
would venture to say that the majority of netted boards have mods installed.
But I would also bet you that most boards do not carry your net. Thus allowing
UUE's in the MOD sub only is understandable. Besides this one little example,
the proper use of UUE's is in the doc's and that makes it a rule.

So to summarize this all up in a nut shell. UUE's are only allowed in the
MOD sub. You as a network sysop, have the right to use UUE's only as stated in
the doc's and not as a way to send your net (upgrades and or startup)
packages. It is not right, nor is it allowed to use UUE for any other purpose.

It is also well known that Net33 will have detailed rules concerning the
use of UUE's.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
─────────────────────────────────────────────────────────────────────────────
"Could someone please send me the Latest copy of McAfee's Clean and Scan? Mine
is old and I don't want to take any chances."

How often have you seen requests like that on Network subs? How often have you
been a "good buddy" and responded to such requests? I know I have!  Most of
us have good local connects, so all it costs us is a couple of minutes to
UUEncode or Packscan the file and stick it on the net. It's great to be on the
receiving end too, as it saves an LD call. The file you requested just appears
on your board in a couple of days. Often you may get several copies since
WWIVnet is a friendly place where a spirit of helpfulness and cooperation
prevail (most of the time).

There is just one small thing we have overlooked while we were being so
helpful. Just how did those utilities get from your system to the person who
wanted them. Well, it may have looked something like this:

           SENDER --> 1040 --> 1050 --> 1120 --> 3314 --> RECEIVER
Ok, you are local to 1040, so that is a free call. 1040, 1050, 1120, and
3314 are Long Distance calls to each other so THEY EACH have to PAY the phone
company in order to move the utilities. Since the receiving system is local to
3314, he doesn't incur any expense. I think at this point you can see the
problem. The mail servers and hubs are stuck PAYING to move YOUR FILES.

When they agreed to allow other systems to connect to them, and to act as a
net mail server, they understood they would be handling MESSAGE traffic. Even
though the average message is less than 1k, the bills add up fast. Servers
routinely pay the phone company over $100 per month just to move MESSAGES.
Remember those utilities you sent out?  After UUEncoding they probably
exceeded 300k. It doesn't take many people sending this type of stuff to add
$25 to $50 a month to a servers bill. It is their right and responsibility to
try and limit the non message traffic. It is their LD bill at stake. Without
these Servers there would be NO WWIVnet!

Now, it seems that some of these helpful, cooperative sysops became nasty and
abusive, when advised that WWIVnet was for MESSAGES, not FILE transfers. It
was explained that this practice is against network guidelines, and incurs
extra costs for the systems handling the mail. They were asked nicely not to
send their files over the net, and these requests were met with comments like:
"It's my right, This is a public network, You can't stop me, I'll just find
another way, etc"

At this point, Tolkien went to work on a utility to detect UUEncoded messages
and several other types of encoding that could be carrying "files". NetProbe
was born. This program was not cheap, nor was it easy to get. Tolkien put in
place a number of safeguards to insure it would never fall into irresponsible
hands. Despite the cost, a number of the Mail Server systems and Hubs shelled
out the cash in hopes they could control this abuse of the net.

UUEing is the most popular way of sending "programs" over the net. The easiest
way to curb this was to target the vehicle (UUEncoding & Packscan). Since
UUEing is a valuable way of moving mods and other small files containing small
EXEs and OBJs, it was decided to ONLY stop the LARGE and MULTIPLE ones, as
they would be the most likely to contain "programs". NetProbe does NOT delete
these messages, it simply flags them by moving them into a separate file. At
that point, the large ones are either passed or deleted at the Server Sysops'
option. If they are deleted, the system(s) involved will get at least ONE
warning. Further attempts will be deleted, and if it continues, the GC/NC will
be notified.

The size limit is a figure that the NetProbe Servers could collectively agree
on. Some favored NO UUEs at all, while others didn't mind singles up to the
32k net limit. Small-(less than 10k)-SINGLE-UUEs still flow freely! Also, a
few subs (like ModNet) that benefit the greater portion of the net were
exempted from the scan. Unfortunately, as with any filter, you sometimes catch
things you don't want, but for the most part, the program is working VERY
well.


I compiled some stats on the volume of UUE type files flowing through here
(6211) for the last couple of months.

     Feb  : 3.5 meg  (including several copyrighted major programs)
     Mar  : 2 meg
     Apr  : .8 meg (and none had to be stopped !)

Last month the only UUEs were those going to & from ModNet (only 147k) and
those going to & from systems who have a common connect here. The phone bill
is lower, and the sysop is smiling.

I'm afraid that if the current attitude held by many sysops that "I can send
what I want at someone else's expense" continues, Wayne will pull the plug
completely and prohibit the use of UUE, Packscan, etc completely over the
net! How many of you that are complaining know what would happen if 1040
(Filo), 1042, 1050, 1051, 1111, 1112, etc, decided that this was costing too
much and shut down their servers.......? It's truly sad that so many Sysops
have so LITTLE RESPECT for the people that pay the LD bills so WWIVnet,
IceNET, etc, can exist!

<concerned, sad sigh>

Of course, there are lots of questions to be answered about this situation.

Question: I can Zip a 10k text file and then UUEncode it and it ends up
smaller than the original (about 8k). Wouldn't that be a better way of sending
mods and large text files?

Answer: No. Network compression or your modem's internal compression (MNP5
or V.42bis) will compress that 10k text file down to about 5k. The
Zipped/UUEncoded version will not compress down much more than it already is.
In fact even though it appears smaller on your hard disk, the Zipped/UUEd
version will have about 20% to 30% more bytes to transmit.

Question: I have a large mod I want to post on ModNet. It is larger than the
32k network message limit. If I zip it, and UUE it, then it will fit. It this
ok?

Answer: No, for two reasons. First, if you split it into two text files
and send them normally, it will take less LD time to transmit them (saving
everyone money). Second, most people want to look at a mod before they decide
if they want it. If it's UUEd, they can't do that. The ONLY reason to UUE a
mod is if you have to include a small EXE or OBJ with it. If so, you should
post a message ahead of it describing exactly what it is.

Question: Can I be sure any UUEs (under 10k) that I send will get through?

Answer: That depends on the Server. The NetProbe systems have agreed on a
"defacto standard" for what to pass. Some servers are more (or less) tolerant
than others. Even though NetProbe only flags large UUEs and PACKSCANs, it
generates a report of ALL of them that pass through the node. If a sysop
observes
you are sending many small UUE's, he may suspect you are trying to put one
over on him by breaking files up into tiny packets. In that case he would
probably put a stop to it.

Question: How many warnings will I get?
Answer: A busy Sever Sysop may not have the time to examine and make
individual decisions on UUE containing messages that have been flagged. He may
just kill them, send you one warning and be done with it. Others may prefer
not to keep a list of who has had warnings and who hasn't, so you may get more
than one warning from them.


Question: Why are you stopping UUEs? They aren't the enemy, it's the EXEs
in them that are the problem.

Answer: If there had been an easy way to only stop UUEs carrying EXEs, and
not mods or OBJs, that would have been much better, but under the
circumstances, we just have to put up with a little inconvenience in order to
keep the net healthy.   The intent is to put an end to using WWIVnet to
transfer "programs"!  It's just too bad that some legitimate uses for UUEing
have been caught in the sieve.

Question: I thought one of the beauties of WWIVnet was that it didn't have
a lot of rules. I was one of the first systems in the net. All these rules
didn't exist then and everything worked fine. Don't you think you have gone a
little overboard?

Answer: Ah... the good old days. Possibly, the fact that computers were
more expensive, not everyone had one, and the net was smaller contributed to
a strong sense of cooperation and respect. At that point, if someone said "
You can connect here, but please keep the traffic low" all the connects would
try their best to do so. Now when one of the servers ask for a little
cooperation or respect, all they get is " You can't do that, It's my right,
etc".

Question: Who gave these "Servers" the right to "censor" my mail? I think
their power has gone to their heads.

Answer: Don't you think they have the 'right' and 'responsibility' to do
their best to keep network traffic flowing?  Along with the obvious cost
factor, they have to maintain enough hard disk space. It takes up to 3 times
the packet size to process an incoming packet. If WWIV allowed file transfers,
many servers would go down due to the increased cost. Those that didn't would
have to get larger hard disks and faster systems. Since at this time, file
transfers aren't allowed, why should these Sysops have to foot the cost for
those who would abuse the system. It is their RESPONSIBILITY to filter out
file transfers so we can maintain the excellent mail service we now enjoy. If
and when file transfers are permitted on the net, I suspect we will see the
demise of the free connects.

Question: One 10 UUE doesn't cost a high speed system more than a couple
of pennies. Why all the fuss?

Answer: You are correct. The cost of a single small UUE is insignificant,
and that is why they still pass freely. Review the stats I posted earlier in
this article where I showed the reduction in UUE type files over the last few
months. The Program is working. For a system like 1021, his savings were on
the order of $40 per month (don't quote me on that figure). That's nearly $500
per year. Enough for a nice new hard disk, or summer camp for the kids, etc...
Question: All the discussion on banning UUEs has probably cost as much as
will ever be saved by doing so. Why didn't someone explain what was happening
before NetProbe went into use?

Answer: I think for the most part, all this bickering is the fault of the
NetProbe systems themselves. We failed to completely and fully explain what
was happening initially. I guess that was my job. I told Tolkien I would
handle getting a "Press Release" out, and I let it slide. Things escalated
from there. I sincerely hope this article helps clear things up.


─────────────────────────────────────────────────────────────────────────────
Deltigar (1@1052)
─────────────────────────────────────────────────────────────────────────────

FILEnet is a network dedicated to making file transfers as easy as possible
while at the same time making some transfers unnecessary. The former is made
possible with the latest in File Transfer software designed specifically for
FILEnet. The latter is a byproduct of being able to request lists of files
from other FILEnet systems.

The concept I have put into play is one of a Server/End Node only network.
This allows the individual sysop to choose what traffic flows through their
system.  On the application form, you are asked several questions concerning
what type of connection you want. All Servers connect to each other, and all
End Nodes connect to at least one server. This keeps the maximum number of
hops to 3. This is mainly to keep the total cost of transfers as low as
possible. Unfortunately, it is one of the lesser understood aspects of
FILEnet. I often get an application from someone who doesn't understand why he
is not just connected to another FILEnet node simply because he is local.
Granted, a connect will be established because they ARE local, but unless the
other node is a Server, the new node will ALSO have to connect to a server.

I would like to ask potential new members to please NOT request a connect to
an End Node as your primary connect. If that individual wishes to pick up
your traffic, they will have to become a server to keep the maximum hop down
to 3. If this individual had wanted to do so in the first place, they would
already be a server.

Server connections are "Call In Only" or "Shared". Call In Only connections
are for End Nodes who are paying for all of their incoming and outgoing
traffic.  Shared means that both the Server and the End Node pick up the tab.
In FILEnet, the importance of the Server cannot be stressed enough.

End Nodes are those nodes whose traffic is theirs, and theirs alone. They may
limit the files leaving simply by editing the configuration files. In their
default state, no files re allowed to be transferred off the new system. Only
by adding the directory numbers to DIRLIST.FTS in the FILEnet directory can
files be made available to FILEnet. Limiting the incoming files is simply a
matter of restraint. If you don't use either FTSREQ or the User File Request
Door, you will not receive files from FILEnet (Except normal net updates).

The Software we use in FILEnet has been specially developed by myself and
Private Idaho. It is intended to be the standard FILEnet software. However,
it is still quite acceptable to use PackScan, WWFNET, or any other method of
sending whole files through the net. You simply need to keep in mind that the
other systems you are dealing with also need to be running that software. If
they do not, then the standard system is still there.

For more information on the development of the new software, and improvements
that are being made, FILEnet Software Development is autorequestable on all
major networks, and a few minor ones. Check your favorite network's subs list
for the subtype nearest you.

[Deltigar's NOTE: Subtypes are WWIVnet 11052, IceNET 11084, WWIVLink 11184,
TARDISNet 11052, FILEnet 101 and TLCnet 155.]

The ONLY transfer method that is expressly banned, is UUE traffic. This is
not because we don't want files sent, it is simply because everything else is
so much more cost effective. UUE files are bigger than the zip files they
contain, so why not just send the zip file?! The standard FILEnet software is
EASIER to use than UUEncoding anyway. With the ability to post on certain
FDL's, UUEncoded subs have become obsolete.

There are two classes of file transfers on FILEnet: FDL and FTS.

FDL - File Distribution List. This system allows a sysop to subscribe to an
FDL (with FDLREQ.EXE) or host one (with FDL.EXE). The concept is somewhat
like a one way message base. The host posts a file, such as a new release, or
updated utility, and it is automatically sent out to the subscribing nodes. On
certain FDL's posts are allowed, making the entire system behave like a
networked directory. This, IMHO, can UUEnd the UUDebate for good.

FTS - File Transfer System. This system allows a sysop to send a single file
to a single node (with FTSEND.EXE), or to request one to be sent (with
FTSREQ.EXE). A listing of all files available on a system may also be
requested (also with FTSREQ.EXE). The system receiving the request has
complete control over which files are made available for request (with
DIRLIST.FTS) and my block out any systems they do not wish to grant access to
(with BADNODES.FTS).

One thing we would like to work for is to make FILEnet the network that other
networks use to transfer files, since files are generally of a nature that
all sysops want, and are not usually network specific.  A good example is the
HS/Link File Distribution List. Once a sysop has subscribed to this list
he/she is assured of receiving the latest version of HS/Link very shortly
after it is released.

Another goal is to get software developers hooked into FILEnet.  This will
greatly decrease the time between when a product is released, and when it
becomes widespread. Already we have Diamond, who recently made a splash with
MO, a new message base optimizer and Private Idaho, who is probably best
known for his GoSnarf utility.

In order to join FILEnet, there has historically been a very strict ritual
involved -- one must ASK to join. You must also be a REGISTERED WWIV sysop.
That simple. The reason behind requiring registration is quite simple. There
are plenty of other networks out there for new WWIV sysops to cut their teeth
on. FILEnet is not network you would want to make mistakes on. A single
misunderstanding could land you a BIG phone bill. You also should be very
familiar with the WWIV software, and if you are that familiar with it, then
your registration trial period has probably already passed <SMILE>.

The VBBS Problem - Since our software reads many of the configuration and
data files on a WWIV system, and due to our lack of VBBS software developers,
we have yet to design an interface for VBBS systems. It is my sincere hope
that sometime in the near future a VBBS programmer will subscribe to FILEnet
Software Development (Offered on all major networks) and help us open FILEnet
to REGISTERED VBBS sysops as well.


─────────────────────────────────────────────────────────────────────────────
                          The FILEnet Application
─────────────────────────────────────────────────────────────────────────────

The EASIEST way to give the information needed is to simply extract the line
for your system from the applicable BBSLIST file in your primary WWIV-Based
network. Insert it below, or fill out the top paragraph.

You will be notified as to what your FILEnet Node number will be as soon as
this form is received. You will also be notified as to which server you will
be connected to. If you have a FILEnet server in your area, please indicate
which one it is.

 Node     Phone Number  Rate   Reg#   Compat BBS Name
@0000    *000-000-0000 #00000 [00000]  !$?  "Your BBS Name Goes Here"

@  Major Net/Node Number:
*  Complete Phone Number:
#  Highest Modem Speed  :
[] WWIV Registration Num:
!$ Modem Compatibility  :
"" System Name          :

Do you want to be an End Node or a Server?

── End Nodes Only ──────────────────────────────────────────────
What type of Connection do you want?
-Call In Only (YOU pay for all YOUR traffic)
-Shared (You SHARE cost with a Server)
────────────────────────────────────────────────────────────────

── Servers Only ────────────────────────────────────────────────
Free Drive Space:
Your VOICE Phone:
Your REAL Name  :
Your AGE        :

What type of connections are you willing to have?
-Call In Only (THEY pay for all THEIR traffic)
-Shared (You share cost with the other node)
 (NOTE: Server-Server connections will be SHARED)
────────────────────────────────────────────────────────────────

Edit and send this form to FILEnet, TARDISNet or WWIVnet 1@1052,
IceNET 1@1084 or WWIVLink 1@1184.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
and Tolkien (1@3456)
─────────────────────────────────────────────────────────────────────────────

During the last few months of 1992, the WWIVnet sysops in the 314 area code
(of which the authors are two), who pay to support the operation of the
St. Louis WWIVnet Server, were informed by the server's sysop, The Sandman
(1@1021), that it appeared that we had a problem.

The Sandman had been running the server's day-to-day operation for over 2
years, and had been observing that as WWIVnet doubled in size, the flow of
WWIVnet packets was increasing exponentially, growing at about 4 times the
rate of WWIVnet expansion. He found this disturbing, especially since much of
the message traffic during that time was routed to other connections via
PCPursuit, which operates at only 2400 bps. Additionally, our server was
gradually being weaned off of PCPursuit and onto standard AT&T phone line, so
that it could take advantage of the US Robotics HST Dual Standard 16,800 bps
modem that our group had purchased. The Sandman was concerned that if this
rate of message traffic increases continued, we would soon not be able to
afford the cost of long distance bills, and that this might force us to shut
down our server.

The Sandman brought his concerns to the server group, and we began to discuss
what could be contributing to this seemingly unwarranted increase in WWIVnet
message traffic. After several days of discussion, what began to emerge was a
feeling that much of this increase in WWIVnet message traffic was the result
of binary-encoded files being sent back and forth over the network. Most of
us were only aware of one (1) form of encoding that would allow a file to be
transmitted as binary data between connecting systems, and that was UUENCODE.
We then discussed how we might be able to not only test this theory, but also
do something about it if it turned out that we were correct.

Since WWIVnet packets are compressed using algorithms from the PKWare
Compression Library, our group decided that it would be necessary to purchase
a copy of this library, so as to be able to decompress the incoming packets
for analysis. It was decided very early that this program would have to
function as NETWORK1. It would be written so as decompress the incoming
packet (if it was compressed) to do its analysis, and then call the "real",
but renamed NETWORK1. The job of writing the program was given to Tolkien,
1@3456, who has a good working knowledge of WWIV data structures.

Tolkien, and others, felt that it would not be ethical to simply delete UUE
packets out of hand, so it was proposed that UUE packets under a certain
agreed upon size would be allowed to pass without being stopped. He and others
also felt that any packet that exceeded that maximum size should simply be
removed from the outgoing packet, and placed in a file, called CHECK.NET,
which could then be viewed, with LNET, by the server's sysop. Also, to be
fair, NETPROBE, as it was soon named, would also be able to sense, and be able
to filter PACKSCAN packets. Tolkien had created PACKSCAN, initially to simply
scan the incoming decompressed LOCAL.NET files and write a synopsis of the
contents to the sysop's log. However, PACKSCAN soon evolved into a utility
which was capable of breaking large files into 32K chunks for transmission
between BBS's. Therefore, with this potential for abuse, PACKSCAN and other
binary data packets sub packets were also added to the list of things for
which
NETPROBE would scan.

With the PkWare Compression Library in hand, Tolkien began to write the
program. Realizing the potential for abuse if NETPROBE was distributed to all
sysops in WWIVnet, it was decided that it would only be made available to
sysops who ran WWIVnet mail servers, for a nominal fee to recover the cost of
our purchase of the PKWare Compression Library. It was also decided, very
early in the development of NETPROBE, that, to prevent some sysops from simply
giving away copies of NETPROBE to their friends, some type of registration
code would be needed before NETPROBE could work. Without this code, NETPROBE
would not be able to function at all. Finally, a NETPROBE "application" was
drafted, and mail to all WWIVnet server sysops. This "application" was
designed to to limit the number of copies of NETPROBE which would be
distributed, and to inform the sysops of the need to use this program
ethically.

It quickly became apparent that the responsibility for deciding who could get
a copy of NETPROBE should not rest in the hands of any one person, since
NETPROBE was written for the good of the entire network. Lance Halle, 1@6211,
graciously volunteered to draft an objective set of qualifications that must
be met by anyone wishing a copy. These qualifications are:

       1) The sysop must be running a server.

       2) The sysop must have run a WWIVnet system for 18 consecutive
          months, 6 months as a server.

       3) The sysop must receive approval from three other server
          sysops running NETPROBE.


NETPROBE is actually quite a simple utility. It decompresses compressed
network packets, and analyzes all packets coming to or through the system it
is running on. It works in a multi-network environment, comes with a network
decompressor, a utility to send command line netmail, and a program to
generate
the daily logs (that can be then sent in netmail to any net address using the
included command line netmailer as part of the external event).

Subpackets are analyzed to determine what they are (message, file, SSM, etc).
Files are logged, along with some information about them (who sent them, who
they was going to, maintype, minortype, etc). If the file is not from a system
that the NETPROBE system has given the "okay" to for sending files through
him/her and if the subpacket is larger than a specified size (default is 10k,
which still leaves room for small utilities and data subpackets) then the file
is shunted into the CHECK.NET file for later personal review by the NETPROBE
sysop. NETPROBE does not itself EVER delete anything. It will delay only.
Actual deletion requires human control.

The creators and sponsors of NETPROBE sincerely hope that it will soon no
longer be needed. NETPROBE is not the ideal solution. The ideal solution
would be for people who wish to transmit files over WWIVnet to get permission
from all the intervening systems instead of covertly trying to have others,
especially net servers, pay the cost for such files, which are usually for the
benefit of just one or two people. However, it appears that a number of
people continue to think about no one but themselves. So for now, NETPROBE is
the only real solution to this growing problem. A point-to-point network FREQ
utility will (hopefully) alleviate the problem, but that remains to be seen.
If such a FREQ program isn't used because people would rather try to make
others pay for their file transfers, then NETPROBE may still be needed years
into the future.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
─────────────────────────────────────────────────────────────────────────────

This utility, written by Tolkien 1@3456 WWIVnet, has evolved into the finest
NET packet analyzer for WWIV or any compatible network.After almost 2 years
of revisions and improvements, PACKSCAN version 2.31 has now become more than
just a WWIV packet scanner.

In 1991, at my urging, Tolkien undertook the task of writing a program which
would scan all incoming NET mail packets for WWIV, and log them to the sysop
log.Since this original program was written, Tolkien has expanded PACKSCAN's
features until today, it is a full-featured NETWORK2 pre-processor for WWIV
networks.

Current features of PACKSCAN v2.31:

    ■  Two versions for systems with different amounts of available memory.
       The standard version has a well written graphical screen which displays
       the progress of packet analysis. The memory-saving version gets rid of
       graphics, and reports its progress in text mode.

    ■  Multi-network compatible.

    ■  Sysop configurable via a user-friendly configuration interface.

    ■  Packet logging to the WWIV sysop log.

    ■  Extended packet logging, providing even more detail than the standard
       sysop log entries provide.

    ■  Detailed error logging which reports errors encountered by PACKSCAN
       when packet transfers occur and are aborted.

    ■  File logging which reports the status of both incoming and outgoing
       program files.

    ■  Ability to transmit and receive program files in specially encoded
       packets or "chunks".

    ■  Ability to receive network updates from network coordinators who use
       a specially written program called "PUS" (PackScan Update System -
       available to all network coordinators for $20).

    ■  Ability to read the WWIV 4.21+ USER.LST to aid in file acquisition.
       This ability may be disabled for those systems which are running
       programs which may encounter SHARE violations, like Windows (R)*.

    ■  Fully implemented CRC-32 error checking of incoming program file
       chunks.

    ■  Ability to accept or reject unsolicited program files sent by other
       network sysops.

    ■  Built-in interface with ALLOW.EXE, a utility for storing and searching
       for file names of previously uploaded programs.

    ■  Configurable ability to send SSM's (Small System Messages) to other
       network systems when program files are received.

    ■  Ability to specify the directory "type" for the WWIV upload directory
       where program files will be sent.

    ■  Full implementation and support for the WWIV external packet
       pre-processor file redirection implemented in NET32.

    ■  Fully configurable "ALIAS" file which gives the sysop ultimate control
       over who may access files from their system.

    ■  Allows transmission and receipt of program files using a "stealth mode"
       which will bypass SSM notification to systems who would normally
       receive notification of a PACKSCAN upload to your system.

    ■  File lists indicate which files are/are not available in transfer
       areas on your system's hard drive at the time of the request. A tad
       slower, perhaps, but then others won't spend the time requesting files
       which are not available on your system. CD-ROM drives are not scanned
       as all files are presumed to be there.

Future features of PACKSCAN:

    ■  Configurable upload event (virus scanning, etc.).

    ■  Automatic subscriber list generation for networked message echos.

    ■  Sysop configurable sound board support (Soundblaster, Adlib, Pro Audio
       Spectrum, etc.).


As always, PACKSCAN version 2.31 is FREE. However, due to numerous upgraded
and newly implemented features, PACKSCAN version 2.31 is not compatible with
any previous version of itself. This includes file requesting, file sending
and file list requests. Also, because the network coordinator's update
utility (PUS) is being upgraded and improved (including some minor
de-bugging), those sysops who use PACKSCAN to receive their network updates
will need to upgrade to version 2.31.

Unlike previous versions, the four utility files which accompany PACKSCAN are
NOT free. These utilities, which give sysops the ability to request file
lists and send and receive files, now must be registered. These file
utilities will require registration before they will work. These utilities
are:

NETFILE .EXE         Allows you to send a file to one or more nodes
FILEREQ .EXE         Allows you to send a file request to another system
LISTREQ .EXE         Allows you to send a file list request to another system
NFM     .EXE         Does all that the first three do, in one integrated
                     program, and allows use of "Stealth Mode" as well.

The utilities listed above must be registered. In an effort to keep sysop
registration costs down, normal registration is $20 for all four PACKSCAN
utilities. However, for a limited time, ALL FOUR PACKSCAN UTILITIES may be
purchased for $10. To take advantage of this LOW $10 registration fee, you
must send in your registration (check or money order - no cash please),
postmarked by July 31, 1993, to:

                            Sara Felix
                            c/o PACKSCAN REGISTRATION
                            7035 Ethel
                            St. Louis, MO 63117

Please make all checks payable to "Sara Felix". All registrations received
will be donated, by Tolkien, to one of the major network mail servers which
moves YOUR network mail around the world.

With this new version of PACKSCAN, the WWIV network sysop will gain more
knowledge about the nature of data flowing into their system. Without
PACKSCAN, you may be "flying in a fog"; with PACKSCAN, you should have
"unlimited visibility".


─────────────────────────────────────────────────────────────────────────────
 Conclusions
──────────────────────────────────────────────────────────────────────────────

Despite the arguments presented against the use of WWIVNet for transmitting
large files in lieu of direct connections, there have always been those who'll
take the "Devil's Advocate" side in the matter. Wayne's final ruling on the
issue, as well as the DE1.EXE distribution will quiet some of the dissention,
but at the same time will no doubt raise other points of order.

The recent DE1.EXE distribution will no doubt be used as a prime example for
both sides of the debate. There will be those who'll use this event as
evidence of how UU encoded files can be beneficial to WWIVNet, while others
will use it to cry "foul!" and "double-standard!!" in what will no doubt be
described as a "sour grapes" response by those who wish to use the net any way
they see fit regardless of the consequences.

In any case, the matter does seem to be essentially a settled one for now.
With the development and forthcoming release of WW4-FREQ by 2@2050, as well
as the existence of FILENET and the PACKSCAN and NETPROBE utilities, perhaps
the final nail has been hammered into a coffin containing UUENCODE.

───────────────┬─────────────────────────────────────────────┬───────────────
               │           Filo's Mod of the Month           │
               │              by Filo (1@2050)               │
               └─────────────────────────────────────────────┘

The Mod-of-The-Month Selection represents my choice of what appears to be a
useful, practical mod to WWIV. It does not mean it is the best mod posted or
even that it works as I may not have tested it. Given the limitations of this
media, uuencoded mods are NOT eligible for selection as mod-of-the-month.

The June selection is another contribution from The Bishop 1@7. This mod
should prove to be useful for those who need to move subs and/or directories.


╔═══════════════════════════════════════════════════════════════════════════╗
║ WWIV Desc    : Re-Order Subs and Dirs in //BOARDEDIT and //DIREDIT        ║
║                                                                           ║
║ Filename     : TB15-422.ZIP          Mod Version       : 1.0σ             ║
║ Author       : τhe ßishop            1st File Modified : SUBEDIT.C        ║
║  1st Net     :  1@   7.WWIVnet       2nd File Modified : DIREDIT.C        ║
║  2nd Net     :  1@   7.WWIVweb       3rd File Modified : FCNS.H           ║
║  3rd Net     :  1@   7.ExpressNet    4th File Modified :                  ║
║  4th Net     :  1@   7.FunNet        5th File Modified :                  ║
║  5th Net     :  [e-mail]        6th File Modified :                  ║
║  6th Net     :  [e-mail]        7th File Modified :                  ║
║                                                                           ║
║ WWIV Version : 4.22                  Date              : 01 June 1993     ║
║                                                                           ║
║ Difficulty   : ████▒▒▒▒▒▒                                                 ║
║                                                                           ║
║ Description  :  Over the years I've wanted to re-order my subs and        ║
║                directories more times than I can remember. So I finally   ║
║                decided to do something about it. This mod allows SysOps   ║
║                to take any one sub/dir and move it before any other one.  ║
║                In addition, it maintains proper qscan pointers for all    ║
║                all of your users (even deleted ones) after moving subs    ║
║                and/or dirs. Enjoy!                                        ║
║                                                                           ║
║                                                                       τß  ║
╚═══════════════════════════════════════════════════════════════════════════╝

┌─────────────────────────────────┐
│ Legend:                         │
│                                 │
│  = Leave this line alone        │
│  + Add this line                │
│  - Delete this line             │
│  | Change this line             │
│  . Many statements elapse here  │
└─────────────────────────────────┘

┌───────────────────────────┐
│ Disclaimer: LIVE WITH IT. │
└───────────────────────────┘

──────────────────────────────────────────────────────────────────────────────
Step 0:   Back your source code up. In addition, back up the
following files in your DATA directory:

     SUBS.*
     DIRS.*
     USER.*

I recommend putting them in one big zip file. I'll be shocked if
you need the backup, but I wouldn't be recommending it if I didn't
think you should do it.
──────────────────────────────────────────────────────────────────────────────

──────────────────────────────────────────────────────────────────────────────
Step 1:   Open up SUBEDIT.C. Block copy swap_subs() in before insert_sub().
──────────────────────────────────────────────────────────────────────────────

/* TB15-422.MOD */
void swap_subs(int sub1, int sub2)
{
  int i,i1,i2,nu;
  unsigned long *qsc, *qsc_p, *qsc_n, *qsc_q, m1, m2, m3, tl;
  subboardrec sbt;
  xtrasubsrec xst;

  nu=number_userrecs();
  close_user();

  qsc=(unsigned long *)farmalloc(syscfg.qscn_len);
  if (qsc) {
    for (i=1; i<=nu; i++) {
      read_qscn(i,qsc,1);
      qsc_n=qsc+1;
      qsc_q=qsc_n+(max_dirs+31)/32;
      qsc_p=qsc_q+(max_subs+31)/32;

      if (qsc_q[sub1/32] & (1L<<(sub1%32)))
        i1=1;
      else
        i1=0;
      if (qsc_q[sub2/32] & (1L<<(sub2%32)))
        i2=1;
      else
        i2=0;
      if (i1+i2==1) {         /* One is scanned; the other isn't */
        qsc_q[sub1/32] ^= (1L<<(sub1%32));
        qsc_q[sub2/32] ^= (1L<<(sub2%32));
      }

      tl=qsc_p[sub1];
      qsc_p[sub1]=qsc_p[sub2];
      qsc_p[sub2]=tl;

      write_qscn(i,qsc,1);
    }
    close_qscn();
    farfree(qsc);
  }

  sbt=subboards[sub1];
  subboards[sub1]=subboards[sub2];
  subboards[sub2]=sbt;

  tl=sub_dates[sub1];
  sub_dates[sub1]=sub_dates[sub2];
  sub_dates[sub2]=tl;

  xst=xsubs[sub1];
  xsubs[sub1]=xsubs[sub2];
  xsubs[sub2]=xst;

  save_subs();
}

──────────────────────────────────────────────────────────────────────────────
Step 2:   Below, at the end of insert_sub(), comment out modify_sub(n);
──────────────────────────────────────────────────────────────────────────────
= save_subs();

= if (curlsub>=n)
=   curlsub++;

| // modify_sub(n);    /* Removed TB15-422.MOD */

──────────────────────────────────────────────────────────────────────────────
Step 3:   Below in boardedit() make the following changes:
──────────────────────────────────────────────────────────────────────────────

void boardedit(void)
{
= int i,i1,i2,done,f;
= char s[81],s1[81],s2[81],ch;
=
= if (!checkpw())
=   return;
= showsubs();
= done=0;
= do {
=   nl();
-   prt(2,get_string(211));
+   prt(2,"Subs: D:elete, I:nsert, M:odify, R:eorder, Q:uit, ? : ");
|   ch=onek("QDIMR?");        /* TB15-422.MOD add R */
=   switch(ch) {
=     case '?':
=       showsubs();
=       break;
=     case 'Q':
=       done=1;
=       break;

/* Add Block (+) */

      case 'R':
        if (num_subs<max_subs) {
          nl();
          prt(2,"Take Sub Number? ");
          input(s,3);
          i1=atoi(s);
          if ((!s[0]) || (i1<0) || (i1>num_subs))
            break;
          nl();
          prt(2,"And Move Before Sub Number? ");
          input(s,3);
          i2=atoi(s);
/*
 *
 *  Note: inserting a sub before sub 0, 32, 64, 92, or etc will toggle on-for-
 *  scanning all the subs in that 32 sub block. For example, moving sub 4
 *  before sub 0 will cause all users to scan subs 0-31. This is not a bug
 *  in my code but rather in Wayne's stock insert_sub (try inserting sub
 *  0 and the same thing will happen). It is minor, but should be fixed for
 *  WWIV v4.23. If you don't care about screwing up the "which subs to scan"
 *  qscan pointer when moving before these subs, remove the (i2%32==0)
 *  condition in the if statement below.
 *
 */
          if ((!s[0]) || (i2<0) || (i2%32==0) || (i2>num_subs) || (i1==i2) ||
(i1+1==i2))
            break;
          nl();
          if (i2<i1)
            i1++;
          write_qscn(usernum,qsc,1);
          insert_sub(i2);
          swap_subs(i1,i2);
          delete_sub(i1);
          showsubs();
        } else {
          nl();
          pl("You must increase the number of subs in INIT.EXE first.");
        }
        break;

/* End Block Add */

=     case 'M':
=       nl();
=       prt(2,get_string(212));
=       input(s,3);
=       i=atoi(s);
=       if ((s[0]!=0) && (i>=0) && (i<num_subs))
=         modify_sub(i);
=       break;
=     case 'I':
=       if (num_subs<max_subs) {
=         nl();
=         prt(2,get_string(213));
=         input(s,3);
=         i=atoi(s);
|         if ((s[0]!=0) && (i>=0) && (i<=num_subs)) {  /* { is TB15-422.MOD */
=           insert_sub(i);
+           modify_sub(i);   /* TB15-422.MOD */
+         }                  /* TB15-422.MOD */
=       }
=       break;

────────────────────────────────────────────────────────────────────────────-
Step 4:  Save SUBEDIT.C and open DIREDIT.C. Block copy swap_dirs()
in before insert_dir(). Uncomment the appropriate lines if you've got
JAFO14.MOD installed, as I do.
────────────────────────────────────────────────────────────────────────────-

/* TB15-422.MOD */
void swap_dirs(int dir1, int dir2)
{
  int i,i1,i2,nu;
  unsigned long *qsc, *qsc_n, tl;
  directoryrec drt;
  // float tf;   /* Only if JAFO14 is installed */

  nu=number_userrecs();
  close_user();

  qsc=(unsigned long *)farmalloc(syscfg.qscn_len);
  if (qsc) {
    for (i=1; i<=nu; i++) {
      read_qscn(i,qsc,1);
      qsc_n=qsc+1;

      if (qsc_n[dir1/32] & (1L<<(dir1%32)))
        i1=1;
      else
        i1=0;
      if (qsc_n[dir2/32] & (1L<<(dir2%32)))
        i2=1;
      else
        i2=0;
      if (i1+i2==1) {         /* One is scanned, the other isn't */
        qsc_n[dir1/32] ^= (1L<<(dir1%32));
        qsc_n[dir2/32] ^= (1L<<(dir2%32));
      }

      write_qscn(i,qsc,1);
    }
    close_qscn();
    farfree(qsc);
  }

  drt=directories[dir1];
  directories[dir1]=directories[dir2];
  directories[dir2]=drt;

  tl=dir_dates[dir1];
  dir_dates[dir1]=dir_dates[dir2];
  dir_dates[dir2]=tl;

  // tf=dir_ratios[dir1];                  /* Only if JAFO14 is installed */
  // dir_ratios[dir1]=dir_ratios[dir2];    /* Only if JAFO14 is installed */
  // dir_ratios[dir2]=tf;                  /* Only if JAFO14 is installed */
  // save_dir_ratios();                    /* Only if JAFO14 is installed */
}


──────────────────────────────────────────────────────────────────────────────
Step 5:   Below, at the end of insert_dir(), comment out modify_dir(n);
──────────────────────────────────────────────────────────────────────────────
=   close_qscn();
=   farfree(qsc);
= }

| // modify_dir(n);    /* Removed TB15-422.MOD */

────────────────────────────────────────────────────────────────────────────-
Step 6:   Below in dlboardedit() make the following changes:
────────────────────────────────────────────────────────────────────────────-
void dlboardedit(void)
{
= int i,i1,i2,done,f;
= char s[81],s1[81],s2[81],ch;
=
= if (!checkpw())
=   return;
= showdirs();
= done=0;
= do {
=   nl();
-   prt(2,get_string(160));
+   prt(2,"Dirs: D:elete, I:nsert, M:odify, R:eorder, Q:uit, ? : ");
|   ch=onek("QDIMR?");        /* TB15-422.MOD add R */
=   switch(ch) {
=     case '?':
=       showdirs();
=       break;
=     case 'Q':
=       done=1;
=       break;

/* Add Block (+) */

      case 'R':
        if (num_dirs<max_dirs) {
          nl();
          prt(2,"Take Dir Number? ");
          input(s,3);
          i1=atoi(s);
          if ((!s[0]) || (i1<0) || (i1>num_dirs))
            break;
          nl();
          prt(2,"And Move Before Dir Number? ");
          input(s,3);
          i2=atoi(s);
/*
 *
 *  Note: inserting a dir before dir 0, 32, 64, 92, or etc will toggle on-for-
 *  scanning all the dirs in that 32 dir block. For example, moving dir 4
 *  before dir 0 will cause all users to scan dirs 0-31. This is not a bug
 *  in my code but rather in Wayne's stock insert_dir (try inserting dir
 *  0 and the same thing will happen). It is minor, but should be fixed for
 *  WWIV v4.23. If you don't care about screwing up the "which dirs to scan"
 *  qscan pointer when moving before these dirs, remove the (i2%32==0)
 *  condition in the if statement below.
 *
 */
          if ((!s[0]) || (i2<0) || (i2%32==0) || (i2>num_dirs) || (i1==i2))
            break;
          nl();
          if (i2<i1)
            i1++;
          write_qscn(usernum,qsc,1);
          insert_dir(i2);
          swap_dirs(i1,i2);
          delete_dir(i1);
          showdirs();
        } else {
          nl();
          pl("You must increase the number of dirs in INIT.EXE first.");
        }
        break;

/* End Block Add */

=     case 'M':
=       nl();
=       prt(2,get_string(161));
=       input(s,3);
=       i=atoi(s);
=       if ((s[0]!=0) && (i>=0) && (i<num_dirs))
=         modify_dir(i);
=       break;
=     case 'I':
=       if (num_dirs<max_dirs) {
=         nl();
=         prt(2,get_string(162));
=         input(s,3);
=         i=atoi(s);
|         if ((s[0]!=0) && (i>=0) && (i<=num_dirs)) {  /* { Add TB15-422.MOD
*/
=           insert_dir(i);
+           modify_dir(i);    /*   Add TB15-422.MOD */
+         }                   /* } Add TB15-422.MOD */
=       }
=       break;

────────────────────────────────────────────────────────────────────────────-
Step 7:   Add swap_subs() and swap_dirs() to FCNS.H:
────────────────────────────────────────────────────────────────────────────-

/* File: diredit.c */

void modify_dir(int n);
void swap_dirs(int dir1, int dir2);  /* TB15-422.MOD */
void insert_dir(int n);
.
.
.
/* File: subedit.c */

void modify_sub(int n);
void swap_subs(int sub1, int sub2);  /* TB15-422.MOD */
void insert_sub(int n);

────────────────────────────────────────────────────────────────────────────-
Step 8:  You're done!  Please email me if you use this mod!

───────────────┬─────────────────────────────────────────────┬───────────────
               │                Type 0 Forum                 │
               │         Edited by Omega Man (1@5282)        │
               └─────────────────────────────────────────────┘


The Type 0 Forum is WWIVnews' "Letters To The Editor" section. Comments,
criticisms, questions, and suggestions can be sent to WWIVnews c/o 1@5282.
WWIVnews reserves the right to edit any submissions for either clarity,
punctuation, or spelling, but will endeavor to maintain the content integrity
as close to that originally submitted as possible.

─────────────────────────────────────────────────────────────────────────────

Dear Editor:

I find it very interesting that you published a letter from Rebel 1 in the
latest WWIVnews!  This guy has *really* gotten on my nerves. I think you
should have pointed out that this guy is *the* Plagiarist Of The Month! He
took my JAFO12 mod (WWIV Time Bank) and changed a line and made it his own.

All he did was remove all the strings and tell people to use his string mod to
put the strings in an external .STR file. Of course, his string mod is just a
TOTAL ripoff of Tolkien and Snorkel's MODSTRIN.MOD.

I did a DIFF of my "void timebank" and his "void jrftime", and not a SINGLE
line was different except for the fact that his didn't have any strings (just
calls to jrf_string).

I posted something nasty on the WWIVnet Mod Sub (Filo moved my post) telling
him if I wanted to distribute my mods without strings I'd do so!


                                                            JAFO (1@8861)

Editor's Reply:

While it's not the policy of WWIVNews to refuse submissions based on any
disagreements between the author and other parties, it is also not the policy
of WWIVNews to point out any reported transgressions, or act in an accusatory
manner in matters such as this. To point out non-sequiturs such as this would
be about as beneficial to WWIVNews as the dismantling of WWIVNet, and would be
about the same as adding an Editor's NOTE before every column telling the
readers what sort of screw-ups the author has committed since last issue.

This, however, is not to say that JAFO's complaints aren't possibly valid.
Those who subscribe to the MODNET subs were witness to the brief debate that
ensued over the accusations of plagiarism. As stated in the last issue of
WWIVNews:

"On the other side of the fence, of course, is the issue of proper accredation
of source material. Nobody likes to see someone else get credit for hard work
they didn't perform, and the same goes triple for programmers. As a result, at
least twice a month there can be heard the cries of "PLAGIARISM!!" on the
Modnet Discussion sub - usually over someone's total duplication of a
sublist(void) or dirlist(void) replacement - and brief flames erupt until Filo
steps in to put them out."

Sure enough, this observation was proven at least twice since this self-quote
first saw print.

Again, plagiarism of modifications - or any other work, for that matter -
isn't part of any proper code of ethical conduct. However, as there are no
WWIVNet guidelines covering such actions, accusations pertaining to such
should be conducted in a civil manner in whatever forum the participants
choose for their discussions on the matter.


Dear Editor:

For the nearly eight years I have been running the WWIV software there hasn't
been a change to the manner in which Wayne Bell (the software author) chose to
list messages on the BBS area, commonly called a "message base," "message
sub," a "public message area," or any variety of other names. This format for
reading public messages displays the title, author, date and time of the
writing, BBS origin (included recently), and sometimes a line indicating it is
"with regards" to another when it is in reply to previous message (also called
a "post"). Another important feature of reading messages includes a feature
whereby a user may scan only the titles of all the "posts".

The scan feature is very useful to sysops and users reading numerous message
areas that contain large numbers of messages, or to many sysops who carry (or
host) an overabundance of message areas and wish to spend as little time as
possible browsing through messages, while still being able to get the most out
of them, as do their users. Enter the infamous Random Title.

This is an example of an actual random title (which was posted in the #1
Sysops nationally networked message base):


Title: RE: Re: The Bermuda Triangle is a strange place  [Random Title]


The above title had nothing to do with the content of its attached message,
and therefore acts as a red herring serving only to conceal the true intent of
the message, whether this result was intentional or not. Moreover, random
titles are usually selected at random from a list of dissimilar titles, and
this process inherently has an infinitesimal chance of correlating to a
message, inevitably having absolutely nothing in connection with the contents
of a message. Randomness may lead to chaos, and it almost certainly
precipitates confusion. The turmoil may increase logarithmically as other
sysops or users respond to messages using random titles, further saturating
the message base with a plethora of post-titles that make no sense and have no
relation to the contents of the messages contained within.

Doctors tell us that humans learn very quickly through conditioned response.
This is the concept demonstrated by the following example: A person may have
an adverse reaction to eating a certain type of food. After finding which food
is responsible, the person will be conditioned to remember the effects and not
eat that food. An analogous situation: Many sysops and users are looking for
answers to questions they have asked in the different forums. After scanning
the message titles for an answer to his earlier post, a sysop or user
encounters a few pertinent messages, but with cryptic titles, and many more
irrelevant message with confusing titles. The unconventional titles often
contain the words "Random Title" in them, or they are only a bit of
punctuation, such as the infamous ellipsis (...), exclamation points (!!!), or
a single word, "Yeah," "No!" "Whatever," or a few words that still don't imply
meaning: "I don't agree," "WWIVCon," "What I said was..." "Etc., etc." "Help
me," "My answer:" and the list continues. After reading many of these
messages, finding them useless, the sysop or user develops a conditioned
response to skip over them.

The worst part about this situation: What happens when message has a random
title, but contains the exact information the sysop or user is looking for,
and is skipped because its title implies no relation to its content?  One
potential result is that the person asking the question repeats it in a second
or third message, and then is either ignored or criticized for repeating the
message & not seeing the original answer. The ensuing messages then clutter up
any topics that are current in the forum. There are other less and more
catastrophic effects that for space considerations of this article I must
leave out. The main point of this example is that important information may be
overlooked.

While some of the above title examples may appear acceptable, none of them
properly imply the what might be the primary content of a message. "Help me,"
for example, could specify what kind of help is required, or what the problem
is, all in the title area. "I don't agree," could also indicate with what and
whom there is not an agreement. Wayne Bell, the author of WWIV, left the
potential length of message titles long to enable sysops and users to be
specific with respect to what help or information they're looking for, not so
that they could be lazy and ignore them, leaving their messages unsupported.

Try to make your titles suggest what the message is going to say. Otherwise,
if you have something important to scan, a lot of people are going to scan
right past it. If someone is scanning through many messages per day, they want
to skip the messages that don't apply to them, and the messages with random or
meaningless titles are the easiest way to make them do that.

A good rule of thumb is to make the titles of your messages describe what your
entire message is about, presenting as much information as possible in the
limited space given. Many people are more likely to read, "How to make
$35/user per yr by charging for XXX .GL d/l's," rather than "Making money..."
or "Check this out!" or "A wrinkle in time is a disastrous thing [Random
Title]."

BBS's are an incredible force for spreading and obtaining information. Used
correctly and proficiently one can reap enormous benefits from them; used with
insouciance or indifference they degenerate into a confused, banal and fatuous
collection of expensive wastes of modems, telephone lines, and computers.

                                                       Number One (1@6951)


Editor's Reply:

Number One's comments speak essentially speak for themselves. The use of
Random or non-related titles on networked subs - especially high-volume ones -
 can render unto one's posts a bit of camouflage that will cause "title
scanners" to skip over them, totally oblivious to the content of the post.

Granted, those in support of the use of this style of titling argue vehemently
that scanning titles is a sign of laziness, and that if one is not going to
read every post on a sub then that person has no business having access to the
sub in the first place.

Problem with this argument is twofold:

First, on a high-volume sub - one that has over 100 posts a day - reading
every single post can take more time than most people with lives have to spend
reading messages. This is especially applicable on politically oriented subs
as the WWIV World-Wide Link and the Political Incorrectness Net, as well as
other subs such as the #1's Only Sub, the IBM Information Net and 1@1's Star
Trek Sub(*). As a result, people with limited time frames must resort to title
scanning in order to keep up as best as possible with the topics of discussion
for the sub in question.

(*) This is applicable primarily during the start of a new season :-)

In other words, its not a matter of laziness, it's a matter of lack of free
time.

Secondly, there's a bit of double-standardization in action here. By refusing
to take the time to give each post a distinct, descriptive title, those who
rely on Random or non-related titles are themselves the ones being lazy.

Now, once upon a time, back in the days before Eight-Ball went off to college,
there was a particularly active poster who insisted on giving every message
posted on the high-volume subs that person frequented a nondescript, macro-
defined title, regardless of the content of the post.

That simple title was "Hi!", and it drove every "title scanner" on those subs
crazy - especially when there were 30-40 posts in a row with that title!

While quite a number of these posts contained serious, intelligent
commentaries, most of them were ignored by the majority of readers because
most of them were "title scanners". The rare times this person's comments were
noticed occurred when someone who wasn't just a "title scanner" quoted
something from one of this person's posts.

When confronted about the nondescript title, the person in question gave two
excuses that attempted to transfer the blame upon the "title scanners". The
first argument was paraphrased earlier. The second one, however, went
something like this:

"I use 'Hi!' as a friendly title for every post. Those who wish to be friendly
should be attracted by this title, and read my post without any concern
beforehand of the content!"

This argument, needless to say, was so full of...well, full of *something*
that it provided perfect cannon fodder not only for the majority of the sub's
more prolific character assassins, but for those in the novice category as
well. In the end, while the poster in question wasn't essentially repentant
after his/her/its public flambe', of the posts originating from that account
a significant portion were _not_ simply titled "Hi!"

Situations like this are also prime arguments for those who wish to see some
sort of WWIVNet ban on Random Titles. However, like taglines, Random Titles
can serve a useful purpose so long as they're used properly. If one is going
to implement a mod to allow for Random Titles, one should also implement a
version of the mod that allows this feature to be turned off for networked
subs whose high traffic flow would cause such posts to be a waste of time and
network resources.

A title is essentially an advertisement for your post. Posters need to
acknowledge the fact that using descriptive titles will enhance their chances
of their posts being read on a high-volume sub. When one is either seeking or
giving information, such efforts are only as good as the methods used to
attract the attention of the target audience. If you need information, and you
don't use a title reflective of this fact, then you have nobody but yourself
to blame for the lack of response you'll receive.


───────────────┬─────────────────────────────────────────────┬───────────────
               │        WWIV-Compatible Networks List        │
               │            (July Final Edition)             │
               │            37 Networks Included             │
               │            by Red Dwarf (1@6264)            │
               └─────────────────────────────────────────────┘

The following information is compiled as a service to BBS operators and has
not been verified for accuracy. Attempts are made to keep the material current
and usable. If you are aware of changes that should be made, such as additions
or deletions, please send them to me in E-Mail.

Information for this listing should only be submitted by the contact person
for each network. You should also inform me of any changes to be made. Please
specify which field the changes affect.

This edition contains new entries or updates for:  SigNet, USLink, IceLink,
DarkNET, SCAnet, InfiNet, ACiDNet, NOVAnet, LeeNet, TerraNet, CARDnet,
SOLARnet, ROCKnet, APEX, Alternetive, Znet, ROPEnet, CHAOSnet, RADSnet,
ADULTNet.

─────────────────────────────────────────────────────────────────────────────
Abyssal Net [General] (80) (5-1-93)
IceNET @8399
Matrix - 908-905-6691
Handles, No Application, No
Roleplaying and Cyberpunk are hot topics.
─────────────────────────────────────────────────────────────────────────────
Acidnet [General] (17) (6-8-93)
WWIVnet @5876, IceNET @5850
Florida Keys - 518-587-0317
Handles, Application, Yes
Growing all the time!  Friendly NC and network staff.
─────────────────────────────────────────────────────────────────────────────
Advent [General] (34) (5-8-93)
WWIVnet @8318
The WILD Side! - 803-788-7469
Handles, No Application, Yes
--Originally started in Aug 90, the net has grown to cover 3 states.
--Has automatic update software, and a dedicated 16.8k hst server
─────────────────────────────────────────────────────────────────────────────
ADULT Net (WWIV Based) [Specific] (1) (6-16-93)
No network connections.
The Funny Pages - 612-888-2080
Handles, No Application, Yes
Adult national discussion of Swinging/Dating/Alternative Lifestyles
Sexual positions/items/toys and stories ALL of ADULT nature.
─────────────────────────────────────────────────────────────────────────────
Alternetive [General] (19) (6-11-93)
WWIVLink @14062
The City Morgue - 410-666-1035
Handles, No Application, Yes
Just a group of laid back people looking to have fun and enjoy
ourselves. A must have for the modern sysop.
─────────────────────────────────────────────────────────────────────────────
APEX
WWIVnet @13600, IceNET @3600, WWIVLink @13600
Purgatory BBS - 306-665-0274
Handles, Application, Yes
-Created in March 1992. It was based on creative writing and RPG
-networking. General Subs Available.
─────────────────────────────────────────────────────────────────────────────
CaffNet
WWIVnet @3101
Star-Lit BBS - 301-229-2957
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────
CARDNet [General] (6) (6-5-93)
IceNET @5077, WWIVLink @15062
? - 510-458-4370,,222222
Handles, No Application, Yes
Cardnet - Chaotic, Random, Deviants Network. The name says it all.
Welcoming members from all areas. Join today!
─────────────────────────────────────────────────────────────────────────────
CHAOSnet [General] (30) (6-12-93)
WWIVnet @9404, IceNET @9402, WWIVLink @19402
Data*West BBS - 904-259-8951
Handles, No Application, Yes
One of the quickest growing national networks with network servers,
automated updates, and the most helpful sysops in any network.
─────────────────────────────────────────────────────────────────────────────
Chess_Net [Specific] (5) (4-4-93)
WWIVnet @5915
The Duke of Earl - 509-291-3760
Handles, No Application, No
Dedicated to the philosophy of chess.
─────────────────────────────────────────────────────────────────────────────
C/NET
WWIVnet @6956, IceNET @6956
Cold Fusion - 619-434-1482
Handles, Application, Yes
─────────────────────────────────────────────────────────────────────────────
DarkNET
IceNET @5805, WWIVnet @5811
Storm Blade - 508-368-7971
Handles, Application, Yes
─────────────────────────────────────────────────────────────────────────────
DeathNet [] () ()
WWIVnet @19982
─────────────────────────────────────────────────────────────────────────────
DEEPnet
WWIVnet @7405, IceNET @7405, WWIVLink @17405
Deep Space 8 - 704-553-0780
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
DragNET
WWIVnet @2936, IceNET @2913
Toon Town - 209-323-9412
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────
DragonNET
WWIVnet @7670
Cool World - 716-681-7341
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────
DragonsNet [Specific] () ()
WWIVnet @6263
Unlimited Enterprises - 612-871-7625
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
EliteNET [General] (29) (2-17-93)
IceNET @2462
Alley Closed BBS - 214-238-8121
Handles, Application, Yes
"The No-Nonsense Network"  Totally democratic network using all
members' opinions and votes. Close and friendly network.
─────────────────────────────────────────────────────────────────────────────
ExpressNET
WWIVnet @6754
Data Express - 617-247-3383
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
EagleNet [General] (12) (2-18-93)
IceNET @7676
Berek's Homeland - 716-826-4698
Handles, No Application, No
EagleNet was set up so that users and sysops could order things that
they use everyday and have it sent to their doorstep.
─────────────────────────────────────────────────────────────────────────────
FIITAnet
WWIVnet @9957
Baxter BBS - 919-878-0054
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────
FILEnet [] () (1-28-93)
WWIVnet @8412 - Inquire at @1052
Pocket Universe - 803-552-8654
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
FUNnet (10) (6-1-93)
WWIVnet @3302, IceNET @3302
? - 303-751-7236
Handles, No Application, Yes
Great subs we are small but the quality of boards is good.
─────────────────────────────────────────────────────────────────────────────
GayNet [Specific] (28) (2-1-93)
WWIVnet @15283, WWIVLink @25283
Handles, Application, Yes
Alternate Lifestyles- don't have to be gay, lesbian, or bi to join. No gay
bashing allowed.
─────────────────────────────────────────────────────────────────────────────
IceLink [General] (6) (5-1-93)
WWWIVnet @5213, IceNET @5213, WWIVLink @5213
Handles, No Application, Yes
General discussions, RPGs, Freedom of Speech, etc... Your everyday
Cool Net
─────────────────────────────────────────────────────────────────────────────
IceNET [General] (737) (4-29-93)
IceNET @1, WWIVnet @7663, WWIVLink @17652
The Great White North - 716-837-0044
Handles, Application, Yes
Full featured network, fast updates, hundreds of message bases to choose
from. A friendly place to be. Highly rated, one of the best.
─────────────────────────────────────────────────────────────────────────────
InfiNet [Specific]
WWIVnet @5335
The Dead Beat Club - 503-233-9168
Handles, Application, Yes
An exclusively West Coast network (CA, OR, & WA). We specialize in
regional topics and making the the local BBS scene better.
─────────────────────────────────────────────────────────────────────────────
InsanityNet
WWIVnet @8355, IceNET @8385
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
LeeNet [General] (?) (6-9-93)
WWIVnet @15269, IceNET @15269, WWIVLink @15269
Secret City BBS - 512-592-8054
Handles, No Application, Yes
Newest net on the market. Hoping to grow with the help of people who will
give it a chance. Discussion is casual.
─────────────────────────────────────────────────────────────────────────────
M.A.G.Net [General] (10) (4-29-93)
WWIVnet @7107
Psycho BBS - 701-780-9168
Handles, No Application, Yes
M.A.G.Net was created to give newer BBSes a way to share information
with other BBSes and help them in getting their BBS going.
─────────────────────────────────────────────────────────────────────────────
NorthStarNET [General] (25) (6-5-93)
WWIVnet @6259, IceNET @6259, WWIVLink @16259
AeroTech BBS - 612-935-3505
Handles, Application, Yes
25 nodes in many states. 50+ subs, most active and not gated. Wide range
of sysops and users, friendly environment.
─────────────────────────────────────────────────────────────────────────────
NOVAnet [Specific] (1) (4-2-93)
IceNET @2351
The InfoLink Cosmos - 213-294-5387
Handles, No Application, Yes
Official TurboPros Support Network. We are a Stories/Ansi/Programming
group which use NOVAnet distribution purposes as well as free speech.
─────────────────────────────────────────────────────────────────────────────
NukeNet
WWIVLink @14063
The White House - 410-760-0712
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────
OgdenNet [General] (6) (3-2-93)
WWIVnet @8135, IceNET @8135
The Sandbox ][ - 801-774-5574
Handles, No Application, No
Local chit-chat, DHS (local computer group).
─────────────────────────────────────────────────────────────────────────────
RADSnet [General] (11) (6-17-93)
WWIVnet @2660, IceNET @2660
R.A.D.S. Y-Town BBS - 216-743-4215
Handles, No Appplication, Yes
RADSnet is a small, yet fast growing network which has spread to 5
states. We offer fast data communication and a lot of SysOp support.
─────────────────────────────────────────────────────────────────────────────
ROCKnet [Specific] (52) (6-1-93)
WWIVnet @15463, IceNET @5463, WWIVLink @15463
Strato's Guitar Shop - 514-683-6978
Handles, Application, Yes
ROCKnet is the specific WWIV based network DEVOTED to music and
entertainment.
─────────────────────────────────────────────────────────────────────────────
ROPEnet [?] (14) (6-12-93)
WWIVnet @9964, IceNET @9970
The Republic of Profane Existence - 919-756-2116
Handles, No Application, Yes
Wide variety of subs, fast updates, good conversations, and a lot
messing around. Easy going, free for all. Growing rapidly.
─────────────────────────────────────────────────────────────────────────────
SCAnet [Specific] (19) (5-4-93)
IceNET @2466
? - 214-361-8541
Handles, No Application, No
SCAnet is dedicated to supporting the Society for Creative
Anachronism through the exchange of ideas and information.
─────────────────────────────────────────────────────────────────────────────
SigNet [General] (3) (5-3-93)
WWIVnet @8433, IceNET @8400
Collage - 804-766-3192
Handles, Application, No
This network is growing not only in the WWIV community, but also
in other areas. Fido compatible boards are linking up now!
─────────────────────────────────────────────────────────────────────────────
SnotLink [Specific] (8) (4-4-93)
WWIVLink @18262
Insomnia - 812-466-4222
Handles, No Application, Yes
For Terre Haute region BBSs ONLY. A true local network with
a slant towards the silly!
─────────────────────────────────────────────────────────────────────────────
SOLARnet [General] (216) (6-12-93)
IceNET @3454, WWIVnet @3484, WWIVLink @13495
Rap City [GSA] - 314-963-7960
Handles, Application, Yes
SOLARnet is another one of your general discussion networks. We
offer over 200 subs, on a variety of topics.
─────────────────────────────────────────────────────────────────────────────
StarLink [General] (10) (5-30-93)
WWIVnet @5208, IceNET @5201
? - 502-877-2573
Handles, No Application, Yes
-NET dedicated to contact between boards & encouragement of positive
-BBS habits; No UUE's without consent of all connects, multi-SUBS.
─────────────────────────────────────────────────────────────────────────────
StarNet [Specific] (4) (5-5-93)
WWIVnet @3956, IceNET @3956
Diamond's BBS - 319-277-0166
Handles, No Application, Yes
Local network of teenage boards to facilitate the transfer of files and
e-mail, to take the load off of the local WWIVnet/IceNET server.
─────────────────────────────────────────────────────────────────────────────
SuperNET
IceNET @3402
The Empire - 304-465-5223
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
TARDISNet (43) (6-9-93)
WWIVnet @2925, IceNET @2925, WWIVLink @22925
The Gallifreyan Matrix BBS - 209-571-0513
Handles, No Application, Yes
For science fiction, current events, and political subs.
─────────────────────────────────────────────────────────────────────────────
TeenNet [General] (21) (4-5-93)
WWIVnet @4075, IceNET @4053, WWIVLink @14064
Central Station - 410-315-9854
Handles, Application, No
TeenNet is made so that all younger sysops in the world can get
a chance at networking. The network is open to all people.
─────────────────────────────────────────────────────────────────────────────
TekNet
IceNET @2459
Canisius College BBS - 716-888-2600
─────────────────────────────────────────────────────────────────────────────
TerraNET [General] (86) (6-11-93)
WWIVnet @8861, IceNET @8857, WWIVLink @18857
Blue Thunder - 818-848-4101
Handles, Application, Yes
National general purpose network. Friendly atmosphere, 140+ subs,
fast automatic updates. Have lots of fun.
─────────────────────────────────────────────────────────────────────────────
TestNet
WWIVnet @19960, IceNET @9994
Test Site BBS - 919-760-4811
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
TLCnet [] () (1-28-93)
WWIVnet @8412, Inquire at @1052
Pocket Universe - 803-552-8654
Handles, No Application, Yes
─────────────────────────────────────────────────────────────────────────────
USLink [General] (25) (4-30-93)
WWIVnet @8854, WWIVLink @18867
ModeMANIA - 818-451-0936
Handles, Application, Yes
Small but expanding network currently covering So. California.
Well-run and frequently updated. Active and involved NC.
─────────────────────────────────────────────────────────────────────────────
WEB [General] (10) (2-13-93)
IceNET @5802, WWIVnet @5813
Sanctuary - 508-892-8529
Handles, Application, Yes
─────────────────────────────────────────────────────────────────────────────
WWIVnet [General] (1400) (1-24-93)
WWIVnet @1
Amber - 310-798-9993
Handles, Application, Yes
─────────────────────────────────────────────────────────────────────────────
ZNET [General] (20) (4-1-93)
No other connections.
The Ethereal Plane - 609-435-5991
Handles, No Application, No
ZNET was designed in 1990 as an alternative for WWIVnet. We are
looking for BBSes in other area codes for area coordinator positions.
─────────────────────────────────────────────────────────────────────────────
Znet [General] (20) (6-13-93)
WWIVnet @5901
The Electronic Asylum - 509-325-6903
Handles, No Application, Yes
Small but growing netowrk started in 1989, to lessen network politics.
─────────────────────────────────────────────────────────────────────────────
*.Net
IceNET @2459, WWIVLink @16976
Reynard's Keep - 214-406-1264
Handles, No Application, No
─────────────────────────────────────────────────────────────────────────────

Network Entry Format:

Name [Content] (Nodes) (Date)
Primary Netaddress, Other Address, ...
Hosting BBS - Phone Number
Description Line One
Description Line Two
Handles, Application, Updates

Name         │ Network's Name
Nodes, Date  │ Number of nodes on <date>
Hosting BBS, │ You may wish to call here for network support
Phone Number    and/or setup files.
Desription   │ Sent to me by the network coordinator
Handles      │ 'Handles' will appear if this net allows aliases, 'Real Names'
                will appear if aliases are not allowed.
Application  │ Is this network's application in the master application file?
Updates      │ Does this network use automated update software?
─────────────────────────────────────────────────────────────────────────────

To submit an entry, use the following application as follows:

Send application to Red Dwarf:

1@6264  WWIVnet
1@6256  IceNET
ICENET 1 AT 6256 @16259 (WWIVLink)

The File Pile                                               [phone]
2400 Baud                                                  Netlist Account

To use netlist account:

Download the NETWORKS.LST and net applications file with the "NETLIST"
account. Password is "NETLIST" and last four digits are "0000"

Sorry, but uploads and updates from this account cannot be accepted.

═══════════════════════════════════════════════════════════════════════════

Network coordinators are responsible for checking their network's information
and reporting any errors or incomplete entries to me.

If you do not see this after your network: [gen/spec] (nodes) (date) (with
information in all of them), please send an application so you can have the
new information in it. Please indicate that this is an update after the
network's name. Thank you.

When submitting your networks application, please use the form below. If this
is an update, please indicate which fields are changed.

╔═══════════════════════════════════════════════════════════════════════╗
║                   NETWORKS.LST Update/New Entry                       ║
║                                                                       ║
║Is this an update?                                                     ║
║  Network Name   :                                                     ║
║  Contact Person Information :                                         ║
║     a) BBS Data Phone Number :                                        ║
║        BBS System Name       :                                        ║
║     b) Primary contact point: WWIVnet, WWIVlink, IceNET: _________    ║
║        Select ONLY ONE above as primary contact point.                ║
║                                                                       ║
║        Answer all that apply:                                         ║
║        WWIVnet Node  :_____________________                           ║
║        WWIVlink Node :_____________________                           ║
║        IceNET Node   :_____________________                           ║
║     c) Do you allow handles in the network:                           ║
║  Net Type (General or Specific, chose one):                           ║
║  If specific, identify topic specialty below (two lines maximum)      ║
║  If general, give a brief network description (two lines maximum)     ║
║                                                                       ║
║                                                                       ║
║  Do you have automatic update software?                               ║
║  If you wish, you also may send me an application for the master file.║
║  Date and Number of Nodes :                                           ║
╚═══════════════════════════════════════════════════════════════════════╝

───────────────┬─────────────────────────────────────────────┬───────────────
               │                 TechNOTES                   │
               │       Compiled by the WWIVNews Staff        │
               └─────────────────────────────────────────────┘

...From the Poison Pen department: The Clintons have become the first couple
in the White House to have an E-Mail address. Those wishing to tell President
Clinton just exactly what's on their mind can now do so from either MCI Mail
or from one of several online services, such as Compu$erve and America Online.
The Clinton administration has even appointed Jock Gill as "Director of
Electronic Publishing and Public Access E-Mail" to help the mail go where its
supposed to go.

...There's a catch to all this, tho: All E-Mail is screened for topicality,
and used to compile a sort of "topics digest" which assists the President in
keeping abreast of what topics are of concern to most Americans. As a result,
Odds are Mr. Limbaugh's favorite Arkie won't see your E-Mail unless it's in
regards to something that catches the eye of one of Jock Gill's assistants.

....As it stands now, the best anyone can truly hope for is to get a return
letter of receipt as proof that your letter was received by someone at the
White House. Still, it's more direct access to the person with the finger on
*the* button(s) than this nation's had since General Washington was drafted
into being something other than a king.

...MCI Mail users can reach the Oval Office by typing "White House" in the
TO: prompt. Those with money to blow can access the White House from CI$
using "GO WHITEHOUSE", while those who prefer to use their money in the most
efficient manner by subscribing to America Online can access this area of
service using the keyword "white house". Prodigy is expected to offer this
service sometime in the fall, although initial reports is that access will
be offered as a premium - read: "Overtly Overcharged" - service.

...Anyone seen the new Microsoft Mouse 2.0? Contrary to popular belief, this
is NOT a "right-handed" mouse as the design would imply. Tests conducted by
one lefty WWIVNews staffer prove that the ergonomic design works just as
well for left-handed users as it does for those using the "normal" hand.

...as if that's not enough to convince people to switch to this version, the
ball mechanism's been reworked so as to all but eliminate the need for a
mouse pad! While this won't interest those who prefer to run their mice over
Cindy Crawford's...er...face, it will be of interest to those who don't have
room for a mouse pad to begin with.

...Finally, the drivers have been reworked to allow for the control of pointer
size, color, and screen wrap. For a $109 MSRP - and a street price of around
$85 - not buying a true Microsoft Mouse has become a really tough decision
to justify.

...From the Internet Junkies department: Got 15Mb of HD space to spare? How
about 30 minutes? If you do, then log onto the Internet and locate the latest
episode of "Geek of the Week", a digitized "radio talk show" sponsored by
Sun Microsystems' Internet Talk Radio experiment.

..."GOTW" is distributed to Internet sites on a weekly basis, and readers
are available for a wide range of platforms. Unlike a normal radio broadcast,
a show in this format can be fast-forwarded or rewound, and no doubt any
really poignant quotations or musical "stings" will find their way into the
.WAV libraries within no time.

...To find out more about Internet Talk Radio, contact your local Internet
admin. If they don't carry the program, ask them to do so, or ask them to
help you locate another nearby site that does.

...From the obituary department: Rest In Peace wishes go to CompuAdd's 110
retail outlets. With only a couple of exceptions, these outlets managed to
keep themselves staffed with salesmen who had at least some intelligence
level above that of a pet rock. Although the company itself is still alive
and kicking - under protection of Chapter 11, no less - the retail outlets
fell victim when the company simply couldn't adapt to today's changing market.

...This, for some, meant that CompuAdd's Bill Hayden simply couldn't bring
himself to play the sort of corporate dirty pool that Michael Dell made
popular among the computer manufacturers. Ergo, CompuAdd couldn't make their
systems cheap enough to beat Dell's prices, and Hayden wouldn't screw his
customers over with chintzy merchandise. However, considering that Dell's own
problems have come to light with regards to company efficiency and system
reliability, one should not be surprised if CompuAdd put on a Phoenix suit
and dragged itself up out of not only its own ashes, but Dell's as well.

...So, for now, raise your glass and give a moment of silence for CompuAdd's
departed retail outlets. Then go visit their Back Dock Shop and pick up a few
bargains while they last!

...And if you think that these claims about Dell's stability are bogus, keep
in mind that in light of a $70 million loss in 1st Quarter '93, they've
renegotiated every line of credit they have to their name in order to satisfy
their creditors. Dell stock has remained in the $20/share bracket since last
Spring's controversial stockholder's report and the preceeding dismantling of
Dell's notebook division. These events sparked a class action suit against
Michael Dell by stockholders, claiming that Dell withheld information on
decisions that would have influenced - and probably neutered - a major stock
selloff last February.

...An aside NOTE: while toasts aren't in order here, it should be noted that
Gecko Computers and Everex Inc. have both gone under in recent months. Those
who have ordered products from either of these companies and haven't received
them yet should contact your local Better Business Bureau to see what sort of
actions are available for you to take.

...Sharp Electronics has announced plans to introduce a flat-panel LCD color
display for desktops by next fall. The 2" thick screen measures 10.4"
diagonally, and is VGA compatible with 640x480 resolution. Two different
versions are expected to ship, one for $5995 MSRP that handles up to 4000
colors, another for $7995 that will handle 16 million colors.

...While this may seem pricey for most people, monitors of this nature will
eventually become the standard in light of concerns over EMF effects and the
general push towards energy efficient machines under the government's new
"Energy Star" program. As demand rises, prices are expected to gradually
drop, but LCD technology is an expensive proposition even with today's
production technologies.

...Over on the gas plasma side of the fence, NEC and Fujitsu are also working
on reducing the costs of plasma screens to make them more competitive with LCD
displays. As it stands now, the largest commercially affordable full-color
plasma displays are less than 10" wide diagonally, with anything larger - say,
14 to 15" - existing only in prototypes with costs in the *six* digit range.

...Fujitsu has announced an 11-pound 21" screen for release by next spring's
COMDEX. The cost of the monitor hasn't been announced, but insiders at Fujitsu
hint at a production "breakthrough" that has reduced costs roughly 20% below
that reduced by existing technologies. Initial price is still expected to be
steep when compared to LCD monitors, but the cheaper production methods are
expected to help reduce cost of smaller monitors in the 14-15" range.

...At the same time, NEC has presented papers on a new method of pixilation
for gas plasma screens using hexagonal elements that promises to reduce costs
even further. NEC's prototype is reportedly crude resolution-wise by today's
standards - barely 320x480 - but the proof-of-technology was sufficient enough
for NEC to start work on a 35" version with 640x480 resolution.

...From the SPA Groupies Department: The recent busts of DOS pirates have
netted not only quite a few arrests, but a humorous note as well. Seems that
a large number of the manuals copied were not only OCR'd from the originals,
but that the spell checking after the scanning wasn't too terribly accurate.
As a result, there were a lot of copies of MD-DOS floating around that looked
like MS-DOS!

...While this should not be confused with an OD..er..OS for physicians,
WWIVNews' resident DOS collector suggests that if you have a copy of this
particular knockoff, keep it. The next big thing in the collector's market is
expected to be obsolete computer systems, peripherals and software. Obscure
and infamous bootlegs will no doubt gather top dollar at trade shows,
especially when the majority of copies will have been used for kindling at the
SPA's family cookouts!

...GeoWorks enthusiasts take NOTE: the arrival of the Personal Desktop
Assistant just might be the kick in the pants this particular GUI needed, and
Tandy appears to be wearing the boots. In a joint venture with Casio, Tandy
will produce the "Zoomer", a 16-bit PDA that uses a version of GeoWorks for
its operating environment. Estimated MSRP for the Zoomer is around $750,
although rumors abound of a $500 introductory price to get the unit off the
ground.

...While the Zoomer was presented at the same time as Apple's "Newton" last
March at the Consumer Electronics Show, some industry experts have professed
to liking the look and feel of Tandy's entry into the PDA arena over that of
Apple's more publicized offering. Already, several companies have offered to
produce apps for the Zoomer for use under the GeoWorks environment, including
Intuit, Palm Computing, and America Online.

...From the Pyramid Scam department: word on the street is that infomercial
huckster Tony Robbins has discovered the CD-ROM market, and is releasing his
own Hypertext-based version of his _Personal Growth_ series of
self-improvement books. Two of Robbins' books have already been introduced
into CD-ROM format with last winter's inclusion in ZCI's Multimedia Powertalk
CD.

...Speaking of ZCI, look for a Hypertext version of the life of JFK, including
the entire Warren Commission report. Other releases will include CD's
dedicated to the Vietnam War, Malcolm X, and Martin Luther King. Prices are
expected to range between $19.95 and $39.95.

...From the Caveat Emptor department: DeskJet 500 owners should pay heed to
the following safety tips. While the printers are as above 24-pin dot-matrix
printers as 24-pins were above 9-pin printers, there's a couple of problems
that have surfaced that weren't apparent when the units first hit the market.

...First off, there's the issue regarding the type of paper used. While HP
recommends that you use their particular - and particularly expensive - brand
of paper, using your typical el-cheapo copier paper will work just as well,
and will actually be less prone to smearing. The reason for this is a
microfine talcum powder that's sprayed on copier paper to - theoretically -
keep the pages from jamming the machine. While this talc bonds the DeskJet ink
to the paper quicker, HP has acknowledged that the print nozzles can get
jammed over a period of time. However, the amount of talc required to jam the
printhead is not enough to generally affect the regular size cartridges.

...As a result, those who do a LOT of graphics work with a LOT of black areas
and use cheap paper should avoid using the extended cartridges for this
purpose. Without proper care, the nozzles can become clogged beyond salvage
long before the cartridge has run out of ink!

...Secondly, it's advised that DJ users avoid those "accordion hypo-bottle"
refills like the plague. Our own WWIVNews editor has personally verified
claims regarding certain problems with the refills, and also has an expensive
white dress shirt with DJ ink splotches all over the front as proof that the
refills do indeed damage the cartridge beyond repair if used as directed.

...While the WWIVNews staff prefers the HP DeskJet over dot-matrix printers
any day, owners and potential owners are advised to take care when attempting
to squeeze more bang for the buck into this line of printers. While doing so
isn't the same as squeezing blood from a turnip, the DeskJets are still
economical enough to operate that only someone on a really tight - read:
welfare - budget should consider implementing these severe cost-cutting
measures.

...Tired of playing "interrupt roulette" with your peripherals? Microsoft and
Intel have finally gotten tired of hearing you bitch about it. Later this
year, expect to see the first prototypes of a new ISA bus specification that
will finally make adapters and peripheral cards truly "plug and play".

...The new spec involves adding a set of PROMs to each adapter containing a
unique ID number for each adapter. Upon bootup, each card would arbitrate
interrupts, I/O ports, DMA channels, and any memory conflicts. Depending on
the results, the cards would then load device drivers into memory if
necessary, or would prompt the user as to what drivers and/or switches were
required. Cards using this new spec would remap themselves around existing old
spec cards, and would automatically remap each time a peripheral was added or
subtracted from the system configuration.

...Although the final spec isn't due out until September, several dozen
peripheral manufacturers have expressed interest, and several already have
working prototypes based on the initial proposed spec. The first boards for
commercial sale aren't expected out until early '94, but industry insiders
report that Hayes is ready for the new bus spec, and will be the first on the
market with a "plug & play" v.FAST modem.

...Meanwhile, over in the SCSI part of town, Corel and NCR have been bedding
together to develop a new chip set that will allow system board manufacturers
to mount a bus-mastered SCSI controller directly on future motherboards. While
there as yet have been no announcements of such, Corel expects the first ones
to appear late this winter, about the same time the "plug and play" version of
the CorelSCSI adapter is officially announced.

...From the "Ooops! You misunderstood us!" department: Microsoft shipped the
v1.1 upgrade for Access earlier this month, and priced it at a seriously
economical MSRP of $19.95 with proof of purchase of v1.0. This happened
despite initial claims that users who bought the initial release at the
introductory MSRP of $99 would not be eligible for upgrades of any sort.

...Calls to Microsoft's direct sales lines have gathered only a "that was a
misunderstanding and/or a misquote" from sales reps, and while no one was
willing to explain what the source of the "misquote" was, the probable source
was a comment made by Bill Gates in a memo regarding the release of Access
1.0, and his explanation for the low introductory price. The memo in question
reportedly was misworded so as to give purchasers the impression that the MSRP
jump to $495 after the promotional deadline would apply not only to copies of
Access bought after that date, but to any future upgrades.

...In any case, after nearly 8 months after its release, there's still a large
supply of Access 1.0 floating around at the introductory price. Microsoft has
allowed retailers to continue selling existing copies at the promotional
price, and some software chains have been bundling both the intro version and
the upgrade for as low as $115, offering to handle the registration paperwork
for the customer.

...Still pent up about whether to buy the Pentium? Insiders at Borland and
Microsoft both claim that while programs specifically compiled for the renamed
80586 or "P5" will run up to 40% faster than versions compiled on a 486, those
same Pentium-optimized programs will still run 10-15% faster on those 486's.
This is the result of the Pentium's dual integer-execution units and the need
for compilers to optimize compiled code to take advantage of dual piping. A
program compiled for the Pentium is already optimized to reduce the number of
interdependent instruction sets that would otherwise eat clock cycles and slow
down the application. When run on a 486 - whose pipeline functions best when
resource-dependency is at a minimum - there is a performance boost.

...Although older processors - the 386 included - lack a comparable pipeline,
several major software developers have announced plans to compile future
releases of their products on Pentium-based machines so as to allow 486 users
to gain the additional boost in performance.

...DEC, meanwhile has announced a second-source for its "Pentium Killer", the
Alpha AXP. Mitsubishi has been awarded a contract to produce Alpha chips, thus
ensuring a stable, competitive second-source for the new processor.

...However, unless Intel can get their collective fecal matter together, the
true killer of Pentiums might just be the bane of all processors - heat. As
reported previously, the 66MHz versions of the Pentium suffer from the same
problems their first 486DX-50 counterparts suffered from. The 60MHz version of
the Pentium are reportedly running just within temperature tolerances to be
granted a release approval, but still require a serious heat sink arrangement
to help dissipate damaging excess heat.

...Word from Intel is that a combination micro-fan and heat sink combination
has been developed that reportedly will cool the 66MHz release of the Pentium
enough to maintain tolerance levels and ensure the chip's life expectancy.
Unlike other chip fans like the CPU Cooker, the Pentium micro-fan taps
directly off the 5v lead in the chip socket as opposed to using a power tap
from one of the drive power cables.

...In case you've been living under a rock the past few months - or under an
old 10Mb IBM full-height "brick", as the case may be - hard drive prices have
fallen through the floor, with street prices approaching the mythical $1/Mb.
Both Western Digital and Connor have dropped their prices on drives below 1/2
Gb to this level, and needless to say a Windows-hungry userbase has been in a
feeding frenzy that shows no sign of letting up.

...However, a recent announcement by Connor may shed some light on just *why*
the prices were slashed. In 1991, Connor acquired VISqUS, a research firm
dealing with innovative technologies. VISqUS had developed a new drive
technology that involved the use of oil films instead of air as a support
medium for hard drive head, which allowed for superior resistance against head
crash and allowed the heads to travel closer to the platter surface than air
technology allowed.

...Connor reportedly saw a good idea, and decided not to let it slip away.
After buying the company, a Connor-labeled prototype drive was seen making the
big trade shows that packed a reported 60Mb on a *single* 3.5" platter. At the
same time, rumors started to surface of a similar design being developed by
Western Digital, with prototypes being demonstrated for stockholders. Shortly
afterwards, both WD and Connor started dropping their prices on hard drives in
the 130-240Mb range, and last March slashed prices from the 540Mb range on
down to the discontinued 40 and 80Mb sizes.

...Industry experts now believe that this dumping serves a twofold purpose:
getting the market used to having affordable, serious mass storage while
getting rid of existing stockpiles of air technology hard drives. While no
official announcements have been made by either company, experts also predict
that the first oil-film drives will hit the market by 2nd Quarter 1994, and
will probably be targeted towards use in laptops.

...From the Microsoft _______ For Windows department: rumors out of the Left
Coast speak of a joint venture between the Gates boys and a major cable
company to produce a new form of interactive TV. The plan reportedly involves
using the soon to be dime-a-dozen 386DX-33's as a foundation for a new cable
box that will act as both an advanced channel selector and a game interface
intended to compete with Sega and Nintendo.

...While no other specifics have surfaced, some cable trade rags have
commented on the rumors, and have predicted that if the venture is to succeed
it *has* to be cheaper in price than Nintendo, better in quality than Sega,
and must offer significant additional features to current cable box
capabilities that today's boxes simply aren't capable of.

...From the Caveat Emptor department: thinking of buying a Video Blaster, an
ATI Graphics UltraPro, or another high-performance video card or frame
grabber? Well, if you're running 16Mb or more on the system board, you might
be in for a bit of a problem. Most cards of this nature require that a linear
frame buffer - AKA a "memory aperture" - be available at or above 16Mb. If RAM
is detected at or above this level, the card won't be able to find an aperture
and won't run. Most cards allow you to turn off the aperture feature, but this
can cut your performance to as low as a third of what it should be.

...Now, all isn't lost. This only applies to ISA systems. EISA's 32-bit bus
can accommodate this aperture requirement, and cards installed on systems with
an EISA bus need not worry. Same may apply in the future for Local Bus ISA
systems, as some vendors have reported that the VLB can be used to circumvent
some of the aperture problems in lieu of an EISA bus. Until then, keep this in
mind when buying video cards such as these.

...While we're caveating the emptors, a brief NOTE from an IBM insider is that
when you buy DOS 6.1 from Big Blue, what you're really getting is PC-DOS 5.0
with some reversed-engineered MS-DOS 6.0 cloned enhancements. IBM reportedly
has no legal access to any version of MS-DOS later than 5.0, which tends to
explain why data compression has been relegated to such third party suppliers
as Stac and AddStor.

...As to whether or not PC-DOS 6.1 is truly compatible, initial reports say
that while the version is as stable as MS-DOS 5.0, there have been reports of
conflicts and system crashes under Windows 3.1. Although IBM has denied any
serious bugs with their new DOS release, the culprit is believed to be the
reversed-engineered version of EMM386.EXE.

...Speaking of those third-party data compression utilities, industry insiders
report that the reason IBM dropped Stac in favor of AddStor for its competitor
against DoubleSpace is essentially the same that Microsoft has given for
dropping Stac. Seems that Stac wanted more than their share of the profits and
credits for the inclusion of Stacker 3.0 with PC-DOS 5.0 last winter, and
wound up talking themselves out of yet another gravy train.

...Guess this is the best place to offer this hot tip regarding compressed
drives and backups: instead of backing up all the files on the compressed file
volume file by file, simply backup the CFV itself. Since the compressed drive
is, of course, compressed, this allows you to turn off any backup compression
routines and save more time. Tests conducted by the WWIVNews staff show that
with Stacker 3.1 and Fastback Plus 3.0, a CFV containing 60Mb of files was
backed up to just under 50 1.44Mb diskettes, whereas backing up the individual
files with compression turned on required 53 diskettes of the same size!
Similar result ratios were gained with Stacker and Norton Backup.

...While we're talking about IBM, the biggest complaint about the lumbering
giant's PS/ValuePoint line of cheap systems - the proprietary video connector
- has just become history. Market surveys had shown that this attempt to
prevent buyers from using non-IBM monitors with the VP systems was the top
reason given for *not* buying one of Big Blue's pseudoclones. Most people
surveyed stated that they would have preferred to buy from the company that
started it all, but that the designs of the ValuePoints prevented their use
with high-quality monitors such as the NEC xFG series and the Sony Trinitron
line.

...From the Mac Geeks Anonymous department: Insiders at Apple report that part
of the Motorola-IBM-Apple arrangement that will make the PowerPC a reality
also includes the rights for vendors using the PowerPC to incorporate Apple's
new ergonomic keyboard into their designs. This will allow vendors to make
this in-demand input device available for non-Mac environments without having
to perform a serious reverse-engineering feat. This particular feature will
also allow for daisy-chaining of Apple-based input devices into the same port,
much as what Mac users currently have available.

...Finally, with v.FAST approaching, modem vendors have started to dump their
existing stockpiles of 9600 bd modems on the market at prices that would have
been unthinkable a year ago. Street prices for 9600 v.32/v.42b Hayes-
compatible modems using the Rockwell chipset have dropped to just under $200,
and 14.4 kbps modems have dropped to under $275. As v.FAST becomes ratified,
expect these prices to drop at least another $100 each and signal the death
knell for 2400 bd modems.

...The WWIVNews staff predicts that within 18 months of the ratification of
v.FAST, not only will you not be able to give away 2400 bd modems, most BBS's
won't even allow you to connect at anything slower than 4800 bd! Based on the
number of 2400 bd modems sold in the US since 1984, don't be surprised if we
see another New Jersey garbage scow scandal when someone tries to find a
landfill big enough to dump all these worthless modems!


───────────────┬─────────────────────────────────────────────┬───────────────
               │             Dateline: @#$*()#!              │
               │ Editorial Commentary by Omega Man (1@5282)  │
               └─────────────────────────────────────────────┘

I had a nice, long, lengthy, in-depth, analytical, critical, full-scale,
educational, logical, soapbox-squashing ranting editorial planned for this
issue's special topic on the UU debate, but seeing as how Wayne essentially
summed up my own thoughts on the matter...well, you get the picture. In any
case, the matter has essentially been settled, and those who are still
disgruntled can find solace in either looking at FileNET, or waiting for
2@2050's WW4-FREQ efforts to bear fruit.

Those who are still not satisfied should consider looking at joining Fidonet.

With that out of the way, I'll simply dedicate this edition of Dateline:
@#$*()#! to several short topics and announcements.

ITEM: Is anyone going to ONE BBSCON next month? If so, WWIVNews would love to
print in-depth articles and reports on the events that are scheduled to take
place. Of extreme importance is Ward Christansen's lecture on how he invented
the BBS; a transcript of this would be most appreciated. Same applies for any
other seminars or lectures held at the convention.

If you're doing an overview of the con as a whole, be sure to point out areas
where the convention holders fouled up. With WWIVCon approaching less than a
year from now, this information could be valuable in helping the WWIVCon
organizers avoid making the same mistakes!

ITEM: See the above item regarding ONE BBSCON? Well, if anyone is going to
Fall COMDEX, and you happen to see any striking technological advances that
can be applied to the BBS environment, feel free to submit reviews of what you
experience.

ITEM: Would you believe over seven months later, I'm STILL getting requests
for the WWIVNews Editorial Desk sub? Folks, if you don't have a SUBS.LST with
a file creation date later than 2/1/93, then contact your AC or your GC about
getting an updated release ASAP! Lord knows that if I'm still getting requests
for a sub long dead, then 8-Ball must be getting quite a few more himself!

ITEM: Ye Editor is looking for a BBS that specializes in TARGA utilities. If
anyone has a line on a system that supports TrueVision boards beyond the usual
stockpile of .TGA images, drop me a line in E-Mail. My job now involves the
use of TARGA boards for professional TV production, and I'd like to find a BBS
that might offer assistance in making this "overpriced...but worth the over!"
card jump through a few more hoops.

ITEM: Thanks go out to Filo (1@2050), Group 4 GC and host of the AC/GC sub for
granting WWIVNews access to this administrative sub. The access will allow
AC's and GC's to interact better with the WWIVNews staff, and will hopefully
lead to regular features from those who bear most of the administrative
burdens of WWIVNews.

ITEM: While the issue is still 8 months away, start thinking about the April
issue for 1994. This time around we'll be doing an "April Fool's" issue, which
will feature as many phony gag articles as the WWIVNews staff can collect
together into one issue. If you've kept up with Penn Jillette's bogus PC
specials the past couple of years in _PC Computing_, then you get the idea of
the type of sick, sadistic humor we're looking for.

ITEM: Hmmm...seem to have run out of items! See you next issue!

─────────────────────────────────────────────────────────────────────────────

Next "Month" in WWIVNews:

MS-DOS 6.0 is upon us at last. However, unlike MS-DOS 5.0, the Gates Boys'
latest upgrade to the industry standard for PC operating systems is reportedly
not as stable as its predecessor. WWIVNews takes a look at the pros and cons
of DOS 6.0, and takes a look into alternatives to MS-DOS as well. WWIV under
Windows 3.1, OS/2.xx, and DesqView will be explored as well.

Coming Soon in WWIVNews:

WWIV 4.23 is just around the corner. What will Multi-line capabilities and
Fidonet compatibility mean to you, the WWIV sysop? WWIVNews asks some
pertinent questions regarding what may be the most important stage in the
evolution of WWIV since the introduction of WWIVNet.

┌───────────────────────────────────────────────────────────────────────────┐
│                             Closing Credits                               │
├───────────────────────────────────────────────────────────────────────────┤
│ WWIVnews is an independent newsletter NORMALLY published monthly as a     │
│ service to the WWIV community of sysops and users. The opinions & reviews │
│ expressed herein are the expressed views of the respective writers, & do  │
│ not necessarily reflect those of the WWIVnews staff. Reproduction in whole│
│ or in part is allowed provided credits are given. All rights reserved by  │
│ WWIVNews, and all articles are copyright of their respective authors.     │
├───────────────────────────────────────────────────────────────────────────┤
│ The source site for WWIVnews is the Klingon Empire BBS (512-459-1088),    │
│ WWIVNet node @5282. Requests for information regarding articles and other │
│ editorial submissions, as well as back issue requests and the WWIVnews    │
│ Writer's Guide, can be sent in e-mail to the WWIVnews editor, c/o 1@5282. │
├───────────────────────────────────────────────────────────────────────────┤
│            WWIV and WWIVNet, copyright 1986,1990 by Wayne Bell            │
│  Any product or company mentioned or reviewed herein are copyrighted of   │
│  their respective owners, creators, and other corporate pseudoentities.   │
└───────────────────────────────────────────────────────────────────────────┘