                          WWIVNEWS Volume 1, Issue 1
                                 January 1991


                               Table of Contents
                               ~~~~~~~~~~~~~~~~~
    The Official History of WWIV.................................Random 1@1
    The Amazing 4.12 Disappearing G-Files...............East Bay Ray 1@9964
    Multi-line WWIV: Myth or Reality?...................East Bay Ray 1@9964
    Submitting to WWIVNEWS...................................WWIVNEWS Staff
    The DGROUP Saga......................................Lord Elric 1@18251
    The Pending File.........................................WWIVNEWS Staff
    The Editor's Corner.................................East Bay Ray 1@9964
    =======================================================================


                         The Official History of WWIV
                                 by Wayne Bell
                                  Random 1@1

          WWIV started around December 1984, when  I first put up a BBS. It
    was run on  an IBM-PC with a 10  meg hard disk and a  Hayes 1200. I was
    running  WWIV v1.0,  which was  in interpreted  BASIC. It crawled along
    quite slowly, and did not have a whole lot of features.
          About the only  other BBSs I was competing with  at the time were
    run on Apple II's, also running  in interpreted BASIC. Of course, there
    were RBBSs  and the like, but  I do not recall  ever having called one.
    Soon the 64k limitation of IBM interpreted BASIC became apparent. I did
    some pretty  strange stuff with  memory allocation and  string storage,
    but I had pretty much reached the  cutoff point. When you try typing in
    30 lines of a  message and the result is an "out  of memory" error, you
    know it is time to go on to something better.
          The better thing was Turbo Pascal 2.0. Turbo 2.0 did not have ANY
    support  directories (all  file I/O  was within  your current directory
    only).  I also  had quite  some trouble  getting comm routines working.
    With the release  of Turbo 3.0, I put  up WWIV v2.0. Soon after  that I
    got  REAL interrupt-driven  comm  routines,  and things  started moving
    along.
          I had  to go off  to UCLA, and  was forced to  take the BBS down.
    Around December  1985 on Christmas vacation,  I decided to put  the BBS
    back up for some reason. I did some major revamping at some time around
    then,  and called  it WWIV  v3.0. Still  in Turbo  Pascal 3.0,  though.
    Around this time (December), I got around to putting in a file section.
    It took  quite a bit  of work getting  xmodem working, and  I had to go
    back and re-format my data files  to allow for file descriptions. Since
    I had never actually  been on any other IBM-type BBS,  I had no clue as
    to  how the  file section  should  work,  so things  turned out  pretty
    randomly.
          On  January 1,  1986 I  finally released  WWIV v3.0.  It ended up
    going through  quite a few revisions,  especially in the first  week or
    two after being  released. And, to make things even  more fun, I had to
    resume classes at UCLA, so I  ended up pretty much writing WWIV without
    running a BBS. As you may guess,  this caused a few unfortunate bugs to
    slip by me, but that's life.
          Sometime around June 1986, I had decided to put in ANSI color and
    call it WWIV v3.2. This involved  re-formatting the user list (to store
    the user's color  selections), and a few other little  fun things, so I
    decided to put up  a BBS again. This was only for  a week because I had
    to move  back up to  UCLA after that  time for the  summer session. You
    might think  that not many  people would end  up calling a  BBS that is
    pretty much stated as  only being up for a week, but  it managed to get
    some pretty good  activity. To make this week even  more fun, for about
    half of it I was not there. I had a friend of mine, Stephen Davis, call
    up and remotely take care of  this experimental BBS. It even managed to
    make it without crashing.
          After releasing that,  it turned out that I had  a pretty bad bug
    in the Y-Modem routine. The BBS would read in a block of data, and THEN
    seek  to the  right place  in the  file instead  of FIRST  seeking then
    reading. So I came out with 3.20a rather quickly. Around January 1987 I
    put up the BBS again, running 3.21d.
          Then  around June  1987 I  started writing  WWIV v4.0. Naturally,
    since I  had a summer  job, things did  not go so  fast. Also, the fact
    that I had never written anything in  my life in C before did not help.
    I eventually got the hang of things. Finally,  on Dec 1, 1987, I put up
    4.0 as my  BBS for testing in real  life. Among my big promises  of how
    great it would be, I said  it would support networking among systems. I
    thought this sounded like  a good idea, only I had no  clue as to how I
    would  go about  implementing it  at the  time. So  I relegated that to
    "don't hold  your breath" status,  secretly thinking I  might never get
    around to it.
          Surprisingly,  I did  get around  to it  relatively soon. By that
    time, everyone had  already installed the BBS on  their computers, so I
    was stuck with the  format I had dreamed up a long  time ago when I had
    no clue how  it would work -- a number  1-65535 indicating which system
    was which. I ended up trying  to design a network around that, although
    it was not  quite the optimal solution (as  if is such a thing).  I was
    bored one day  and had been talking with someone  about a network, so I
    decided  to start  writing a  program to  send files between computers.
    There was no planning at all, I  just pretty much sat down and typed it
    in. That developed into the NETWORK.EXE program.
          Of course, there was more to  it than that. It was actually after
    I had the  NETWORK.EXE program mostly  working that I  started thinking
    about how the systems would connect together. I originally started with
    the idea of having it pretty much hierarchial, with a local-system list
    for all  systems to call  directly any systems  that were local.  After
    talking with Stephen Davis about this  for a while, I decided to pretty
    much  have it  grid-like, with  an amorphous  structure. That does not,
    however, prevent some  structure from being applied to  it. Without any
    software  changes,  it  can  be  easily  changed  over  to  a  straight
    hierarchial structure. All I would have  to do is set up the hierarchy,
    change one file, and send out an update of that.
          Well that  pretty much brings me  up to the present  time. Future
    expansion? Who  knows. One thing  that keeps appearing  is a multi-line
    WWIV.  That just  is not   practical. WWIV  depends upon  many external
    programs  (chains,   FSED,  archiving  programs)   and  you  can   NOT,
    practically, have the BBS run external programs without running under a
    multi-tasking  operating  system.  To  put  it  simply,  PC-DOS was not
    designed with multi-tasking in mind.
    =======================================================================


                     The Amazing 4.12 Disappearing G-Files
                                by Jeff Garzik
                              East Bay Ray 1@9964

          The  release of  WWIV v4.12  brought many  new features,  such as
    Zmodem  batch  downloads,  almost  100k  of  memory  savings  with TC++
    overlays, an upload event, and much  more. WWIV v4.12 also brought with
    it a hideous  bug. In v4.12 the G-Files section  had disappeared, and a
    new one could be not created. As you might have guessed, this created a
    stir almost immediately on both Amber  and WWIVnet. You see, Wayne made
    a small typographical error  in XINIT.C, where he told  the BBS to look
    for the G-File data in the GFILES directory This was a mistake, because
    the GFILE.DAT file goes into DATA, not GFILES.
          This problem  is very easy to  fix. When you first  run your BBS,
    copy  GFILE.DAT  from  your  DATA  directory  to your GFILES directory.
    Whenever you edit it with //GFILEEDIT (or 'G' from WFC screen), copy it
    over to the GFILES directory. If  you have registered to get the source
    code,  you  may  apply  this  small   mod  to  XINIT.C  to  remove  the
    disappearing  G-File  problem  altogether.  Search  for  this  line  in
    XINIT.C:

                   sprintf(s,"%sGFILE.DAT",syscfg.gfilesdir);

    and replace it with this:

                   sprintf(s,"%sGFILE.DAT",syscfg.datadir);

          That will stop your G-Files  from disappearing. If you still need
    help with this problem, you can contact 1@9964 for assistance.
    =======================================================================


                       Multi-line WWIV: Myth or Reality?
                                by Jeff Garzik
                              East Bay Ray 1@9964

          Current  technology has  opened up  new worlds  in BBSing. One of
    those is the capability for a single  BBS to have more than one user on
    the  BBS concurrently.  RBBS, PC-Board,  TBBS, and  many others already
    have this capability, but WWIV does not.
          There  are  many  solutions  to  the  problem of adding multinode
    support. One of them is using a LAN (Local Area Network), where several
    computers  are available,  one for  each phone  line. Another solution,
    sometimes used in  conjunction with a LAN, is the  user of a commercial
    multitasker such  as Desqview, DoubleDOS,  or MS Windows.  These multi-
    taskers allow  the use of  more than one  program concurrently, at  the
    price of  program speed. The final  solution is for a  BBS to multitask
    using its own routines.
          A  BBS multitasking  using its  own routines  is usually the most
    efficient solution, because it causes  the least program slowdown. This
    also removes  the author from dependence  on another company's product.
    Drawbacks  of this  include the  author not  having access  to all  the
    resources a large commercial has.
          The LAN method requires a lot of hardware (it involves a computer
    for  each node;  4 nodes  = 4  PCs), but  it is  generally the accepted
    method for large BBSs. LANs, however, are sometimes notoriously slow.
          The commercial  multitasker method is the  general choice for the
    hobbyist-sysop.  It  allows  multiple  nodes  on  a  single computer by
    running  2  or  more  programs  at  the  same  time. This does slow the
    individual programs  down, because a  single processor is  handling the
    load for  more than one  program at a  time. Processor slowdown  is not
    really a problem on fast machines, such as an 80386 at 33 Mhz.
          That is a little about multiple  node BBSs in general. Wayne Bell
    summarily declared a few years ago  (see the closing statements of "The
    Official History of WWIV") that WWIV is not going to be a multinode BBS
    system. He has, in my opinion, weakened in his position since then, but
    he has not  wavered visibly. I think there WILL  be a multinode version
    of WWIV,  but it is  still a long  way off, and  there is a possibility
    that it will not be written by  Wayne at all (the multinode portion). A
    multiple node WWIV, for now at least, is a myth and not reality.
    =======================================================================


                            Submitting to WWIVNEWS
                               by WWIVNEWS Staff

                    Submitting Tips/Letters to WWIVNEWS
                    -----------------------------------
          To  submit a  letter to  the  editor  (to be  published in  later
    editions) or a tip, simply send e-mail to 1@9964. Tell me in the letter
    that  it is  to be  published in  a later  edition of WWIVNEWS. Letters
    submitted  immediately  become  the  property  of  Jeff  Garzik, and he
    reserves the  right to edit any  tip or letter (letters  will be edited
    only for  size limitations and  clarity). Tips and  letters will be  no
    longer  than  1,000  bytes.  The  letter  or  tip  must include express
    permission  to  print  your  tip  or  letter.  If  not,  it will not be
    published. All unpublished or unacceptable submissions will be deleted,
    possibly without notification of the author or submitter.


                     Submitting an Article to WWIVNEWS
                     ---------------------------------

          Listed below are the requirements  for submissions (all this must
    be included in a single letter addressed to user 1@9964).

    1) The  title of the e-mail  you send to 1@9964  should be something to
    the effect of  "WWIVNEWS submission". It helps to  know your letter has
    something  to  do  with  WWIVNEWS,  because  that  will really speed up
    processing.

    2) Article title of no more than 40 characters.

    3) Real name,  such as "Jeff Garzik". If this  line is not included, or
    you use an alias, then the submission will be rejected.

    4) Your preferred alias, such as "Filo", "East Bay Ray", etc.

    5) Your main WWIVnet or WWIVlink node address.

    6) Double-space and then include a one or two line summary of your sub-
    mission. An example might be:

        This article is  about the problem of DGROUP, a  description
        of what it is, and recommendations on how to solve this problem.

    7) Double-space again. You will now enter your article. I would suggest
    that  you limit  your article  to between  3,000 and  5,000 bytes. This
    should  be  more  than  enough  for  a  decent  sized article. If space
    requirements become  more constraining in the  future, the maximum size
    (5,000 bytes) may be lowered.

    NOTE: All  submissions immediately become the  property of Jeff Garzik,
    and he reserves the right to print  and edit the submissions as he sees
    fit.  If substantial  changes need  to be  made, WWIVNEWS will probably
    contact you at the WWIVnet  address supplied. All WWIVNEWS issues are
    kept  for permanent  storage, and  all other  non-published submissions
    will be subsequently deleted.
    =======================================================================


                                The DGROUP Saga
                               by Wayne McDaniel
                              Lord Elric 1@18251

          One of the  most often asked questions by WWIV  modders is "I get
    this DGROUP error. What can I do?" This article should explain what the
    error is, what causes it, and how to prevent it.
          First, some background information is needed. The DGROUP error is
    a direct result of the architecture of the 8088 chip. The 8088 chip has
    a 16 bit word length. Using 16 bits, only 64K of memory is addressable.
    So, how can you have over 64K  in your computer? The chip uses 2 16-bit
    variables (known as "words") to store the address.
          The two words are called the segment and the offset. Each segment
    contains 64K. Segments start on even  16 byte boundaries. So, the first
    segment starts  at memory location  00h, the next  at 10h, the  next at
    20h, and so on. The offset is then added to the segment to generate the
    exact address.
          So, the  exact formula for a  memory address is (segment  * 16) +
    offset. In  hex, conveniently, this  involves shifting the  segment one
    position to  the left. Here  is a  sample  address in hex  and how they
    would go together.

    1111:2222 = 11110 <- shift the segment left, fill in a zero
              +  2222 <- add the offset
             --------
                13332 <- final memory address

          Anyway, what has all this got to do with DGROUP errors? Well, let
    me explain. DGROUP is the name Turbo  C gives for a particular group of
    segments. To be more specific, the _BSS and the _DATA segments are both
    lumped into DGROUP. Maybe this map will show you a bit more...

    Map of a C program, Large memory model

    Low    CS ->---------------------------------------
                : Code from one file                  :  Each chunk of code
                :        ---------                    :  is 1 segment, so
                : code from another file              :  you can have
                :       --------                      :  multiple chunks.
                : code from another file              :
           DS ->---------------------------------------
                : _DATA                               :  _DATA and _BSS
                :    initialized data                 :  are collectively
                :-------------------------------------:  known as DGROUP.
                : _BSS                                :  64K limit for
                :    uninitialized data               :  both combined.
           SS ->---------------------------------------
                :           free space                :  The stack can be
                :                                     :  up to 64K.
    Current SP->:-------------------------------------:
                : stack  (grows high to low)          :
    Start   SP->---------------------------------------
                :                                     :  Heap is all the
                : heap  (grows low to high)           :  remaining memory
                :                                     :  all the way up to
                :                                     :  the 640K boundary.
                ---------------------------------------
     High
     Address...

          As you can  see, the DGROUP segment consists  of the static data,
    both  the  initialized  (_DATA  segment)  and  the uninitialized (_BSS)
    segment. Since the _DATA segment and  the _BSS segment both have to fit
    in the DGROUP segment, this limits you to 64K total. Getting the DGROUP
    error simply means you have too  much data in the DGROUP segment. First
    lets take a look at what kind of data this is, so you know what to pull
    out.  The  _DATA  segment  consists   of  global  variables  which  are
    pre-initialized. This would be something like:

    int myvar ={25};

    which would  declare an integer myvar,  and initialize it to  25 at the
    start of the  program. The major part of the  _DATA section is not pre-
    initialized variables, but text. Plain and simple text.

    pl("Press a key to continue");
    strcpy(s,"Some more text examples");

          In these samples,  anything between the quotes is  going into the
    _DATA portion  of DGROUP. The other  section of DGROUP is  _BSS, or the
    uninitialized data.  And, thats what it  is, any global or  static data
    which does  not have a  constant or pre-defined  value has to  fit into
    _BSS. One way to check how much  DGROUP data you have is to consult the
    map file,  which will tell  you just exactly  how much DGROUP  data you
    havem and where it comes from. If you are compiling with the integrated
    environment,  turn detailed  maps on.   If you  are compiling  with the
    command line compiler, add "/s" to your call to tlink.

    The first section of the map file looks like this...


    Start  Stop   Length Name               Class

    00000H 00E2EH 00E2FH _TEXT              CODE
    00E2FH 03FDFH 031B1H BBS_TEXT           CODE

    . . .

    3863BH 38670H 00036H WHEREXY_TEXT       CODE
    38680H 40CADH 0862EH _DATA              DATA
    40CAEH 40CB1H 00004H _EMUSEG            DATA
    40CB2H 40CB3H 00002H _CRTSEG            DATA
    40CB4H 40CBBH 00008H _CVTSEG            DATA
    40CBCH 40CD3H 00018H _SCNSEG            DATA
    40CD4H 485B7H 078E4H _BSS               BSS
    485B8H 485B8H 00000H _BSSEND            STACK
    485C0H 486A5H 000E6H _STACK             STACK

          The addresses here have the  segment and offset already combined.
    The two most  important lines are near the bottom  of this section, the
    one for _DATA and the one for _BSSEND. Take the hex value for the start
    of _BSSEND  and subtract the  starting value of  _DATA to find  out how
    much DGROUP data  you have. So, I am using  485B8H-38680H = FF38. Since
    FFFF  is the  maximum allowed,  I have  FFFF-FF38, or  C7, or 199 bytes
    left. In other words, not much.

          The next part of the map breaks  down the segments a bit more, so
    you can see just exactly what makes up _DATA and _DGROUP.

    Detailed map of segments
     Address  Size Class    Segment          Group     Module name  ????
    0000:0367 0000 C=CODE   S=_TEXT          G=(none)  M=FLAGS87    ACBP=28
    0000:0367 0260 C=CODE   S=_TEXT          G=(none)  M=FPEXCEP    ACBP=28

    3868:0000 0093 C=DATA   S=_DATA          G=DGROUP  M=C0L        ACBP=68
    3868:0094 07F5 C=DATA   S=_DATA          G=DGROUP  M=bbs.c      ACBP=48
    3868:088A 1100 C=DATA   S=_DATA          G=DGROUP  M=bbsutl.c   ACBP=48

    3868:8654 0000 C=BSS    S=_BSS           G=DGROUP  M=C0L        ACBP=48
    3868:8654 7331 C=BSS    S=_BSS           G=DGROUP  M=bbs.c      ACBP=48
    3868:F986 00CD C=BSS    S=_BSS           G=DGROUP  M=bbsutl.c   ACBP=48

          So, you can  see that the initialized data  and text for BBSUTL.C
    takes up 1100H  bytes, or 4352 bytes in decimal,  or even better, 6% of
    the  space in  DGROUP. Add  them all   up, and  you wind  up with  text
    accounting for almost 50% of the DGROUP space.

          Now you know what the DGROUP error is and why it occurs. What can
    you do about it?  Well, the obvious thing to do is  to cut down on text
    in the source code. Instead of  "Oooh baby, tickle my keyboard" use the
    smaller "pause". That  may seem insignifigant, but that  is 24 bytes of
    DGROUP space  you just saved.  Find little used  text, comment it  out,
    copy it to a text file, and then use printfile to pull it off the disk.
    This  is only  recommended if  the text  is fairly  large. For example,
    change:

    pl("Please Re-enter your user number when prompted");
    pl("and write down your password");
    pl("Waste some more DGROUP");

    to

    /*
    pl("Please Re-enter your user number when prompted");
    pl("and write down your password");
    pl("Waste some more DGROUP");
    */
    printfile("newuser1");

          Now  all  the  text  is  stored  in  the  gfiles  directory under
    NEWUSER1.MSG, and not in DGROUP.
          One mod  to look for is  the External Strings Manager  by Caramon
    Majere. He has written a program to  read strings in from a file and an
    editor to  maintain the file. One  problem, however, is speed.  It will
    slow  the BBS  down (the  slowdown is  usually only  noticeable on slow
    computers  or hard  drives), so  I suggest  only using the infrequently
    accessed lines, and I would also suggest  a disk cache. Up to 500 lines
    of string data may be taken out  of your code using his program, and if
    you figure even 100 strings with an  average length of 40 bytes that is
    4K of extra  space. If you take out 500  strings with an average length
    of 4K, you just  saved 20K. A good method for doing  that is to comment
    out the line, but leave it in the source, so later when you are reading
    your  source code  you can  still search  for the  string to  find that
    section of code. Such as:

    /* pl("Please enter name or number"); */  /* now string 27 */
    get_string(27);

          I hope this  file has at least helped you  to understand what the
    DGROUP  error is,  and has  given you  some hints.  Mostly, remove  the
    string  text. String  text accounts   for 40%-50%  of your  DGROUP data
    usually. The  other option is to  remove some of the  static and global
    variables. However, since  you need almost every one  of them, it would
    be hard to do.  If you have any further questions, I  can be reached at
    812-877-3488, The Kingdom of Melnibone.
    =======================================================================


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

    If you find  a message in one of your  extended net logs (NETDAT0.LOG -
    NETDAT2.LOG in  your GFILES directory) informing  you that WWIVnet does
    not know what "8/0" is, and that  you don't have a "de2" program, don't
    worry  about it.  It is  a test  of an  upcoming WWIVnet feature, being
    conducted by  Black Dragon 1@2380  and Random 1@1.  It will not  affect
    your system in any way.

    For those of you who have Richard Ruffner's program SUBEDIT, do not use
    it. It is incompatible with  the new multiple-BBSLIST format introduced
    in NET20.  Both Filo 1@5252 and  East Bay Ray 1@9964  have released new
    sub  editors,  and  either  of  these  should  be  used in place of the
    original SUBEDIT.

    For those  who use NETEDIT, version  1.25 is out. It  is now separately
    compiled  for faster  execution if  you  have  an 80287  or 80387  math
    co-processor. The filename is usually  NETEDIT.ZIP, and it can be found
    on Amber and Black Dragon Enterprises (the author's BBS).

    As  many  are  aware,  a  program  called  NetZip  II was released into
    WWIVnet,  plagued with  dozens of  problems and  bugs. It  has now been
    fixed  and  has  been  working  for  several  weeks.  The  filename  is
    NETZIP26.ZIP.

    For those who are having problems with DSZ data overruns and are using
    US Robotics' HSTs, try putting "ha slow" on the command line.

    If anyone has  ever seen the message "corrupted,  not processing", then
    they  know that  particular feeling  of frustration.  After Wayne  Bell
    (almost) lost  a 2.3 meg packet,  he decided to implement  some sort of
    recovery  for  corrupted  packets.  LNET  and  NETWORK1  will now split
    corrupted  packets as  to isolate  the corrupted  part, and process the
    rest.

    Also, as  a result of  continued debate, Wayne  declared in a  piece of
    global mail  that all illegal activities,  such as pirating, phreaking,
    hacking, and other like undertakings which are carried over WWIVnet are
    outlawed and  forbidden. Further policy  and discretion is  left to the
    individual Group and Area Coordinators.
    =======================================================================


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

          This  section is  for any  notes, notices,  or changes  in policy
    regarding  any aspect  of WWIVNEWS.  It may  also contain  some sort of
    editorial, or information regarding  articles in upcoming issues. Since
    this is the  first issue of what I  hope to be a tradition  in WWIVnet,
    there isn't really any news (because the whole thing is new(s)!).
          I  also want  to clear  the  air  about a  couple things.  First,
    reviews ARE accepted, but they must  be objective AND they must cover a
    major utility,  such as NETEDIT. I  also prefer that the  author review
    the product,  but this is  not set  in  stone, per say.  As many people
    know, I  am fairly well  known as  both  a programmer (some  say of ill
    repute) and as  a modder. I will do the  utmost to keep advertisements,
    and any  other related material (excepting  announcements which I think
    benefit the  network as a whole)  away from WWIVNEWS. I  will also keep
    all "fights" between sysops or  factions away from this magazine unless
    it affects  a majority of the  net. An example of  an exception to this
    rule might be  the WWIVlink crisis. If people wish  to call my bulletin
    board,  my number  is listed  in the  BBSLIST (group  5) along  with my
    maximum baud rate. I also want to point  out that I try to keep my name
    out of  it as much  as possible. If  there is a  suitable place, I will
    exchange "East Bay Ray" for "WWIVNEWS" or "WWIVNEWS Staff".
          Some people  might be scared  away but such  things as the  tech-
    nicality of having to submit an article. I am very lenient, and as long
    as the article  comes with the basic information  I won't, for example,
    remove yours  outright simply because it  is missing a double  space in
    the  recommended place.  Far from  from it!  I want  to encourage,  not
    discourage,  submissions. Bug  reports (as  long as  they are supported
    with evidence, and are reproducible) are accepted and welcomed also.
          Finally, a  word about the accuracy  of this document. It  is not
    spell-checked at  all, only proofread by  myself. I am human,  and I do
    make errors. In the future, this will hopefully change, but until then,
    I will  stick with  the human  spell checker,  the Turbo  Pascal Editor
    Toolbox text editor, and RightWriter grammar checker.
    =======================================================================


                                    The End

 