оллнА млллллм мллллллА ллА  ллА мллллллА ллА    ллА млллллм
          ллА  ллААААА ллммммА  лллм ллА ллммммА  ллА    ллА ллААААА
          ллА  ллА     ллппппА  ллпллллА ллппппА  ллА м  ллА плллллм
         оллнА плллллп пллллллА ллА пллА пллллллА ллмлллмллА  ААААллА
          ллА    ллААА  ллАллА  ллА  ллА  ллАллАА пллп пллп  плллллп
          онА    онА    онАонА  онА  оА   онАонА   онА  оА    онАоА
           нА    оА      нА     оА         нА      оА         оА

     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.                                                 Г
  РФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФФй