Ú¿Ú¿Ú¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿Ú¿ Ú¿ÚÄ¿ Ú¿ÚÄÄÄÄ¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿ ÉÍÍÍÍÍÍÍÍÍÍÍÍͳ³³³³³³³³³³³ÀÄ¿ÚÄÙ³³ ³³³ À¿³³³ÚÄÄÄÙ³³³³³³³ÚÄÄÄÙÍÍÍÍÍÍÍÍÍÍÍÍÍ» º Volume 4 ³³³³³³³³³³³³ ³³ ÀÅ¿ÚÅÙ³ ÀÙ³³ÀÄÄÄ¿³³³³³³³ÀÄÄÄ¿ June/July º º Issue 2 ³³³³³³³³³³³³ ³³ ³³³³ ³Ú¿ ³³ÚÄÄÄÙ³³³³³³ÀÄÄÄ¿³ 1993 º ÈÍÍÍÍÍÍÍÍÍÑÍÍͳÀÙÀÙ³³ÀÙÀÙ³ÚÄÙÀÄ¿ ÀÅÅÙ ³³À¿ ³³ÀÄÄÄ¿³ÀÙÀÙ³ÚÄÄÄÙ³ÍÍÍÑÍÍÍÍÍÍÍÍͼ ³ ÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ÀÙ ÀÙ ÀÄÙÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ³ ³ The Electronic Forum for WWIVNet Sysops & Users! ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³This Issue's Features³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Random Factors...................................Wayne Bell (1@1) ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ WWIVNews Feature Topic: The UU Debate ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ Introduction to the UU Debate....................Omega Man (1@5282) ³ ³ ³ ³ Editorial Contributors...........................The Menace (1@4071) ³ ³ Redman (1@16950) ³ ³ Sleepy (1@3085) ³ ³ Snorkel (1@3459) ³ ³ ³ ³ Technical Contributors...........................Deltigar (1@1052) ³ ³ Snorkel (1@3459) ³ ³ Tolkien (1@3456) ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Filo's Mod of the Month..........................Filo (1@2050) ³ ³ ³ ³ Type 0 Forum.....................................Omega Man (1@5282) ³ ³ ³ ³ WWIV-Compatible Networks List....................Red Dwarf (1@6264) ³ ³ ³ ³ TechnOTES........................................WWIVNews Staff ³ ³ ³ ³ Dateline: @#$*()#!...............................Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Random Factors ³ ³ Creative Commentary by Wayne Bell (1@1) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Quite a few things to discuss this issue, so let's get started: NET33 BUG: Yes, NET33 does have a bug where the 'BAD PW' SSM lops off the last digit of a node number. That's because i had strlen(s+1) instead of strlen(s)+1. This has been fixed for NET34, and the current one is still usable as an error flag If you see there's a bad PW, you can always look at NET.LOG and see which node is having connection problems. NET34: NET34 should have multiple nets in the same callout, although I haven't started coding that part of it yet. As usual, there have been a few minor bug fixes since net33. No major changes have been done yet, though. I (obviously) do not have a release date set yet. NEW DE1.EXE: As most of you saw in the last mail_to_all_sysops, I've sent out a new DE1.EXE. (If you haven't installed it, then you won't be reading this.)This was sent as a UU encoded .ZIP file. To use this, you need to UUDecode it, unZip it, then overwrite your current WWIVNet DE1.EXE with this. You should no longer use the old DE1.EXE (the one in NET*.ZIP). There have been those on some of the Sysop subs that have shown concern whether the UU'd file did in fact originate from @1, despite the source verification flags. If you're one of those who are still worried about this, take a look at the archive once you've decoded it. If PKZIP reports the CRC as 331fe474, then you have an authentic copy. If you are in more than one network, make sure you overwrite the correct DE1.EXE. Your DE1.EXE is probably in your WWIVNet data directory, or if not there, probably in your main WWIV directory. This new DE1.EXE utilizes compression (PKWare Data Compression Library) to reduce the size of net updates, and hopefully decrease network costs. This also means it is slower than the older version. An aside note to the AC's and GC's: Please make sure that new systems joining the network receive this new DE1.EXE. It's also suggested that you make it available for download by those sysops who are either unfamiliar or uncomfortable with the use of the UUDECODE procedures. WWIV v4.23: WWIV v4.23 is being worked on now. No, I do not have a preliminary date set for its release yet. I will let people know when a date is set, so please do not email me to ask. Unlike previous releases, though, v4.23 will have some significant portions of the new/upgraded code installed by other people. Tolkien (@3456) has installed a number of new features, augmented existing ones, and has made a lot of cosmetic changes. Jim Wire (@3950) is in the process of installing multi-instance (multi-line) code, and that should be being tested by the time this WWIVnews is released. v4.23 already has multi-languages supported (although most of the code for that was in v4.22 also, and not many non-English language .str files are available yet). Shakespear (2@2050) is currently working on a FidoNet implementation, which should work more elegantly than existing interfaces (which require "fake" fidonet node numbers (@6xx)). UU'D FILES & WWIVNet: As has been made clear in the mail-to-all-sysops before the one containing the DE1.EXE update, files should >NOT< be sent through WWIVNet, except if you have the permission of all intervening systems. This covers not only UUENCODEd files, but also PACKSCAN files, and any other method that may pop up. Yes, many times it may be convenient to use WWIVNet to send files to someone. However, by sending them through the net, you make other people pay for your convenience, which is not fair. If you have a need currently to send files to someone on a continuing basis, the best way is to set up your own mini- network, and then send files (uuencoded or via PACKSCAN) on your own network. That leaves the convenience for you, does not cost other people anything, and will not end up routing normal WWIVNet traffic between your systems (as would be the case if you simply added a WWIVNet connection between systems). I know some systems in the St. Louis area have set up their own separate network for this very purpose. Some people have complained to me about the no-file policy, saying things like "But I already pay $xx a month for dues to the server." Yes, but that is for just ONE server. messages of any type on the net tend to go through many intervening systems, not just the one server. Files also tend to be much larger than normal net traffic, and server dues are based upon normal traffic, not based upon the few people who want to send large files. In any case, in the relatively near future (no, no date yet), there will be an FREQ-type program available for WWIV systems, which will allow direct transfer of files between WWIV systems, not using any network. This will end up being (I believe) the most convenient method, and will limit the costs to those actually doing file transfers. Rules and policies regarding this matter will be covered in detail in the new WWIVNet policy docs that will accompany the release of NET33.ZIP. Any questions regarding the FREQ utility should be directed to the author, 2@2050. REGISTRATION & MULTI-LINE WWIV: Prior to this writing, I've received several E-Mails regarding the per-line registration deal. I would like to take a somewhat more mellow attitude about it right now, than what these people seem to think is the situation. Basically, explaining what the situation is, why changes are necessary, and what we're currently proposing, and why. This opposed to taking the attitude of "This is it, love it or leave it." Previously, the license agreement has not explicitly addressed the issue of running a multiple line WWIV, as until recently, it has only been possible to run it on one line (and even so, not many people have been going multi-line with it so far anyway). Since more and more people have become interested in running multi-lines, and since v4.23 will probably support multiple lines, obviously the license should be modified to explicitly address the multi-line issue. That much, everyone should agree with. The real issue, therefore, is in what way should multi-lines be handled (in the license)? A long time ago, someone (I'm sure) wanted to run two WWIV's. Not multi-line, but two separate BBS's. The question therefore came up, "Do I need one or two registrations?" If someone could run two BBS's with one registration, then it would also be possible for someone to say, "Yes, I run two BBS's - one at my house, and one at my friend John's house" as a way to try to get John's BBS to count as registered for "free." Also, other DOS-based licenses (eg, BC++) don't work that way - the license is for one copy on one computer. In any case, as I understand copyright law (and they just gave a big lecture at work on this), the standard license is for one copy on one computer. Anything beyond that has to be explicitly granted by the license agreement. So, obviously, if someone was running two BBS's, he needed two registrations. That "decision" also expanded when someone wanted to run two separate BBS's on the same computer (under DV, say). It therefore came to be "one registration per phone line." I'm almost certain I've posted that on at least one sysop's sub. Currently, that also applies to one person running a two-line BBS. Yes, I agree that's not perfectly fair, but it's all I could come up with. If I went with anything less restrictive than that, it would become possible for people to 'cheat' on it (although I don't think most people would intend to do that). "But," I hear people saying, "I can mod my BBS however I want, and I choose to mod it to handle multiple lines." Actually, that's not accurate. What people have done to handle multiple lines is modify the BBS so that multiple copies can be running simultaneously, not that one copy can handle multiple lines (that is, the difference between having one BBS.EXE running, and having more than one BBS.EXE running). So, even though it is one computer handling two phone lines, it is still two BBS.EXE's running at the same time. That's two copies. Thus the need for two registrations. Let me explain the difference there a bit more. Modifying your BBS to handle multiple phone lines would mean that you would have one BBS.EXE running on your machine, which would have the multi-tasking code built into it, and it would be the same BBS.EXE that was handling all users (on the same CPU). What people have done is to have the BBS.EXE's lock files, and gracefully allow multiple BBS.EXE's to access the same files almost concurrently. Unfortunately, since DOS machines can typically handle only one user at a time, DOS people have never encountered real multi-user licenses. In other environments (eg, UNIX, which is what I use at work), where multi-user machines are common, the typical licensing agreement is for a set number of concurrently running copies. For example, FrameMaker (a word-processor type program) has a "license server" program running on one machine in a network. Whenever a user (on that machine or on another) wants to run FrameMaker, their copy of FrameMaker gets a "license" from the license server. The server ensures that no more than the set number of licenses are active at a time. If you need to run more than that, then you pay more money for more licenses, and they send you a new keyfile or password to enable the greater number of licenses (the keyfile/password is based upon the machine name/serial-number/ ethernet-address, to ensure that you don't use the same key/pass on more than one machine). So, in response to all this, the WWIV license is being changed to be less restrictive. Instead of having to have a separate registration for each phone line, people will now be able to (legally) run a multi-line WWIV paying much less than $80 per line. Hopefully this clarifies matters a bit. UTILITY.WW4: Finally, Filo (1@2050) is in the process of compiling a comprehensive list of utilities for WWIV, to be included in the documentation package. If you wish to have your utility (or utilities, as the case may be) the following information should be submitted: FILENAME.EXT, Author's Name, ID, Description ^ ^ ^ ^ ^ : : : : :...Description MUST not be longer than : : : : 102 characters including spaces. : : : : If it is available only at a fee : : : : then include the fee in the : : : : description. : : : : : : : :....... Use PD, SW, or CM as ID to : : : indicate Public Domain, ShareWare : : : or commercial. : : : : : :.................. Self Explanatory : : : :.......................... Type of Compression used : :................................. Filename used as identification Submissions can be sent to the following addresses: WWIVNet: 1@830 WWIVLink: WWIVNet #1 at 830 @2050 IceNET: WWIVNet #1 at 830 @2050 That's all for now. See you next issue. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Introduction To The UU Debate ³ ³ by Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Transmission of UU encoded files over WWIVNet has been a topic of debate for as long as the net has been in operation. The arguments for and against the use of UU encoding have periodically turned sysop subs across the net into heated flamefest arenas, producing lots of hurt feelings and very few real answers to the questions raised. The questions raised were simple ones with complex answers. Was the UU method actually more efficient than a file request network relying on direct hookups? Were UU'd files containing archives actually larger than the archives by themselves? Should text files be UU'd? Do servers and pass-through nodes have the right to scan network packets and purge UU'd files regardless of size or content? Does the WWIVNet as a whole have the responsibility to bear the costs involved in sending such large files, or does it have the right to take steps as a whole to prevent this perceived abuse of resources? Oddly enough, while it appeared the majority of WWIVNet was against UU'd file transmissions, many of those opposed also expressed their doubts against any sort of absolute rule against their use. At the same time, those in favor of few or no controls on UU transmission were also some of the more outspoken and persuasive members of WWIVNet, and what they lacked in acceptance among their peers they made up for with tenacity and aggressiveness. In an effort to help present all sides of this serious issue, WWIVNews placed a Call for Articles on UU encoding. There were quite a few submissions for editorials, as well as several reviews and technical articles regarding the various utilities designed to manage - and even eliminate - network packets containing UU'd files. However, as this issue was being compiled, WWIVNet 1@1 issued what can best be described as "The Last Word" on UU transmissions. As a result, several of those who submitted editorials on this topic requested that their submissions be dropped from publication. The reason cited was the same in all cases: Wayne had rendered the debate a moot issue, and the forthcoming release of a File Request netutil simply added the final nail to the coffin. Still, there were some views that were allowed to be expressed. The following editorials, technical papers, and product reviews are the remainder of the 30+ submissions on this topic. While the matter has arguably been settled, for future reference the WWIVNews staff came to the consensus to publish the remaining submissions, as presented below. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The Menace (WWIVNet 1@4071) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ As of late there has been a controversy concerning UUENCODED files being transferred across WWIVNet. A UUENCODED file (UUE) is coded with a special program called UUENCODE, a program common to the UNIX world. By UUE'ing a file, WWIVNet is capable of sending it across the network as a message. This encoding is done since WWIVNet and WWIV itself, does not have the capability of transferring files between nodes of the network. Upon receipt of this encoded file, you would use UUDECODE to transform it back to it's original usable/readable state. The issue seems to reside in the cost of the network connects. When these UUE files are transferred across the network, and distributed amongst the some 5000 BBS's in WWIVNet, each system must endure the extra cost and time, in addition to the normal cost associated with a normal network transfer. This issue may not seem like a concern to many, but there are those who abuse the freedom that WWIVNet offers. Occasionally sending a UUE file is not the issue, it is the constant transfer of packets containing large UUENCODED files created by rather lazy users. Most of these Sysops are accepting the increase in phone charges without a charge to the users. Most Sysops start a BBS because it is fun, and the idea behind WWIVNet was the free flow of information. These UUENCODED files in net packets, increase the cost of running a BBS and are tarnishing the charm of being "networked". In addition, some users and/or Sysops have been sending Non-Public Domain files (NPD) across the net in a UUE fashion. This exchange of illegal files is somewhat alarming to the Sysops who do not wish to associated with that part of BBS'ing community. The possibility of legal action being taken against a sysop on a network who has packets containing NPD software could be a major detraction to those that only wish to use the network as a message medium. A few users have compared WWIVNet to FidoNet, where files from other sites are allowed to be transferred and housed by your system. WWIVNet is a different medium all together. That feature was built into FidoNet by its creator, not much unlike the way it was left out by the creator of WWIV. Wayne wanted a message based BBS to exchange ideas and information, not files. My opinion, although it will probably anger many, is to come up with a simple across-the-board policy/standard. I think we should disallow ALL UUENCODED files from being transferred across WWIVNet. I feel that we can not compare apples to oranges anymore. We must decided together what the policy for the network is. In this decision, there should be fair consideration to all, no matter who they are or for what reasons they run their BBS. This approach seems fairest to everyone involved. I have heard talk of a feature in an upcoming release of WWIV, where you would be able to send a file directly to another node by aid of the BBS list. This way the cost would be incurred directly to the system who intends to send the file. This seems to be a wise solution, if it is possible to implement. The Sysop of the originating system could be notified about the file for transfer, and have final say as to whether he should let the file be transferred directly to the intended receiver node. Much like the NET VALIDATION option in the netted WWIV subs, this would help sysops to regulate the network into an orderly manner for all, yet maintain a high degree of fairness. Sysops would have a say in how their systems would be used.... ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Sleepy (1@3085) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ There has been more than enough discussion on the transfer of UU'd files across WWIVnet. It seems to me that some of the more obvious (not to mention Important) reasons against them have been completely ignored. That is what prompted me to offer my opinion for everyone to read. One more thought before I get to it, please remember that this is only my opinion, backed up with a few facts that are available to all WWIVnet SysOp's, the only thing I did was Read The Docs... Here is a partial quote from the WWIVNET.DOC Introduction, which *everyone* should have read. This quote maybe considered superfluous by a lot of you however, everything and everyone *Must* start somewhere. "WWIVnet is a voluntary association of bulletin boards using WWIV software, and participating in a network by calling one another to facilitate the transfer of electronic mail (e-mail) and message bases (subs)..." "Through this network, a user of any of the bulletin boards that are members may send e-mail to a user of any other board. A User may also post on a message base which may be read by the users of systems which subscribe to that message base;...Because this system of Communication read by others and because it has an effect on systems other than the one on which it originates, a spirit of cooperation must prevail. Out of this spirit grows a system of organization and regulation which are discussed in the pages that follow." After reading the above documentation there is only one intelligent interpretation: Data (be it messages or files) transferred on WWIVnet *MUST* be WWIVnet Message Subs posts or WWIVnet e-mail. IMHO if nothing else common sense should have turned a light on somewhere. Since we are all only human, and as such have responsibilities, some with families, but all with the same feelings that are too often hurt. We should be able to afford one another common courtesy. Common Courtesy is easily given and should be extended to everyone in the same manner and degree that we should all like to expect to receive. I don't run up your phone bill so don't you run up mine. We have all agreed to incur the costs necessary to transfer WWIVnet to and from our connects, some connects are fortunate enough to be local to one another. But there are some out there that must pay to transfer their packets. I don't mean to sound condescending, I honestly believe that all of us were taught manners by our parents. Everyone wants to be liked and wants to like everyone in return. However when Joe Blow on AbracadrabraNet will send anything and everything over his network, that does not mean that Wayne Bell allows the same. What matters is what is fair. Plain and simple, you don't use Sally's phone to do Sam's business nor can you expect others to incur charges for something that has nothing to do with what they are interested in. Would you pay for you neighbor's newspaper, say the daily East Palooka Extra? Oh that isn't the newspaper that you wanted to read? So sorry, but it is already here so what can you do??? It is impossible to run a board without expecting it to cost money. But the normal expenses are high enough without having to pay for another board's interest in a network that you have no interest in. And saying that sending "Mod" files is not fair because other files cannot be sent is completely unfair. The "Mod" files that are sent are for a Message base (which is in the Documentation as legit data) and the majority of SysOp's in WWIVnet do benefit from the Mods. I truly believe the whole UU'd discussion took place only because the file's being sent could be considered "unsolicited junkmail". I'm not calling anyone's Network Junk...I along with I'm sure 99% of the other WWIV SysOp's, don't begrudge success to anyone in any project they wish to pursue. We just don't want to foot the bill. Most of us have already agreed that we don't what unsolicited e-mail, so the same would (IMHO) be true of files that have nothing to do with WWIVnet. Although I do not believe that UU'd files should be completely banned, but once the guidelines are abused the abuse will continue. Most of the SysOp's that I know fairly well have no problems with WWIVnet files being UU'd and sent. If someone wants a file bad enough they should pay for it. Whether they are paying for a Commercial file or for the toll charges for a Shareware download. We should all care about each other's feelings, boards and pocket's. We are all in it for the same reason....FUN! We know just how hard we all have to work at keeping our boards running. Have a little respect for your fellow SysOp's and you'll get a lot in return. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Redman (1@16950) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The practice of sending a UUE of your net package through another net is not a very good idea. This is not a practice that other nets should follow. To start with there was a reason for your starting your own network. And I am sure that one of the reasons was that you felt you had something better to offer. Therefore, having started your own net, it would only be proper that you do not send your net startup package, nor updates through another net. In my opinion you should either call that board or have the board that wants to join, call your board for the package. But to send a UUE of your net package for any reason is not right. I am sure that there is a reason for the UUE's. Otherwise the program would not have been made. But to use it for one network to send your net package over another network (Even if it is just one {this time}) is not right. You and I both know that it is not a 1 time thing. I am sure that many updates (startup) packages are being sent. I am the AC of DEADnet and I WILL NOT SEND the initial package or even an upgrade on someone else's network. Other networks were set up (more then likely) because WWIVnet did not quite suit your needs. Therefore you MUST be obligated to either a) pay for calling the board that wants to join your net, or b) have them call you. Seams BLACK AND WHITE. Reason being that I would not want another network to be sending their updates or start up packages through my net. Look at it this way, those that have set up nets did so with the understanding that their net would be used for their net, not for other networks. Would you like to set up a net and have other networks tieing up all of your members boards sending their network through yours? I do not think so! And to think that you can send it in UUE and then complain because it was deleted is moronic. It plainly states in the doc's that UUE's are allowed for the MOD sub ONLY. Reasoning behind this was so that those that program would be able to send ( small ) exe's and com's in a mod. Plus the big boys of WWIV have set a size limit for UUE's as well. I would venture to say that this was to help prevent huge phone bills for the LD connections. This purpose was for the benefit of most network users. So now you are thinking, "Why only allow UUE's for the MOD sub". Well even I can figure this out. The mods are a benefit to all that use them. And I would venture to say that the majority of netted boards have mods installed. But I would also bet you that most boards do not carry your net. Thus allowing UUE's in the MOD sub only is understandable. Besides this one little example, the proper use of UUE's is in the doc's and that makes it a rule. So to summarize this all up in a nut shell. UUE's are only allowed in the MOD sub. You as a network sysop, have the right to use UUE's only as stated in the doc's and not as a way to send your net (upgrades and or startup) packages. It is not right, nor is it allowed to use UUE for any other purpose. It is also well known that Net33 will have detailed rules concerning the use of UUE's. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Snorkel (1@3459) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ "Could someone please send me the Latest copy of McAfee's Clean and Scan? Mine is old and I don't want to take any chances." How often have you seen requests like that on Network subs? How often have you been a "good buddy" and responded to such requests? I know I have! Most of us have good local connects, so all it costs us is a couple of minutes to UUEncode or Packscan the file and stick it on the net. It's great to be on the receiving end too, as it saves an LD call. The file you requested just appears on your board in a couple of days. Often you may get several copies since WWIVnet is a friendly place where a spirit of helpfulness and cooperation prevail (most of the time). There is just one small thing we have overlooked while we were being so helpful. Just how did those utilities get from your system to the person who wanted them. Well, it may have looked something like this: SENDER --> 1040 --> 1050 --> 1120 --> 3314 --> RECEIVER Ok, you are local to 1040, so that is a free call. 1040, 1050, 1120, and 3314 are Long Distance calls to each other so THEY EACH have to PAY the phone company in order to move the utilities. Since the receiving system is local to 3314, he doesn't incur any expense. I think at this point you can see the problem. The mail servers and hubs are stuck PAYING to move YOUR FILES. When they agreed to allow other systems to connect to them, and to act as a net mail server, they understood they would be handling MESSAGE traffic. Even though the average message is less than 1k, the bills add up fast. Servers routinely pay the phone company over $100 per month just to move MESSAGES. Remember those utilities you sent out? After UUEncoding they probably exceeded 300k. It doesn't take many people sending this type of stuff to add $25 to $50 a month to a servers bill. It is their right and responsibility to try and limit the non message traffic. It is their LD bill at stake. Without these Servers there would be NO WWIVnet! Now, it seems that some of these helpful, cooperative sysops became nasty and abusive, when advised that WWIVnet was for MESSAGES, not FILE transfers. It was explained that this practice is against network guidelines, and incurs extra costs for the systems handling the mail. They were asked nicely not to send their files over the net, and these requests were met with comments like: "It's my right, This is a public network, You can't stop me, I'll just find another way, etc" At this point, Tolkien went to work on a utility to detect UUEncoded messages and several other types of encoding that could be carrying "files". NetProbe was born. This program was not cheap, nor was it easy to get. Tolkien put in place a number of safeguards to insure it would never fall into irresponsible hands. Despite the cost, a number of the Mail Server systems and Hubs shelled out the cash in hopes they could control this abuse of the net. UUEing is the most popular way of sending "programs" over the net. The easiest way to curb this was to target the vehicle (UUEncoding & Packscan). Since UUEing is a valuable way of moving mods and other small files containing small EXEs and OBJs, it was decided to ONLY stop the LARGE and MULTIPLE ones, as they would be the most likely to contain "programs". NetProbe does NOT delete these messages, it simply flags them by moving them into a separate file. At that point, the large ones are either passed or deleted at the Server Sysops' option. If they are deleted, the system(s) involved will get at least ONE warning. Further attempts will be deleted, and if it continues, the GC/NC will be notified. The size limit is a figure that the NetProbe Servers could collectively agree on. Some favored NO UUEs at all, while others didn't mind singles up to the 32k net limit. Small-(less than 10k)-SINGLE-UUEs still flow freely! Also, a few subs (like ModNet) that benefit the greater portion of the net were exempted from the scan. Unfortunately, as with any filter, you sometimes catch things you don't want, but for the most part, the program is working VERY well. I compiled some stats on the volume of UUE type files flowing through here (6211) for the last couple of months. Feb : 3.5 meg (including several copyrighted major programs) Mar : 2 meg Apr : .8 meg (and none had to be stopped !) Last month the only UUEs were those going to & from ModNet (only 147k) and those going to & from systems who have a common connect here. The phone bill is lower, and the sysop is smiling. I'm afraid that if the current attitude held by many sysops that "I can send what I want at someone else's expense" continues, Wayne will pull the plug completely and prohibit the use of UUE, Packscan, etc completely over the net! How many of you that are complaining know what would happen if 1040 (Filo), 1042, 1050, 1051, 1111, 1112, etc, decided that this was costing too much and shut down their servers.......? It's truly sad that so many Sysops have so LITTLE RESPECT for the people that pay the LD bills so WWIVnet, IceNET, etc, can exist! Of course, there are lots of questions to be answered about this situation. Question: I can Zip a 10k text file and then UUEncode it and it ends up smaller than the original (about 8k). Wouldn't that be a better way of sending mods and large text files? Answer: No. Network compression or your modem's internal compression (MNP5 or V.42bis) will compress that 10k text file down to about 5k. The Zipped/UUEncoded version will not compress down much more than it already is. In fact even though it appears smaller on your hard disk, the Zipped/UUEd version will have about 20% to 30% more bytes to transmit. Question: I have a large mod I want to post on ModNet. It is larger than the 32k network message limit. If I zip it, and UUE it, then it will fit. It this ok? Answer: No, for two reasons. First, if you split it into two text files and send them normally, it will take less LD time to transmit them (saving everyone money). Second, most people want to look at a mod before they decide if they want it. If it's UUEd, they can't do that. The ONLY reason to UUE a mod is if you have to include a small EXE or OBJ with it. If so, you should post a message ahead of it describing exactly what it is. Question: Can I be sure any UUEs (under 10k) that I send will get through? Answer: That depends on the Server. The NetProbe systems have agreed on a "defacto standard" for what to pass. Some servers are more (or less) tolerant than others. Even though NetProbe only flags large UUEs and PACKSCANs, it generates a report of ALL of them that pass through the node. If a sysop observes you are sending many small UUE's, he may suspect you are trying to put one over on him by breaking files up into tiny packets. In that case he would probably put a stop to it. Question: How many warnings will I get? Answer: A busy Sever Sysop may not have the time to examine and make individual decisions on UUE containing messages that have been flagged. He may just kill them, send you one warning and be done with it. Others may prefer not to keep a list of who has had warnings and who hasn't, so you may get more than one warning from them. Question: Why are you stopping UUEs? They aren't the enemy, it's the EXEs in them that are the problem. Answer: If there had been an easy way to only stop UUEs carrying EXEs, and not mods or OBJs, that would have been much better, but under the circumstances, we just have to put up with a little inconvenience in order to keep the net healthy. The intent is to put an end to using WWIVnet to transfer "programs"! It's just too bad that some legitimate uses for UUEing have been caught in the sieve. Question: I thought one of the beauties of WWIVnet was that it didn't have a lot of rules. I was one of the first systems in the net. All these rules didn't exist then and everything worked fine. Don't you think you have gone a little overboard? Answer: Ah... the good old days. Possibly, the fact that computers were more expensive, not everyone had one, and the net was smaller contributed to a strong sense of cooperation and respect. At that point, if someone said " You can connect here, but please keep the traffic low" all the connects would try their best to do so. Now when one of the servers ask for a little cooperation or respect, all they get is " You can't do that, It's my right, etc". Question: Who gave these "Servers" the right to "censor" my mail? I think their power has gone to their heads. Answer: Don't you think they have the 'right' and 'responsibility' to do their best to keep network traffic flowing? Along with the obvious cost factor, they have to maintain enough hard disk space. It takes up to 3 times the packet size to process an incoming packet. If WWIV allowed file transfers, many servers would go down due to the increased cost. Those that didn't would have to get larger hard disks and faster systems. Since at this time, file transfers aren't allowed, why should these Sysops have to foot the cost for those who would abuse the system. It is their RESPONSIBILITY to filter out file transfers so we can maintain the excellent mail service we now enjoy. If and when file transfers are permitted on the net, I suspect we will see the demise of the free connects. Question: One 10 UUE doesn't cost a high speed system more than a couple of pennies. Why all the fuss? Answer: You are correct. The cost of a single small UUE is insignificant, and that is why they still pass freely. Review the stats I posted earlier in this article where I showed the reduction in UUE type files over the last few months. The Program is working. For a system like 1021, his savings were on the order of $40 per month (don't quote me on that figure). That's nearly $500 per year. Enough for a nice new hard disk, or summer camp for the kids, etc... Question: All the discussion on banning UUEs has probably cost as much as will ever be saved by doing so. Why didn't someone explain what was happening before NetProbe went into use? Answer: I think for the most part, all this bickering is the fault of the NetProbe systems themselves. We failed to completely and fully explain what was happening initially. I guess that was my job. I told Tolkien I would handle getting a "Press Release" out, and I let it slide. Things escalated from there. I sincerely hope this article helps clear things up. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Deltigar (1@1052) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FILEnet is a network dedicated to making file transfers as easy as possible while at the same time making some transfers unnecessary. The former is made possible with the latest in File Transfer software designed specifically for FILEnet. The latter is a byproduct of being able to request lists of files from other FILEnet systems. The concept I have put into play is one of a Server/End Node only network. This allows the individual sysop to choose what traffic flows through their system. On the application form, you are asked several questions concerning what type of connection you want. All Servers connect to each other, and all End Nodes connect to at least one server. This keeps the maximum number of hops to 3. This is mainly to keep the total cost of transfers as low as possible. Unfortunately, it is one of the lesser understood aspects of FILEnet. I often get an application from someone who doesn't understand why he is not just connected to another FILEnet node simply because he is local. Granted, a connect will be established because they ARE local, but unless the other node is a Server, the new node will ALSO have to connect to a server. I would like to ask potential new members to please NOT request a connect to an End Node as your primary connect. If that individual wishes to pick up your traffic, they will have to become a server to keep the maximum hop down to 3. If this individual had wanted to do so in the first place, they would already be a server. Server connections are "Call In Only" or "Shared". Call In Only connections are for End Nodes who are paying for all of their incoming and outgoing traffic. Shared means that both the Server and the End Node pick up the tab. In FILEnet, the importance of the Server cannot be stressed enough. End Nodes are those nodes whose traffic is theirs, and theirs alone. They may limit the files leaving simply by editing the configuration files. In their default state, no files re allowed to be transferred off the new system. Only by adding the directory numbers to DIRLIST.FTS in the FILEnet directory can files be made available to FILEnet. Limiting the incoming files is simply a matter of restraint. If you don't use either FTSREQ or the User File Request Door, you will not receive files from FILEnet (Except normal net updates). The Software we use in FILEnet has been specially developed by myself and Private Idaho. It is intended to be the standard FILEnet software. However, it is still quite acceptable to use PackScan, WWFNET, or any other method of sending whole files through the net. You simply need to keep in mind that the other systems you are dealing with also need to be running that software. If they do not, then the standard system is still there. For more information on the development of the new software, and improvements that are being made, FILEnet Software Development is autorequestable on all major networks, and a few minor ones. Check your favorite network's subs list for the subtype nearest you. [Deltigar's NOTE: Subtypes are WWIVnet 11052, IceNET 11084, WWIVLink 11184, TARDISNet 11052, FILEnet 101 and TLCnet 155.] The ONLY transfer method that is expressly banned, is UUE traffic. This is not because we don't want files sent, it is simply because everything else is so much more cost effective. UUE files are bigger than the zip files they contain, so why not just send the zip file?! The standard FILEnet software is EASIER to use than UUEncoding anyway. With the ability to post on certain FDL's, UUEncoded subs have become obsolete. There are two classes of file transfers on FILEnet: FDL and FTS. FDL - File Distribution List. This system allows a sysop to subscribe to an FDL (with FDLREQ.EXE) or host one (with FDL.EXE). The concept is somewhat like a one way message base. The host posts a file, such as a new release, or updated utility, and it is automatically sent out to the subscribing nodes. On certain FDL's posts are allowed, making the entire system behave like a networked directory. This, IMHO, can UUEnd the UUDebate for good. FTS - File Transfer System. This system allows a sysop to send a single file to a single node (with FTSEND.EXE), or to request one to be sent (with FTSREQ.EXE). A listing of all files available on a system may also be requested (also with FTSREQ.EXE). The system receiving the request has complete control over which files are made available for request (with DIRLIST.FTS) and my block out any systems they do not wish to grant access to (with BADNODES.FTS). One thing we would like to work for is to make FILEnet the network that other networks use to transfer files, since files are generally of a nature that all sysops want, and are not usually network specific. A good example is the HS/Link File Distribution List. Once a sysop has subscribed to this list he/she is assured of receiving the latest version of HS/Link very shortly after it is released. Another goal is to get software developers hooked into FILEnet. This will greatly decrease the time between when a product is released, and when it becomes widespread. Already we have Diamond, who recently made a splash with MO, a new message base optimizer and Private Idaho, who is probably best known for his GoSnarf utility. In order to join FILEnet, there has historically been a very strict ritual involved -- one must ASK to join. You must also be a REGISTERED WWIV sysop. That simple. The reason behind requiring registration is quite simple. There are plenty of other networks out there for new WWIV sysops to cut their teeth on. FILEnet is not network you would want to make mistakes on. A single misunderstanding could land you a BIG phone bill. You also should be very familiar with the WWIV software, and if you are that familiar with it, then your registration trial period has probably already passed . The VBBS Problem - Since our software reads many of the configuration and data files on a WWIV system, and due to our lack of VBBS software developers, we have yet to design an interface for VBBS systems. It is my sincere hope that sometime in the near future a VBBS programmer will subscribe to FILEnet Software Development (Offered on all major networks) and help us open FILEnet to REGISTERED VBBS sysops as well. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The FILEnet Application ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The EASIEST way to give the information needed is to simply extract the line for your system from the applicable BBSLIST file in your primary WWIV-Based network. Insert it below, or fill out the top paragraph. You will be notified as to what your FILEnet Node number will be as soon as this form is received. You will also be notified as to which server you will be connected to. If you have a FILEnet server in your area, please indicate which one it is. Node Phone Number Rate Reg# Compat BBS Name @0000 *000-000-0000 #00000 [00000] !$? "Your BBS Name Goes Here" @ Major Net/Node Number: * Complete Phone Number: # Highest Modem Speed : [] WWIV Registration Num: !$ Modem Compatibility : "" System Name : Do you want to be an End Node or a Server? ÄÄ End Nodes Only ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ What type of Connection do you want? -Call In Only (YOU pay for all YOUR traffic) -Shared (You SHARE cost with a Server) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄ Servers Only ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Free Drive Space: Your VOICE Phone: Your REAL Name : Your AGE : What type of connections are you willing to have? -Call In Only (THEY pay for all THEIR traffic) -Shared (You share cost with the other node) (NOTE: Server-Server connections will be SHARED) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Edit and send this form to FILEnet, TARDISNet or WWIVnet 1@1052, IceNET 1@1084 or WWIVLink 1@1184. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Snorkel (1@3459) and Tolkien (1@3456) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ During the last few months of 1992, the WWIVnet sysops in the 314 area code (of which the authors are two), who pay to support the operation of the St. Louis WWIVnet Server, were informed by the server's sysop, The Sandman (1@1021), that it appeared that we had a problem. The Sandman had been running the server's day-to-day operation for over 2 years, and had been observing that as WWIVnet doubled in size, the flow of WWIVnet packets was increasing exponentially, growing at about 4 times the rate of WWIVnet expansion. He found this disturbing, especially since much of the message traffic during that time was routed to other connections via PCPursuit, which operates at only 2400 bps. Additionally, our server was gradually being weaned off of PCPursuit and onto standard AT&T phone line, so that it could take advantage of the US Robotics HST Dual Standard 16,800 bps modem that our group had purchased. The Sandman was concerned that if this rate of message traffic increases continued, we would soon not be able to afford the cost of long distance bills, and that this might force us to shut down our server. The Sandman brought his concerns to the server group, and we began to discuss what could be contributing to this seemingly unwarranted increase in WWIVnet message traffic. After several days of discussion, what began to emerge was a feeling that much of this increase in WWIVnet message traffic was the result of binary-encoded files being sent back and forth over the network. Most of us were only aware of one (1) form of encoding that would allow a file to be transmitted as binary data between connecting systems, and that was UUENCODE. We then discussed how we might be able to not only test this theory, but also do something about it if it turned out that we were correct. Since WWIVnet packets are compressed using algorithms from the PKWare Compression Library, our group decided that it would be necessary to purchase a copy of this library, so as to be able to decompress the incoming packets for analysis. It was decided very early that this program would have to function as NETWORK1. It would be written so as decompress the incoming packet (if it was compressed) to do its analysis, and then call the "real", but renamed NETWORK1. The job of writing the program was given to Tolkien, 1@3456, who has a good working knowledge of WWIV data structures. Tolkien, and others, felt that it would not be ethical to simply delete UUE packets out of hand, so it was proposed that UUE packets under a certain agreed upon size would be allowed to pass without being stopped. He and others also felt that any packet that exceeded that maximum size should simply be removed from the outgoing packet, and placed in a file, called CHECK.NET, which could then be viewed, with LNET, by the server's sysop. Also, to be fair, NETPROBE, as it was soon named, would also be able to sense, and be able to filter PACKSCAN packets. Tolkien had created PACKSCAN, initially to simply scan the incoming decompressed LOCAL.NET files and write a synopsis of the contents to the sysop's log. However, PACKSCAN soon evolved into a utility which was capable of breaking large files into 32K chunks for transmission between BBS's. Therefore, with this potential for abuse, PACKSCAN and other binary data packets sub packets were also added to the list of things for which NETPROBE would scan. With the PkWare Compression Library in hand, Tolkien began to write the program. Realizing the potential for abuse if NETPROBE was distributed to all sysops in WWIVnet, it was decided that it would only be made available to sysops who ran WWIVnet mail servers, for a nominal fee to recover the cost of our purchase of the PKWare Compression Library. It was also decided, very early in the development of NETPROBE, that, to prevent some sysops from simply giving away copies of NETPROBE to their friends, some type of registration code would be needed before NETPROBE could work. Without this code, NETPROBE would not be able to function at all. Finally, a NETPROBE "application" was drafted, and mail to all WWIVnet server sysops. This "application" was designed to to limit the number of copies of NETPROBE which would be distributed, and to inform the sysops of the need to use this program ethically. It quickly became apparent that the responsibility for deciding who could get a copy of NETPROBE should not rest in the hands of any one person, since NETPROBE was written for the good of the entire network. Lance Halle, 1@6211, graciously volunteered to draft an objective set of qualifications that must be met by anyone wishing a copy. These qualifications are: 1) The sysop must be running a server. 2) The sysop must have run a WWIVnet system for 18 consecutive months, 6 months as a server. 3) The sysop must receive approval from three other server sysops running NETPROBE. NETPROBE is actually quite a simple utility. It decompresses compressed network packets, and analyzes all packets coming to or through the system it is running on. It works in a multi-network environment, comes with a network decompressor, a utility to send command line netmail, and a program to generate the daily logs (that can be then sent in netmail to any net address using the included command line netmailer as part of the external event). Subpackets are analyzed to determine what they are (message, file, SSM, etc). Files are logged, along with some information about them (who sent them, who they was going to, maintype, minortype, etc). If the file is not from a system that the NETPROBE system has given the "okay" to for sending files through him/her and if the subpacket is larger than a specified size (default is 10k, which still leaves room for small utilities and data subpackets) then the file is shunted into the CHECK.NET file for later personal review by the NETPROBE sysop. NETPROBE does not itself EVER delete anything. It will delay only. Actual deletion requires human control. The creators and sponsors of NETPROBE sincerely hope that it will soon no longer be needed. NETPROBE is not the ideal solution. The ideal solution would be for people who wish to transmit files over WWIVnet to get permission from all the intervening systems instead of covertly trying to have others, especially net servers, pay the cost for such files, which are usually for the benefit of just one or two people. However, it appears that a number of people continue to think about no one but themselves. So for now, NETPROBE is the only real solution to this growing problem. A point-to-point network FREQ utility will (hopefully) alleviate the problem, but that remains to be seen. If such a FREQ program isn't used because people would rather try to make others pay for their file transfers, then NETPROBE may still be needed years into the future. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Snorkel (1@3459) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ This utility, written by Tolkien 1@3456 WWIVnet, has evolved into the finest NET packet analyzer for WWIV or any compatible network.After almost 2 years of revisions and improvements, PACKSCAN version 2.31 has now become more than just a WWIV packet scanner. In 1991, at my urging, Tolkien undertook the task of writing a program which would scan all incoming NET mail packets for WWIV, and log them to the sysop log.Since this original program was written, Tolkien has expanded PACKSCAN's features until today, it is a full-featured NETWORK2 pre-processor for WWIV networks. Current features of PACKSCAN v2.31: þ Two versions for systems with different amounts of available memory. The standard version has a well written graphical screen which displays the progress of packet analysis. The memory-saving version gets rid of graphics, and reports its progress in text mode. þ Multi-network compatible. þ Sysop configurable via a user-friendly configuration interface. þ Packet logging to the WWIV sysop log. þ Extended packet logging, providing even more detail than the standard sysop log entries provide. þ Detailed error logging which reports errors encountered by PACKSCAN when packet transfers occur and are aborted. þ File logging which reports the status of both incoming and outgoing program files. þ Ability to transmit and receive program files in specially encoded packets or "chunks". þ Ability to receive network updates from network coordinators who use a specially written program called "PUS" (PackScan Update System - available to all network coordinators for $20). þ Ability to read the WWIV 4.21+ USER.LST to aid in file acquisition. This ability may be disabled for those systems which are running programs which may encounter SHARE violations, like Windows (R)*. þ Fully implemented CRC-32 error checking of incoming program file chunks. þ Ability to accept or reject unsolicited program files sent by other network sysops. þ Built-in interface with ALLOW.EXE, a utility for storing and searching for file names of previously uploaded programs. þ Configurable ability to send SSM's (Small System Messages) to other network systems when program files are received. þ Ability to specify the directory "type" for the WWIV upload directory where program files will be sent. þ Full implementation and support for the WWIV external packet pre-processor file redirection implemented in NET32. þ Fully configurable "ALIAS" file which gives the sysop ultimate control over who may access files from their system. þ Allows transmission and receipt of program files using a "stealth mode" which will bypass SSM notification to systems who would normally receive notification of a PACKSCAN upload to your system. þ File lists indicate which files are/are not available in transfer areas on your system's hard drive at the time of the request. A tad slower, perhaps, but then others won't spend the time requesting files which are not available on your system. CD-ROM drives are not scanned as all files are presumed to be there. Future features of PACKSCAN: þ Configurable upload event (virus scanning, etc.). þ Automatic subscriber list generation for networked message echos. þ Sysop configurable sound board support (Soundblaster, Adlib, Pro Audio Spectrum, etc.). As always, PACKSCAN version 2.31 is FREE. However, due to numerous upgraded and newly implemented features, PACKSCAN version 2.31 is not compatible with any previous version of itself. This includes file requesting, file sending and file list requests. Also, because the network coordinator's update utility (PUS) is being upgraded and improved (including some minor de-bugging), those sysops who use PACKSCAN to receive their network updates will need to upgrade to version 2.31. Unlike previous versions, the four utility files which accompany PACKSCAN are NOT free. These utilities, which give sysops the ability to request file lists and send and receive files, now must be registered. These file utilities will require registration before they will work. These utilities are: NETFILE .EXE Allows you to send a file to one or more nodes FILEREQ .EXE Allows you to send a file request to another system LISTREQ .EXE Allows you to send a file list request to another system NFM .EXE Does all that the first three do, in one integrated program, and allows use of "Stealth Mode" as well. The utilities listed above must be registered. In an effort to keep sysop registration costs down, normal registration is $20 for all four PACKSCAN utilities. However, for a limited time, ALL FOUR PACKSCAN UTILITIES may be purchased for $10. To take advantage of this LOW $10 registration fee, you must send in your registration (check or money order - no cash please), postmarked by July 31, 1993, to: Sara Felix c/o PACKSCAN REGISTRATION 7035 Ethel St. Louis, MO 63117 Please make all checks payable to "Sara Felix". All registrations received will be donated, by Tolkien, to one of the major network mail servers which moves YOUR network mail around the world. With this new version of PACKSCAN, the WWIV network sysop will gain more knowledge about the nature of data flowing into their system. Without PACKSCAN, you may be "flying in a fog"; with PACKSCAN, you should have "unlimited visibility". ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Conclusions ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Despite the arguments presented against the use of WWIVNet for transmitting large files in lieu of direct connections, there have always been those who'll take the "Devil's Advocate" side in the matter. Wayne's final ruling on the issue, as well as the DE1.EXE distribution will quiet some of the dissention, but at the same time will no doubt raise other points of order. The recent DE1.EXE distribution will no doubt be used as a prime example for both sides of the debate. There will be those who'll use this event as evidence of how UU encoded files can be beneficial to WWIVNet, while others will use it to cry "foul!" and "double-standard!!" in what will no doubt be described as a "sour grapes" response by those who wish to use the net any way they see fit regardless of the consequences. In any case, the matter does seem to be essentially a settled one for now. With the development and forthcoming release of WW4-FREQ by 2@2050, as well as the existence of FILENET and the PACKSCAN and NETPROBE utilities, perhaps the final nail has been hammered into a coffin containing UUENCODE. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Filo's Mod of the Month ³ ³ by Filo (1@2050) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The Mod-of-The-Month Selection represents my choice of what appears to be a useful, practical mod to WWIV. It does not mean it is the best mod posted or even that it works as I may not have tested it. Given the limitations of this media, uuencoded mods are NOT eligible for selection as mod-of-the-month. The June selection is another contribution from The Bishop 1@7. This mod should prove to be useful for those who need to move subs and/or directories. ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º WWIV Desc : Re-Order Subs and Dirs in //BOARDEDIT and //DIREDIT º º º º Filename : TB15-422.ZIP Mod Version : 1.0å º º Author : çhe áishop 1st File Modified : SUBEDIT.C º º 1st Net : 1@ 7.WWIVnet 2nd File Modified : DIREDIT.C º º 2nd Net : 1@ 7.WWIVweb 3rd File Modified : FCNS.H º º 3rd Net : 1@ 7.ExpressNet 4th File Modified : º º 4th Net : 1@ 7.FunNet 5th File Modified : º º 5th Net : 1@4550.IceNet 6th File Modified : º º 6th Net : 1@4550.USLink 7th File Modified : º º º º WWIV Version : 4.22 Date : 01 June 1993 º º º º Difficulty : ÛÛÛÛ±±±±±± º º º º Description : Over the years I've wanted to re-order my subs and º º directories more times than I can remember. So I finally º º decided to do something about it. This mod allows SysOps º º to take any one sub/dir and move it before any other one. º º In addition, it maintains proper qscan pointers for all º º all of your users (even deleted ones) after moving subs º º and/or dirs. Enjoy! º º º º çá º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Legend: ³ ³ ³ ³ = Leave this line alone ³ ³ + Add this line ³ ³ - Delete this line ³ ³ | Change this line ³ ³ . Many statements elapse here ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Disclaimer: LIVE WITH IT. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Step 0: Back your source code up. In addition, back up the following files in your DATA directory: SUBS.* DIRS.* USER.* I recommend putting them in one big zip file. I'll be shocked if you need the backup, but I wouldn't be recommending it if I didn't think you should do it. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Step 1: Open up SUBEDIT.C. Block copy swap_subs() in before insert_sub(). ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ /* TB15-422.MOD */ void swap_subs(int sub1, int sub2) { int i,i1,i2,nu; unsigned long *qsc, *qsc_p, *qsc_n, *qsc_q, m1, m2, m3, tl; subboardrec sbt; xtrasubsrec xst; nu=number_userrecs(); close_user(); qsc=(unsigned long *)farmalloc(syscfg.qscn_len); if (qsc) { for (i=1; i<=nu; i++) { read_qscn(i,qsc,1); qsc_n=qsc+1; qsc_q=qsc_n+(max_dirs+31)/32; qsc_p=qsc_q+(max_subs+31)/32; if (qsc_q[sub1/32] & (1L<<(sub1%32))) i1=1; else i1=0; if (qsc_q[sub2/32] & (1L<<(sub2%32))) i2=1; else i2=0; if (i1+i2==1) { /* One is scanned; the other isn't */ qsc_q[sub1/32] ^= (1L<<(sub1%32)); qsc_q[sub2/32] ^= (1L<<(sub2%32)); } tl=qsc_p[sub1]; qsc_p[sub1]=qsc_p[sub2]; qsc_p[sub2]=tl; write_qscn(i,qsc,1); } close_qscn(); farfree(qsc); } sbt=subboards[sub1]; subboards[sub1]=subboards[sub2]; subboards[sub2]=sbt; tl=sub_dates[sub1]; sub_dates[sub1]=sub_dates[sub2]; sub_dates[sub2]=tl; xst=xsubs[sub1]; xsubs[sub1]=xsubs[sub2]; xsubs[sub2]=xst; save_subs(); } ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Step 2: Below, at the end of insert_sub(), comment out modify_sub(n); ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ = save_subs(); = if (curlsub>=n) = curlsub++; | // modify_sub(n); /* Removed TB15-422.MOD */ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Step 3: Below in boardedit() make the following changes: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ void boardedit(void) { = int i,i1,i2,done,f; = char s[81],s1[81],s2[81],ch; = = if (!checkpw()) = return; = showsubs(); = done=0; = do { = nl(); - prt(2,get_string(211)); + prt(2,"Subs: D:elete, I:nsert, M:odify, R:eorder, Q:uit, ? : "); | ch=onek("QDIMR?"); /* TB15-422.MOD add R */ = switch(ch) { = case '?': = showsubs(); = break; = case 'Q': = done=1; = break; /* Add Block (+) */ case 'R': if (num_subsnum_subs)) break; nl(); prt(2,"And Move Before Sub Number? "); input(s,3); i2=atoi(s); /* * * Note: inserting a sub before sub 0, 32, 64, 92, or etc will toggle on-for- * scanning all the subs in that 32 sub block. For example, moving sub 4 * before sub 0 will cause all users to scan subs 0-31. This is not a bug * in my code but rather in Wayne's stock insert_sub (try inserting sub * 0 and the same thing will happen). It is minor, but should be fixed for * WWIV v4.23. If you don't care about screwing up the "which subs to scan" * qscan pointer when moving before these subs, remove the (i2%32==0) * condition in the if statement below. * */ if ((!s[0]) || (i2<0) || (i2%32==0) || (i2>num_subs) || (i1==i2) || (i1+1==i2)) break; nl(); if (i2=0) && (i=0) && (i<=num_subs)) { /* { is TB15-422.MOD */ = insert_sub(i); + modify_sub(i); /* TB15-422.MOD */ + } /* TB15-422.MOD */ = } = break; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- Step 4: Save SUBEDIT.C and open DIREDIT.C. Block copy swap_dirs() in before insert_dir(). Uncomment the appropriate lines if you've got JAFO14.MOD installed, as I do. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- /* TB15-422.MOD */ void swap_dirs(int dir1, int dir2) { int i,i1,i2,nu; unsigned long *qsc, *qsc_n, tl; directoryrec drt; // float tf; /* Only if JAFO14 is installed */ nu=number_userrecs(); close_user(); qsc=(unsigned long *)farmalloc(syscfg.qscn_len); if (qsc) { for (i=1; i<=nu; i++) { read_qscn(i,qsc,1); qsc_n=qsc+1; if (qsc_n[dir1/32] & (1L<<(dir1%32))) i1=1; else i1=0; if (qsc_n[dir2/32] & (1L<<(dir2%32))) i2=1; else i2=0; if (i1+i2==1) { /* One is scanned, the other isn't */ qsc_n[dir1/32] ^= (1L<<(dir1%32)); qsc_n[dir2/32] ^= (1L<<(dir2%32)); } write_qscn(i,qsc,1); } close_qscn(); farfree(qsc); } drt=directories[dir1]; directories[dir1]=directories[dir2]; directories[dir2]=drt; tl=dir_dates[dir1]; dir_dates[dir1]=dir_dates[dir2]; dir_dates[dir2]=tl; // tf=dir_ratios[dir1]; /* Only if JAFO14 is installed */ // dir_ratios[dir1]=dir_ratios[dir2]; /* Only if JAFO14 is installed */ // dir_ratios[dir2]=tf; /* Only if JAFO14 is installed */ // save_dir_ratios(); /* Only if JAFO14 is installed */ } ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Step 5: Below, at the end of insert_dir(), comment out modify_dir(n); ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ = close_qscn(); = farfree(qsc); = } | // modify_dir(n); /* Removed TB15-422.MOD */ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- Step 6: Below in dlboardedit() make the following changes: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- void dlboardedit(void) { = int i,i1,i2,done,f; = char s[81],s1[81],s2[81],ch; = = if (!checkpw()) = return; = showdirs(); = done=0; = do { = nl(); - prt(2,get_string(160)); + prt(2,"Dirs: D:elete, I:nsert, M:odify, R:eorder, Q:uit, ? : "); | ch=onek("QDIMR?"); /* TB15-422.MOD add R */ = switch(ch) { = case '?': = showdirs(); = break; = case 'Q': = done=1; = break; /* Add Block (+) */ case 'R': if (num_dirsnum_dirs)) break; nl(); prt(2,"And Move Before Dir Number? "); input(s,3); i2=atoi(s); /* * * Note: inserting a dir before dir 0, 32, 64, 92, or etc will toggle on-for- * scanning all the dirs in that 32 dir block. For example, moving dir 4 * before dir 0 will cause all users to scan dirs 0-31. This is not a bug * in my code but rather in Wayne's stock insert_dir (try inserting dir * 0 and the same thing will happen). It is minor, but should be fixed for * WWIV v4.23. If you don't care about screwing up the "which dirs to scan" * qscan pointer when moving before these dirs, remove the (i2%32==0) * condition in the if statement below. * */ if ((!s[0]) || (i2<0) || (i2%32==0) || (i2>num_dirs) || (i1==i2)) break; nl(); if (i2=0) && (i=0) && (i<=num_dirs)) { /* { Add TB15-422.MOD */ = insert_dir(i); + modify_dir(i); /* Add TB15-422.MOD */ + } /* } Add TB15-422.MOD */ = } = break; ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- Step 7: Add swap_subs() and swap_dirs() to FCNS.H: ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- /* File: diredit.c */ void modify_dir(int n); void swap_dirs(int dir1, int dir2); /* TB15-422.MOD */ void insert_dir(int n); . . . /* File: subedit.c */ void modify_sub(int n); void swap_subs(int sub1, int sub2); /* TB15-422.MOD */ void insert_sub(int n); ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ- Step 8: You're done! Please email me if you use this mod! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Type 0 Forum ³ ³ Edited by Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The Type 0 Forum is WWIVnews' "Letters To The Editor" section. Comments, criticisms, questions, and suggestions can be sent to WWIVnews c/o 1@5282. WWIVnews reserves the right to edit any submissions for either clarity, punctuation, or spelling, but will endeavor to maintain the content integrity as close to that originally submitted as possible. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Dear Editor: I find it very interesting that you published a letter from Rebel 1 in the latest WWIVnews! This guy has *really* gotten on my nerves. I think you should have pointed out that this guy is *the* Plagiarist Of The Month! He took my JAFO12 mod (WWIV Time Bank) and changed a line and made it his own. All he did was remove all the strings and tell people to use his string mod to put the strings in an external .STR file. Of course, his string mod is just a TOTAL ripoff of Tolkien and Snorkel's MODSTRIN.MOD. I did a DIFF of my "void timebank" and his "void jrftime", and not a SINGLE line was different except for the fact that his didn't have any strings (just calls to jrf_string). I posted something nasty on the WWIVnet Mod Sub (Filo moved my post) telling him if I wanted to distribute my mods without strings I'd do so! JAFO (1@8861) Editor's Reply: While it's not the policy of WWIVNews to refuse submissions based on any disagreements between the author and other parties, it is also not the policy of WWIVNews to point out any reported transgressions, or act in an accusatory manner in matters such as this. To point out non-sequiturs such as this would be about as beneficial to WWIVNews as the dismantling of WWIVNet, and would be about the same as adding an Editor's NOTE before every column telling the readers what sort of screw-ups the author has committed since last issue. This, however, is not to say that JAFO's complaints aren't possibly valid. Those who subscribe to the MODNET subs were witness to the brief debate that ensued over the accusations of plagiarism. As stated in the last issue of WWIVNews: "On the other side of the fence, of course, is the issue of proper accredation of source material. Nobody likes to see someone else get credit for hard work they didn't perform, and the same goes triple for programmers. As a result, at least twice a month there can be heard the cries of "PLAGIARISM!!" on the Modnet Discussion sub - usually over someone's total duplication of a sublist(void) or dirlist(void) replacement - and brief flames erupt until Filo steps in to put them out." Sure enough, this observation was proven at least twice since this self-quote first saw print. Again, plagiarism of modifications - or any other work, for that matter - isn't part of any proper code of ethical conduct. However, as there are no WWIVNet guidelines covering such actions, accusations pertaining to such should be conducted in a civil manner in whatever forum the participants choose for their discussions on the matter. Dear Editor: For the nearly eight years I have been running the WWIV software there hasn't been a change to the manner in which Wayne Bell (the software author) chose to list messages on the BBS area, commonly called a "message base," "message sub," a "public message area," or any variety of other names. This format for reading public messages displays the title, author, date and time of the writing, BBS origin (included recently), and sometimes a line indicating it is "with regards" to another when it is in reply to previous message (also called a "post"). Another important feature of reading messages includes a feature whereby a user may scan only the titles of all the "posts". The scan feature is very useful to sysops and users reading numerous message areas that contain large numbers of messages, or to many sysops who carry (or host) an overabundance of message areas and wish to spend as little time as possible browsing through messages, while still being able to get the most out of them, as do their users. Enter the infamous Random Title. This is an example of an actual random title (which was posted in the #1 Sysops nationally networked message base): Title: RE: Re: The Bermuda Triangle is a strange place [Random Title] The above title had nothing to do with the content of its attached message, and therefore acts as a red herring serving only to conceal the true intent of the message, whether this result was intentional or not. Moreover, random titles are usually selected at random from a list of dissimilar titles, and this process inherently has an infinitesimal chance of correlating to a message, inevitably having absolutely nothing in connection with the contents of a message. Randomness may lead to chaos, and it almost certainly precipitates confusion. The turmoil may increase logarithmically as other sysops or users respond to messages using random titles, further saturating the message base with a plethora of post-titles that make no sense and have no relation to the contents of the messages contained within. Doctors tell us that humans learn very quickly through conditioned response. This is the concept demonstrated by the following example: A person may have an adverse reaction to eating a certain type of food. After finding which food is responsible, the person will be conditioned to remember the effects and not eat that food. An analogous situation: Many sysops and users are looking for answers to questions they have asked in the different forums. After scanning the message titles for an answer to his earlier post, a sysop or user encounters a few pertinent messages, but with cryptic titles, and many more irrelevant message with confusing titles. The unconventional titles often contain the words "Random Title" in them, or they are only a bit of punctuation, such as the infamous ellipsis (...), exclamation points (!!!), or a single word, "Yeah," "No!" "Whatever," or a few words that still don't imply meaning: "I don't agree," "WWIVCon," "What I said was..." "Etc., etc." "Help me," "My answer:" and the list continues. After reading many of these messages, finding them useless, the sysop or user develops a conditioned response to skip over them. The worst part about this situation: What happens when message has a random title, but contains the exact information the sysop or user is looking for, and is skipped because its title implies no relation to its content? One potential result is that the person asking the question repeats it in a second or third message, and then is either ignored or criticized for repeating the message & not seeing the original answer. The ensuing messages then clutter up any topics that are current in the forum. There are other less and more catastrophic effects that for space considerations of this article I must leave out. The main point of this example is that important information may be overlooked. While some of the above title examples may appear acceptable, none of them properly imply the what might be the primary content of a message. "Help me," for example, could specify what kind of help is required, or what the problem is, all in the title area. "I don't agree," could also indicate with what and whom there is not an agreement. Wayne Bell, the author of WWIV, left the potential length of message titles long to enable sysops and users to be specific with respect to what help or information they're looking for, not so that they could be lazy and ignore them, leaving their messages unsupported. Try to make your titles suggest what the message is going to say. Otherwise, if you have something important to scan, a lot of people are going to scan right past it. If someone is scanning through many messages per day, they want to skip the messages that don't apply to them, and the messages with random or meaningless titles are the easiest way to make them do that. A good rule of thumb is to make the titles of your messages describe what your entire message is about, presenting as much information as possible in the limited space given. Many people are more likely to read, "How to make $35/user per yr by charging for XXX .GL d/l's," rather than "Making money..." or "Check this out!" or "A wrinkle in time is a disastrous thing [Random Title]." BBS's are an incredible force for spreading and obtaining information. Used correctly and proficiently one can reap enormous benefits from them; used with insouciance or indifference they degenerate into a confused, banal and fatuous collection of expensive wastes of modems, telephone lines, and computers. Number One (1@6951) Editor's Reply: Number One's comments speak essentially speak for themselves. The use of Random or non-related titles on networked subs - especially high-volume ones - can render unto one's posts a bit of camouflage that will cause "title scanners" to skip over them, totally oblivious to the content of the post. Granted, those in support of the use of this style of titling argue vehemently that scanning titles is a sign of laziness, and that if one is not going to read every post on a sub then that person has no business having access to the sub in the first place. Problem with this argument is twofold: First, on a high-volume sub - one that has over 100 posts a day - reading every single post can take more time than most people with lives have to spend reading messages. This is especially applicable on politically oriented subs as the WWIV World-Wide Link and the Political Incorrectness Net, as well as other subs such as the #1's Only Sub, the IBM Information Net and 1@1's Star Trek Sub(*). As a result, people with limited time frames must resort to title scanning in order to keep up as best as possible with the topics of discussion for the sub in question. (*) This is applicable primarily during the start of a new season :-) In other words, its not a matter of laziness, it's a matter of lack of free time. Secondly, there's a bit of double-standardization in action here. By refusing to take the time to give each post a distinct, descriptive title, those who rely on Random or non-related titles are themselves the ones being lazy. Now, once upon a time, back in the days before Eight-Ball went off to college, there was a particularly active poster who insisted on giving every message posted on the high-volume subs that person frequented a nondescript, macro- defined title, regardless of the content of the post. That simple title was "Hi!", and it drove every "title scanner" on those subs crazy - especially when there were 30-40 posts in a row with that title! While quite a number of these posts contained serious, intelligent commentaries, most of them were ignored by the majority of readers because most of them were "title scanners". The rare times this person's comments were noticed occurred when someone who wasn't just a "title scanner" quoted something from one of this person's posts. When confronted about the nondescript title, the person in question gave two excuses that attempted to transfer the blame upon the "title scanners". The first argument was paraphrased earlier. The second one, however, went something like this: "I use 'Hi!' as a friendly title for every post. Those who wish to be friendly should be attracted by this title, and read my post without any concern beforehand of the content!" This argument, needless to say, was so full of...well, full of *something* that it provided perfect cannon fodder not only for the majority of the sub's more prolific character assassins, but for those in the novice category as well. In the end, while the poster in question wasn't essentially repentant after his/her/its public flambe', of the posts originating from that account a significant portion were _not_ simply titled "Hi!" Situations like this are also prime arguments for those who wish to see some sort of WWIVNet ban on Random Titles. However, like taglines, Random Titles can serve a useful purpose so long as they're used properly. If one is going to implement a mod to allow for Random Titles, one should also implement a version of the mod that allows this feature to be turned off for networked subs whose high traffic flow would cause such posts to be a waste of time and network resources. A title is essentially an advertisement for your post. Posters need to acknowledge the fact that using descriptive titles will enhance their chances of their posts being read on a high-volume sub. When one is either seeking or giving information, such efforts are only as good as the methods used to attract the attention of the target audience. If you need information, and you don't use a title reflective of this fact, then you have nobody but yourself to blame for the lack of response you'll receive. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ WWIV-Compatible Networks List ³ ³ (July Final Edition) ³ ³ 37 Networks Included ³ ³ by Red Dwarf (1@6264) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The following information is compiled as a service to BBS operators and has not been verified for accuracy. Attempts are made to keep the material current and usable. If you are aware of changes that should be made, such as additions or deletions, please send them to me in E-Mail. Information for this listing should only be submitted by the contact person for each network. You should also inform me of any changes to be made. Please specify which field the changes affect. This edition contains new entries or updates for: SigNet, USLink, IceLink, DarkNET, SCAnet, InfiNet, ACiDNet, NOVAnet, LeeNet, TerraNet, CARDnet, SOLARnet, ROCKnet, APEX, Alternetive, Znet, ROPEnet, CHAOSnet, RADSnet, ADULTNet. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Abyssal Net [General] (80) (5-1-93) IceNET @8399 Matrix - 908-905-6691 Handles, No Application, No Roleplaying and Cyberpunk are hot topics. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Acidnet [General] (17) (6-8-93) WWIVnet @5876, IceNET @5850 Florida Keys - 518-587-0317 Handles, Application, Yes Growing all the time! Friendly NC and network staff. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Advent [General] (34) (5-8-93) WWIVnet @8318 The WILD Side! - 803-788-7469 Handles, No Application, Yes --Originally started in Aug 90, the net has grown to cover 3 states. --Has automatic update software, and a dedicated 16.8k hst server ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ADULT Net (WWIV Based) [Specific] (1) (6-16-93) No network connections. The Funny Pages - 612-888-2080 Handles, No Application, Yes Adult national discussion of Swinging/Dating/Alternative Lifestyles Sexual positions/items/toys and stories ALL of ADULT nature. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Alternetive [General] (19) (6-11-93) WWIVLink @14062 The City Morgue - 410-666-1035 Handles, No Application, Yes Just a group of laid back people looking to have fun and enjoy ourselves. A must have for the modern sysop. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ APEX WWIVnet @13600, IceNET @3600, WWIVLink @13600 Purgatory BBS - 306-665-0274 Handles, Application, Yes -Created in March 1992. It was based on creative writing and RPG -networking. General Subs Available. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ CaffNet WWIVnet @3101 Star-Lit BBS - 301-229-2957 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ CARDNet [General] (6) (6-5-93) IceNET @5077, WWIVLink @15062 ? - 510-458-4370,,222222 Handles, No Application, Yes Cardnet - Chaotic, Random, Deviants Network. The name says it all. Welcoming members from all areas. Join today! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ CHAOSnet [General] (30) (6-12-93) WWIVnet @9404, IceNET @9402, WWIVLink @19402 Data*West BBS - 904-259-8951 Handles, No Application, Yes One of the quickest growing national networks with network servers, automated updates, and the most helpful sysops in any network. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Chess_Net [Specific] (5) (4-4-93) WWIVnet @5915 The Duke of Earl - 509-291-3760 Handles, No Application, No Dedicated to the philosophy of chess. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ C/NET WWIVnet @6956, IceNET @6956 Cold Fusion - 619-434-1482 Handles, Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DarkNET IceNET @5805, WWIVnet @5811 Storm Blade - 508-368-7971 Handles, Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DeathNet [] () () WWIVnet @19982 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DEEPnet WWIVnet @7405, IceNET @7405, WWIVLink @17405 Deep Space 8 - 704-553-0780 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DragNET WWIVnet @2936, IceNET @2913 Toon Town - 209-323-9412 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DragonNET WWIVnet @7670 Cool World - 716-681-7341 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DragonsNet [Specific] () () WWIVnet @6263 Unlimited Enterprises - 612-871-7625 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ EliteNET [General] (29) (2-17-93) IceNET @2462 Alley Closed BBS - 214-238-8121 Handles, Application, Yes "The No-Nonsense Network" Totally democratic network using all members' opinions and votes. Close and friendly network. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ExpressNET WWIVnet @6754 Data Express - 617-247-3383 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ EagleNet [General] (12) (2-18-93) IceNET @7676 Berek's Homeland - 716-826-4698 Handles, No Application, No EagleNet was set up so that users and sysops could order things that they use everyday and have it sent to their doorstep. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FIITAnet WWIVnet @9957 Baxter BBS - 919-878-0054 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FILEnet [] () (1-28-93) WWIVnet @8412 - Inquire at @1052 Pocket Universe - 803-552-8654 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ FUNnet (10) (6-1-93) WWIVnet @3302, IceNET @3302 ? - 303-751-7236 Handles, No Application, Yes Great subs we are small but the quality of boards is good. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ GayNet [Specific] (28) (2-1-93) WWIVnet @15283, WWIVLink @25283 Handles, Application, Yes Alternate Lifestyles- don't have to be gay, lesbian, or bi to join. No gay bashing allowed. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ IceLink [General] (6) (5-1-93) WWWIVnet @5213, IceNET @5213, WWIVLink @5213 Handles, No Application, Yes General discussions, RPGs, Freedom of Speech, etc... Your everyday Cool Net ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ IceNET [General] (737) (4-29-93) IceNET @1, WWIVnet @7663, WWIVLink @17652 The Great White North - 716-837-0044 Handles, Application, Yes Full featured network, fast updates, hundreds of message bases to choose from. A friendly place to be. Highly rated, one of the best. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ InfiNet [Specific] WWIVnet @5335 The Dead Beat Club - 503-233-9168 Handles, Application, Yes An exclusively West Coast network (CA, OR, & WA). We specialize in regional topics and making the the local BBS scene better. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ InsanityNet WWIVnet @8355, IceNET @8385 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ LeeNet [General] (?) (6-9-93) WWIVnet @15269, IceNET @15269, WWIVLink @15269 Secret City BBS - 512-592-8054 Handles, No Application, Yes Newest net on the market. Hoping to grow with the help of people who will give it a chance. Discussion is casual. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ M.A.G.Net [General] (10) (4-29-93) WWIVnet @7107 Psycho BBS - 701-780-9168 Handles, No Application, Yes M.A.G.Net was created to give newer BBSes a way to share information with other BBSes and help them in getting their BBS going. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ NorthStarNET [General] (25) (6-5-93) WWIVnet @6259, IceNET @6259, WWIVLink @16259 AeroTech BBS - 612-935-3505 Handles, Application, Yes 25 nodes in many states. 50+ subs, most active and not gated. Wide range of sysops and users, friendly environment. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ NOVAnet [Specific] (1) (4-2-93) IceNET @2351 The InfoLink Cosmos - 213-294-5387 Handles, No Application, Yes Official TurboPros Support Network. We are a Stories/Ansi/Programming group which use NOVAnet distribution purposes as well as free speech. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ NukeNet WWIVLink @14063 The White House - 410-760-0712 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ OgdenNet [General] (6) (3-2-93) WWIVnet @8135, IceNET @8135 The Sandbox ][ - 801-774-5574 Handles, No Application, No Local chit-chat, DHS (local computer group). ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ RADSnet [General] (11) (6-17-93) WWIVnet @2660, IceNET @2660 R.A.D.S. Y-Town BBS - 216-743-4215 Handles, No Appplication, Yes RADSnet is a small, yet fast growing network which has spread to 5 states. We offer fast data communication and a lot of SysOp support. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ROCKnet [Specific] (52) (6-1-93) WWIVnet @15463, IceNET @5463, WWIVLink @15463 Strato's Guitar Shop - 514-683-6978 Handles, Application, Yes ROCKnet is the specific WWIV based network DEVOTED to music and entertainment. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ROPEnet [?] (14) (6-12-93) WWIVnet @9964, IceNET @9970 The Republic of Profane Existence - 919-756-2116 Handles, No Application, Yes Wide variety of subs, fast updates, good conversations, and a lot messing around. Easy going, free for all. Growing rapidly. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SCAnet [Specific] (19) (5-4-93) IceNET @2466 ? - 214-361-8541 Handles, No Application, No SCAnet is dedicated to supporting the Society for Creative Anachronism through the exchange of ideas and information. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SigNet [General] (3) (5-3-93) WWIVnet @8433, IceNET @8400 Collage - 804-766-3192 Handles, Application, No This network is growing not only in the WWIV community, but also in other areas. Fido compatible boards are linking up now! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SnotLink [Specific] (8) (4-4-93) WWIVLink @18262 Insomnia - 812-466-4222 Handles, No Application, Yes For Terre Haute region BBSs ONLY. A true local network with a slant towards the silly! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SOLARnet [General] (216) (6-12-93) IceNET @3454, WWIVnet @3484, WWIVLink @13495 Rap City [GSA] - 314-963-7960 Handles, Application, Yes SOLARnet is another one of your general discussion networks. We offer over 200 subs, on a variety of topics. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ StarLink [General] (10) (5-30-93) WWIVnet @5208, IceNET @5201 ? - 502-877-2573 Handles, No Application, Yes -NET dedicated to contact between boards & encouragement of positive -BBS habits; No UUE's without consent of all connects, multi-SUBS. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ StarNet [Specific] (4) (5-5-93) WWIVnet @3956, IceNET @3956 Diamond's BBS - 319-277-0166 Handles, No Application, Yes Local network of teenage boards to facilitate the transfer of files and e-mail, to take the load off of the local WWIVnet/IceNET server. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ SuperNET IceNET @3402 The Empire - 304-465-5223 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TARDISNet (43) (6-9-93) WWIVnet @2925, IceNET @2925, WWIVLink @22925 The Gallifreyan Matrix BBS - 209-571-0513 Handles, No Application, Yes For science fiction, current events, and political subs. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TeenNet [General] (21) (4-5-93) WWIVnet @4075, IceNET @4053, WWIVLink @14064 Central Station - 410-315-9854 Handles, Application, No TeenNet is made so that all younger sysops in the world can get a chance at networking. The network is open to all people. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TekNet IceNET @2459 Canisius College BBS - 716-888-2600 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TerraNET [General] (86) (6-11-93) WWIVnet @8861, IceNET @8857, WWIVLink @18857 Blue Thunder - 818-848-4101 Handles, Application, Yes National general purpose network. Friendly atmosphere, 140+ subs, fast automatic updates. Have lots of fun. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TestNet WWIVnet @19960, IceNET @9994 Test Site BBS - 919-760-4811 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ TLCnet [] () (1-28-93) WWIVnet @8412, Inquire at @1052 Pocket Universe - 803-552-8654 Handles, No Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ USLink [General] (25) (4-30-93) WWIVnet @8854, WWIVLink @18867 ModeMANIA - 818-451-0936 Handles, Application, Yes Small but expanding network currently covering So. California. Well-run and frequently updated. Active and involved NC. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ WEB [General] (10) (2-13-93) IceNET @5802, WWIVnet @5813 Sanctuary - 508-892-8529 Handles, Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ WWIVnet [General] (1400) (1-24-93) WWIVnet @1 Amber - 310-798-9993 Handles, Application, Yes ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ZNET [General] (20) (4-1-93) No other connections. The Ethereal Plane - 609-435-5991 Handles, No Application, No ZNET was designed in 1990 as an alternative for WWIVnet. We are looking for BBSes in other area codes for area coordinator positions. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Znet [General] (20) (6-13-93) WWIVnet @5901 The Electronic Asylum - 509-325-6903 Handles, No Application, Yes Small but growing netowrk started in 1989, to lessen network politics. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ *.Net IceNET @2459, WWIVLink @16976 Reynard's Keep - 214-406-1264 Handles, No Application, No ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Network Entry Format: Name [Content] (Nodes) (Date) Primary Netaddress, Other Address, ... Hosting BBS - Phone Number Description Line One Description Line Two Handles, Application, Updates Name ³ Network's Name Nodes, Date ³ Number of nodes on Hosting BBS, ³ You may wish to call here for network support Phone Number and/or setup files. Desription ³ Sent to me by the network coordinator Handles ³ 'Handles' will appear if this net allows aliases, 'Real Names' will appear if aliases are not allowed. Application ³ Is this network's application in the master application file? Updates ³ Does this network use automated update software? ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ To submit an entry, use the following application as follows: Send application to Red Dwarf: 1@6264 WWIVnet 1@6256 IceNET ICENET 1 AT 6256 @16259 (WWIVLink) The File Pile (612) 351-0144 2400 Baud Netlist Account To use netlist account: Download the NETWORKS.LST and net applications file with the "NETLIST" account. Password is "NETLIST" and last four digits are "0000" Sorry, but uploads and updates from this account cannot be accepted. ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ Network coordinators are responsible for checking their network's information and reporting any errors or incomplete entries to me. If you do not see this after your network: [gen/spec] (nodes) (date) (with information in all of them), please send an application so you can have the new information in it. Please indicate that this is an update after the network's name. Thank you. When submitting your networks application, please use the form below. If this is an update, please indicate which fields are changed. ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º NETWORKS.LST Update/New Entry º º º ºIs this an update? º º Network Name : º º Contact Person Information : º º a) BBS Data Phone Number : º º BBS System Name : º º b) Primary contact point: WWIVnet, WWIVlink, IceNET: _________ º º Select ONLY ONE above as primary contact point. º º º º Answer all that apply: º º WWIVnet Node :_____________________ º º WWIVlink Node :_____________________ º º IceNET Node :_____________________ º º c) Do you allow handles in the network: º º Net Type (General or Specific, chose one): º º If specific, identify topic specialty below (two lines maximum) º º If general, give a brief network description (two lines maximum) º º º º º º Do you have automatic update software? º º If you wish, you also may send me an application for the master file.º º Date and Number of Nodes : º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ TechNOTES ³ ³ Compiled by the WWIVNews Staff ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ...From the Poison Pen department: The Clintons have become the first couple in the White House to have an E-Mail address. Those wishing to tell President Clinton just exactly what's on their mind can now do so from either MCI Mail or from one of several online services, such as Compu$erve and America Online. The Clinton administration has even appointed Jock Gill as "Director of Electronic Publishing and Public Access E-Mail" to help the mail go where its supposed to go. ...There's a catch to all this, tho: All E-Mail is screened for topicality, and used to compile a sort of "topics digest" which assists the President in keeping abreast of what topics are of concern to most Americans. As a result, Odds are Mr. Limbaugh's favorite Arkie won't see your E-Mail unless it's in regards to something that catches the eye of one of Jock Gill's assistants. ....As it stands now, the best anyone can truly hope for is to get a return letter of receipt as proof that your letter was received by someone at the White House. Still, it's more direct access to the person with the finger on *the* button(s) than this nation's had since General Washington was drafted into being something other than a king. ...MCI Mail users can reach the Oval Office by typing "White House" in the TO: prompt. Those with money to blow can access the White House from CI$ using "GO WHITEHOUSE", while those who prefer to use their money in the most efficient manner by subscribing to America Online can access this area of service using the keyword "white house". Prodigy is expected to offer this service sometime in the fall, although initial reports is that access will be offered as a premium - read: "Overtly Overcharged" - service. ...Anyone seen the new Microsoft Mouse 2.0? Contrary to popular belief, this is NOT a "right-handed" mouse as the design would imply. Tests conducted by one lefty WWIVNews staffer prove that the ergonomic design works just as well for left-handed users as it does for those using the "normal" hand. ...as if that's not enough to convince people to switch to this version, the ball mechanism's been reworked so as to all but eliminate the need for a mouse pad! While this won't interest those who prefer to run their mice over Cindy Crawford's...er...face, it will be of interest to those who don't have room for a mouse pad to begin with. ...Finally, the drivers have been reworked to allow for the control of pointer size, color, and screen wrap. For a $109 MSRP - and a street price of around $85 - not buying a true Microsoft Mouse has become a really tough decision to justify. ...From the Internet Junkies department: Got 15Mb of HD space to spare? How about 30 minutes? If you do, then log onto the Internet and locate the latest episode of "Geek of the Week", a digitized "radio talk show" sponsored by Sun Microsystems' Internet Talk Radio experiment. ..."GOTW" is distributed to Internet sites on a weekly basis, and readers are available for a wide range of platforms. Unlike a normal radio broadcast, a show in this format can be fast-forwarded or rewound, and no doubt any really poignant quotations or musical "stings" will find their way into the .WAV libraries within no time. ...To find out more about Internet Talk Radio, contact your local Internet admin. If they don't carry the program, ask them to do so, or ask them to help you locate another nearby site that does. ...From the obituary department: Rest In Peace wishes go to CompuAdd's 110 retail outlets. With only a couple of exceptions, these outlets managed to keep themselves staffed with salesmen who had at least some intelligence level above that of a pet rock. Although the company itself is still alive and kicking - under protection of Chapter 11, no less - the retail outlets fell victim when the company simply couldn't adapt to today's changing market. ...This, for some, meant that CompuAdd's Bill Hayden simply couldn't bring himself to play the sort of corporate dirty pool that Michael Dell made popular among the computer manufacturers. Ergo, CompuAdd couldn't make their systems cheap enough to beat Dell's prices, and Hayden wouldn't screw his customers over with chintzy merchandise. However, considering that Dell's own problems have come to light with regards to company efficiency and system reliability, one should not be surprised if CompuAdd put on a Phoenix suit and dragged itself up out of not only its own ashes, but Dell's as well. ...So, for now, raise your glass and give a moment of silence for CompuAdd's departed retail outlets. Then go visit their Back Dock Shop and pick up a few bargains while they last! ...And if you think that these claims about Dell's stability are bogus, keep in mind that in light of a $70 million loss in 1st Quarter '93, they've renegotiated every line of credit they have to their name in order to satisfy their creditors. Dell stock has remained in the $20/share bracket since last Spring's controversial stockholder's report and the preceeding dismantling of Dell's notebook division. These events sparked a class action suit against Michael Dell by stockholders, claiming that Dell withheld information on decisions that would have influenced - and probably neutered - a major stock selloff last February. ...An aside NOTE: while toasts aren't in order here, it should be noted that Gecko Computers and Everex Inc. have both gone under in recent months. Those who have ordered products from either of these companies and haven't received them yet should contact your local Better Business Bureau to see what sort of actions are available for you to take. ...Sharp Electronics has announced plans to introduce a flat-panel LCD color display for desktops by next fall. The 2" thick screen measures 10.4" diagonally, and is VGA compatible with 640x480 resolution. Two different versions are expected to ship, one for $5995 MSRP that handles up to 4000 colors, another for $7995 that will handle 16 million colors. ...While this may seem pricey for most people, monitors of this nature will eventually become the standard in light of concerns over EMF effects and the general push towards energy efficient machines under the government's new "Energy Star" program. As demand rises, prices are expected to gradually drop, but LCD technology is an expensive proposition even with today's production technologies. ...Over on the gas plasma side of the fence, NEC and Fujitsu are also working on reducing the costs of plasma screens to make them more competitive with LCD displays. As it stands now, the largest commercially affordable full-color plasma displays are less than 10" wide diagonally, with anything larger - say, 14 to 15" - existing only in prototypes with costs in the *six* digit range. ...Fujitsu has announced an 11-pound 21" screen for release by next spring's COMDEX. The cost of the monitor hasn't been announced, but insiders at Fujitsu hint at a production "breakthrough" that has reduced costs roughly 20% below that reduced by existing technologies. Initial price is still expected to be steep when compared to LCD monitors, but the cheaper production methods are expected to help reduce cost of smaller monitors in the 14-15" range. ...At the same time, NEC has presented papers on a new method of pixilation for gas plasma screens using hexagonal elements that promises to reduce costs even further. NEC's prototype is reportedly crude resolution-wise by today's standards - barely 320x480 - but the proof-of-technology was sufficient enough for NEC to start work on a 35" version with 640x480 resolution. ...From the SPA Groupies Department: The recent busts of DOS pirates have netted not only quite a few arrests, but a humorous note as well. Seems that a large number of the manuals copied were not only OCR'd from the originals, but that the spell checking after the scanning wasn't too terribly accurate. As a result, there were a lot of copies of MD-DOS floating around that looked like MS-DOS! ...While this should not be confused with an OD..er..OS for physicians, WWIVNews' resident DOS collector suggests that if you have a copy of this particular knockoff, keep it. The next big thing in the collector's market is expected to be obsolete computer systems, peripherals and software. Obscure and infamous bootlegs will no doubt gather top dollar at trade shows, especially when the majority of copies will have been used for kindling at the SPA's family cookouts! ...GeoWorks enthusiasts take NOTE: the arrival of the Personal Desktop Assistant just might be the kick in the pants this particular GUI needed, and Tandy appears to be wearing the boots. In a joint venture with Casio, Tandy will produce the "Zoomer", a 16-bit PDA that uses a version of GeoWorks for its operating environment. Estimated MSRP for the Zoomer is around $750, although rumors abound of a $500 introductory price to get the unit off the ground. ...While the Zoomer was presented at the same time as Apple's "Newton" last March at the Consumer Electronics Show, some industry experts have professed to liking the look and feel of Tandy's entry into the PDA arena over that of Apple's more publicized offering. Already, several companies have offered to produce apps for the Zoomer for use under the GeoWorks environment, including Intuit, Palm Computing, and America Online. ...From the Pyramid Scam department: word on the street is that infomercial huckster Tony Robbins has discovered the CD-ROM market, and is releasing his own Hypertext-based version of his _Personal Growth_ series of self-improvement books. Two of Robbins' books have already been introduced into CD-ROM format with last winter's inclusion in ZCI's Multimedia Powertalk CD. ...Speaking of ZCI, look for a Hypertext version of the life of JFK, including the entire Warren Commission report. Other releases will include CD's dedicated to the Vietnam War, Malcolm X, and Martin Luther King. Prices are expected to range between $19.95 and $39.95. ...From the Caveat Emptor department: DeskJet 500 owners should pay heed to the following safety tips. While the printers are as above 24-pin dot-matrix printers as 24-pins were above 9-pin printers, there's a couple of problems that have surfaced that weren't apparent when the units first hit the market. ...First off, there's the issue regarding the type of paper used. While HP recommends that you use their particular - and particularly expensive - brand of paper, using your typical el-cheapo copier paper will work just as well, and will actually be less prone to smearing. The reason for this is a microfine talcum powder that's sprayed on copier paper to - theoretically - keep the pages from jamming the machine. While this talc bonds the DeskJet ink to the paper quicker, HP has acknowledged that the print nozzles can get jammed over a period of time. However, the amount of talc required to jam the printhead is not enough to generally affect the regular size cartridges. ...As a result, those who do a LOT of graphics work with a LOT of black areas and use cheap paper should avoid using the extended cartridges for this purpose. Without proper care, the nozzles can become clogged beyond salvage long before the cartridge has run out of ink! ...Secondly, it's advised that DJ users avoid those "accordion hypo-bottle" refills like the plague. Our own WWIVNews editor has personally verified claims regarding certain problems with the refills, and also has an expensive white dress shirt with DJ ink splotches all over the front as proof that the refills do indeed damage the cartridge beyond repair if used as directed. ...While the WWIVNews staff prefers the HP DeskJet over dot-matrix printers any day, owners and potential owners are advised to take care when attempting to squeeze more bang for the buck into this line of printers. While doing so isn't the same as squeezing blood from a turnip, the DeskJets are still economical enough to operate that only someone on a really tight - read: welfare - budget should consider implementing these severe cost-cutting measures. ...Tired of playing "interrupt roulette" with your peripherals? Microsoft and Intel have finally gotten tired of hearing you bitch about it. Later this year, expect to see the first prototypes of a new ISA bus specification that will finally make adapters and peripheral cards truly "plug and play". ...The new spec involves adding a set of PROMs to each adapter containing a unique ID number for each adapter. Upon bootup, each card would arbitrate interrupts, I/O ports, DMA channels, and any memory conflicts. Depending on the results, the cards would then load device drivers into memory if necessary, or would prompt the user as to what drivers and/or switches were required. Cards using this new spec would remap themselves around existing old spec cards, and would automatically remap each time a peripheral was added or subtracted from the system configuration. ...Although the final spec isn't due out until September, several dozen peripheral manufacturers have expressed interest, and several already have working prototypes based on the initial proposed spec. The first boards for commercial sale aren't expected out until early '94, but industry insiders report that Hayes is ready for the new bus spec, and will be the first on the market with a "plug & play" v.FAST modem. ...Meanwhile, over in the SCSI part of town, Corel and NCR have been bedding together to develop a new chip set that will allow system board manufacturers to mount a bus-mastered SCSI controller directly on future motherboards. While there as yet have been no announcements of such, Corel expects the first ones to appear late this winter, about the same time the "plug and play" version of the CorelSCSI adapter is officially announced. ...From the "Ooops! You misunderstood us!" department: Microsoft shipped the v1.1 upgrade for Access earlier this month, and priced it at a seriously economical MSRP of $19.95 with proof of purchase of v1.0. This happened despite initial claims that users who bought the initial release at the introductory MSRP of $99 would not be eligible for upgrades of any sort. ...Calls to Microsoft's direct sales lines have gathered only a "that was a misunderstanding and/or a misquote" from sales reps, and while no one was willing to explain what the source of the "misquote" was, the probable source was a comment made by Bill Gates in a memo regarding the release of Access 1.0, and his explanation for the low introductory price. The memo in question reportedly was misworded so as to give purchasers the impression that the MSRP jump to $495 after the promotional deadline would apply not only to copies of Access bought after that date, but to any future upgrades. ...In any case, after nearly 8 months after its release, there's still a large supply of Access 1.0 floating around at the introductory price. Microsoft has allowed retailers to continue selling existing copies at the promotional price, and some software chains have been bundling both the intro version and the upgrade for as low as $115, offering to handle the registration paperwork for the customer. ...Still pent up about whether to buy the Pentium? Insiders at Borland and Microsoft both claim that while programs specifically compiled for the renamed 80586 or "P5" will run up to 40% faster than versions compiled on a 486, those same Pentium-optimized programs will still run 10-15% faster on those 486's. This is the result of the Pentium's dual integer-execution units and the need for compilers to optimize compiled code to take advantage of dual piping. A program compiled for the Pentium is already optimized to reduce the number of interdependent instruction sets that would otherwise eat clock cycles and slow down the application. When run on a 486 - whose pipeline functions best when resource-dependency is at a minimum - there is a performance boost. ...Although older processors - the 386 included - lack a comparable pipeline, several major software developers have announced plans to compile future releases of their products on Pentium-based machines so as to allow 486 users to gain the additional boost in performance. ...DEC, meanwhile has announced a second-source for its "Pentium Killer", the Alpha AXP. Mitsubishi has been awarded a contract to produce Alpha chips, thus ensuring a stable, competitive second-source for the new processor. ...However, unless Intel can get their collective fecal matter together, the true killer of Pentiums might just be the bane of all processors - heat. As reported previously, the 66MHz versions of the Pentium suffer from the same problems their first 486DX-50 counterparts suffered from. The 60MHz version of the Pentium are reportedly running just within temperature tolerances to be granted a release approval, but still require a serious heat sink arrangement to help dissipate damaging excess heat. ...Word from Intel is that a combination micro-fan and heat sink combination has been developed that reportedly will cool the 66MHz release of the Pentium enough to maintain tolerance levels and ensure the chip's life expectancy. Unlike other chip fans like the CPU Cooker, the Pentium micro-fan taps directly off the 5v lead in the chip socket as opposed to using a power tap from one of the drive power cables. ...In case you've been living under a rock the past few months - or under an old 10Mb IBM full-height "brick", as the case may be - hard drive prices have fallen through the floor, with street prices approaching the mythical $1/Mb. Both Western Digital and Connor have dropped their prices on drives below 1/2 Gb to this level, and needless to say a Windows-hungry userbase has been in a feeding frenzy that shows no sign of letting up. ...However, a recent announcement by Connor may shed some light on just *why* the prices were slashed. In 1991, Connor acquired VISqUS, a research firm dealing with innovative technologies. VISqUS had developed a new drive technology that involved the use of oil films instead of air as a support medium for hard drive head, which allowed for superior resistance against head crash and allowed the heads to travel closer to the platter surface than air technology allowed. ...Connor reportedly saw a good idea, and decided not to let it slip away. After buying the company, a Connor-labeled prototype drive was seen making the big trade shows that packed a reported 60Mb on a *single* 3.5" platter. At the same time, rumors started to surface of a similar design being developed by Western Digital, with prototypes being demonstrated for stockholders. Shortly afterwards, both WD and Connor started dropping their prices on hard drives in the 130-240Mb range, and last March slashed prices from the 540Mb range on down to the discontinued 40 and 80Mb sizes. ...Industry experts now believe that this dumping serves a twofold purpose: getting the market used to having affordable, serious mass storage while getting rid of existing stockpiles of air technology hard drives. While no official announcements have been made by either company, experts also predict that the first oil-film drives will hit the market by 2nd Quarter 1994, and will probably be targeted towards use in laptops. ...From the Microsoft _______ For Windows department: rumors out of the Left Coast speak of a joint venture between the Gates boys and a major cable company to produce a new form of interactive TV. The plan reportedly involves using the soon to be dime-a-dozen 386DX-33's as a foundation for a new cable box that will act as both an advanced channel selector and a game interface intended to compete with Sega and Nintendo. ...While no other specifics have surfaced, some cable trade rags have commented on the rumors, and have predicted that if the venture is to succeed it *has* to be cheaper in price than Nintendo, better in quality than Sega, and must offer significant additional features to current cable box capabilities that today's boxes simply aren't capable of. ...From the Caveat Emptor department: thinking of buying a Video Blaster, an ATI Graphics UltraPro, or another high-performance video card or frame grabber? Well, if you're running 16Mb or more on the system board, you might be in for a bit of a problem. Most cards of this nature require that a linear frame buffer - AKA a "memory aperture" - be available at or above 16Mb. If RAM is detected at or above this level, the card won't be able to find an aperture and won't run. Most cards allow you to turn off the aperture feature, but this can cut your performance to as low as a third of what it should be. ...Now, all isn't lost. This only applies to ISA systems. EISA's 32-bit bus can accommodate this aperture requirement, and cards installed on systems with an EISA bus need not worry. Same may apply in the future for Local Bus ISA systems, as some vendors have reported that the VLB can be used to circumvent some of the aperture problems in lieu of an EISA bus. Until then, keep this in mind when buying video cards such as these. ...While we're caveating the emptors, a brief NOTE from an IBM insider is that when you buy DOS 6.1 from Big Blue, what you're really getting is PC-DOS 5.0 with some reversed-engineered MS-DOS 6.0 cloned enhancements. IBM reportedly has no legal access to any version of MS-DOS later than 5.0, which tends to explain why data compression has been relegated to such third party suppliers as Stac and AddStor. ...As to whether or not PC-DOS 6.1 is truly compatible, initial reports say that while the version is as stable as MS-DOS 5.0, there have been reports of conflicts and system crashes under Windows 3.1. Although IBM has denied any serious bugs with their new DOS release, the culprit is believed to be the reversed-engineered version of EMM386.EXE. ...Speaking of those third-party data compression utilities, industry insiders report that the reason IBM dropped Stac in favor of AddStor for its competitor against DoubleSpace is essentially the same that Microsoft has given for dropping Stac. Seems that Stac wanted more than their share of the profits and credits for the inclusion of Stacker 3.0 with PC-DOS 5.0 last winter, and wound up talking themselves out of yet another gravy train. ...Guess this is the best place to offer this hot tip regarding compressed drives and backups: instead of backing up all the files on the compressed file volume file by file, simply backup the CFV itself. Since the compressed drive is, of course, compressed, this allows you to turn off any backup compression routines and save more time. Tests conducted by the WWIVNews staff show that with Stacker 3.1 and Fastback Plus 3.0, a CFV containing 60Mb of files was backed up to just under 50 1.44Mb diskettes, whereas backing up the individual files with compression turned on required 53 diskettes of the same size! Similar result ratios were gained with Stacker and Norton Backup. ...While we're talking about IBM, the biggest complaint about the lumbering giant's PS/ValuePoint line of cheap systems - the proprietary video connector - has just become history. Market surveys had shown that this attempt to prevent buyers from using non-IBM monitors with the VP systems was the top reason given for *not* buying one of Big Blue's pseudoclones. Most people surveyed stated that they would have preferred to buy from the company that started it all, but that the designs of the ValuePoints prevented their use with high-quality monitors such as the NEC xFG series and the Sony Trinitron line. ...From the Mac Geeks Anonymous department: Insiders at Apple report that part of the Motorola-IBM-Apple arrangement that will make the PowerPC a reality also includes the rights for vendors using the PowerPC to incorporate Apple's new ergonomic keyboard into their designs. This will allow vendors to make this in-demand input device available for non-Mac environments without having to perform a serious reverse-engineering feat. This particular feature will also allow for daisy-chaining of Apple-based input devices into the same port, much as what Mac users currently have available. ...Finally, with v.FAST approaching, modem vendors have started to dump their existing stockpiles of 9600 bd modems on the market at prices that would have been unthinkable a year ago. Street prices for 9600 v.32/v.42b Hayes- compatible modems using the Rockwell chipset have dropped to just under $200, and 14.4 kbps modems have dropped to under $275. As v.FAST becomes ratified, expect these prices to drop at least another $100 each and signal the death knell for 2400 bd modems. ...The WWIVNews staff predicts that within 18 months of the ratification of v.FAST, not only will you not be able to give away 2400 bd modems, most BBS's won't even allow you to connect at anything slower than 4800 bd! Based on the number of 2400 bd modems sold in the US since 1984, don't be surprised if we see another New Jersey garbage scow scandal when someone tries to find a landfill big enough to dump all these worthless modems! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Dateline: @#$*()#! ³ ³ Editorial Commentary by Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ I had a nice, long, lengthy, in-depth, analytical, critical, full-scale, educational, logical, soapbox-squashing ranting editorial planned for this issue's special topic on the UU debate, but seeing as how Wayne essentially summed up my own thoughts on the matter...well, you get the picture. In any case, the matter has essentially been settled, and those who are still disgruntled can find solace in either looking at FileNET, or waiting for 2@2050's WW4-FREQ efforts to bear fruit. Those who are still not satisfied should consider looking at joining Fidonet. With that out of the way, I'll simply dedicate this edition of Dateline: @#$*()#! to several short topics and announcements. ITEM: Is anyone going to ONE BBSCON next month? If so, WWIVNews would love to print in-depth articles and reports on the events that are scheduled to take place. Of extreme importance is Ward Christansen's lecture on how he invented the BBS; a transcript of this would be most appreciated. Same applies for any other seminars or lectures held at the convention. If you're doing an overview of the con as a whole, be sure to point out areas where the convention holders fouled up. With WWIVCon approaching less than a year from now, this information could be valuable in helping the WWIVCon organizers avoid making the same mistakes! ITEM: See the above item regarding ONE BBSCON? Well, if anyone is going to Fall COMDEX, and you happen to see any striking technological advances that can be applied to the BBS environment, feel free to submit reviews of what you experience. ITEM: Would you believe over seven months later, I'm STILL getting requests for the WWIVNews Editorial Desk sub? Folks, if you don't have a SUBS.LST with a file creation date later than 2/1/93, then contact your AC or your GC about getting an updated release ASAP! Lord knows that if I'm still getting requests for a sub long dead, then 8-Ball must be getting quite a few more himself! ITEM: Ye Editor is looking for a BBS that specializes in TARGA utilities. If anyone has a line on a system that supports TrueVision boards beyond the usual stockpile of .TGA images, drop me a line in E-Mail. My job now involves the use of TARGA boards for professional TV production, and I'd like to find a BBS that might offer assistance in making this "overpriced...but worth the over!" card jump through a few more hoops. ITEM: Thanks go out to Filo (1@2050), Group 4 GC and host of the AC/GC sub for granting WWIVNews access to this administrative sub. The access will allow AC's and GC's to interact better with the WWIVNews staff, and will hopefully lead to regular features from those who bear most of the administrative burdens of WWIVNews. ITEM: While the issue is still 8 months away, start thinking about the April issue for 1994. This time around we'll be doing an "April Fool's" issue, which will feature as many phony gag articles as the WWIVNews staff can collect together into one issue. If you've kept up with Penn Jillette's bogus PC specials the past couple of years in _PC Computing_, then you get the idea of the type of sick, sadistic humor we're looking for. ITEM: Hmmm...seem to have run out of items! See you next issue! ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Next "Month" in WWIVNews: MS-DOS 6.0 is upon us at last. However, unlike MS-DOS 5.0, the Gates Boys' latest upgrade to the industry standard for PC operating systems is reportedly not as stable as its predecessor. WWIVNews takes a look at the pros and cons of DOS 6.0, and takes a look into alternatives to MS-DOS as well. WWIV under Windows 3.1, OS/2.xx, and DesqView will be explored as well. Coming Soon in WWIVNews: WWIV 4.23 is just around the corner. What will Multi-line capabilities and Fidonet compatibility mean to you, the WWIV sysop? WWIVNews asks some pertinent questions regarding what may be the most important stage in the evolution of WWIV since the introduction of WWIVNet. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Closing Credits ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ WWIVnews is an independent newsletter NORMALLY published monthly as a ³ ³ service to the WWIV community of sysops and users. The opinions & reviews ³ ³ expressed herein are the expressed views of the respective writers, & do ³ ³ not necessarily reflect those of the WWIVnews staff. Reproduction in whole³ ³ or in part is allowed provided credits are given. All rights reserved by ³ ³ WWIVNews, and all articles are copyright of their respective authors. ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ The source site for WWIVnews is the Klingon Empire BBS (512-459-1088), ³ ³ WWIVNet node @5282. Requests for information regarding articles and other ³ ³ editorial submissions, as well as back issue requests and the WWIVnews ³ ³ Writer's Guide, can be sent in e-mail to the WWIVnews editor, c/o 1@5282. ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ WWIV and WWIVNet, copyright 1986,1990 by Wayne Bell ³ ³ Any product or company mentioned or reviewed herein are copyrighted of ³ ³ their respective owners, creators, and other corporate pseudoentities. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ