synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / main / TEXT / NEWS9412.TXT < prev next >

Wrap

Text File | 2001-07-30 | 95.1 KB | 1,739 lines

▐██▌░ ▄█████▄ ▄██████░ ██░ ██░ ▄██████░ ██░ ██░ ▄█████▄ ██░ ██░░░░░ ██▄▄▄▄░ ███▄ ██░ ██▄▄▄▄░ ██░ ██░ ██░░░░░ ██░ ██░ ██▀▀▀▀░ ██▀████░ ██▀▀▀▀░ ██░ ▄ ██░ ▀█████▄ ▐██▌░ ▀█████▀ ▀██████░ ██░ ▀██░ ▀██████░ ██▄███▄██░ ░░░░██░ ██░ ██░░░ ██░██░ ██░ ██░ ██░██░░ ▀██▀ ▀██▀ ▀█████▀ ▐▌░ ▐▌░ ▐▌░▐▌░ ▐▌░ ▐░ ▐▌░▐▌░ ▐▌░ ▐░ ▐▌░▐░ ▌░ ▐░ ▌░ ▐░ ▌░ ▐░ ▐░ The Journal of IceNET December 1994 ┌───────────────────────────────────────────────────────────────────┐ │The Editor's Desk │ │ The Upper Registers Will 1@6754 │ │ │ │Features │ │ Getting to WWIVcon, Cheap! Seafox 1@2459 │ │ WWIV for OS/2 Preview East Bay Ray 323@3050 │ │ │ │WWIV Chronicles │ │ Modifications for Dummies! Spotnick 1@5497 │ │ │ │Software/Programming │ │ IBM OS/2 Warp v3 Will 1@6754 │ │ │ │Light Bytes │ │ The REAL Sysops Guide Aldo Cella 654@7654 │ │ Silly Strings Ima Moron 1@9661 │ │ │ │Special Feature │ │ The WWIVnet Technical │ │ Documentation (2/4) Midnight Tree Bandit 1@8411 │ ├───────────────────────────────────────────────────────────────────┤ │ IceNEWS Staff For December 1994 │ │ │ │ "...Winners of the 1994 WWIVcon Award for Electronic News" │ │ │ │ IceNEWS Publisher - Jim 1@1 │ │ IceNEWS Editor-In-Chief - Will 1@6754 │ │ │ │ IceNEWS Contributing Editors │ │ WWIV-Specific - Spotnick 1@5497 Lite Bytes - Ima Moron 1@9661 │ │ Software - Music Man 1@9680 │ │ │ │ Editor-At-Large - Crave 1@7668 │ │ IceNEWS Production - Help Wanted │ ├───────────────────────────────────────────────────────────────────┤ │ IceNEWS is always seeking submissions from those who have │ │ ideas for stories. If you have any ideas that you might │ │ like to see published, contact any IceNEWS editor or │ │ subscribe to IceNEWS Beat, subtype IceNEWS, host @1. │ └───────────────────────────────────────────────────────────────────┘ ┌───────────────────────────┐ ────────────────────────┘ E D I T O R ' S D E S K └──────────────────────── ┌──────────────────────┐ │ The Upper Registers │ by Will 1@6754 └──────────────────────┴─────────────────── Welcome to IceNEWS! We have a shorter than usual issue for you this month, but some neat information. Seafox tells you how you and the other sysops in your area can get to WWIVcon cheap. East Bay Ray has provided us with a sneak peek at the new version of WWIV for OS/2. We've got the second installment of the WWIV Technical documentation. And for all those who are considering starting up their own BBS, we've got the REAL sysops guide.. We've also got a comprehensive look at the features in the new version of OS/2, Warp. While the product is not perfect (nothing is), I think that it has the potential to be an extremely important product. Therefore, you can expect to see more information on OS/2 Warp and related stories over the next year. Happy Holidays to all, and we'll be back to a more conventional format next month. ──══════════════════════════════════════════════════════════════════── ┌───────────────────────────────┐ ──────────────────────┘ F E A T U R E S T O R I E S └─────────────────────── ┌────────────────────────────┐ │ Getting to WWIVcon, Cheap! │ by Seafox 1@2459 └────────────────────────────┴────────────────────── Everyone understands air travel on the most basic level. You buy a ticket, you go up in the air, you come down, you leave the plane. However, the modern airfare climate is such a twisted morass that only people who work in it, day to day, have a glimmer of hope in understanding it. As a Travel Agent, I see this all of the time. The rules are so convoluted these days that only by being informed can you ever hope to get the cheapest fare. MY SYSOP WENT TO WWIVCON, AND ALL I GOT WAS THIS LOUSY GIF FILE Lets talk about groups. A group, in Travel Industry parlance, is 10 or more people, travelling on the same flights together. If a group has 21 people, that 21st person goes free. (A great way to reward the local server sysop....) Groups require planning. The best way to plan a group is to have a person designated as the group leader. From there, you determine how many people are interested in going. Then, the group leader calls his local travel agent, and gets the fare to the destination, as well as what airlines fly there from his home airport. (Everything is airports. A group can consist of all of Saskatechewan, as long as they all use the same airport to fly to the convention.) From there, the Group leader contacts everyone and advises them of the fare. Anyone who says "Outrageous! I could buy a Yak for that much money," or any similar sign of toxic cashflow shock, should probably be moved into the maybe column. From there, you get a firmer count. Then, the fun starts. Call the travel agent again, or use whatever arrangements the convention has planned. (WWIVcon might be developing it's own meeting desk, if the particulars can be worked out...) Then, inform the agent of your group size, as well as preferred flight times and carriers. Make sure to ask which ones are non-stop. It might be worth it to make a stop in St. Louis or Houston to fly TWA or Continental, for instance. (And of course, with proper co-ordination, you can pick up other groups at such points, thereby subjecting the flight attendants to an ever growing hoard of BBS'ers.....) The travel agent will call the airlines, and negotiate a rate for your group. Be sure to ask the travel agent what the rate is on all of the carriers you're interested in, not just one or two. Some agents get commission overrides on particular carriers, and they will try to steer you towards certain carriers even though the cost may be higher. From there, you will also get a deadline. Take this deadline very seriously. Also, you will only be able to reduce your group by 20% and still keep the negotiated rate. Get on this today. As space fills up, and as we get closer to the date, it will be harder and harder to get group space. Now, what if you're one of those people who lives in a tiny WWIV community? This is where the Convention/Meeting Rate kicks in. The WWIVcon staff will be negotiating Convention rates with the major carriers. This will definitely include United, Delta, and American Airlines, and will also probably include a few of the smaller carriers as well. (If you know of one you want to fly on, E-mail the WWIVcon staff) Convention rates are a compliment to Group rates, but with a twist. Group rates require everyone to be on the same flights. The convention rate provides a percentage discount to all people flying to a certain convention point, as long as they book their reservation using the convention code. The usual discount is 5% for coach class tickets, and 10% for first class seats. ACTUAL CONTENTS MAY VARY There are several things that you need to make sure you get. First off, you want seat assignments and boarding passes. This ensures you the kind of seat you want, and also saves time because you don't have to go the counter at the airport. However, there is one good reason to go to the counter-- Exit row seats. On some carriers, Exit rows can be assigned beforehand, but the boarding passes can't be issued. This is to ensure that the passenger meets the exit row criteria implemented by the FCC- physically able to open the exit doors, as well as willing to open them and assist people in evacuating the plane in an emergency. Exit rows offer extra legroom. You want the seats facing forward, as the seats facing backward do not recline. The row just in front of the rear facing exit row also don't recline. Ask about special meal options. They are usually catered in much smaller quantities, and as a result, usually taste much better. This is extra important if you have dietary needs. Low fat, low salt, kosher, hindu, vegetarian, vegan, and moslem meals are all offered by most carriers, as well as options for fruit plates, seafood meals, and a couple of other special meals. Make sure you get the lowest fare in the market, and if at all possible, get one that is refundable. If you are willing to do a connection, and can't take advantage of convention or group rates, try to get a connection through Chicago or Atlanta. These cities have become low fare meccas since the wave of cheaper start-up carriers have hit the markets. Names to remember are MarkAir, Valujet, Southwest Airlines, National Airlines, and Midway Airlines. Avoid Sunjet- they frequently lose reservations and are often not on time. Get a frequent flyer number on whatever carrier you plan to fly on. If you are flying TWA, and you usually fly American, you can use your advantage number on your flight. Frequent flyer numbers give you something for nothing, and that's always a good deal. IT'S LATE IN THE EVENING... Now it's less than one month before WWIVcon. Everyone else who's going in your home town (or more importantly, airport region,) has made their plans. They're getting a group fare, and the local server sysop is getting to fly free as thanks for all he does. Suddenly, you realize that you are, after all, going to be able to make it. But you can't afford full coach, and there are no fare wars going on. What to do? You call Travel Bargains. If you're within 30 days but not within a week, Travel Bargains can get you a low fare on TWA. They do not handle originations in St. Louis. (They have a really stupid reason for this......) You will need a credit card, or be willing to Fed Ex a check. Their fares are usually 60% of TWA's KE14NR fare. Call TWA to get the rate for that fare, ask if it's available in "T" class, and then call Travel Bargains. Their number is 1-800- 872-8385. And if you put it off for too long, you're gonna miss it, bud..... BIG OL' JET AIRLINER It *is* possible to get to WWIVcon economically. The key is planning. With WWIVcon in Buffalo, a lot of people have shown concern that it'll be too expensive. However, the WWIVcon Site Committee has decided that Buffalo has so much to offer that it offsets the expense. If you can possibly make it, you owe it to yourself to try. If you're in a big WWIV community, volunteer to be a group leader. This will mean more people from your area will make it, and someone might get to go free. E-mail Jim (1@1.Icenet) and let him know you want to get 20 of your closest friends at WWIVcon. If you're in a smaller community, get involved in the WWIVcon sub. And if you're in Buffalo, get ready, because a whole bunch of computer nerds are about to descend on you and want a good time. With the information in this article, you will be much better armed to deal with the realities and possibilities of affordable air travel. Because it's always easier to let someone else drive............ ──══════════════════════════════════════════════════════════════════── ┌───────────────────────┐ │ WWIV for OS/2 Preview │ by Easy Bay Ray 323@3050 └───────────────────────┴──────────────────────── [Introductory Note by IceNEWS EIC, Will 1@6754: A few months ago, East Bay Ray, developer of the OS/2 version of WWIV, sent us a question and answer sheet about the product. Ray's been busy since, and we haven't been able to obtain more information. However, I've decided to run this information in it's entirety in order to inform the WWIV community of what's going on in this exciting area] Guys - This is my preliminary Q&A for WWIV for OS/2. _PLEASE_ let me know if you can think of any other questions you or another SysOp might like to know the answer to... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- WWIV for OS/2 - A Preview by Jeff Garzik (East Bay Ray #323@3050 WW4Net) Since many of you have sent me questions via e-mail, I will attempt to describe WWIV/2 in a Q&A format. How is the WWIV/2 user interface different? There is no difference. How is the WWIV /2 SysOp interface different? There is no difference. How is the WWIV/2 setup different? For new installations, the SysOp will go through the normal INIT.EXE setup procedure, and then run INITOS2.EXE to complete the installation. For upgrades, the SysOp will merely have to run INITOS2.EXE. I'm upgrading to WWIV/2 - will I lose my data? Absolutely not. WWIV/2 data files are byte-for-byte compatible with files created with WWIV for DOS. Will I notice any change in response times over WWIV for DOS? On lower end machines (386s) or machines with very little RAM (4MB-6MB), there will be very little difference in the response times. On other machines, there will be an increase in response times and decrease in lost characters (for the higher speed modems). What are the minimum requirements for running WWIV/2? OS/2 version 2.1 Any 386, 486, or Pentium machine 4 megabytes of RAM Any WWIV-supported modem What are the recommended requirements for running WWIV/2? OS/2 version 2.11 (that's OS/2 v2.1 with the CSD applied) 486 or Pentium machine 8 megabytes of RAM Any WWIV-supported modem Will WWIV/2 run my new super-fast 19.2k or 28.8k modem? Yes, but you currently have to lock your port at 38400. The next version of WWIV/2 will support any speed your serial card supports. Will WWIV/2 run native OS/2 chains? Yes. The C chain functions (inkey(), mpl(), onek(), etc.) provided by WWIV will be available in the form of an OS/2 DLL. Will WWIV/2 run my current MS-DOS chains (doors)? Yes, but expect to take a resource hit. Running an MS-DOS program requires a much greater amount of memory than a corresponding OS/2 program. Will OS/2 versions of the network utilities become available? This issue is up to Wayne, not me. I have bugged him several times, but he doesn't want to give out the source to the network utilities. What does that mean for you? The initial version of WWIV/2 will use the DOS network utilities -- taking up a LOT of your precious RAM. If you are running two nodes on the same OS/2 machine (or simply running another application while WWIV/2 is doing network stuff), expect to take a serious performance hit. Bug Wayne so that you, the SysOp, will have decent OS/2 network utilities when WWIV/2 is released! ;-) How much will this glorious product cost? Ask Filo. I'm just a byte monkey. ;-) Will shrink capability be available in WWIV/2? No. There is no need. OS/2 does not have a foolish 640k barrier. ──══════════════════════════════════════════════════════════════════── ┌───────────────────────────────┐ ──────────────────────┘ W W I V C H R O N I C L E S └─────────────────────── ┌──────────────────────────┐ │Modifications For Dummies!│ by Spotnick 1@5497 └──────────────────────────┴────────────────────────────────────────────────── If there is something that I dislike about the WWIV modifications, it's that 75% of them never works on the first time you install them. For some reason, there is always a bug somewhere in the modification, and you wasted your time installing them. Well, I am one of those modification author that was writing modifications that always needs a fix, because I was having problems to extract the mod from inside WWIV and put it in a text file. Many other authors are regular to the "D" revision of their modifications, and sometimes there is more... To start being careful about that, I remember receiving a e-mail that made me realize that it would be better for me to test them before posting anything, that what I started to do then, and also asked for beta testers to check them out before their release. It was great, but of course, there is NOTHING that can stop an error from getting in there. So to you, novice or intermediate modders, even those who are well known to produce quality modifications, you should all follow those simple rules: ■ Never release a modification before a rough test on your own system for a specific period of time (1 Month is good). ■ Ask some people to test the modification for you before releasing it. ■ Install your modification on a virgin copy of WWIV before releasing it. Follow your own text file and act if you were modding for the first time. ■ Make your modification to fit the more possible with WWIV standards functions, avoid the "you must have *.MOD installed to use this modification" unless it is one of your own modification, or something very popular. Because most of the time, people don't have that installed and will have to look everywhere to find it before installing your modification. A kind of pain that will reduce the activity of your own modification. If you follow those simple rules, you will have success in the WWIV world. Because you will be known as a bug-free modifier and people will start trusting you. Note that there is other things that you must follow, that is why I decided to include this ethical code for WWIV modificators. This is generally what most Sysop uses, but in case you didn't know, here it is: I will take my own modifications group example to follow the ethical code: ┌─────────────────────────────────┐ │ WWIV Modifications Ethical Code │ └─────────────────────────────────┘ The Header ══════════ ┌┬─── ── ─ ─ ── ───────────────────────────────────────────────────┬─ ∙∙ ││ Alternative Worlds Presents │ └┼─────────────────────────────────────────────────────────────────────┐ ││ Mod Name » ALTW-02A.MOD │∙ ││ Difficulty » █████▒▒▒▒▒▒ (5/10) │: ││ WWIV Version » 4.24 ││ ││ Date Affected » 10/24/94 ││ :│ Files Affected » BBS.C / MODEM.C / NETSUP.C / VARS.H / XINIT.C ││ ∙│ Description » VGA Waiting For Caller Screen Status Screen ││ └─────────────────────────────────────────────────────────────────────┼┐ │ A French Mod Division Release - (C) 1994 FutureSoft ││ ∙∙ ─┴─────────────────────────────────────────────────── ── ─ ─ ── ───└┘ ■ Avoid too long header: Generally, most of the Sysops hate that. The example has a fancy header, but it isn't too long, so you can see it in less than a half screen. DO NOT PUT COLOR CODES IN THEM! This will be a pain when people will see it in their text editor when doing the modifications. ■ Mod Name Line: Generally, you input the filename you wish, not more than 7 letters, and it should have the extension *.MOD and not *.WWIVVERSION, because this cause many problems to SysOp that collects modifications. You must use a name that is specific to your alias or system name, to avoid incompatibility with modifications below WWIV v4.22 where there was no ethical code. You have to put a number also to show that this is your xth modification, and put the revision letter if it is a revision. ALTW-02A.MOD ^^^^ ^ ^ |___|_|____________ ALTW, specific to Alternative Worlds | | |_|____________ 02, this is the 2nd modification | |____________ A, this is revision A. If you follow this example, it will help you on your way to hall of fame <grin>, because it will be easy to find your modifications on a BBS that put mods in their directories. Double check to be sure that nobody else uses your acronym. ■ Difficulty Line: Put yourself at the time you started modding, and think of the difficulty your modification would be to install. You can use a graphical meter: █████▒▒▒▒▒ or put the numbers: (5/10) This will help novice modders to ask for help to install some modifications, or to be more careful than others. ■ WWIV Version Line: Tell on which version you installed the modification and TESTED the modification. Do not include future versions of WWIV unless you are sure that it is going to work. We saw too many people tell "should work with v4.23" and that were using "open/read/write" without the multi-instance modifications needed that this is very important. On the example, you see v4.24, well, as a Beta site of WWIV, I can assure that this will work with v4.24. I did a small mistake by not including the Beta number (which is ßeta 3). Do not include previous versions of WWIV unless you tested it also, a v4.23 modifications won't necessarily work under v4.22, so then people using v4.22 will be aware that it is possible that the modification won't work. ■ The Date Line: Very useful for system that produce mods collection, to put your modification in the right collection. Also shows that it is a repost if someone post your modification again. ■ The Files Affected Line: This is very important also, it should how many files your modification will affect, and will warn the person if it affects any of the major *.H that need an entire compilation. It will also help SysOp to think if they already modified that file before reaching the last step of your modification and finding out that they have a totally different function instead of yours. ■ The Description Line: A very BRIEF description of what your modification does, not more than ONE line, keep in mind that this is what people will check first, so you need to have a punch line there. If your punch line is interesting, people will check the extended description section. ■ The Name Line: Include your handle or modification group name, to know who did that modification. ■ The Copyright Line: Now that we know that modifications can be copyrighted, but keep in mind that all WWIV code included is copyrighted to WWIV Software Services, you have the right to include your own copyright notice. I suggest you put the disclaimer at the end of the file instead of the top, because this generally bug people very much, only if it is more than one line. Introduction ════════════ ■ The Long Description: A verbose description of what your modification will do, generally, it is better if you include a snap shot of what it will look like also. You need to describe each features of your modification. Include also multi-taskers under which your modification has been tested. This can be very useful. You should also put the compiler name and version that you used to do this modification. I already did modifications that weren't working with older versions of Turbo C. ■ Requirements: Include anything that is needed to use your modification. If you need another place, this is the place where you put the name of this modification. Example: Requirements for using this modification: - VGA Graphic Card Or Better - VGA Monitor or Better - WWIV v4.23 or higher (tested on v4.24 Beta 3) ■ Thanks: This is where you give credit where it is due, generally it would be a shame to forget Wayne Bell in those lines, since it is his software you are modifying. Also put here the name of each and every single person you might have steel code from. This is very important, just like when you do a report, you have to include all your sources. ■ Upgrading Information: If your modification is a revision, you need to tell people that installed your modification, what to do to upgrade from previous version, which steps to proceed, etc... this is NEEDED in each mod that you produce. ■ Legend: Include this because it might confuse some people if you produce modifications that doesn't use the same standards. Example: ┌═══╤════════════════════╕ │ = │ Existing Line │ │ + │ Add this line │ │ - │ Remove this line │ │ * │ Modify this line │ ╘═══╧════════════════════┘ Note also that some people use 1 space between the code, and some doesn't. There is no standard for this, but it will be a good place to put a note about it. This won't change a thing, but make the source code more easy to see. ■ Warning Line: Do like most of modders, include a warning line even if you have tested your modification. Tell people to do BACKUPS of their source before installing your modification. This is important. Body Of The Modification ════════════════════════ ■ Steps: Separate your steps so it can be easily found. We use this standard: ───[Step 1]─────────────────────────────────────────────────────────────────── So we are sure that nobody will miss a step. Don't include more than one operation in each step. Do not include modifications to more than one function in each step. Put at least 2 existing lines, so people can locate more easily. It is also VERY IMPORTANT that you don't put color codes at the end of each lines (after the ';' code generally) even if it makes your mod ugly at the display, because this causes pain to everyone when they try to install your modification from an extracted post. The End Of File ═══════════════ ■ Compiler Informations: Tell people if they need to do MAKE FCNS, if there is a change to the makefile, please tell them under which compiler you did this modification, and also notice if they need to do a full or partial compilation. ■ Informations Lines: Tell people where they can reach you, name of your BBS, phone number and network address of the main WWIV networks you are in. You don't have to include local networks generally, but you can do that too. If you have a sub about your modifications, leave a note here for people to know how to get support from you. If you don't plan to do support, it is the place to tell that, because you should generally get mail from the modifications you did. And you are done, following all those steps should end with a clear text file, ready to post on the modification subs all around. If you upload your mod to a system, please include in the archive a FILE_ID.DIZ or DESC.SDI inside it, with your description. Here is the example we use in French Mod Division: Shut-Down System For WWIV Mod Name : ALTW-27.MOD Difficulty » █▒▒▒▒▒▒▒▒▒ WWIV Version » 4.23/v4.24 Date Affected » 10/25/94 A French Mod Division Release.. So people will see that when they download or list the files. Be sure that the first line is the description, because stock WWIV version with file tagging doesn't allow to show more than 1 line, so this is the important line. If you post the modification, there is also an ethical code for the title you use. I already tried to have people do it another way, and I got tons of replies to keep it the way it is. PLEASE do that, it is very important, else your modification may suffer from that, because it is needed for SysOps that extract modifications do their xfer area: Title: FILENAME.MOD: Breif Description Of Your Modification. Once this is done, then everything should be perfect. Again, this is a standard. You might not conform to it, but this is what should help people to follow a code that will help the WWIV community. ┌─────────────────────────────────────────┐ ─────────────────┘ S O F T W A R E / P R O G R A M M I N G └────────────────── ┌────────────────────┐ │ IBM OS/2 Warp v3 │ by Will 1@6754 └────────────────────┴───────────────── With the release of the new version of OS/2, now officially known as Warp, IBM has brought Operating System/2 to a new level. Warp features enhancements and performance increases in virtually every area, with added performance, usability features, and bonus applications. While it's dangerous to compare Warp to an as yet unreleased product (Windows 95), it's probably safe to say that Warp is a match for any Operating System product that will be made available in the next year. I should note that I made these installations over Windows for Workgroups 3.11, starting from scratch. The current version of Warp is not designed to install over OS/2 2.1 systems. The most noticeable enhancement to the product is that it's much leaner in terms of memory requirements. Warp takes as much disk space as before, but it will now successfully run (although not blazingly fast, but tolerably so) in four megabytes of RAM. In fact, this article is being written on a 486sx-33 laptop with four megabytes RAM running Warp, and while there's a lot of disk swapping, it's really just as usable as Windows for Workgroups on the same machine. Overall execution speed has been improved (although with the additional features in the release version, Warp does execute slightly slower than the first Beta). In tests, Warp executed Win16 applications considerably faster than Windows NT 3.5, and only slightly slower than Windows For Workgroups 3.11 (in fact, the difference was not noticeable in virtually every case, except for a slight delay at the beginning where OS/2 loads the Windows code into memory). Device support has been greatly increased, as well. Warp comes with a much larger variety of sound, video, SCSI, and CD-ROM drivers than OS/2 2.x. Earlier versions came with a large amount of printer drivers, and that number has been increased as well. Warp now ships with drivers for most Sound Card-CDROM combinations, something else that was lacking in 2.x. It should be noted that OS/2 now supports more devices right out of the box than Windows 3.x or Windows NT, and supports many newer pieces of hardware to boot. The installer has been greatly improved. It now does a much better job of auto-recognizing hardware than before. On both my systems, it correctly identified all the hardware (it picked the wrong NEC CD-ROM drive, but the driver it installed functioned fine) installed. Again, some of it (such as the SCSI card) was not supported directly under 2.1. There is also a "One Button Install" option for novice users, which will make all the decisions for you, and then just prompt you for disks. When I tried this, it worked fine. Multimedia install, once a seperate process, has been integrated into the main installer, althouh some of the extra multimedia programs (such as the Media Viewer) are installed separately as part of the BonusPack. The desktop has three main new features, once installed. Most obviously, the desktop default color has been altered to teal (which, while it may sound terrible, is actually a wonderful color for the purpose, and I haven't bothered to change it to anything else), and all the icons have been redone in a 3d style. This lends Warp a much more modern look than pervious versions. A floating Launchbar has been added to the bottom of the screen. It holds shadows of various objects (by default, the shredder, A: drive, and some others), which you launch with one click. You can also create drawers to hold additional objects. My Internet drawer, for instance, has the SL/IP dialer visible on the Launchbar, and the rest of my Internet utilities in the drawer. To see the rest of the icons, I click on the handle and the drawer comes out. Click again to retract it. The drawers can be dragged to any portion of the screen, to boot. The last obvious change is on the pull-out menus that you access by right clicking an object. The settings selection, which was previously a submenu under the "Open" heading, now has it's own place on the main menu. This makes training and use much easier. Multimedia support in Warp has been greatly enhanced. The digital video module now supports more varieties of .AVI file, and also plays digital video files in .FLI and .MPG (MPEG) formats. A "Media Viewer" is included in the BonusPack (see below) which acts as a light table for multimedia files. This works by dragging image files (GIF, TIFF, PCX, etc) into the window, where OS/2 then generates a thumbnail image. It also provides "click here" icons for video and sound files. This worked well, and produced accurate thumbnail representations of the images. The only problem was when I dragged a large (over 1024x768) file onto the display. The system slowed almost to unusability as the Viewer attempted to generate a thumbnail. After five minutes, I rebooted. As we've seen, Warp also includes drivers for many more sound cards (including some relatively obscure ones) than it did previously. You also get a stripped down copy of Person-to-Person, IBM's groupware offering. An almost totally new set of sound files are included, as well as several MIDI music files, including a nice jazz riff that plays during the BonusPack installation. Warp now includes a complete set of external applications in the new "BonusPack". IBM Works (originally a popular stand alone integrated package for OS/2) includes a spreadsheet, database, word processor, and charting module. These are not "applets" like those packaged with Windows 3.1 or Windows NT - they're full strength applications, with features like a spell checker, mail merge, and full DDE links between them. At the product launching, one IBM representative said that the programs were being included to demonstrate the usefulness of real 32bit OS/2 applications. They do a good job. The OLE/DDE features, perhaps the best integrated, are fast and seamless. For example, you simply grab a chart in the charting module with the mouse, and drag it into a word processor document. It's instantly transferred. The is a sharp contrast with Windows 3.1 OLE, where, when this is possible at all, the transfer can take several seconds to minutes. The integrated applications make OS/2 a one shop software shop, as the programs are of a higher quality than those found in some standalone integrated packages (such as Microsoft Works). The BonusPack also includes several other applications, including a "Lite" version of HyperAccess Communications for OS/2, FaxWorks/PM, a system information tool, and the IBM Internet Connection. This last is perhaps the most impressive. It essentially consists of a slightly stripped down version of IBM TCP/IP 2.0 (providing SL/IP line connectivity), and a set of clients. You can connect via SLIP to the IBM provider (Advantis) or to a local provider. I took this opportunity to setup a SLIP connect with a local vendor (The Internet Access Company of Bedford, Mass), and it worked great. The included Internet clients range from adequate to excellent. The Newsreader and Gopher clients are fine. The FTP client was usable, although I decided to use a Windows based one instead. Ultimedia Mail/2 Lite has some nice features, but was difficult to configure and had some rough edges (for instance, no word wrap). While it also possessed some excellent features, I decided to use Eudora (a popular Windows based mailreader) instead. Web Explorer/2, the World Wide Web/Mosaic client, isn't shipped with the package. Instead, once you have Warp installed, you use the "Retrieve Software Updates" program and download the latest Beta. This worked well when I was first installing the package, and is how I obtained Beta .91. When .92 was released (on November 23rd), this option gave me an "Unable to resolve address" error, and I had to FTP the package instead. I can only assume that this is a problem at the IBM server. The client itself, however, is excellent. I'd been using Mosaic Netscape, and WE/2 matches it in terms of features, and surpasses it in terms of reliability. I wasn't able to find one HTML document it couldn't handle. It runs quickly, and supports Forms better than Netscape. It does a great job of printing the pages as well. The WebMap (which allows you to move back to any spot you visited previously) is wonderful. The only thing that isn't supported (that I could find) was mailto: links, which allow you to click and send mail. In .91, these weren't recognized, but in .92 I got an error message saying that they weren't currently supported, so we can assume that it will be added before the program is finished. It also takes advantage of OS/2's threading and object-orientation features, allowing, among other things, you to drag a .GIF file out of the program and onto your hard disk. The one thing the Internet Connection lacks is an IRC client, but I found a relatively good (text mode) IRC/2 client that works quite well. The Internet Connection software contains a shell Windows Sockets DLL, which allows you to use any standard Windows based client. The DLL is very fast and reliable. On the whole, the software causes me much less trouble than similar Windows based programs, and runs faster. With it's enhanced speed and usability, not to mention bonus applications, Warp is an excellent product. While I hate to come out this much in favor of a product, I really can't help myself in this case. IBM has been promising a better Windows than Windows for quite some time (it's been a better DOS than DOS for years), and they've finally delivered. The one sore spot is applications, which is being quickly rectified, by the inclusion of excellent apps within the OS package itself, and an increase in development by third parties (Borland, for instance, is porting their Object Windows libraries to OS/2. When this is completed, we can expect a flood of OS/2 versions of current software). Warp has the potential to catch on, and it should - it's shameful that people should have to make do with DOS and a shell. Additional flavors of Warp will be released late this year and early 1995. These include a version featuring peer to peer networking (which, according to IBM, will be compatible with Windows for Workgroups (NETBEUI) networks, as well as Novell and other platforms), and versions including IBM's optimized WIN-OS2 code. There will also be a new version supporting Symmetric Multiproccessing, in the first half of 1995 (OS/2 2.1 for SMP is available now). ──══════════════════════════════════════════════════════════════════── ┌─────────────────────┐ ───────────────────────────┘ L I T E B Y T E S └──────────────────────────── ┌────────────────────────┐ │ The REAL Sysops Guide │ By Aldo Cella 654@7654 └────────────────────────┴─────────────────────── So, you want to run a BBS, do you? Got it all planned out, eh? Well, before you start anything at all, there are a few things you ought to remember. It seems that lately, with all the boards, AE's, and CF's going up everywhere, quite a few sysops have forgotten or completely ignored the unwritten code established by those early pioneering spirits of the good ol' days. You see, no matter what hardware you use, no matter how much storage, how fast a modem, or what software you want to run, the success or failure of your system ultimately depends on YOU. The remainder of this file consists not of countless obscure details on how to run your system, but of a few short hints which should prove helpful at times. Remember, REAL sysops know the difference between constructive criticism and insults. * ACCESS - One of the most frustrating things that can happen to a new user is to log onto your board after being validated by you, only to find out that he still doesn't have access to 80% of your system. REAL Sysops make plenty of their system available to the average, non-privileged user. ** Corollary: You'll always have more average users than privileged ones. * SUBSCRIPTION FEES - If you plan to charge a subscription fee of any kind for your system, MAKE SURE that it's worth the money to have an account on your system! REAL Sysops who charge subscription fees realize that their system is now a business. * SUBSCRIPTION FEES II - If you are going to charge a subscription fee, MAKE SURE that you VERY CLEARLY define exactly what it is about your system that the user is having to pay for. REAL Sysops who charge subscription fees check out all the legalities FIRST. * SUBSCRIPTION FEES III - If your system happens to have an AE, Catfur, etc., or happens to have any phreak/hack info anywhere on it, DO NOT CHARGE ANY FEES! REAL Sysops may take a chance here and there, but they aren't idiots. * ADVERTISING - Getting publicity for your system must be done carefully. Most likely, people's first impression of your board is going to be determined by the first few lines of your ad, so post your ad carefully. REAL Sysops understand this, and will not sound like a used car salesman when advertising their board. ** Corollary: REAL Sysops know that arrogant ads will attract only arrogant users. * ADVERTISING II - Be decent about how you put your ad on someone's board. Make it short and to the point, and leave it in a section which you know is read frequently (i.e., the public board). REAL Sysops know that redundancy will irritate intelligent people. * SECURITY - If possible, make every possible test of your security before you put your system up. It is best to do most of these tests both while logged in at the board, and again from over the phone. It also can't hurt to have other people try to crash your system during the testing. REAL Sysops are very thorough about this, and sleep much better because of it. ** Corollary: Time spent perfecting your input routines is more wisely used than time spent re-constructing your userfile after it's been blown away. * SECURITY II - Once your done testing, and you know your system is solid, don't make a big deal out of it. Talking about security all the time will make users think you're paranoid, and hackers think you're challenging them. REAL Sysops know that discretion is as important as prevention. ** Corollary: REAL USERS rarely ever ask a sysop about his system's security. * VALIDATION - Always validate within 24 hours if you can. Little is more frustrating for a user than to log onto your board after a week has gone by, and find out he still isn't valid. REAL Sysops always validate quickly, as it always helps with public image. * VALIDATION II - NEVER, at any time, ask new users to answer why they should be given an account on your system. REAL Sysops know that the only people who could answer that question impressively don't even NEED to be calling your system. ** Corollary: You can't build an ELITE board by treating users like spinach in a strainer. * RESTRICTED BOARDS - If you are going to have restricted areas on your system, it's best to make them invisible to those who can't access them. REAL Sysops would rather do this than answer 10000000 feedback messages from users asking for access to your restricted areas. * ABUSERS - From time to time, or perhaps more frequently, you'll end up having to deal with some jerk who is making trouble on your board. REAL Sysops handle these people swiftly and quietly before they get out of hand. ** Corollary: REAL Sysops will only warn abusers ONCE. * ABUSERS II - At times, the jerk that you really want to grind into the dust hasn't really done anything serious yet - maybe just sent you some rude complaints. In this case, it's better not to lose your cool. REAL Sysops know that trading insults with an idiot makes you look worse than he does. ** Corollary: REAL Sysops never drag private matters out in front of the public eye. * CRASHERS - It is very likely that the day you first advertise your board, you'll probably get a couple of attempts at crashing your system. These crashers are doing it just for the thrill, and are counting on the fact that the security of new systems is generally poor. REAL Sysops will have taken this into account, and will have little to worry about. * HACKERS - You probably won't encounter any real hackers unless you charge a subscription fee for your system. These people are usually more determined than the above crashers, and are out to get someone's account on your system, preferably one with high access. Preferably YOURS. REAL Sysops deal with these people carefully and try not to make enemies of them. ** Corollary: REAL Sysops know the difference between a REAL Hacker and a 12-year old WARGAMES fanatic with an acoustic coupler. * NOVICES - From time to time, you'll also most likely run across people on your board who are very new to telecommunications, and will ask very dumb questions. REAL Sysops remember what it's like to be "unenlightened", and will not snap out rude answers at these people. * ADEPTS - Eventually, you may also run into a few people who are so advanced, it'll blow your mind. REAL Sysops know just what to do upon discovering one of these users - QUESTION HIM! Get him to talk to you, and find out what he knows and how it can help you. ** Corollary: There's a difference between being inquisitive and being a pest. ** 2nd Corollary: REAL ADEPTS don't hoard their knowledge. * PUBLIC RELATIONS - Many systems suffer from having a sysop who never chats with users, and answers feedback rarely at best. REAL Sysops keep in touch with their callers, and are respected for it. * CUSTOMIZING YOUR SYSTEM Adding modifications to your system is mandatory if you expect it to be unique, and can be one of the main factors in its success. It can also be the primary instrument of its destruction. REAL Sysops know this, and usually follow some variation of the following rules. Follow these steps, and you'll rarely ever have to worry about any mods you add to your board: A. Pull an idea for a mod out of your imagination. B. Consider how you would go about adding it to your board. C. Try adding it in that way to a BACKUP COPY of your system. D. Test it to see if it works. If not, you added it wrong. Back to B. E. Test the mod to make sure it can't be used to crash your system. F. Test the rest of your system to make sure it's still solid. This completes the REAL Sysop's Guide. On a final note, you won't ever have trouble recognizing a REAL Sysop. Just listen to everyone talk about a board they really like sometime. There's probably a REAL Sysop running it. ──══════════════════════════════════════════════════════════════════── ┌───────────────────────────────┐ │ Silly Strings │ by Ima Moron 1@9661 │ From Icenet Sysops Everywhere │ Lite Bytes Editor └───────────────────────────────┴──────────────────── From: Morgoth #2@10408 WWIVNet Home In Nome on my modem by the Bearing Sea! From: Sam #1@4051 WWIVNet MacIntosh: Computer with training wheels you can't remove. From: The Zoo Keeper #1@20762 WWIVNet If the answer isn't right, the question must be wrong! From: "Adam Selene" Rodent #221@3 WWIVNet Good...Bad...I'm the guy with the gun. From: Octavious #1@8357 Icenet Never put off till' tomorrow what you can avoid all together. From: Aaron Pathfinder #18@2491 WWIVNet Those that beat their swords into plow shares, will plow for those who don't From: Indiana Jones #174@15131 WWIVNet ...Your tagline has been assimilated. -- The Collective From: Pandora #424@9661 Icenet Pandora....open my box if you can!!! From: Jim Lilly #74@1294 WWIVNet Worry is a dark room for developing negatives.... From: Papa Bear 1@11579 WWIVNet (A)bort, (R)etry, (I)nfluence with a large hammer. ──══════════════════════════════════════════════════════════════════── ┌───────────────────────────────┐ │ WWIVnet Technical Docs │ by Midnight Tree Bandit 1@8411 └───────────────────────────────┴─────────────────────────────── [IceNEWS Serialization Note - This is part two of four. Internal page numbers have been retained for ease of reference. Page breaks, however, have been removed.] IV. MESSAGE PACKETS The most important component of any network is the mail file, which contains all the public posts, email, and network information which makes the BBS network what it is. WWIVnet mail files consist of a series of mail packets, each with its own header segment describing the type and size of the packet. There are two types of mail files in WWIVnet, each similar but processed differently. The netmail file is the file received from another system, and contains packets destined for that system as well as other systems in the network (if the BBS has more than one connect). Netmail files may be compressed, using the PKWare compres- sion libraries. The local mail file contains the packets from the netmail file which are destined for the BBS only. A. Message Header Each message sent through the network has a header. The header tells which user/system originated the message, where it is to be sent to, the type of message, and other information. The structure of the header is: typedef struct { unsigned short tosys, touser, fromsys, fromuser; unsigned short main_type, minor_type; unsigned short list_len; unsigned long daten; unsigned long length; unsigned short method; } net_header_rec; Each header is 24 bytes long. The fields, in detail, are: tosys, touser The destination of this message (system number and user number, if applicable). The touser field will be zero in all cases except for email (main_type==2) and SSMs (main_type==15). fromsys, fromuser The origin of the message (system number and user number). This contains the user number/system number combination of who actually wrote the message. If the message is "gated" (that is, a sub post from a system on a different network, or email from a user in another network), 'fromuser' will be zero. main_type, minor_type The type of message this is. The main type stores the actual type (email, post), and the minor_type is used to specify what sub-type it is. For example, the main_type for a post is 3. The minor_type is then used to specify what type of post it is, what subboard the post is to go on to. A list of main and minor types is found in section IV(D), below. daten The time the message was sent, stored in unix time, as the number of seconds since Jan 1, 1970. length The length of the message. This includes any information between the packet header and the message itself, such as the sender's name, message title, and so forth. Note that the length does not include the node list indicated by list_len. method If the file is encrypted, compressed, or source-verified, this describes the type of compression or encryption used. This will tell NETWORK2 (or other local mail tosser) which DEmmm.EXE to execute. DEmmm.EXE is explained in more detail in the next section, below. list_len Some messages need to go to more than one system. For example, networked posts may go to over 20 different systems. It makes no sense to have a separate copy of the message for each destination system, so the same copy of the header and message is used. (This is referred to as "stacking" the message). The list_len specifies the number of destination systems listed. If list_len is non-zero, then the touser and tosys fields are ignored. The list_len is not used for e-mail to a user (main_type is 2 or 7). When a message has only one destination system, the destina- tion system is stored in tosys, and list_len is zero. If there are two or more destinations, then tosys is 0, and list_len holds the number of destination systems. When list_len is non-zero, the list of destination systems is stored immediately after the header, but before the actual message itself. The length of the list is not included in the length field in the header; the length stored in the header is the length of the message only. Each entry in the destination system list is two bytes long, and is stored in the standard byte-reversed format of 80x86 chips. For example, if a post is destined to system 1, the tosys field will be 1, and list_len will be 0. If the post is destined to systems 1 and 2, tosys will be 0, list_len will be 2, and there will be 4 bytes between the header and message. The bytes will be: 01 00 02 00 (remember, byte-reversed format). The rest of the header will be the same for both messages. A packet thus consists of a net header, a destination list (if any), and the text of the message. The length of a full message packet is thus: 24 + 2*list_len + msg_length. The message text (the part following the header) for a post or email begins with information intended for the message header shown when the message is displayed. Each piece of information is followed by a carriage return and line feed (cr/lf) character to separate it from the next except for the message title, which is followed by a NUL character. For most posts and email, that information is: Message Title Whatever title the user gave to the post. Sender name usually the name and number of the user who wrote the message with the system number, in whatever format the sending BBS uses. Date string Formatted date the post was written, in whatever format the BBS uses. So the message header format for most posts and email would be TITLE<nul>SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT. Some main_types have other information, as noted in the main_type descriptions in section IV(D). B. Mail File Processing A WWIVnet file is simply several packets appended into one file. Starting with NET25, the WWIVnet software supports compression of the netmail files to help save on connection time in long distance connections, using the PKWare Compression Libraries. These files have a slightly different format from uncompressed files, but the most important issue at this point is that the first long int of a compressed file has the value 0xFFFEFFFE. If you purchase the compression libraries from PKWare, details covering compressed packets are found in Appendix A. Otherwise, anyone using WWIVnet compatible software should be advised to make sure their connect only sends them uncompressed files, and the software should be able to detect and reject compressed packets before attempting to process them. Since there is nothing in the data exchange described above to warn that an incoming packet is compressed, there is no way to detect and prevent transfer of a compressed mail file. Once it has been received and (if necessary) uncompressed, the mail file should be processed following these steps: 1. Open the file, and set the current message pointer to the beginning of the file. 2. Read in the net header (24 bytes). 3. If list_len is non-zero, read in the list following the header (2 * list_len bytes). 4. Read in the message itself (length bytes). 5. Process the message. 6. If not the end of file, go to step 2. To ensure the integrity of the mail file, an initial pass over it should be done. This pass would step through each packet in the file, reading each header and making sure no packets are truncated. If the file ends in the middle of a packet, then it is obviously corrupted and cannot be processed properly. At this point, either throw away the whole file or remove the truncated packet and process the remaining packets. During the packet tossing, each packet needs to be marked as processed. Thus, if analysis is interrupted before completion, the packet analyzer can skip over those packets already processed when run again. To mark the packet as already processed (or deleted), set the main_type to 65535. Any packet with a main_type of 65535 should therefore not be processed. The analyzer should follow these steps when processing each packet: 1. If main_type is 65535 (deleted), skip the message. 2. If list_len is non-zero, do steps 3-6 for each entry in the list, substituting that entry for "tosys" 3. If tosys is this system, process the file locally (in the case of NETWORK1.EXE, the message is copied to LOCAL.NET for processing by the local packet processor). 4. If tosys is an unknown system or unreachable, put the packet in the dead mail file. 5. If the next system to forward the packet to ("next hop") is the system that the message was last received from, put the packet in the dead mail file. This prevents messages from looping 6. If the tosys is okay, put the packet into the file that is to be sent to the next hop. Of course, it is more complicated than that. If list_len is non-zero, all destination systems should be processed before the message is stored anywhere. This way, if the message has 10 destinations, each of which has the same next hop, only one copy of the message will be printed out, that packet with 10 systems in its destination list. Likewise, for a system with more than one connection, if a message has 4 destination systems going through one next hop and 3 going through another, one copy of the message will go into each hop's file -- one with four systems in the node list, the other with the remaining three. The dead mail file is reprocessed whenever a network update (new BBSlist or connection list) is received. C. Local Mail Processing and DEmmm.EXE Processing of local mail packets should be similar to processing of incoming netmail packets. The main difference between netmail tossing and local mail tossing is that the main and minor types are ignored during netmail processing, and the list_len and node list are ignored (since there won't be a list on local mail). 1. Open the file, and set the current message pointer to the beginning of the file. 2. Read in the net header (24 bytes). 3. Read in the message itself (length bytes). 4. Process the message. This is done according to the main_type and (if applicable) minor_type of the message. 5. If not the end of file, go to step 2. A few main_types (noted below) cause return messages to be generated to go back out to other systems. The local mail file analyzer should place these into an interim mail file that will be processed by the netmail file analyzer after local mail processing has been completed. The WWIVnet local mail analyzer (NETWORK2.EXE) puts these messages into P1.001 or P2.001. Then NETWORK1.EXE analyzes this file and places them into outgoing netmail files for the system's connections. Some types of messages that contain network related files such as updates to the nodelists and connect lists and email to all sysops from the NC or GC. For the sake of network security, these messages have a source-verification signature at the beginning (using, for example, RSA or a similar algorithm). There are several "methods" used to handle these messages, and each requires a decryption program, or DEmmm.EXE (where "mmm" is the encryption method, as listed in the 'method. field of the net header). These DEmmm.EXE files MUST be supplied by the NC or GC of each network, and each network's DEmmm.EXE are unique to that network. That is, WWIVnet's DE1.EXE will not handle method 1 messages from WWIVLink, nor vice versa. When a message is encountered with 'method!=0', the following steps are taken: 1. The local packet analyzer writes out the text of the message (no header or node list) to a temporary file (TEMPDE.XXX) in the data directory for the relevant network. 2. A command line for calling the appropriate DEmmm.EXE is created using the C command "sprintf(cmd, "de%u %s/tempde.xxx", nh.method, net_data);" ('nh' is a structure of type net_header_record, 'net_data' is the network data directory). The command is then executed. 3. The DEmmm.EXE program is then responsible for reading the TEMPDE.XXX in from disk, deleting it, then attempting to decode it. Two things can then happen: a. If the TEMPDE.XXX fails decoding (bad CRC), DEmmm.EXE just exits (returning to the local packet analyzer). If the analyzer finds the TEMPDE.XXX file does not exist, the message is deleted and the program goes to the next packet. b. If the CRC checks out in the DEmmm.EXE program, it writes out the decoded text into a new TEMPDE.XXX file and exits. The local packet analyzer reads in the data from that file and replaces the text of the message with that, then goes ahead and processes the packet as determined by main_type. Network operators who wish to write EN/DE programs for their own netwide messages may wish to consider using the RSAREF library to develop their own source-verification scheme. D. Main and Minor Message Types The main and minor type of each message determines how it is processed (where it goes, whether it's a sub post, email, or network info, etc.). The analyzer reads the message header in first to get the main and minor types, then performs the operation indicated by those fields. Here is a list of the main_ and minor_types, along with the WWIV BBS #define name and descriptions of the processing required. Encoding method is assumed to be zero unless otherwise noted. Note that while these descriptions concern analyzing local mail packets, they also apply to how to create outgoing netmail packets. It should also be noted that some of the "UNUSED" message types could be used by some third party software, but they are not an official part of the WWIVnet software, so no mention is made of them. main_type 1 (0x0001) -- main_type_net_info These messages contain various network information files, encoded with method 1 (requiring DE1.EXE). Once DE1.EXE has verified the source and returned to the analyzer, the file is created in the network's DATA directory with the filename determined by the minor_type (except minor_type 1). 0 -- Feedback to sysop from the NC. This is sent to the #1 account as source-verified email. 1 -- BBSLIST.NET -- Old-style node list (non-Group setup). 2 -- CONNECT.NET -- Old-style connections list (non-Group). 3 -- SUBS.LST -- List of subboards ("subs") available through the network. This has been replaced by main_type 9. 4 -- WWIVNEWS.NET -- An electronic magazine of sorts distributed within some networks, usually monthly. 5 -- FBACKHDR.NET -- a header file added to network update reports for the network. 6 -- Additional WWIVNEWS.NET text -- appended to the existing WWIVNEWS.NET file. 7 -- CATEG.NET -- List of sub categories. WWIV's sub setup facility uses this list so the sysop can specify what category a netted sub falls into. The network's SUBS.LST compiler uses this information for compiling the subs lists sent out as main_type 9. 8 -- NETWORKS.LST -- A list of all current WWIVnet type networks. This message type is source-verified. That is, there is a digital signature at the beginning of the message text which is decoded by the DE1.EXE to verify that it has come from a "legal" source. This helps make sure that the network info will only come from the Network Coordinator. If the source- verification fails, the packet is discarded. main_type 2 (0x0002) -- main_type_email This is regular email sent to a user number at this system (see tosys and touser, above). Note that this type of mail should only be received by systems that assign numbers to users (WWIV, VBBS, etc.). BBSes in a WWIV network that only identify users by name (PCBoard, RBBS, etc.) can only receive email-by-name (see main_type 7, below). Email has no minor type, so minor_type will always be zero. Processing of the email is straightforward. The analyzer looks for the user number indicated by the touser field. If the number exists and the user has not been deleted from the BBS, the message is written into the email file, addressed to the user indicated. If the number does not exist or the user at that number has been deleted, the packet is deleted without processing. Alternatively, the analyzer may generate a return message (as email) to the sender telling him that the mail was not delivered and quoting the message back to him. main_type 3 (0x0003) -- main_type_post This is a post sent from the sub host's system to the subscriber systems, for subs that have a numeric sub-type (subs of alphanumeric subtypes are main_type 26, described below). The minor_type will be the numeric subtype the post will go to. When this type is encountered, the network analyzer should search the BBS data files for the sub type given. When the sub is found, the message is written into the indicated message file in whatever format the BBS software uses. If the sub type is not found, the message packet is simply deleted. (There are some local mail preprocessors which will scan the packet for messages on subs that the system does not carry, and return the message to the host system. An alternate mail analyzer could have such a capability built in.) main_type 4 (0x0004) -- UNUSED main_type 5 (0x0005) -- main_type_pre_post These messages are similar to main_type_3, except they are posts en route from the subscribers to the host of a sub. Like main_type 3, the minor_type is the numeric subtype of the sub. Since this is from subscriber to host, list_len will be zero. When this type of packet is received, the local mail tosser should look for the appropriate file which will contain the list of subscribers to the sub (WWIV and NETxx use N[subtype].NET) If the file is found, a main_type 3 copy of the post is generated in an outgoing netmail file, with the node list read from the subscriber file inserted before the message text (and the list_len field modified reflecting the addition of the node list). If the file cannot be found, the analyzer assumes the BBS does not host the sub and deletes the packet. Many WWIV sysops use a feature of the software known as network validation ("netval"). When a sub is set for netval (this is found in the SUBS.DAT record for the sub), the analyzer does not send the post out to the network. The sysop must validate the post on the BBS, at which point it is sent out by the BBS. This also applies to pre-posts for main_type 26 (main_type_new_post). main_type 6 (0x0006) -- main_type_external This type has largely been replaced with main_type 27 (main_type_new_external), but essentially works the same way. This will create messages that are read and processed by an external processor. The minor_type is determined by the program expected to work with it. When the processor encounters this type of message, it searches for a file that contains the names of external programs, and the minor_types they accept, used by the BBS (EXT_LIST.NET for the WWIVnet software). If found, the message is written or appended to EXTERNAL.NET in the network's data directory. The external program, when run, should be able to find the file and process it, then delete the file (or the portion that it uses). Note that when there is more than one main_type 6 message in a mail file, the EXTERNAL.NET will contain all messages of that type, so the external message processor needs to be able to find the relevant text within the file. It is encouraged that programs that use external messages use main_type 27 (main_type_new_external), which has more robust features. Among other things, that type will create a separate temporary file for each main_type 27 message found, making processing of external messages simpler. main_type 7 (0x0007) -- main_type_email_name The other email type. The touser field is zero, and the name is found at the beginning of the message text, followed by a NUL character. Minor_type will always be zero. When this type of packet is encountered, the analyzer gets the name from the beginning of the message text and searches through the BBS's user list to find the specified name. If it is found, the message is written into the email file for the BBS. If it is not, the message will be deleted or a return email may be sent back to the sender, explaining that the message was not delivered and quoting the email back. The destination user's name is prepended to the beginning of the message text, followed by a NUL, then the rest of the usual message header info and the message text. The message header info at the beginning of email-by-name messages is thus DEST_USER_NAME<nul>TITLE<nul>SENDER_NAME<cr/lf> DATE_STRING<cr/lf>MESSAGE_TEXT. main_type 8 (0x0008) -- main_type_net_edit This type is used by Black Dragon in conjunction with his program NETEDIT, a utility for managing the network files on a WWIV BBS. Minor_types are as follows: 0 -- A partial update to the BBSLIST information. 1 -- A request for BBSLIST information to be changed. 2 -- A partial update to the connection information. 3 -- A request for connection information to change. 4 -- An update to NETEDIT's registration record. 5 -- A transmittal of the installation message. 6 -- A request for to transmit a registration record. 7 -- A response to request for a registration record. 8 -- A remote request for a net analysis ("/A"). 9 -- An ASCII text response to a remote analysis. 10 - Network Editor E-mail and/or automatic feedback. 11 - A message reporting an error condition. 12 - A request for installation and ver information. 13 - A request for a remote node's ALIASES.NET file. 14 - A request for a node's aliases. 15 - A response to the alias request. For more information on the use of these types, see the NETEDIT documentation, or email Black Dragon at @1180 on WWIVnet or @13080 on WWIVLink. main_type 9 (0x0009) -- main_type_sub_lst Networks with large subs lists (over 32k) break them up into parts and send the set out under this main type rather than the subs.lst type under main_type 1. The minor_type indicates the part of the subs list. When the analyzer processes this type, it creates a file in the appropriate network directory and copies the message text into it. Minor_type zero creates the file SUBS.LST, and all other minor_types create a SUBS.x file where 'x' is the minor_type. main_type 10 (0x000a) -- UNUSED main_type 11 (0x000b) -- main_type_bbslist This type is for the new-style BBSLIST files used in networks that use the Group setup. It covers full and partial updates sent from the Network Coordinator (NC) to the entire network as well as update requests sent from the Group Coordinators (GCs) to the NC. The encoding method is either 1 (when coming from the NC) or calculated as ((minor_type % 256)+256) (when coming from the GC). Messages of this type are source verified by DE<method>.EXE, handled the same as main_type 1 packets are. Minor types are as follows: 0..255 Full bbslist update sent from NC to the network. Minor type is the Group number. Creates BBSLIST.<minor_type> in the network data direc- tory. 257..511 Full bbslist update sent from the GC to the NC. Minor_type is the Group number plus 256. Creates BBSLIST.A<minor-less-256-in-hex> in the NC's network data directory. 513..767 Partial bbslist update sent from the NC to the network. Minor type is the Group number plus 512. Creates the file BBSLIST.<minor-type> in the network data directory. This file will be merged with the appropriate full BBSLIST file during network analysis (described below). In some networks, the Group updates are sent out to the network by the GCs rather than the NC. main_type 12 (0x000c) -- main_type_connect This is the same as main_type 11, except it is for CONNECT files. It also does not include partial updates, as there are none for CONNECT files. The encoding method is also either 1 (from NC) or ((minor_type % 256)+256) (from NC) for this type. These packets are also source-verified, checked by DE<method>.EXE. Minor types: 0..255 Full CONNECT update sent from NC to the network. Minor type is the Group number. Creates CONNECT.<minor-type> in the network data directory (after source-verification). 257..511 Full bbslist update sent from the GC to the NC. Minor_type is the Group number plus 256. Creates CONNECT.A<minor-less-256-in-hex> in the NC's network data directory (after source verifica- tion). In some networks, the Group updates are sent out to the network by the GCs rather than the NC. main_type 13 (0x000d) -- UNUSED main_type 14 (0x000e) -- main_type_group_info For now, this type only covers email to the members of a particular Group by the GC, so minor type will always be zero. Encoding method is the Group number plus 256. Processing for this is the same as for type 1/0 messages. They are source-verified by DE<method>.EXE. main_type 15 (0x000f) -- main_type_ssm WWIV BBSes also send out small messages, known as "SSMs", across the network. These are little one-line messages generally telling users when their mail has been read and so forth. Some BBSes have been modified to send other types of messages. At any rate, main_type handles these small messages. Minor_type is always zero. Like email, the analyzer searches for the user number in the BBS's user list. If found, the message is written into the SSM file for the BBS. Since this is a feature most non-WWIV systems do not support, they can be ignored. One feature of WWIV networking is the ability for network sysops to send "REQs" to the hosts of subs, enabling them to automati- cally subscribe to and drop subs they belong to. Main_types 16 through 19 handle REQs and their responses. main_type 16 (0x0010) -- main_type_sub_add_req This is for requests to add the sending system to a sub's subscriber list. Minor_type will be the numeric sub type, or zero for alphanumeric sub types. For minor_type==0, the sub type (followed by NUL) will be the message text. Otherwise, there should be no message text (if there is, ignore it). When this message type is received, the analyzer should search for the subtype's subscriber file (N[subtype].NET for WWIV systems). If the file is found, the system number of the new subscriber is added, if it is not in there already. If the add is successful, it will then look for a text file in the data directory (SA[subtype].NET for the WWIVnet software) that contains information the sysop wants to send back to the subscriber. A type 18 message is sent to the subscriber indicating status of the add request (see below) and including the text in the SA[subtype].NET file, if one is found. If the add is not allowed, the analyzer looks for SR[subtype].NET and sends that text back to the requester. If the add is otherwise unsuccessful, the type 18 message will include the status and a short explanation of why the add was not successful. main_type 17 (0x0011) -- main_type_sub_drop_req This is the same as a main_type 16 message, except that it is sent by a subscriber wishing to drop a sub. The minor_type is determined the same way as main_type 16. There should be no message text, but if there is any, it is ignored. Processing is similar to a type 16 message. The analyzer searches for the subtype's subscriber file, and upon finding it removes the subscriber's system number from it, if it is there. Status of the drop request is returned to the sender in a main_type 19 message, with a short message appended that explains the status. main_type 18 (0x0012) -- main_type_sub_add_resp This carries the status response to a main_type 16 (sub add request). The minor_type is determined the same way as type 16 message. The first byte of message text (after the subtype, if minor_type==0) is the status of the add request. Possible status byte values are: 0 -- Subscriber added successfully. 1 -- This system is not the host (N[subtype].NET not found). 3 -- Not allowed to add subscribers automatically. 4 -- System number already there (can't add it again). Since these messages also may contain a message to the requesting sysop, the message header info at the beginning of the message text appears as SUBTYPE<nul>STATUS_BYTE TITLE<nul>SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT. In this case, SENDER_NAME will be the name of the sysop of the system hosting the sub. 'SUBTYPE<nul>' will only be included if the sub is an alpha subtype. And finally, note that there is not <cr/lf> or <nul> after the status byte. When received, the processor will send the message text mentioned in the main_type 16 description (minus the status byte) to the sysop as email, if the status is 0 or 3. main_type 19 (0x0013)- main_type_sub_drop_resp Similar to main_type 18, this carries the response to a sub drop request, with the minor_type following the same conventions as above. This also carries a status byte as the message text: 0 -- Sub dropped successfully. 1 -- This system is not the host. 2 -- System number is not there (can't drop it). 3 -- not allowed to drop subscribers automatically. The message header info in the message text is the same format as for main_type 18. When received, the processor will send the message text mentioned in their main_type 17 description (minus the status byte) to the sysop as email, is the status is 0 or 3. main_type 20 (0x0014) -- main_type_sub_list_info In many WWIV networks, the subs list coordinator (SLC) occasionally sends out "pings" to all network members. When this message type is received from the SLC (minor_type 0), the analyzer checks the BBS's sub data file. If there are any subs hosted by the receiving system which are flagged for inclusion in the distributed SUBS.LST, a list of them is returned to the SLC via another main_type 20 message with minor_type==1). When the SLC receives the reply, it is written into SUBS.INF in the network's data directory (appended if the file exists). main_types 21 (0x0015) through 25 (0x0019) -- UNUSED These were formerly reserved for the WWIVLink network for their own updates, before they purchased NETUP (WSS's network update software). It is not longer used by that network. main_type 26 (0x001a) -- main_type_new_post Because of the growing number of networked subs on WWIVnet, the number of available subtypes was getting scarce. Starting with WWIV version 4.22 and NET32, alphanumeric subtype support was added, greatly expanding the possible subtypes. Alpha subtypes are seven characters -- the first must be a letter, but the rest can be any character allowed in a DOS filename. This main_type covers both subscriber- to-host and host-to-subscriber messages. Minor type is always zero (since it's ignored), and the subtype appears as the first part of the message text, followed by a NUL. Thus, the message header info at the beginning of the message text is in the format SUBTYPE<nul>TITLE<nul> SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT. It is assumed that a message coming into a host is a prepost, and it is processed similarly to main_type 5. Likewise, it is assumed that messages coming into a sub- scriber system are net posts, and they are processed similarly to main_type 3. main_type 27 (0x001b) -- main_type_new_external This is the new type of external message, implemented with NET33. Like main_type 6, it creates an external file with the message text for an external program to process. Again, the minor_type is determined by the external program. There is a full explanation of how these messages are processed in Filo's WWIVnet Software Docs. In short, similar to main_type 6, the local mail processor searches for the minor_type in a data file (EPROGS.NET for NETxx), and creates an external file if it is found. When the local mail processor is finished with the local mail file, the program associated with that minor_type will execute, with the associated filename (with path) as a parameter. [More Next Issue] ──══════════════════════════════════════════════════════════════════── ┌────────────────────────────────────────────────────────────────────────┐ │ IceNEWS is an independent journal published monthly as a service to │ │ IceNET, its Sysops and users. The opinions & reviews expressed herein │ │ are the expressed views of the respective writers. All Rights Reserved.│ │ Many product names used herein are the property of their respective │ │ manufacturers/authors. │ └────────────────────────────────────────────────────────────────────────┘