F I D O N E W S -- | Vol. 9 No. 5 (3 February 1992)
The newsletter of the |
FidoNet BBS community | Published by:
_ |
/ \ | "FidoNews" BBS
/|oo \ | (415)-863-2739
(_| /_) | FidoNet 1:1/1
_`@/_ \ _ | Internet:
| | \ \\ |
[email protected]
| (*) | \ )) |
|__U__| / \// | Editors:
_//|| _\ / | Tom Jennings
(_/(_|(____/ | Tim Pozar
(jm) |
----------------------------+---------------------------------------
Published weekly by and for the Members of the FidoNet international
amateur network. Copyright 1991, Fido Software. All rights reserved.
Duplication and/or distribution permitted for noncommercial purposes
only. For use in other circumstances, please contact FidoNews.
Paper price: . . . . . . . . . . . . . . . . . . . . . . . $5.00US
Electronic Price: . . . . . . . . . . . . . . . . . . . . . free!
For more information about FidoNews refer to the end of this file.
--------------------------------------------------------------------
Table of Contents
1. EDITORIAL ..................................................... 1
Editorial: Where was I ........................................ 1
2. ARTICLES ...................................................... 3
FOSSILs: ancient history ...................................... 3
A day in the life of an overworked UK sysop ................... 4
UpComing Software - Tic Zipper ................................ 7
Country Computing ............................................. 8
I TOLD YOU SO!!! .............................................. 9
3. LATEST VERSIONS ............................................... 19
Software List ................................................. 19
4. FIDONEWS INFORMATION .......................................... 25
FidoNews 9-05 Page 1 3 Feb 1992
======================================================================
EDITORIAL
======================================================================
Editorial: Where was I
by Tom Jennings (1:1/1)
It's amazing how we can take incredible things for granted.
For the last few months I've been working for a telecomm. service
provider, writing some sort-of fancy testing software involving bit-
serial stuff. It turned out to be kind of interesting; I had to learn
how to do high-precision arithmetic, high-precision division, and
quickly. Knuth's "The Art of Computer Programming" SEMI-NUMERICAL
ALGORITHMS (dry as a desert) and all that. An as you might imagine, I
have fairly decent serial port drivers (my integral "Fido" driver that
later became the basis for FOSSIL) and a FOSSIL interface.
I use Ray Gwinn's X00, run under DESQview, with my Fido BBS (Dual Std
HST) in it's own window. I don't think too much about it. I installed it
who-knows how long ago. Couple of years. I touched it twice in the last
year; once when someone sent me a new version (the old one worked just
fine) and once when I got a 16550 and second serial card. It's a nice,
boring program. (Who wants excitement in a device driver?)
For testing this thing I usually run it in a DESQview window, which
works at 19,200 and below just fine; even at 1920 bytes/sec send and
receive, it drops very few bits, and only when Fido is writing disk
files. (Note in this case, the same X00 driver code is being accessed by
Fido from one DV window, and my test program in another.) For high-speed
testing I have to take DESQview down; sustained 38,400 baud halts DV
altogether! (It's 100% busy reading bytes; when you pause the data it
comes back to you.) So I'm testing this new program, outputting data at
3840 bytes/sec (long-term average), into a shorting plug that loops the
data into the receive side, and comparing the ins and outs, debugging my
new printf(), whatever. Testing consists of a few minutes run (million
bytes or so), and and end-of-day test (overnight, 8 hours), does 100
million bytes. Error rate: no bad bytes. Great.
Then I realize -- wait a minute! I'm running on the FOSSIL driver, not
my integral driver! No changes whatsoever, and half the time, there are
two programs using the same driver! (And it turns out my old-fashioned
integral IBM driver is signifigantly slower than the FOSSIL!)
Ray Gwinn's program, at least for the pclone world, has become the part
of the bedrock upon which FidoNet sits. It is hot stuff, and also boring
when it should be!
The FidoNet's history of technical development is interesting, and I
think completely unappreciated by "industry" with a few exceptions.
FidoNet has made, and broken, some modem manufacturers -- some like U.S.
Robotics and Telebit, actually listened to us, and made changes to their
products and marketing that assured their niches.
FidoNews 9-05 Page 2 3 Feb 1992
It's safe to say that the FidoNet serial-communication technology is the
most advanced on PCs; we have collectively pushed serial performance far
beyond what even the hardware was considered capable of. To us, 19,200
fixed-DCE rate and 10,000 bytes/sec, and faster, are common. Believe me,
there are many large businesses that believe this completely, flatly
impossible. And we do it routinely.
I think it's time that each of us consider that maybe, we should tell
software and hardware manufacturers that the FOSSIL interface is now a
defacto standard, and ask, when are they going to support it directly?
This past summer I had to hack a driver to run at 56,000 bits/sec over a
leased telephone line, PC to PC, using KA9Q's NOS package. It was like
going back in time. (Though NOS has it's own "generic" interface for
serial, ether, coax drivers.) The manufacturer of the serial card
(SEALEVEL Inc, quite nice I may add) hadn't heard of a FOSSIL driver.
They provide the usual "sample driver code" that is the barest fragment;
wouldn't it be nice of they could ship fully functional, high-
performance drivers? For free? Like giving away razor blades to sell
razors...
If you have any contacts or influence in places that use serial
technology for any reason (modems, printers, LANs) tell 'em about
FOSSIL. Tell them about how our programs use a FOSSIL interface, if one
is present. Give them code, and FSC-0015 (the FidoNet technical standard
document covering FOSSILs).
I think we tend to sell ourselves short in where we stand in the world
at large. (I have a theory regarding the proportional relationship of
head in the sand too-busy-bullying-local-sysops vs. dealing with the
outside world, but I'l leave that untouched for now.) We have an
incredible body of technical wizardry here. Our FidoNet technology
doesn't make sense sometimes to more "traditional" telecomm. people,
because FidoNet was designed in a vaccuum, developed along unique lines
(PCs), and now, because we far outpace existing networks in some areas.
(Social sophistication isn't one of them.)
As much as we like to think we're so big and smart, not many people are
actually aware of how FidoNet is put together.
Just something to think about.
Somehow in all of this I ended up writing a history of FOSSIL
development; to avoid boring you I put it into a separate article.
----------------------------------------------------------------------
FidoNews 9-05 Page 3 3 Feb 1992
======================================================================
ARTICLES
======================================================================
FOSSIL drivers' ancient history
Tom Jennings
1:125/111
The FOSSIL interface was originally the Fido internal serial library
interface; the calls are fairly generic in design. I had been using it
for a few years before Fido, in programs like Phoenix Technologies'
TELINK (later Ptel) program. (The original TELINK program was written in
BDS "C" for CP/M, and yes, it contained it's own internal driver of
amazingly similar design (but no interrupts (but I digress)).) At the
time, the "IBM PC" was brand new and expensive, and every hardware
platform (Compupro, Tandy 2000, TI Professional, Computer Devices' DOT,
Otrona Attache 8:16, etc) had completely different hardware. I had a
"driver layer", and wrote simple drivers that were hardware-specific,
and linked them into the program.
(During those years I was writing MSDOS BIOSes, not ROMs but the hidden
\IO.SYS that actually contains the MSDOS.SYS interface. MSDOS.SYS opens
files etc, and passes requests to the driver, IO.SYS, which in turn gets
the job done using whatever the hardware is. What I did was write IO.SYS
in two layers; a very smart one that handled error checking, blocking,
segment boundary handling (can't DMA across a 64K boundary) and all that
really hard stuff, and was quite stable and completely hardware
independent. The hardware drivers were stupid, did no error checking and
talked directly to the hardware, and talked to the smart guy through a
table. With this scheme we were able to do complete MSDOS ports to
virgin hardware, boot ROM, IO.SYS, disk formatter, utilities, etc, in
under a week...)
Anyways, the original Fido used the same scheme for serial I/O. The
driver was linked into the FIDO program using an object linker. Even
post-IBM, there were enough non-IBM machines (DEC Rainbow, Sanyo 555,
etc) to warrant me writing drivers and linking up Fido programs for
them.
Some machines weren't worth the trouble -- and I usually didn't have
access to hardware. (The DEC Rainbow driver took 3 months, and was
written OVER THE VOICE PHONE, as John Madill's Rainbow 100A was in
Balto. The most painful code I have ever written.)
For a typical Fido release in 1985, I created five versions: IBM, DEC,
VICTOR 9000, SANYO 555, and OTRONA ATTACHE 8:16 (I had the hand-wired
prototype (no schematics, not ROM listings!, which caught on fire two
years later). This was getting ridiculous!
So I decided to pass the buck: I documented the serial device functions
(read, write, ready test, etc) and using the existing IBM ROM INT 14h as
a model, made another Fido version, the poorly-named GENERIC Fido. Then,
when someone called me with some wacko computer, I could finally say
"You do it!"
FidoNews 9-05 Page 4 3 Feb 1992
The history from this point on is contained in document FSC-0015,
written by Rick Moore. I'll merely summarize from it.
While I considered myself off the hook at this point, the "Generic"
driver was barely enough to do the job. Thom Henderson (who also had his
own SEAdog drivers) and Bob Hartman built a driver around the GENERIC
interface to solve some particular SEAdog problem; Vince Perriello took
this further and under the extensive prodding of Ken Kaplan (global
FidoNet facilitator supreme deluxe) generated a DEC Rainbow driver and
then SEAdog ran on that now-historic hardware.
Some guy no one ever heard of named Wynn Wagner was trying to get a
commercial serial driver package to work for his Opus, without much
success. Bob Hartman suggested that with a few changes, it could use the
drivers already coded for SEAdog (and my implication, Fido). And, quote,
"...Vince called Wynn to discuss porting Opus to the DEC Rainbow, Wynn
called Bob, Bob called Vince, and the FOSSIL driver came into
existence". ("FOSSIL" stands for: Fido Opus Seadog Standard Interface
Layer.) Rick Moore, Solar Wind Computing, authored FSC-0015, the FidoNet
FOSSIL standard.
In 1987 I finally renamed my FIDO_GEN to FIDO_FSL, dumped my GENERIC
drivers in favor of the FOSSIL system. (It took me that long simply
because I'm lazy.)
In 1992, I upgraded my own drivers. No longer will I have to link up
separate FOSSIL and IBM versions; each program will automatically use a
FOSSIL driver if present, or fall back to the integral driver. It's
amazing how long it takes to get around to these things!
----------------------------------------------------------------------
by Mike Butler
Sysop of Manhattan Skyline, Sileby, UK (2:250/416, 2:250/417)
A day in the life of an overworked UK sysop
- or -
How to survive a business, BBS and family without cracking up
I live on the outskirts of a small village called Sileby in the middle
of the UK. For those of you who know the UK, it's between Leicester
and Nottingham. Nice views over open fields at the front and a long
garden with a railway line at the bottom at the back. I always wanted
a train set!
The day starts at around 7:00am. Well, to be exact it started five
minutes earlier when my son woke up, closely followed by my wife.
The first thing I know about it is someone is pulling my hair. My son
has decided to practice mountain climbing. Guess who is honorary
mountain for today. Got it in one - me! One thing I should mention
here is that my son developed cerebral palsey after being born 13
weeks early and is disabled. The first and last time my wife has ever
been anything but late :-). I hope she never sees this......<thwack>
FidoNews 9-05 Page 5 3 Feb 1992
After about ten minutes the word 'breakfast' starts to waft around the
bedroom. Not in the 'would you like breakfast' style. More like the
'breakfast would be a good idea if you want to live till lunch' style.
Off I go downstairs, trying to avoid the assorted toy cars and squeaky
dog toys we have littered around the place.
I didn't mention the dog did I? Snuzzle is a mixture of several dogs.
Unfortunately none of them had a brain. At least, she never inherited
one. She is eight years old now but no-one has told her. She still
thinks she is a pup. She sleeps on the end of the bed. Unless she
thinks no-one is watching when she sneaks up and lies between us.
Anyway, back to the morning.....
I've made it to the kitchen. Fill the kettle completely full and put
it on to boil. Get some milk and stick it in the microwave to warm for
the kid's cereal. I now have around five minutes to dive into the
office and check to see what the night has delived to the BBS. Not a
lot really. No new netmail, a few files from my file host and a whole
bunch of echomail. Wildmail is still tossing it into Wildcat. I really
must buy a decent machine. The mail BBS runs on an original IBM AT
which is slow at best. When tossing mail it is ssssslllloooowwww!
Looking out of the window doesn't reveal a lot. It's still dark.
<click> The kettle turns off. Back to the kitchen, get the milk out of
the microwave. Make a mental note to wipe up the bit that overflowed.
Back upstairs with breakfast. No paper yet. The newsagent said the boy
had not turned up. I asked when they would get a reliable one. Silence
at the other end of the phone. No sense of humour some people.
I crawl back into bed and power down for ten minutes while Sandra
stuffs Lee full of breakfast. I get rudely awakened by a plastic Bart
Simpson landing on my head. This does not bode well for the day ahead.
Sandra carts Lee off into his bedroom to get him dressed. I wake
up and get dressed - not necessarily in that order. I get downstairs
first and make the coffee. I may wake up yet.....
Outside has emerged from under the darkness. It's very frosty. The
trees and lawn are white. The wife's car is iced up. Mine is in the
garage <hehehehehe>. The trees near the house are full of birds
looking at an empty bird table. I stock it up with bread and get back
inside where it's warm.
At about 8:15 Lee gets picked up by the school bus. He goes to a
special school about 15 miles away for four days a week. Once he is
five he'll go full time. He is four in a couple of weeks - Feb 5th.
The mail arrives shortly afterwards. The mail is pushed through the
letterbox. Folded. Including a couple of diskettes. Great! Nothing of
any interest. Unless bills interest you that is. And two bent disks.
FidoNews 9-05 Page 6 3 Feb 1992
I'm supposed to be at a clients site at 11am. I work as a consultant,
programmer or whatever. I get off at around 9am. Two hours is about
right for the 110 mile journey. It should be around 1 1/2 hours but
what with the motorway roadworks etc I allow a bit extra. After about
ten minutes I am rudely disturbed by the car phone. Turn down the
stereo. It's the wife. The client phoned. They are flooded due to
heavy rain. Can I leave it for today. Hmmmmmm........back home.
So, I've got a day to kill. Every cloud has a silver lining. Except
the one which flooded out my client.
Maybe these disks should be looked at ? Some surgury is required. Take
the actual disk bit out of the bent envelope and stick it into a new
one. Wonderful - it loads fine. Someone has sent me some files for the
BBS. Even more wonderful is that I've not already got them!
I downloaded the latest beta of D'Bridge yesterday so I decide to
install it. Back up the current stuff then install it. Everything
seems fine so I leave it running and load up Flight Simulator. I
bought the sound and plane addon last week so I'm flying Concorde
around the place. One day I'll land it properly. The best sound effect
so far comes when you crash. Sort of breaking glass....
The BBS is quiet. Unusual. Hold on - why is the modem off-hook. This
is not right. Reset the modem - whoever put the nice little switch on
the new DS should be given a medal. The next caller got onto the BBS
ok. When he exited D'Bridge left the modem off-hook again. After an
hour or so of testing with a line analyser between the modem and the
PC, several large mugs of coffee and various interruptions the cause
is found totally by accident. Seems this new D'Bridge has a bug which
causes the modem to be left off-hook if you don't scan for echomail
when you start it. The sample batch files force netmail and echomail
scan on startup. My batch file doesn't as I unpack externally. Ho hum.
A few changes to the batch files and things are fine again. Send off
the bug report with a request for a free "I found a bug in D'Bridge"
sweatshirt.
Lunchtime........down to the local restaurant for a bite to eat. Nice
place. It was an old primary school building which was converted into a
restaurant in 1979. Food is good, we know all the staff so we stay too
long. Back home at 3pm.
Quiet afternoon really. Top Gun was on the TV a few days back so
various shoot'em'up games have been dug out. I'm sure I should
have been a fighter pilot. They would need to make the planes a bit
wider though. I'm not overweight, just short for my height. I should
be around 8'6".
Had a call from a local company. If they donate some money to the fund
we set up to buy Lee a decent all-terrain-wheelchair would we mind if
it went in the local papers to give them a little publicity. What more
could we ask. A donation and publicity for the appeal. Good stuff!
FidoNews 9-05 Page 7 3 Feb 1992
Around 4:30pm we hear the 'beep beep' of the school bus outside. Lee
is back. The routine is well set up now. Sandra zooms out to the bus
to collect him and have a brief chat with the escorts. I hit the
'start' button om the microwave for his tea then zoom into the living
room to put the Bart Simpson tape on. He won't eat his tea unless Bart
is on. While Sandra fills him with shepherd's pie and beans I check
out the school bag. He's been painting again. I thought his hair had
little colored bits in it. From his notebook it seems they took the
kids shopping today as well. All fun stuff. I remember when I was a
kid........
After tea it's "pester daddy" time. We play with his cars, his toy
Bart and do some drawing and generally make a mess. We also play on
one of the computers for a while. 2:250/417 has been consigned to
games duty.
Diversion....Why are so few games suitable for disabled kids? The
only decent one is a Disney one called "Goofy's railway" or something.
All Lee has to do is keep hitting keys and things keep happening.
Simple but very effective. If any games writer are listening please
take note. Just add a mode to any game with good sound and graphics
where it can be worked by hitting *any* key and you'll sell to
disabled kids. It may not seem fun to you but the kids love it!
Lee goes off to bed at around 6:30pm. Tears as usual, followed by
slinging *another* toy Bart around the bed then off to sleep.
Nothing decent on the TV again. Ten channels and nothing worth
watching on any of them. We decide to watch Total Recall again. Good
film and good sound effects with the Dolby decoder on. Halfway though
the BBS starts beeping. Forgot to turn off the page. Someone wants to
know if I have any 'adult' GIF files. Nope, but I know a BBS which
does so I give him the number. Then turned of the page. Back to the
film. Sandra wants an early night so I decide to have half an hour
tinkering with the BBS. Well, it was going to be half an hour. At
around 1:30 I decide to go off to bed - after checking the page keys
are all disabled.
So, that's an average day here in Sileby. Fun stuff huh?
Mike
----------------------------------------------------------------------
TiZZer - Tick Zipper (Tick Post Processor)
coming soon: Version 1.00b (beta)
FidoNews 9-05 Page 8 3 Feb 1992
(c) 1991 Robert McCullough
to be Distributed as Freeware for NonCommercial Use Only
Tizzer - Tic Outbound File Manager (Packer)
Tic, Text, & File Compressor for File Echos.
FTS Product for Hubs and File Movers.
TiZZer Packs Tics (and more if you choose via the options in
your TiZZer.Ctl) in a HexFile.TZ? (where ? is a Number from
0 thru 9). TiZZer runs in two modes (depending on your front end
mailer) Binkley (opus/fido/max/etc) and FrontDoor. TiZZer
allows the packer of your chooice. It saves money ($$) via
Transfers picking up bundled files instead of Small .Tic .SDA
Wnt .Des .ANS etc
If you hub File Echos it is easy to set up via the TiZZer.Ctl
file. The Remote (recieving) system does not need to run TiZZer
(only a couple of simple processing lines in thier batch file).
TiZZer allows you to select tic & tic'd files by File Extension,
Size NetNode you are Sending to, and Zone (outbound). TiZZer
creates a standard log. And, there is a TiZZer Conference to
get support directly from the Author, Robert McCullough.
TiZZer will run safely on Multi-Line Hub operations. It will
create a busy file and in the other one check for that file (and
vise-versa). All this is available via the Configuration File.
Article by Kevin Snively FileEcho Hub
and TiZZer Tester and User. 1:116/29
----------------------------------------------------------------------
by Donald Tees
Ex-Libris BBS, Windrush Farm, 1:221/192 (Ontario, Canada)
Whimsy from the Farm
Well, we are dug out and back to normal. I noted in my last
article that it was going to take a few hours with a front-end
loader to dig out ... it did not, and therein lies a story. You
see, my neighbour has a largish snow-blower (for the Californian
readers, that is not a Canadian lady of the night, but a machine
that chews up snow in front and spews it out the side by auger.)
and came over to lend a hand.
FidoNews 9-05 Page 9 3 Feb 1992
We have a small unit about three foot wide, but his is a
rather humungous piece of equipment that fastens to the tractor.
It will cut a swath ten feet wide through six feet of snow and
toss the snow about one hundred feet to the side.
That is what it does to snow. I have (had), however, a nice
blue plastic box with "we recycle" written on the side. It was
sitting at the side of the road for pickup before the storm,
filled with old newspapers neatly tied with string. It is now
spread over four and one half acres, chewed up into tiny blue
pieces of plastic. Intermingled are several thousand two-inch
by three-inch pieces of newsprint. It was quite entertaining to
see, sounded like a giant ridding itself of phlem, but is going
to be a swine to clean up. Maybe a baling machine ...
I mentioned in my last article that I thought Fidonews too
dry. I had hoped that what I wrote would trigger a few more
personal vignettes about the lives of our net members. I have
received lots of net mail agreeing, but seen nothing in
Fidonews. Am I alone? Ah well, when in doubt hammer away until
someone objects ...
----------------------------------------------------------------------
Jack Decker
Fidonet 1:154/8
I TOLD YOU SO!!!
Dennis McClain-Furmanski's article entitled "Who's On Top Of The 'Top
Down' Structure?" in FidoNews 9-01 was, in its own way, one of the best
commentaries I've seen in FidoNews in a long time. But at the same
time, I suspect that his complaints may seem a bit puzzling to some of
the newer members if Fidonet, who haven't been around long enough to
remember how things used to be. So for your benefit, as well as the
benefit of those who may have forgotten, here is a short, politically
incorrect history of how we got into this condition. I'll begin with a
little personal history, since my vantage point is necessarily limited
to the time I have been in Fidonet.
I joined Fidonet in about 1987 or '88, I'm not sure exactly which year
it was but the main reason I got an XT clone was to participate in
Fidonet. My old TRS-80 had handled all my computing needs quite nicely
until then, but it couldn't run Fidonet software.
A friend of mine, for reasons I won't go into here (because they aren't
relevant), wanted to set up a BBS and carry echomail. He wanted to
connect with Fidonet, but did not want to spend the time necessary to
properly maintain a BBS, so he asked if I would co-sysop his board. I
said that I would in exchange for an echomail feed. At the time, he
lived in Grand Rapids, Michigan, and I lived in Sault Ste. Marie, as I
still do. There was one net covering most of the state of Michigan,
Net 120 out of Detroit. We set up an Opus 1.03 system on each of our
machines, and set it up so that his system would poll for echomail, and
then poll my system to deliver the mail I wanted. At the same time, we
set up a mechanism where I could update the various control files on
FidoNews 9-05 Page 10 3 Feb 1992
his BBS remotely.
Now, there were a few (less than ten, if I recall correctly) Fidonet
nodes in Grand Rapids at the time, and they basically weren't bringing
in more than just a handful of echomail (a couple of large echoes,
perhaps TECH and COMM, and that was about it). There were also local
echoes. A few months after we joined, some of the local nodes decided
that they wanted to form a net of their own for West Michigan (Net
228). Since by that time we were doing mail with a number of other
boards and didn't want to change addresses, we stayed in Net 120. And
you know what? Neither the folks in Net 228 nor the folks in Net 120
gave us any hassle at all about that. We weren't opposed to the
formation of a local net, but we just didn't want to have to have to
force everyone that we communicated with to change our address in their
control files. And in my case, Sault Ste. Marie is just about as far
from Detroit as it is from Grand Rapids.
Actually, in those days you could just about join any net you wished.
Net 120 had some nodes up in the Upper Peninsula (Marquette area) and
in mid-Ohio. For the most part, these nodes weren't a local call to
any existing local net, and therefore it made more sense for them to
join a large, well established net. And then there were situations
like mine, where someone was co-Sysoping a board remotely and it made
more sense for them to be in the same net as the board they were
co-Sysoping. In the first nodelist I ever saw, some midwest nets had
nodes on the west coast in their listings.
Now in those days, most echomail conferences were unmoderated, and
you'd start a new conference by announcing its existence in Fidonews or
on the ECHO_REQ (Echo Request) echo, and telling folks where they could
call to link in. If you had a good idea for an echo, you'd usually get
sysops polling your system to pick up that echo. Of course, anyone who
got the echo from you could in turn offer it to others. There were no
restrictions on where you could get echoes. If you were in Maine and
for some reason it made economic sense for you to call California to
get an echo, you could do so.
A few sysops ran large hub boards... they would carry 50 - 100 echo
conferences or more (a lot of the software limited you to 100 echoes
back then!) and would allow anyone to call in to get feeds. This also
helped echoes to get widely distributed, because if you had an echo
that you wanted to get onto as many boards as possible, you'd probably
send it up to one of the large hubs on your nickel... and of course,
you'd probably pick up a few other echoes while you were there.
Many of the larger hubs were run by folks who had access to WATS lines
and other low-cost communication links not available to the average
person. My friend in Grand Rapids was with a company that had a Dial 1
WATS service through an alternate carrier. So, the calls he made to
pick up echomail were not as expensive for him as they might have been
for others, and he was more than happy to share the echoes that he
brought in with others in the Grand Rapids area. He never reached the
status of a large hub (partly due to the use of a machine that had a
tendency to crash for no apparent reason), but I believe he was the
first sysop to bring a number of echomail conferences into the Grand
Rapids area.
FidoNews 9-05 Page 11 3 Feb 1992
Many of the large hub operators ran hubs for the simple reason that
they were echomail junkies, and being a large hub often meant that you
had echoes delivered to you rather than you having to go out and get
them. The folks who had started an echo would call your board and drop
off their conference, in order to gain wider distribution, and pick up
a few echoes on the same call.
At some point an echomail "backbone" developed. I wasn't privy to this
organization, so I can only speculate on how it happened, but my
suspicion is that at first it was just the large hub operators
exchanging echomail on an informal basis.
Remember, at this time you could just about join any net you wanted to
(though most sysops naturally chose to join a nearby net), and you
could get echomail from anyone who would give you a feed. You might
wonder why anyone would want to get an out-of-area feed. Well, the
main reasons were cost, reliability, and availability. That is, folks
tended to get their echomail from the least costly source that had the
echoes they wanted, and that didn't seem to crash or lose mail every
other day.
Cost was a big factor in those days... keep in mind that the prevalent
modem speed in those days was only 2400 bps, except for the lucky few
who could afford HST's, and many sysops were still using 1200 bps
modems. There were still some 300 bps modems in the nodelist, too! In
the United States, calls within your home state often cost more than a
call across the country, so sysops soon discovered that an out of state
feed was less costly than a feed within one's home state. My friend
soon realized that it was not cost-effective to pick up echoes via long
distance from Detroit, since that was an in-state call, so he obtained
PC Pursuit service from Telenet (now SprintNet) and was able to pick up
as much echomail as he wanted from any of several major cities for only
a flat rate price of $25 per month! It was no coincidence that some of
the larger echomail hubs were in PC Pursuitable cities.
Unfortunately, there were some people who wanted to limit echomail
distribution. Coincidentally(?), some of the folks who ran the large
hubs were in favor of this.
One of the main reasons given for wanting to control echomail
distribution was to limit duplicate messages... and it is a fact that
there we a lot more dupes in those days. In some loads of echomail,
you might typically see 20% - 30% dupes. Obviously, this wasn't
economical and I can fully understand the desire to stop the flow of
dupes, since it increased the cost of moving echomail.
As most of us know, dupes are caused when a node turns on the same echo
from more than one feed. And because echomail delivery was less
reliable back then (echomail software was in an earlier stage of
development), some sysops would turn on the same echo from two sources,
in the hope that if one feed lost a day's echomail, the other would
come through. Unfortunately, this caused an instant dupe loop.
Without going into technical details, I will just say that this was a
software design error. When echomail was originally designed, no one
ever envisioned that it would encompass a network of over 10,000 nodes.
I suspect that the author of the original software was a bit surprised
FidoNews 9-05 Page 12 3 Feb 1992
to find the first 100 nodes carrying echomail! So what you had was
software written for use by close-knit group of technically-skilled
sysops suddenly being used all over the globe, by folks who didn't
always understand how it operated. And this software, on which later
echomail software was patterned, was designed in such a way that when a
neophyte Sysop did something that would at first blush seem a perfectly
reasonable thing to do... that is, secure a redundant feed for an echo
that he really wanted... it caused an instant dupe loop.
So those who operated the large hub nodes figured that they had the
perfect reason to try and impose some restrictions on the movement of
echomail. The idea was that you had to somehow impose some controls so
that sysops could not just go out and pick up echomail from anyplace,
thereby causing dupe loops. There was an insistence by some that an
"echomail policy" was badly needed, so an echomail conference called
ECHOPOL was formed. This conference was open only to Echomail
Coordinators, not to "just plain sysops."
It soon became apparent that there were two camps... those who wanted
to impose geographic restrictions on where a sysop could get echomail,
and those who did not. The latter group tried to point out that dupes
could be controlled by requiring that a sysop get all of his echomail
feeds from one source (without requiring that the source be within a
particular geographic area), and/or by requiring that all echomail
software use and maintain the PATH line, so that dupe loops could be
traced. The former group, however, insisted on the strict geographic
hierarchy we have today, which in my opinion is like using a
sledgehammer to drive a tack... it solves the problem but it's
certainly not the best way to go about it!
At the time, I made the point that you could control the topology of
the network without overlaying it onto a map. If I had to get all my
echoes from only one source in order to control dupes, what difference
did it make if that source were in Michigan or California? No one has
ever satisfactorily answered that question. As an aside, it might be
noted that today a point system operator can get echomail from any
system that will give him a feed, and that doesn't seem to screw up
Fidonet too much. It's only the nodelisted nodes that are forced to
abide by the geographic restrictions. Strange.
Of course, some of us saw a possible other motive in the effort to
bring geographic exclusivity to echomail. Keep in mind that under the
system previously in effect, if a hub operator started acting like a
donkey's behind, you could simply switch your echomail feeds to a more
cooperative sysop's hub. However, if a group of sysops - all the
sysops in a Fidonet region, for example - were required to get their
echoes from one and ONLY one echomail feed, then the operator of that
hub could basically require everyone in the region to send all the
echomail traffic in the region through his system. His only cost would
be that of calling his feed, and if he were a monopoly source of
echomail, he might even try to force other nodes to pay his expenses
for those calls. Of course, when we suggested such things, some of the
supporters of the geographic restrictions insisted that such things
could never happen, because Fidonet sysops wouldn't stand for it.
Hmmmm....
FidoNews 9-05 Page 13 3 Feb 1992
The hub operators insisted that it cost them a lot of money to set up
and operate their hubs (never mind that they would eventually be
getting hundreds of echo conferences at next to no cost if they could
get this scheme in place) and that something had to be done about the
dupe problem, and besides, the people who objected to geographic
restrictions were just idiots who didn't understand the problem anyway.
And the ultimate threat... if they didn't get their way, they might
stop delivering echomail! I considered THAT an unlikely threat, since
most of these guys were echomail junkies who would no more have
discontinued their echomail participation than cut off their right arm,
but the threat sure scared a lot of other sysops.
And the strange part of it is that the Echomail Policy that emerged
from ECHOPOL was never really made official policy of Fidonet by what
the average person would consider a "legal" mechanism. For a while it
was simply the "backbone operating procedure" and all the backbone hubs
referred to it as though it WAS official policy, when it was not. Then
the ZC finally declared a modified version of it as the official
policy. I don't recall if an official vote was taken after that, but
by then many sysops were under the impression that EchoPol was the
official policy anyway. I'll leave it to the lawyer types to figure
out if EchoPol can be "legally" enforced today, but if I were on the
jury, I doubt I'd go along with that notion.
By the time that the ECHOPOL echo was in full swing, my friend the
sysop had moved to Milwaukee and had set up an echomail hub there,
still using PC Pursuit to go out and get echoes. Since I was still
basically doing the day-to-day operation of his board by "remote
control", and since we were at that point supplying the majority of the
echomail coming into Milwaukee, they made me the NEC (later my friend
moved again, but by that time I was coSysoping a second Milwaukee node
which acted as the echomail hub for a time). Since I was the NEC, I
had the right to participate in the ECHOPOL echo, which as I mentioned
was open only to Echomail Coordinators. I'm sure that if the average
sysop had been allowed to participate, there would have been much more
objection to the geographic restrictions, and a few other things that
made it into EchoPol as well. As it was, there was still a
considerable amount of objection, but those who favored geographic
restrictions seemed to hold those who opposed them in utter contempt.
A classic example, which I saved for posterity, was the "fools" message
written by Mike Ratledge to Vince Perriello... Mike was an Echomail
Coordinator (and I *THINK* he was the moderator of ECHOPOL at the time,
although my memory is a little shaky on that point), and Vince is a
Fidonet software developer and one of the authors of BinkleyTerm, and
the message read as follows (Note: This is slightly reformatted to
conform to FidoNews line lengths, but is otherwise unchanged):
From: Mike Ratledge
To: Vince Perriello 16 Nov 88 10:28:00
Subject: Slight change in timing
FidoNews 9-05 Page 14 3 Feb 1992
EID: c72e 1170538d
NH>> There is a clear concensus that PATH lines are required. The
NH>> messages in this conference have been overwelming in favor of
NH>> them. We did not> feel it was necessary to re-hash topics that
NH>> alreay had a majority.
-> PATH lines are NOT necessary. If you guys are going to design
-> software this way, ignoring the FTSC working group, then you can
-> damned well WRITE it too.
They aren't necessary *if* we have the topology "locked down" and *if*
we can control every one of the fools out there that thinks they're
better off ignoring the requirements like not going out-of-region, etc,
etc.
We *could* totally eliminate SEEN-BY: lines, too - *if* the above two
things were true - but I don't look for it to happen any time in the
near future.
I agree that there are a lot of things that we're talking about here
that do overlap the FTSC. I think that the FTSC should be responsible
for the basic format of the messages, the structure of the packets, etc
- but the actual message content should be more in "our ballpark" here.
I realize it's a fine line - especially when we're talking about the
kludge lines - but we've got to start somewhere - or we'll never get
there!
If the FTSC makes a decision which changes what is written in ECHOPOL,
then I think that we should ammend the policy - that's all.
--- via XRS 0.30
* Origin: That Mean ol' RatMan's "Point-Less" Point (TComm 1:372/666.1)
[End of quoted message]
That message marked a sort of "turning point" in the discussion... it
seemed that from then on, those who opposed the geographic restrictions
were treated as though they had rocks and feathers where brains should
be. The discussion reached new lows of name-calling and mud-slinging.
One other policy that somehow came into place was that the originator
of an echomail conference could not distribute it independently of the
Fidonet backbone if he wanted it on the backbone. In other words, if
you give an echomail conference to the backbone to distribute, you
effectively lose control over its distribution. In theory, you can
remove a violator of your conference rules from an echo, but actual
enforcement can be difficult and haphazard. But it also means that if
someone really wants an echomail conference but doesn't care to deal
with their "assigned" echomail hub, they can't even go to the
originator's system to get it, if that would be an out-of-region feed.
This, of course, was a complete turnaround from the previous situation.
FidoNews 9-05 Page 15 3 Feb 1992
When I raised my objections to the geographic restrictions, one of my
biggest fears was that sysops would be required to get their echoes
from a source that was not the least-cost source. I was assured that
ECHOPOL would provide for an exception in such cases, in that you could
get permission to go out of region for a feed by getting your NEC and
REC, and your proposed feed's NEC and REC to agree to it. When I
pointed out that any one of those four coordinators could veto the
idea, I was told that I must have an unreasonably negative attitude
toward the Fidonet coordinators, to think that any of them would turn
down a reasonable request for an out-of-region feed! (I guess it must
be your imagination, Dennis!)
Of course, the powers-that-were didn't much appreciate my outspokenness
on the geographic issue, and one coordinator at the regional level
tried his best to get me thrown out of Fidonet. Since my NC was behind
me, it didn't work, although my net in Milwaukee was out of the
nodelist for a week during the dispute. In response, I proposed the
Official Public Computer Network nodelist, a nodelist of
Fidonet-technology nodes that volunteer to be listed. Unfortunately,
the first person to take the idea and run with it decided to include
the whole Fidonet nodelist without permission, and was promptly
threatened with a lawsuit (although to this day I wonder who would have
had legal standing to sue). Anyway, he promptly dropped the project,
(and shortly thereafter, out of Fidonet completely) and Jim Grubs of
1:234/1 took it over and has published it (legally) ever since. It's
still a good list of nodes in some of the "other" Fidonet-technology
networks, and has on occasion served as a place where nets that are "in
the doghouse" in the mind of some Fidonet coordinator can still be
listed.
One of my other fears was that with geographic exclusivity, the
monopoly provider of echomail could force people to pay for echomail.
My objection to this was that the provider could then set the cost at
whatever level he wanted, since folks would not be free to go anywhere
else. In other words, you might be sitting near a regional boundary
and just across the line there's a free and reliable echomail hub with
all the echoes you want, but maybe your Regional Echomail Coordinator
wants you to pay $25 a month because he wants to buy a new '486 system
and makes all his echomail calls using AT&T long distance at standard
daytime rates, and to top it off his system isn't as reliable. Forget
it, you're still forced by "policy" to go to your guy. At the time of
the ECHOPOL conference, many participants seemed to be of the opinion
that there would never be forced cost-sharing, only "voluntary"
cost-sharing. Well, it's voluntary all right, but in some places you
either "volunteer" to pay or you don't get any echomail! It's about as
voluntary as paying for the food you take off the shelf at the local
grocer.
There were, of course, other factors that played a part in how this all
evolved. There was the Midwest Star fiasco, where the operator of a
large Fidonet hub disappeared into the night with several thousands of
dollars of other people's money and equipment, causing a few to
postulate that anyone who offered free echomail HAD to be up to no
good. There was also the change from a two-dimensional NET/NODE
addressing format, to a kludged-in three-dimensional (and later,
four-dimensional) format that "broke" much software and made PATH line
FidoNews 9-05 Page 16 3 Feb 1992
checking far less reliable.
But mostly, it was people who wanted to force people to deal with them,
and to have their own little "fiefdoms." One of the first indications
I had of this was how Bob Hoffman was treated by others in the net.
Bob, you see, worked for a major long distance carrier and was NC for a
net in a remote section of Arkansas (or one of the states in that
area). When he was reassigned to a job in Pennsylvania, none of the
local sysops wanted the NC hat, and since Bob had "free" long distance
as a benefit of his employment, he continued to act as NC, polling
nodes in his former location so that it didn't cost them anything.
From the reports I've heard, they were perfectly happy with the
arrangement, especially considering that they were getting netmail and
echomail for free, but this didn't set well with the
geography-is-sacrosanct crowd.
In actuality, I suspect that many of the objections were as much an
attack against some of Bob's occasionally outspoken views on theology
as anything, but the net result was that some sysops who had a generous
benefactor that was willing to deliver mail to them were deprived of
that benefit because someone else was somehow offended by this
arrangement. Not only that, but forever after Bob Hoffman could do no
right in the eyes of some... when malcontents attempted to first
destroy and then steal an echo that he moderated, the backbone turned a
blind eye and a deaf ear, and cited the fact that he had done the
terribly evil deed of acting as an out-of-town NC, as if that had
anything to do with echo conference moderation. Bob can be pretty
direct about saying what he believes, and I often don't agree with him,
but he sure didn't do anything to deserve the treatment he got at the
hands of the backbone nodes (however, as a result he left Fidonet and
formed an alternate Fidonet-technology network that is still in
operation).
There's a lot more that could be said, and a lot more examples of abuse
of authority that could be given, but I suspect I'm severely pushing
the size limit for a Fidonews article as is. I must point out that
while I have tried to be as accurate as possible, my memory sometimes
fails me so please be kind if I have managed to screw up some minor
detail.
Now, where do we go from here? Let me close with a few facts you
should think about (with my commentary thrown in for good measure):
1) Some coordinators seem to only follow Policy when it suits their
purposes, and they ignore it when it is to their benefit to do so.
Therefore, why should you feel constrained by it, especially since you
probably had little or no input into it, and no opportunity to vote on
it?
2) In an informal organization like Fidonet, Policy can only be
enforced when a majority agree to be bound by it. I think any
consensus on being bound by Policy evaporated a long time ago. Many
sysops have never even read it!
FidoNews 9-05 Page 17 3 Feb 1992
3) Echomail coordinators love to bitch and moan about how much it costs
them (in time and money) to be an echomail hub. My question is, WHY DO
THEY DO IT THEN? Next time they complain about their time/trouble/wear
on their system, etc., ask them what BENEFITS they're getting. The
ONLY reason someone becomes an echomail hub is because they like the
idea of having a multitude of echoes on their system, and being able to
do that while having you and everyone else pay their expenses is the
ultimate echomail junkie's dream. The bottom line is that they want to
charge everyone else for echomail so that they can have their 300 or
400 conferences for free, and you should never forget that. If an
echomail coordinator can honestly tell you that the "expenses" (in time
and effort) outweigh the benefits, and he hasn't put in his
resignation, then he's crazy... and do you really want a crazy person
as a coordinator?
4) Other networks get along just fine without geographic restrictions.
UseNet is much larger than Fidonet, and they don't have any such
restrictions. If Fidonet technical standards are so bad that we can't
control dupes without such restrictions, then we either need some new
standards, or we need to find ways to make the restrictions work
without using the "mental crutch" of a map. Besides, it's quite
possible to set up a dupe loop that is totally WITHIN a region, so
arbitrary geographic restrictions don't prevent dupe loops, they just
tend to confine them to a particular region. The point is, if control
is to be exercised, it should be over network topology, without regard
to geography. In my opinion, people who cannot understand the concept
of network topology unless they can overlay it onto a map have no
business being anywhere near a computer (unless a responsible adult is
present to put on the game disk for them)!
5) There ARE companies and individuals who would provide free echomail
service to many sysops if it were not for the restrictive policies. If
someone is going to provide a service for free, they don't want to be
hassled by petty dictators quoting some idiotic Policy provisions to
them. Many of the "free" echomail sources have gone away SOLELY
because of the hassle they were getting from the "Policy Freaks." I
suspect that some might come back, or some new ones might come into the
fold if the stupid echomail policy were declared dead.
6) I wonder what would happen if we were to start "Fidonet II"... a
second network with separate nodelist or nodelist segment (but still
officially part of Fidonet) in which nodes could affiliate with each
other on the basis of choice, not on the basis of some artificial
policy constraints? Let the marketplace decide which form of
government they prefer. Please note that in a net that does not have
geographic exclusivity, nodes COULD still choose to affiliate on a
primarily geographic basis, and I'm sure that many WOULD, but they just
wouldn't be FORCED to.
In the final analysis, what strikes me as really weird about Fidonet is
that so many of you are politically liberal, and seem to believe very
strongly in "freedom of speech" and "freedom of association", yet you
get on Fidonet and turn into ultraconservatives where Policy is
concerned. If that isn't hypocritical, I don't know what is. You'll
go after phone companies that want to charge a "data surcharge", or the
FCC because you hear a rumor that they want to impose a "modem tax",
FidoNews 9-05 Page 18 3 Feb 1992
but you let Fidonet coordinators get away with outrageous actions. I
just don't get it.
Anyway, it seems like all the bad things I predicted would happen if
geographic restrictions were allowed are coming to pass. I hate to say
"I told you so", but...
----------------------------------------------------------------------
FidoNews 9-05 Page 19 3 Feb 1992
======================================================================
LATEST VERSIONS
======================================================================
Latest Greatest SoftWare Versions
Latest Update: 01/27/92
----------------------------------------------------------------------
MS-DOS Systems
--------------
BBS Software NodeList Utilities Compression
Name Version Name Version Utilities
-------------------- -------------------- Name Version
ADTBBS 1.50@ EditNL 4.00 --------------------
Aurora 1.32b FDND 1.10 ARC 7.12
DMG 2.93 MakeNL 2.31 ARJ 2.20
DreamBBS 1.05 Parselst 1.33 LHA 2.13
Fido/FidoNet 12.21 Prune 1.40 PAK 2.51
Genesis Deluxe 3.2 SysNL 3.14 PKPak 3.61
GSBBS 3.02 XlatList 2.90 PKZip 1.10
Kitten 1.01 XlaxNode/Diff 2.53
Lynx 1.30
Maximus-CBCS 2.00
Merlin 1.39n Other Utilities(A-M) Other Utilities(N-Z)
Opus 1.73a* Name Version Name Version
Oracomm 5.M.6P@ -------------------- --------------------
Oracomm Plus 6.E@ 2DAPoint 1.50* Netsex 2.00b
PCBoard 14.5a 4Dog/4DMatrix 1.18 OFFLINE 1.35
Phoenix 1.07* ARCAsim 2.31 Oliver 1.0a
ProBoard 1.20* ARCmail 3.00* OSIRIS CBIS 3.02
QuickBBS 2.75 Areafix 1.20 PKInsert 7.10
RBBS 17.3b ConfMail 4.00 PolyXarc 2.1a
RemoteAccess 1.11* Crossnet 1.5 QM 1.00a
SimplexBBS 1.05 DOMAIN 1.42 QSort 4.04
SLBBS 2.15C* DEMM 1.06 RAD Plus 2.11
Socrates 1.11 DGMM 1.06 Raid 1.00
SuperBBS 1.12* DOMAIN 1.42 RBBSMail 18.0
SuperComm 0.99 EEngine 0.32 ScanToss 1.28
TAG 2.5g EMM 2.11* ScMail 1.00
TBBS 2.1 EZPoint 2.1 ScEdit 1.12
TComm/TCommNet 3.4 FGroup 1.00 Sirius 1.0x
Telegard 2.7* FidoPCB 1.0s@ SLMail 2.15C
TPBoard 6.1 FNPGate 2.70 SquishMail 1.00
TriTel 2.0* GateWorks 3.06e StarLink 1.01
WildCat! 3.02* GMail 2.05 TagMail 2.41
WWIV 4.20 GMD 3.10 TCOMMail 2.2
XBBS 1.77 GMM 1.21 Telemail 1.5*
GoldEd 2.31p TGroup 1.13
GROUP 2.23 TIRES 3.11
Network Mailers GUS 1.40 TMail 1.21
Name Version Harvey's Robot 4.10 TosScan 1.00
-------------------- HeadEdit 1.18 UFGATE 1.03
BinkleyTerm 2.50 HLIST 1.09 VPurge 4.09e
D'Bridge 1.30 IMAIL 1.20 WEdit 2.0@
Dreamer 1.06 InterPCB 1.31 WildMail 2.00
FidoNews 9-05 Page 20 3 Feb 1992
Dutchie 2.90c ISIS 5.12@ WMail 2.2
FrontDoor 2.02 Lola 1.01d WNode 2.1
InterMail 2.01 Mosaic 1.00b XRS 4.99
Milqtoast 1.00 MailBase 4.11a@ XST 2.3e
PreNM 1.48 MSG 4.5* YUPPIE! 2.00
SEAdog 4.60 MSGED 2.06 ZmailH 1.25
SEAmail 1.01 MsgLnk 1.0c ZSX 2.40
TIMS 1.0(mod8) MsgMstr 2.03a
MsgNum 4.16d
MSGTOSS 1.3
OS/2 Systems
------------
BBS Software Other Utilities(A-M Other Utilities(N-Z)
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Kitten 1.01 ARC 7.12 oMMM 1.52
Maximus-CBCS 2.00 ARC2 6.01 Omail 3.1
SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33
EchoStat 6.0 PKZip 1.02
EZPoint 2.1 PMSnoop 1.30
Network Mailers FGroup 1.00 PolyXOS2 2.1a
Name Version GROUP 2.23 QSort 2.1
-------------------- LH2 2.11 Raid 1.0
BinkleyTerm 2.50 MSG 4.2 Remapper 1.2
BinkleyTerm(S) 2.50 MsgEd 2.06c SquishMail 1.00
BinkleyTerm/2-MT MsgLink 1.0c Tick 2.0
1.40.02 MsgNum 4.16d VPurge 4.09e
SEAmail 1.01
Xenix/Unix 386
--------------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARC 5.21
C-LHARC 1.00
MsgEd 2.06
|Contact: Willy Paine 1:343/15,| MSGLINK 1.01
|or Eddy van Loo 2:285/406 | oMMM 1.42
Omail 1.00
ParseLst 1.32
Unzip 3.10
VPurge 4.08
Zoo 2.01
FidoNews 9-05 Page 21 3 Feb 1992
QNX
---
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
QTach2 1.09 QMM 0.50s Kermit 2.03
QCP 1.02
NodeList Utilities Archive Utilities QSave 3.6
Name Version Name Version QTTSysop 1.07.1
-------------------- -------------------- SeaLink 1.05
QNode 2.09 Arc 6.02 XModem 1.00
LH 1.00.2 YModem 1.01
Unzip 2.01 ZModem 0.02f
Zoo 2.01
Apple II
--------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
DDBBS + 8.0* Fruity Dog 2.0 deARC2e 2.1
GBBS Pro 2.1 ProSel 8.70*
ShrinkIt 3.30*
|Contact: Dennis McClain-Furmanski 1:275/42| ShrinkIt GS 1.04
Apple CP/M
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
Daisy 2j Daisy Mailer 0.38 Filer 2-D
MsgUtil 2.5
Nodecomp 0.37
PackUser 4
UNARC.Com 1.20
Macintosh
---------
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FBBS 0.91 Copernicus 1.0 ArcMac 1.3
Hermes 1.6.1 Tabby 2.2 AreaFix 1.6
Mansion 7.15 Compact Pro 1.30
Precision Sys. 0.95b EventMeister 1.0
Red Ryder Host 2.1 Export 3.21
Telefinder Host Import 3.2
FidoNews 9-05 Page 22 3 Feb 1992
2.12T10 LHARC 0.41
MacArd 0.04
Mantissa 3.21
Point System Mehitable 2.0
Software OriginatorII 2.0
Name Version PreStamp 3.2
-------------------- StuffIt Classic 1.6
Copernicus 1.00 SunDial 3.2
CounterPoint 1.09 TExport 1.92
MacWoof 1.1 TimeStamp 1.6
TImport 1.92
Tset 1.3
TSort 1.0
UNZIP 1.02c
Zenith 1.5
Zip Extract 0.10
Amiga
-----
BBS Software Network Mailers Other Software
Name Version Name Version Name Version
-------------------- -------------------- --------------------
4D-BBS 1.65 BinkleyTerm 1.00 Areafix 1.48
DLG Pro. 0.96b TrapDoor 1.80 AReceipt 1.5
Falcon CBCS 1.00 WelMat 0.44 ChameleonEdit 0.11
Starnet 1.0q@ ConfMail 1.12
TransAmiga 1.07 ElectricHerald 1.66
XenoLink 1.0 Compression FFRS 1.0@
Utilities FileMgr 2.08
Name Version Fozzle 1.0@
NodeList Utilities -------------------- Login 0.18
Name Version AmigArc 0.23 MessageFilter 1.52
-------------------- booz 1.01 Message View 1.12
ParseLst 1.66 LHARC 1.30 oMMM 1.50
Skyparse 2.30 LhA 1.10 PolyXAmy 2.02
TrapList 1.40 LZ 1.92 RMB 1.30
PkAX 1.00 Roof 46.15
UnZip 4.1 RoboWriter 1.02
Zippy (Unzip) 1.25 Rsh 4.07a
Zoo 2.01 Tick 0.75
TrapToss 1.20
|Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02
Atari ST/TT
-----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
FIDOdoor/ST 2.5.1 BinkleyTerm 2.40n9 ApplyList 1.00@
FiFo 2.1v The Box 1.95* Burep 1.1
LED ST 1.00 ComScan 1.04
MSGED 1.99 ConfMail 4.10
QuickBBS/ST 1.06* NodeList Utilities Echoscan 1.10
FidoNews 9-05 Page 23 3 Feb 1992
Name Version FDrenum 2.5.2
-------------------- FastPack 1.20
Compression ParseList 1.30 Import 1.14
Utilities EchoFix 1.20 oMMM 1.40
Name Version sTICK/Hatch 5.50 Pack 1.00
-------------------- Trenum 0.10
ARC 6.02
LHARC 2.01i
PackConvert
STZip 1.1*
UnJARST 2.00
WhatArc 2.02
Archimedes
----------
BBS Software Network Mailers Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
ARCbbs 1.61 BinkleyTerm ARC 1.20
Odyssey 0.37 2.06f-wimp !AskFor 1.01
RiscBBS 0.9.85m BatchPacker 1.00
DeLZ 0.01
MailED 0.95
NetFile 1.00
ParseLst 1.30
Raul 1.01
!Spark 2.16
!SparkMail 2.08
!SparkPlug 2.14
UnArj 2.21
UnZip 3.00
Zip 1.00
Tandy Color Computer 3 (OS-9 Level II)
--------------------------------------
BBS Software Compression Utility Other Utilities
Name Version Name Version Name Version
-------------------- -------------------- --------------------
RiBBS 2.02+ Ar 1.3 Ascan 1.2
DeArc 5.12 AutoFRL 2.0
OS9Arc 1.0 Bundle 2.2
UnZip 3.10 CKARC 1.1
UnLZH 3.0 EchoCheck 1.01
FReq 2.5a
LookNode 2.00
ParseLST
PReq 2.2
FidoNews 9-05 Page 24 3 Feb 1992
RList 1.03
RTick 2.00
UnBundle 1.4
UnSeen 1.1
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Key: + - Netmail Capable (Doesn't Require Additional Mailer Software)
* - Recently Updated Version
@ - New Addition
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
The Complete List is Available For FReq as VERSIONS from 1:103/250
Utility Authors: Please help keep this list up to date by reporting
all new versions to 1:103/250 in this format:
1) Software Name & Version 2) FileName.Ext
3) Support Node Address 4) Support BBS Phone Number
Note: It is not our intent to list all utilities here, only those
which verge on necessity. If you want it updated in the next
FidoNews, get it to me by Thursday evening.
--David French, 1:103/250
----------------------------------------------------------------------
FidoNews 9-05 Page 25 3 Feb 1992
======================================================================
FIDONEWS INFORMATION
======================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
Editors: Tom Jennings, Tim Pozar
Editors Emeritii: Thom Henderson, Dale Lovell, Vince Periello
Special thanks to Ken Kaplan, 1:100/22, aka Fido #22
"FidoNews" BBS
FidoNet 1:1/1
Internet
[email protected]
BBS (415)-863-2739 (9600 HST/V32)
(Postal Service mailing address)
FidoNews
Box 77731
San Francisco
CA 94107 USA
Published weekly by and for the Members of the FidoNet international
amateur electronic mail system. It is a compilation of individual
articles contributed by their authors or their authorized agents. The
contribution of articles to this compilation does not diminish the
rights of the authors. Opinions expressed in these articles are those
of the authors and not necessarily those of FidoNews.
FidoNews is copyright 1991 Fido Software. All rights reserved.
Duplication and/or distribution permitted for noncommercial purposes
only. For use in other circumstances, please contact FidoNews (we're
easy).
OBTAINING COPIES: FidoNews in electronic form may be obtained from
the FidoNews BBS via manual download or Wazoo FileRequest, or from
various sites in the FidoNet and via uucp. PRINTED COPIES mailed
may be obtained from Fido Software for $5.00US each PostPaid First
Class within North America, or $7.00US elsewhere, mailed Air Mail.
(US funds drawn upon a US bank only.)
Periodic subscriptions are not available at this time; if enough
people request it I will implement it.
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable
from 1:1/1 as file "ARTSPEC.DOC".
FidoNews 9-05 Page 26 3 Feb 1992
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings of Fido Software, Box 77731, San Francisco
CA 94107, USA and are used with permission.
-- END
----------------------------------------------------------------------
