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: | | \ \\ | fidonews@fidonews.fidonet.org | (*) | \ )) | |__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...... 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. 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 . 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 fidonews@fidonews.fidonet.org 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 ----------------------------------------------------------------------