WWIVNEWS Volume 1, Issue 2
                                 February 1991

                               Table of Contents
    WWIV v4.20: A New Twist In Modem Handling....................Random 1@1
    WWIV and Zygote: The Dynamic Duo......................Tony Godfrey 1@18
    NetZip II Revision 6................................East Bay Ray 1@9964
    Thoughts on a Multi-Line WWIV..........................John Wash 1@8403
    Bug in the Main Menu Prompt....................The Dunghill Fowl 1@2371
    The Pending File.........................................WWIVNEWS Staff
    Letters to the Editor...........................................Various
    Official Jargon..............................................Random 1@1
    The Editor's Corner.................................East Bay Ray 1@9964
    Acknowledgements.........................................WWIVNEWS Staff

                   WWIV v4.20: A New Twist In Modem Handling
                                 by Random 1@1
                 (Originally captured from Amber: Dec 1, 1990)

          The text at the end of this article is my first cut at a modem
    configuration file. You first notice that it is in ASCII text, for ease
    of editing by users, and it is much easier to expand upon later. In the
    final release, there will be a configuration file such as the one
    below. configurations for will be: USR HST/V.32/DS, Hayes compat. 300,
    Hayes compatible 1200, Hayes compatible 2400, plus slightly modified
    versions of the Hayes compatible ones for modems that have timing
          Here is a description of the file. Comments are lines that begin
    with a #. Blank lines are ignored. The first four characters on a line
    (followed by a colon) describe what type the line is. The first section
    has a couple of strings that are sent to the modem (INIT, SETU, ANSR,
    PICK, HANG, DIAL). The SETU string will be sent to the modem when the
    BBS first starts up, setting up various modem parameters. The INIT
    string will be sent to the modem after each user loggs off, the same as
    the current init string. The other strings should be self-explanatory.
          The next part of the file deals with result codes and several
    switches that can be set. It tells what state the modem is in based
    upon the result codes received. These are listed at the top of the file
    for your reference. The first few "state switches" tell what state the
    modem is in (NORM, RING, RINGING, ERR, DIS, CON). The next few set
    various other options, modem speed, com speed, asymmetrical baud rates
    (such as for the USR HST protocol), error correcting protocols (MNP2-4,
    LAPM) and data compression protocols (MNP5, V.42bis). Also, flow
    control is thrown in there, although most likely that will not change
    based on result codes. The "DEFL" line defines the default modem
    switches, which are set before the modem init string is sent. It mostly
    just tells flow control and the com port speed to use.
          The rest of the file defines the result codes or partial result
    codes. A result code from the modem can be split up into numerious
    partial result codes. For example, from the HST, you can get a result
    code such as "CONNECT 2400" as well as "CONNECT 9600/ARQ/V32/LAPM/
    V42BIS". The "SEPR" definition defines which characters to use. It
    separates the full result code into partial result codes. It can be
    nothing, in which case there aren't really any "partial result codes".
    Another possibility is that the characters could not be present in the
    string, in which case the full result code is a "partial result code".
          Here is a working example. Suppose the modem is sitting there at
    WFC, and it gets a string from the modem ("RING"). It finds no "/" in
    it (the SEPR character), so searches the result code listing for
    "RING". It finds it, and finds the state switch "RING", meaning the
    phone is ringing. It then sends the ANSR string, answering the phone.
          At this point, say it gets "CONNECT 2400". It finds no "/", so
    searches for that string, and finds it. It sets the description to
    "2400", sets the modem speed to 2400, the com speed to 2400, and
    notices that it is now connected. At this point, it continues with the
          Suppose that it got "CONNECT 9600/ARQ/V32/LAPM/V42BIS". It
    notices a couple slashes, so interprets all the parital result codes
    ("CONNECT 9600", "ARQ", "V32", "LAPM", and "V42BIS") one at a time.
    First it finds the CONNECT 9600, so it sets the description to "9600",
    sets the two baud rates to 9600, and notices that it is connected. It
    does not actually consider itself connected until it has processed all
    the partial result codes from the full result code, so it continues.
    Next is "ARQ", meaning we have an error correcting connection (EC=Y).
    Also, the way the modem is configured for all ARQ connections, the com
    port baud rate is locked at 38400. It will set the com speed to that.
    Next comes "V32". This is a symmetrical protocol, so AS=N. Since AS=N
    is the default (as defined at the top of the file), this is not really
    necessary to put in, but puttting it in is clearer that way. Also, the
    string '/V.32' is defined. This is in SINGLE QUOTES, so the "/V.32" is
    added on to the description instead of overwriting it (as would be the
    case if it were in double quotes). The desription is now "9600/V.32".
    Next we get 'LAPM', which adds "/LAPM" on to the description, and sets
    EC=Y again, which is not really necessary. Again, it is clearer that
    way. Finally, "/V42BIS". Adds the string '/V.42bis', and sets DC=Y,
    indicating data compression is in use.
          It is now done with the full result code, so it recognizes that
    it is connected (due to the CON), and continues with the logon. Now we
    notice that the switches are set: MS=9600, CS=38400, EC=Y, DC=Y, AS=N,
    FC=Y. This means:
          The modem is talking at 9600 to the other modem, while we are
    talking to the modem at 38400. Also, we are using flow control (FC=Y).
    This is what we would know using the current setup for the result
    codes. We also get additional information informing us that we are
    using error correction, data compression, and that we have a
    symmetrical baud rate (9600 in both directions). The description at
    this point is "9600/V.32/LAPM/V.42bis".
          In addition to being more free form and more easily extensible,
    we get three additional pieces of information: whether error correction
    is being used, whether data compression is being used, and if we have a
    symmetrical baud rate setup. The symmetrical/asymmetrical flag can be
    used in the BBS to determine if BiModem should be used or not (same
    with the net software), and error correction can be used to determine
    if protocols like YMODEM-G should be allowed.
          So that is the way it will be implemented in INIT, instead of
    entering the modem info and result code info as you do now, you'll get
    a menu of known modem types, and be able to pick one. It will then
    parse through the file and create a machine-readable format for the BBS
    (and net software) to use.

# NORM      normal state of modem
# RING      phone is ringing
# RINGING   remote phone is ringing
# ERR       error encountered
# DIS       disconnected (No connection)
# CON       connection established
# MS=       modem speed
# CS=       com port speed
# AS=       asymmetrical baud rates (Y/N)
# EC=       error correcting (Y/N)
# DC=       data compression (Y/N)
# FC=       flow control (Y/N)

NAME: "USR Dual Standard"

# some strings sent to the modem
SETU: "ATC1E0F1H0M0Q0V1X6&A3&B2&C1&D2&H1&I0&K2&N0&R2&S0S0=0S2=1{"

# separator in result code for partial result codes
SEPR: "/"

# default settings of switches
DEFL: MS=38400 CS=38400 EC=N DC=N AS=N FC=Y

# list of partial (or full) result codes from modem.  Descriptions in
# double quotes ("") overwrite the previous description, those in single
# quotes ('') append to the previous description.
RESL: "OK"              "Normal"        NORM
RESL: "RING"            "Ring"          RING
RESL: "NO CARRIER"      "No Carrier"    DIS
RESL: "ERROR"           "Error"         ERR
RESL: "NO DIAL TONE"    "No Dial Tone"  DIS
RESL: "BUSY"            "Busy"          DIS
RESL: "NO ANSWER"       "No Answer"     DIS
RESL: "RINGING"         "Ringing"       RINGING
RESL: "VOICE"           "Voice"         DIS

RESL: "CONNECT"         "300"           MS=300   CS=300   CON
RESL: "CONNECT 1200"    "1200"          MS=1200  CS=1200  CON
RESL: "CONNECT 2400"    "2400"          MS=2400  CS=2400  CON
RESL: "CONNECT 4800"    "4800"          MS=4800  CS=4800  CON
RESL: "CONNECT 7200"    "7200"          MS=7200  CS=7200  CON
RESL: "CONNECT 9600"    "9600"          MS=9600  CS=9600  CON
RESL: "CONNECT 12000"   "12000"         MS=12000 CS=12000 CON
RESL: "CONNECT 14400"   "14400"         MS=14400 CS=14400 CON

RESL: "ARQ"                             EC=Y     CS=38400
RESL: "HST"             '/HST'          AS=Y
RESL: "V32"             '/V.32'         AS=N
RESL: "MNP"             '/MNP'          EC=Y
RESL: "LAPM"            '/LAPM'         EC=Y
RESL: "MNP5"            '/MNP5'         DC=Y
RESL: "V42BIS"          '/V.42bis'      DC=Y
RESL: "NONE"                            EC=N

                       WWIV and Zygote: The Dynamic Duo
                             by Tony Godfrey 1@18

          One of the nice things about a registered WWIV is that you can
    modify the source code to your heart's content. Sysops modify their
    boards to make WWIV easier to use for themselves and the users. Some
    modifications spice up the board by adding more color, or more ANSI-
    extensive routines. This can decrease the speed of WWIV by a fairly
    large amount, and speed is one of WWIV's strong points.
          Zygote Term is a terminal program on the PD/Shareware market. It
    isn't quite as popular as Telix or Procomm, but it is gaining popu-
    larity every day. Each new version of Zygote contains new features that
    surpass other term programs many times over. The best thing about
    Zygote is that it has special features accessible by a WWIV BBS. On any
    other board, Zygote would act as any other terminal program would
    (except with a few more features that cannot be found on other term
    programs). When Zygote is used on a WWIV BBS that makes use of Zygote's
    features, however, a whole new realm of BBSing is entered.
          The Zygote/WWIV Multitask Chat is the first of these features to
    be released. WWIV currently comes with two chat modes: standard, and
    two-way. Zygote/WWIV Multitask Chat looks much like two-way chat,
    except chatting takes place on one half of the screen. In the other
    half, normal BBS functions can be performed. While the sysop and a user
    are chatting, either the sysop or the user can switch between chat
    window and BBS window. In the BBS window, functions such as reading
    messages, listing files, writing messages, moving, sorting, removing
    files, editing users, etc. can all be performed while the chat window
    remains intact. This is especially useful if you want to discuss a
    certain message or look for a certain file and chat about it, or to
    have something else to do while the chatter rambles on. Version 1.0 of
    this modification was released in October 1990, and version 1.1 is
    scheduled to be released in late December 1990 or early January 1991.
          A new feature still in the testing stages, but very close to
    release, is the Zygote/WWIV Binary Screen Feature. This modification
    gives WWIV a complete facelift. Any part of the BBS can be made into a
    full-screen ANSI picture. With regular terminal programs, WWIV would
    have to send an ANSI picture over the modem, and then send codes to
    place prompts on the screen. With Zygote, WWIV simply tells it which
    binary screen (an ANSI screen saved in binary format) to display, and
    in less than 2 seconds, a full screen ansi is displayed on both ends,
    ready for input. Positioning of the cursor still has to be done, which
    WWIV then takes care of. Since binary screens are only 4000 bytes in
    size, having several of these binary screens on disk would not consume
    a large amount of disk space. If either the BBS or the Zygote user does
    not have a matching screen, then WWIV will simply display the screen
    normally (albeit much slower than the speed of binary screen display).
          WWIV sysops will see this modification released in modules. Each
    module will contain documentation on what part of the board to modify
    as well as a standard WWIV binary screen. The first modules to be re-
    leased will be logon and message bases. Binary screens can be custo-
    mized, but at the same time the customizer must know where to position
    the cursor and make the necessary changes. These features are just the
    beginning in a series of featues to be released. Zygote continues to
    grow, as does WWIV, and these features make them both 10 times as
    powerful as any other term program or BBS.

    Zygote Term by Miguel Sanchez a.k.a. My Nguyen

                             NetZip II Revision 6
                            by East Bay Ray 1@9964

          Many people who have seen how other networks, such as FidoNet,
    use compression to make their net packets smaller. They have been doing
    this for years with the help of SEA's ARC program and PKWare's PKZIP
    program. WWIVnet now has the same opportunity. NetZip, written by East
    Bay Ray, provides network compression for any node in WWIVnet or
          This idea is not a new one to WWIVnet. There were two previous
    tries by Alph 1@8403 and Benny Hill 1@7400. They both were stopped by a
    strange bug that would produce a Divide Overflow on some computer
    systems, but not on others. East Bay Ray was also previously stopped by
    a conflict with Wayne's ZIP routines that resulted in lost mail. At
    last, however, a version was found that worked.
          Installation of NetZip is quite easy. An INSTALL batch file does
    most of what minimal work there is (thoughtfully provided by Filo #1
    @5252). All that is left, after running INSTALL, it to create
    ZIPSYS.NET. This is a plain text file which contains a list of nodes
    you wish to use NetZip with (they must also have NetZip installed, or
    be using NET22). It is that simple.
          How does NetZip work internally? NetZip first takes the un-
    compressed Sxxxx.NET file and renames it to a P*.NET file (one higher
    than the last existing P*.NET file in the current archive). Then it
    adds this to Sxxxx.ZIP. The Sxxxx.ZIP is then renamed to Sxxxx.NET, and
    CONTACT.NET is updated to reflect the adjusted sizes of each Sxxxx.NET
    file that was compressed. If you wish to see the ratio of compression,
    all you have to do is view the Sxxxx.NET with PKZIP or PKUNZIP. NetZip
    is an excellent, which has finally been purged of the bugs present in
    the previous versions, along with the stigma of Revision 3, which lost
    mail. If you have a chance, download it and share it with your
    neighbors. It will save you a lot of transmission time. Over long
    distance lines, it will save money also.

                         Thoughts on a Multi-Line WWIV
                              by John Wash 1@8403
                      with input from Richi Shinn 4@8404

          Before I get started, please note that this article was written
    in response to an article of like subject, written by Jeff Garzik
    1@9964, that originally appeared in WWIVNEWS Vol. 1, Issue 1.
          First, I wholly agree with Jeff on possible solutions: You can
    either make the program itself single-tasking but multi-user, or you
    can run it in a multi-tasking -- and optionally a multi-user -- envi-
          At this point, though, I begin to differ with Jeff. A LAN would
    indeed be an expensive solution (as he said, "4 nodes = 4 PCs"), but it
    would NOT be a slow one. The standard in PC networking today is
    Novell's Netware, a distributed-processing system. In a LAN
    implementation, you have a server system and client systems. The server
    controls the shared resources of the LAN--storage, printers, modems,
    etc.--and each client (or workstation) uses its own resources--a local
    hard drive or a local printer, for example. A multi-line WWIV running
    in a Novell Netware environment, and sharing data files with other
    nodes by storing them on the server's drive, would not be noticeably
    slower than individual PCs running individual BBSes--that's the entire
    idea behind distributed processing, and part of the reason that
    educated administrators choose Netware as a networking solution rather
    than packages that run on the server and treat client systems as
    dependents rather than autonomous entities.
          If you MUST run PC-DOS, it is possible to have multiple WWIVs
    running concurrently with, as Jeff said, a "commercial multitasker"
    such as Windows 3.0 or Quarterdeck's DESQview. However, they're going
    to be individual copies of WWIV, sharing perhaps only the FILES in the
    transfer and G-File sections.
          What needs to be done to WWIV is a total re-write. Wayne Bell
    knows this. He hinted at it when he suggested that he wouldn't port
    WWIV to UNIX. He stated that would re-write it for UNIX.
          Internal multi-node capability would not be that difficult to
    implement. If you have handlers processing I/O for all com ports as
    well as the console, half of your battle is over. It remains, however,
    that you have no facilities for file and record locking, an integral
    part of almost any multi-user system.
          So why go the extra step? Don't bother making WWIV multi-line.
    Instead, make WWIV support file and record locking. You'd save oodles
    of memory, because you wouldn't have to allocate a chunk to store a
    .SUB file, a .DIR file, or anything like that. If you wanted a user's
    record, open USER.LST, lock the record, read the record, unlock the
    record, and close the file. If you wanted to read a message, or upload
    a file, or anything that requires file I/O, you would do basically the
    same thing. If you get file and record locking working properly, there
    would not be any need to "make WWIV a multi-line BBS"-- you'd just need
    a copy of MS-Windows 3.0, or Novell Netware, or PC-MOS, or
    DESQview/386, a good machine and some patience in getting it set up.
          This is my opinion on multi-line systems. Summing it all up,
    making WWIV talk to several com ports at once is a waste of time. Worry
    about file sharing and you'll be set. If anyone would like me to
    discuss file and record locking in a future issue of WWIVNEWS, drop me
    a note at 1@8403 and I'll see what I can do.

    (About the author: John Wash is a professional UNIX zealot and a
    full-time social irritant.)

                          Bug in the Main Menu Prompt
                          by The Dunghill Fowl 1@2371

          This problem only happens if you are on a board where you have
    access to all 32 Subs (I don't know about boards with the 64 Sub Mod).
    While at the main menu prompt, at sub #31, if you hit the plus key (+),
    instead of going to sub #32 it will jump to sub #1. However, hitting
    the minus key (-) at sub #1 will bring you to sub #32. For example:

    T - 00:32:48
    [31] [Fred's Fried Fish Sub]:+    <--- Hitting plus from sub #31

    T - 00:32:26
    [1] [General Messages]:-    <--- Skipped sub #32, hitting minus key

    T - 00:31:53
    [32] [Underwater Basket Weaving]:    <--- Now at the long lost sub #32

    Ok, that's all there is to it, it isn't that big of a deal, but it's

    [This only occurs on the aforementioned sub numbers EXACTLY. I easily
    spotted the problem in the code, and I notified Wayne about it.  - Ed.]

                               The Pending File
                           (Tips, Tricks, and News)
                               by WWIVNEWS Staff

    The next WWIV release will be v4.20. It HAS NOT been released, nor will
    it be released any time soon. Wayne has not set a release date.
    Features will include batch uploads, BiModem support, a complete
    rewrite of the modem handling routines, and several other smaller
    features. For more information on the modem handling routines, see the
    earlier article in this issue.

    WWIVnet also has a new SUBS.LST coordinator. 1 @7100 now receives the
    new information for subs and sends out regular SUBS.LST/SUBS.1 updates.
    Do NOT send any e-mail to 1 @6860 regarding sub list changes.

    Intel is offering a Sysop deal on their 9600EX high speed modem. It's a
    V.22, V.32, V.42/42bis compatible, and will connect to standard v.32 /
    v.42 modems at speeds up to 38,400 Baud. It WILL NOT connect to a USR
    HST at any speed higher than 2400 Baud, so there is a downside. It's a
    good deal if you can't afford a $699 USR DS or a $675 Microcom, but
    "let the buyer beware." (Charles Boyer 1@9962)

    NETEDIT v1.27 by Black Dragon #1 @2380 has just recently been released.
    It fixes a potential bug in v1.26. v1.26 (which was not annouced in
    WWIVNEWS) makes a couple improvements over v1.25, including handling of
    NET22's partial updates, and a technical correction on one of the
    menus. (Black Dragon 1@2380)

    WWIVNEWS has some competition on WWIVlink. WWIVlink now distributes a
    newsletter much like this one, called "The Link Post". These will also
    be made available on my board as I get them.

    My new program, NETPURGE, goes through the specified network pending
    data file (defaults to DEAD.NET) and deletes all non-e-mail. It returns
    all E-mail of types 1-0, 2-0, 7-0, and 8-10 to the originator with a
    few extra lines in the header telling the originator what type of
    E-mail he sent, to whom, and that it was undeliverable.
    (Black Dragon 1@2380)

                             Letters to the Editor

          I noted with interest the appearance of WWIVNEWS.NET in my data
    directory today. It's an interesting idea, and I hope it works out to
    the benefit of WWIVnet sysops. However, I have a couple of suggestions
    for distribution:

        1. Announce its presence. I had no earthly idea that WWIVNEWS was
        going to be distributed along with updates. I'm not complaining,
        just suggesting that you flaunt it a little bit more than you have.

        2. Change the name. I assume will to come out once a month, and I
        also assume that volumes change once a year. With that in mind,
        perhaps I can suggest another naming convention:

            a. Do it Fido-nodelist-style. Call it WWIVNEWS.<num>, where
            <num> is the number of days into the year on which that issue
            was released.

            b. Do it Another Way. If you are only going to have 16 volumes
            and 12 issues per volume, then use hexidecimal format. For
            example, WWIVNEWS.1-1 would be volume 1, issue 1, and
            WWIVNEWS.A-3 would be volume 10 (0Ah), issue 3. Or provide 256
            issues per volume: WWIVNEWS.AFF (volume 10 (0Ah), issue 255

            c. Here is yet another possibility. How about this:
            0006-0010.NWS (Volume 6, Issue 10, WWIVNEWS).

          What this boils down to is that I don't want to lose WWIVNEWS
    every time a new one comes out, and why not make provisions to keep 'em
    rather than having me COPY 'em?
                                           John Wash #1 @8403

    [All of these are excellent suggestions. My favorite idea overall is
    naming it WWIVNEWS.v-i (v = volume number in hex, i = issue number in
    hex). However, it will stay the same way basically because Wayne
    already put it in the code that way, and he is reluctant to change it
    so quickly after its birth. I do, however, provide on my board back
    issues for anyone not collecting them.  -Ed.]

                                Official Jargon
                                 by Random 1@1
                        (Wayne's All-Mail for January)

    A couple things:

    1. When you wish to be removed from distribution for a subboard, please
    do >NOT< post a message about it on the subboard.  The correct thing to
    do is to email the host of the sub and inform him/her that way.

    2. NET22 apparently has some problems receiving net updates. I am not
    precisely sure why this did not also happen in NET21, but it apparently
    doesn't. So, for now, it would be a good idea to use the network2.exe
    file from NET21. NET23 (which fixes that problem) should be out about
    January 27th or so.

    3. Also about January 27th, we will be going to multiple CONNECT files.
    In addition to the CONNECT.0 file, you will find CONNECT.1 through
    CONNECT.12 files in your DATA directory (with the exception of
    CONNECT.6, as there is no group 6). The network will continue to
    function the same, however. This should not affect anyone except GCs
    and maybe ACs.

    Due to the way the connection updates will be handled, it is now
    REQUIRED that AC's forward connection updates to the GC. You will NOT
    be able to send connection update requests directly to me. So, to
    reiterate, for anything in the network (connection update, bbslist
    update, complaint, etc), the correct order is to first contact your AC,
    then your GC and finally the NC (me). if you have been unable to
    resolve A few people have come to me with things that they should have
    contacted their GC about and I have simply referred them back to the
    GC. Going directly to me tends to slow things down, not speed them up.

    4. Starting with WWIV v4.20 (for which a release date has not yet been
    set, but will be in a few months), the source code to WWIV will also be
    distributed (to registered sysops ONLY) on certain select WWIVnet
    systems. It will work like this:

    a. About 5-10 WWIVnet systems will be selected as source distribution

    b. I will make up a list, based on inputs from registered WWIV users,
    of which users on those systems are, in fact, registered WWIV users.
    Those users, and only those users, will be able to download the source
    code to WWIV from those systems.

    c. The sysops of the source distribution points will have a special
    file transfer section for WWIV source distribution. The file section
    will have a specific DAR. Only the users listed on the 'master list'
    will have that DAR, and hence be allowed to download the source code.

    The list will look something like:

    Reg num Accounts
    1       Random #1 @1, Random #2 @1234
    90999   Hector #123 @1, Hector #22 @1234, Hector #67 @1177
    90888   Dude #321 @1, Dude #198 @1177

    Where @1234 and @1177 are the source distribution points.

    We are now at step "a": selecting source distribution points. If you
    are a registered WWIV sysop, have been registered for over a year, have
    been in WWIVnet for over a year, would like to be a source distribution
    point, and agree to release the source code to users only on the list,
    then please reply and tell me you are interested. Remember, there will
    only be around 5-10 distribution points, and I'd like to have them in
    various areas of the country, so if 20 people reply from Rhode Island,
    only one of them will actually be selected.

                              The Editor's Corner
                            by East Bay Ray 1@9964

          One of the several network subs to investigate this month is the
    "Alternative SysOp's Sub", sub type 9999, hosted by John Hardman @9954
    (send mail to 2@9954 for speed answering), the GC of group 5. It boasts
    less flames than other sysop subs. Check it out, it might make a nice
    Valentine's gift for yourself.
          Observant people will notice that the text is no longer justified
    to the right margin. I wanted to be able to fit more text into less
    space, so the decision was made. Thanks are due to Omega Man for his
    suggestion regarding that one.
          I also decided that I would stop publishing real names unless so
    requested. I thought about it a while and came to the conclusion that
    aliases were for people to hide their real names. I will continue to
    publish their net addresses.
          There has been some flak about my policy on the ownership of the
    articles printed in WWIVNews. I thought the original policy was fair,
    but apparently some people did not. I have modified it, so now my
    position on the ownership of WWIVNews article is that all articles,
    unless copyrighted by the author (whether stated copyright or official
    copyright) become my property. If the article is copyrighted, then the
    article's author retains full ownership and distribution rights of that
    article. He MUST, if the article is copyrighted, give me specific
    written (electronic or otherwise) permission to print the article in an
    upcoming issue of WWIVNews.


    WWIV (c) 1988 by Wayne Bell.
    NetZip II (c) 1990,1991 by Jeff Garzik.
    PKZip, PKUnZip, and PKLite are registered trademarks of PKWare, Inc.
    ARC is a registered trademark of SEA Enhancement Associates.
    BiModem (c) 1988-90 by Erik Labs.
    USR, USR HST, and USR Dual Standard are trademarks of US Robotics, Inc.
    Hayes is a registered trademark of Hayes Microcomputer Products, Inc.
    MNP (Microcom Networking Protocol) is a trademark of Microcom, Inc.
    Windows is a trademark of Microsoft Corporation.
    DesqView is a trademark of Quarterdeck Office Systems, Inc.
    PC-MOS is a trademark of The Software Link.
    NetWare is a trademark of Novell Data Systems.
    All other products mentioned are either registered trademarks or
      copyrighted by their respectives manufacturers.

                                    The End