ڿڿڿڿڿڿۄńĿڿ  ڿۄߠڿۄńĿڿڿڿۄńĿ
 ʍ΍΍΍΍΍΍ӳӳӳӳӳӳDࠚřӳ  ӳӠ?ӳԚńřӳӳӳԚńř΍΍΍΍΍΍ͻ
 ڠVolume 7    ӳӳӳӳӳӳ  ӳ  EࠚƙӠ YӳDń߳ӳӳӳDńߠ   Spring   ڍ
 ڠIssue 1     ӳӳӳӳӳӳ  ӳ   ӳӳ Ԛߠ ӳۄńٳӳӳԀńĿӠ     1996   ڍ
 ɍ΍΍΍΍΍΍ԀڀٳԀڀٳۄڀĿ Eƙ ӳ? ӳDń߳YYԚńřԍ΍΍΍΍΍΍܍
       Ӡ  DńřDńřDńř  Y  Y Dڀńńڀńńڀńń٠  Ӎ
       ӠServing WWIV Sysops & Users Across All WWIV Networks Ӎ
       Dńńńńńńńńńńńńńńńńńńńńńńńńńńř


             ۄńńńńńńńńńńߍ
             Ԕhis Issue's FeaturesӍ
ۄńńńńńńńńńńńŁńńńńńńńńńńŁńńńńńńńńńńńńńńߍ
ӠRandom Notes........................................Wayne Bell (1@1)      Ӎ
Ӡ                                                                          Ӎ
ӠSoft Servings:  News from WWIV Software Services....Sam (1@2863)          Ӎ
Ӡ                                                                          Ӎ
ӠThird-Party Developers and WWIV.....................Dawg (1@2121)         Ӎ
Ӡ                                                                          Ӎ
ӠShareware Mods...An Idea Who's Time has Come?.......Pug (1@11750)         Ӎ
Ӡ                                                                          Ӎ
ӠRunning WWIV Under Novell Netware...................Festus Hagen (1@9400) Ӎ
Ӡ                                                                          Ӎ
ӠUnderstanding Viruses (Part 3 in a Series)..........Sam (1@2863)          Ӎ
Ӊ                                   Ӎ
ӠType 2/0 Forum......................................Sam (1@2863)          Ӎ
Ӡ                                                                          Ӎ
ӠFilo's Mod of the Month.............................Frank Reid (1@8213)   Ӎ
Ӡ                                                                          Ӎ
ӠTechnical Section...................................Burmese (1@15111)     Ӎ
Ӡ                                                                          Ӎ
ӠClassified Ads......................................A Compilation         Ӎ
Ӡ                                                                          Ӎ
ӠOn the Lighter Side.................................Sam (1@2863)          Ӎ
Ӡ                                                                          Ӎ
ӠClosing Thoughts....................................Sam (1@2863)          Ӎ
Dńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńńٍ


ńńńńńńńłńńńńńńńńńńńńńńńńńńńńńńłńńńńńńńč
           Ӡ              Random Factors                Ӎ
           Ӡ  Creative Commentary by Wayne Bell (1@1)   Ӎ
           Dńńńńńńńńńńńńńńńńńńńńńńٍ


Well, I've been spending most of my free time lately investigating
Internet and PPP connectivity (for NGTRANS).  I don't really have
anything coded yet, but that doesn't mean too much.  Most of my
programming seems to be of the form of, "Contemplate until it comes
together, then program it."  My PPP ideas haven't completely coalesced
yet, but things are getting closer.  Since windows/OS2 .DLL files aren't
as advanced as Unix .so files, it will probably end up requiring a bit
more work on the part of sysops than most WWIV stuff has in the past.

How do I see BBS's in relation to the Internet?  Well, Internet email
support within BBS's will definitely be a good thing, and probably some
Usenet support will be good also (although I still think BBS subs are
superior to usenet newsgroups).  If you're interested in how BBS's and
the Internet will end up together/apart, you'll probably be interested
in subscribing to sub type "NETWAR" hosted by @3000, a sub dedicated to
figuring out how it all will end up, and how BBS's can "compete" with
the Internet.  Note, this is not a flame-type sub, but is dedicated to
serious discussions and suggestions.

How is the OS/2 native version of WWIV coming along?  Last I heard, it
was doing fairly well.  I hope it'll become available in the fairly near
future, but can't offer any promises yet.

How will computer networks end up working a year from now?  Ha-ha-ha, if
I could tell (I wish), I'd be borrowing money to invest in stock options
as I type.  Or, I guess, when the brokerage is open.  In any case, the
future of computers, networking, and BBS's is much more up-in-the-air
today than it has been in the past.  It'll require the experience and
knowledge and effort of all of us to help ensure that it all turns out
for the best, as opposed to letting the future be driven by (as my
father would say) "people unable to identify a computer two out of three
times."  And that would tend to include about 99.99% of all politicians.

                   -=��

ńńńńńńńłńńńńńńńńńńńńńńńńńńńńńńłńńńńńńńč
           Ӡ     "Third Party Programs and WWIV"        Ӎ
           Ӡ             By Dawg (1@2121)               Ӎ
           Dńńńńńńńńńńńńńńńńńńńńńńٍ

    There has been an ongoing debate for several years regarding the
inclusion of items into WWIV that have traditionally been external programs.
The debate came to a head with the Asylum QWK mod being included into WWIV.
There was a great hue and cry that it would mark the beginning of the end
of third party programs for WWIV.  I for one do not believe that has happened
and nor do I believe it will.

        I believe that anything that WSS can include with WWIV will only serve
to enhance it's marketability and it's viability in the marketplace.  It's
true that many system operators have no need for the QWK or the RIP that is
now part of stock WWIV, there are those out there that would not use the
software without it.  If including these basic functions can help sell WWIV
then all of the systems running it stand to benefit from further development
and support.

        I understand the arguments made by those who were supporting Mike
Leib's WWIVmail program.  I've registered many shareware programs (and
authored several as well).  However, with that being said it's my belief that
if the program is truly worth the money it will survive and perhaps prosper
even more.  I'll use the French Mod Division WWIVsys program as an example.
The majority of the functions performed by that piece of software duplicate
what is already either internal to WWIV or available in modification form.
Yet, there are still over eighty registrations for the software.  The first
question that would pop to mind might be "Why?".  I can't speak for everyone
else, but I registered it recently because of the excellent support offered
for it as well as the ease of use.  For me it's far easier to be open to open
a separate OS/2 session and be able to do almost any conceivable maintenance
task for WWIV with ease.  FMD seems to have found a market and taken advantage
of it.  The same can be said to a lesser extent about Rob Raper's Fedit.
Fedit seemed headed for doom quite sometime ago with WSS's decision to include
Adam Caldwell's WWIVedit program in an accessory package for WWIV.  However,
Adam sold the rights to WWIVedit to WSS.  Despite reports to the contrary
WSS has not been able to release an updated version with such things as time
slicing code which is vital to the many of us running in multi-tasking
environments.  That being the case Fedit has a new lease on life and is taking
shape as the new "editor of choice" for many system operators.  These two
examples may be two of the better ones, but there are more out there.

    What I believe will destroy third party programs is not what WSS
chooses to include with WWIV; but rather is people who choose to use the
shareware programs and not register them.  It's my experience that many
authors do not write these programs as a line of work, but merely in their
free time.  The occasional registration check is a nice incentive to not only
support what has already been written, but to encourage more programs to be
written.  There will always be someone out there talented enough to write
a program to improve upon whatever Wayne Bell and WSS includes in the basic
WWIV package.  It'll be a matter of if there is an incentive for them to take
the time to do so.

                    -=��

ńńńńńńńłńńńńńńńńńńńńńńńńńńńńńńłńńńńńńńč
           Ӡ             "Shareware Mods"               Ӎ
           Ӡ             By Pug (1@11750)               Ӎ
           Dńńńńńńńńńńńńńńńńńńńńńńٍ

        As many of you know, I have recently released a new multinode
chatroom for WWIV.  It is technically a "mod", as far as it requires your
source code to be recompiled.  I have a shareware and a registered version
of this mod.  How, you ask?  Rather than releasing the source code to the
public, almost everything dealing with the chatroom's operation is contained
inside a separate .OBJ file which is linked into your source code.

        This has caused some controversy.  I received various responses, some
positive, some negative.  I am going to address the negative ones.  The most
common negative response was "You expect people to PAY for a mod?"  Yes.  I
have written 17 mods which available to the public free.  They each took me
between 2 hours to 3 days to program.  I don't have a problem releasing that
sort of thing for free.  However, my chatroom took OVER two months to program.
When I work on something for two months, I don't think giving it away for free
is absolutely necessary.

        I believe that most sysops that write mods are discouraged to write
really large mods, because in the past no one had thought of a way to charge
for them.  Releasing "shareware mods" in .OBJ files is an excellent idea.  I
don't think mod authors should charge for every mod they program, but for
large mods, it's definitely a good idea.  Also, many programs, such as
chatrooms, don't work nearly as well as external executable files as they do
as internal mods.  Mods use very little overhead and can operate quickly.
There are definite advantages to linking in an .OBJ rather than using an
external program to do the same thing.

        The other complaint I received was that a foreign .OBJ file could
contain back doors.  I can't argue that it couldn't, but I can argue that
an .EXE could just as easily have back doors.  Any program that can locate
your CONFIG.DAT & user data files can provide someone with the system password
and the user's password of their choice.  The program could even shell someone
to a DOS prompt if programmed properly.  My chatroom, to the best of my
knowledge, contains no back doors whatsoever, but any other executable door
being run could contain them.

    Shareware mods aren't such a bad idea.  It encourages mod authors to
write bigger and better modifications that work faster than external programs.
Just because sysops complain about paying for something that was free in the
past doesn't mean it's a bad thing.  I am in no way suggesting that all mods
be charged for, just mods that take a great deal of time and effort on the
part of the mod author.

                    -=��

ńńńńńńńłńńńńńńńńńńńńńńńńńńńńńńłńńńńńńńńč
           Ӡ     Running WWIV Under Novell Netware      Ӎ
           Ӡ        By Festus Hagen  (1@9400)           Ӎ
           Dńńńńńńńńńńńńńńńńńńńńńńٍ

[Editor's Note-

With the recent debate over which is the better operating system (OS/2 or
Windows 95), perhaps the best solution for multi-node WWIV operation has been
overlooked - Netware.

The following is a "how to" written by Festus Hagen.  As a Novell CNE myself,
I found it very informative and easy to understand.  For those of you able to
get yourself a copy of Netware, this may be just what you have been looking
for.]


[Short background on Netware volumes]

Netware uses segments of storage space called "volumes" as opposed to drives.
With Netware 3.12, it is possible to have up to 32 volumes that span 64
physical drives that contain up to 32 TB of space. A volume can span across
multiple physical drives. Conversely, more than one volume can reside on the
same drive. Most (all) netware volumes should be set up where the first
volume is called SYS. Additional volumes are usually called VOL1, VOL2, etc,
though their names are not as critical as the first volume being called SYS.
Novell uses drive "mappings".  A drive mapping is simply a pointer to a
logical portion of your netware volume.  For instance, if you have a subdir-
ectory called APPS off of the root, you could "map a drive pointer" to that
directory.  For instance, if you type

map g:=sys:apps

Whenever you go to the "g drive" you will actually be in the \apps directory.

WWIV needs what it believes is a TRUE drive!
So you need to 'map root' the drive.. like so:

map root s:=sys:user/bbs
        ^^^ ^^^^^^^^... Whatever you want!
          | .. Whatever volume you want!!

That will give you a fake "ROOT" directory called drive s: off of volume
SYS:\USER\BBS

Change to S: and you will be in SYS:\USER\BBS directory!

S:\>

But using a drive letter that far down the letter chain will cause you to
lose to many SEARCH drives!! SEARCH drives start at Z and work backwards!!

(A "search drive" is simply a mapped drive that is treated just as DOS
directories placed in your PATH= statement are treated....that is, they are
just another place the operating system looks for the commands you give it
if it cannot find them in RAM or in the current directory. You can have up to
16 search drives.)

For the most part, mapped drives start at F and work forward.  Depending on
whether your client is using VLM or NETX and what the LASTDRIVE statement
in your workstation config.sys file is set to, this may differ.  It is beyond
the scope of this article to delve into that area.

Personally I use P: for my BBS
My setup As Novell Netware sees it:    I have cut this down to size!!


       VOL3:\               // 4th Drive = 1.2gigs
       ĄłB1               // MAP ROOT P:=VOL3:BB1, MAP S16:=VOL3:BB1\BBS
       Ӡ ĄłAT            // MAP S16:=VOL3:BB1\BAT
       Ӡ ĄłBS            // Main WWIV dir!
       Ӡ Ӡ ĄłADLINK     // Linkers LAME empty dir
       Ӡ Ӡ ĄŃHAINS      // Onliners
       Ӡ Ӡ Ӡ ĄńRAWPOKE // JNS Draw Poker
       Ӡ Ӡ Ӡ ĄœTREE    // JNS Soli-Tree
       Ӡ Ӡ Ӡ             // Cut to shorten
       Ӡ Ӡ ĄńATA        // WWIV data dir
       Ӡ Ӡ ĄŇFILES      // WWIV gfiles dir
       Ӡ Ӡ Ӡ DœUBAVAIL // Compilation of SUBS.x Avail via 'G'files
       Ӡ Ӡ ĄŌANG        // Language parent
       Ӡ Ӡ Ӡ ĄŅNG      // English
       Ӡ Ӡ Ӡ ĄœPAN     // Spanish
       Ӡ Ӡ Ӡ ĄņREN     // French
       Ӡ Ӡ Ӡ DŇERM     // German
       Ӡ Ӡ ĄŌOGS        // Various Log files
       Ӡ Ӡ ĄōSGS        // WWIV message dir
       Ӡ Ӡ ĄŎETS        // Networks parent
       Ӡ Ӡ Ӡ ĄʼnCENET   // ICEnet data
       Ӡ Ӡ Ӡ ĄŔCG      // TCGnet data (Private)
       Ӡ Ӡ Ӡ ĄŗWIV     // WWIVnet data
       Ӡ Ӡ Ӡ DŘANTH    // XanthNET data
       Ӡ Ӡ ĄŔMP         // Temp dir parent
       Ӡ Ӡ Ӡ ĄłATCH1   // node 1
       Ӡ Ӡ Ӡ ĄłATCH2   // etc...
       Ӡ Ӡ Ӡ ĄłATCH3   // etc...
       Ӡ Ӡ Ӡ             // Cut to shorten
       Ӡ Ӡ Ӡ ĄŔEMP1    // node 1
       Ӡ Ӡ Ӡ ĄŔEMP2    // etc...
       Ӡ Ӡ Ӡ ĄŔEMP3    // etc...
       Ӡ Ӡ Ӡ             // cut to shorten
       Ӡ Ӡ DŗEDIT       // WWIVEdit
       Ӡ Ӡ    ĄŃONFIG
       Ӡ Ӡ    ĄńICT
       Ӡ Ӡ    DńOC
       Ӡ ĄńLDS           // Downloads (Partial)
       Ӡ Ӡ ĄŃODEING     // Most of my dloads are on other VOL's
       Ӡ Ӡ                // Cut to shorten
       Ӡ ĄńOCS           // All Doc's
       Ӡ ĄņAX            // Fax setup
       Ӡ DŕPLOADS        // New uploads!!
                // cut to shorten

My WWIV is setup to use P:\BBS
Changing to MAP ROOT'ed drive P: results in this:
      P:\               // Actual Netware path, VOL3:\BB1
      ĄłAT            // MAP S16:=VOL3:BB1\BAT
      ĄłBS            // Main WWIV dir!
      Ӡ ĄłADLINK     // Linkers LAME empty dir!
      Ӡ ĄŃHAINS      // Onliners
      Ӡ Ӡ ĄńRAWPOKE // JNS Draw Poker
      Ӡ Ӡ ĄœTREE    // JNS Soli-Tree
      Ӡ Ӡ             // Cut to shorten
      Ӡ ĄńATA        // WWIV data dir
      Ӡ ĄŇFILES      // WWIV gfiles dir
      Ӡ Ӡ DœUBAVAIL // Compilation of SUBS.x Avail via 'G'files
      Ӡ ĄŌANG        // Language parent
      Ӡ Ӡ ĄŅNG      // English
      Ӡ Ӡ ĄœPAN     // Spanish
      Ӡ Ӡ ĄņREN     // French
      Ӡ Ӡ DŇERM     // German
      Ӡ ĄŌOGS        // Various Log files
      Ӡ ĄōSGS        // WWIV message dir
      Ӡ ĄŎETS        // Networks parent
      Ӡ Ӡ ĄʼnCENET   // ICEnet data
      Ӡ Ӡ ĄŔCG      // TCGnet data (Private)
      Ӡ Ӡ ĄŗWIV     // WWIVnet data
      Ӡ Ӡ DŘANTH    // XanthNET data
      Ӡ ĄŔMP         // Temp dir parent
      Ӡ Ӡ ĄłATCH1   // node 1
      Ӡ Ӡ ĄłATCH2   // etc...
      Ӡ Ӡ ĄłATCH3   // etc...
      Ӡ Ӡ             // cut to shorten
      Ӡ Ӡ ĄŔEMP1    // node 1
      Ӡ Ӡ ĄŔEMP2    // etc...
      Ӡ Ӡ ĄŔEMP3    // etc...
      Ӡ Ӡ             // cut to shorten
      Ӡ DŗEDIT       // WWIVEdit
      Ӡ    ĄŃONFIG
      Ӡ    ĄńICT
      Ӡ    DńOC
      ĄńLDS           // Downloads (Partial)
      Ӡ ĄŃODEING     // Most of my dloads are on other VOL's
      Ӡ                // cut to shorten
      ĄńOCS           // All Doc's
      ĄņAX            // Fax setup
      DŕPLOADS        // New uploads!!



Create a Novell multiple logon account named 'BBS', Give it RWCEMF rights
to VOLx:\BB1.. (Read, Write, Create, Erase, Modify, and Filescan rights).
Create a login script for each user that you want to be able to run the
BBS and add these commands!

MAP ROOT P:=VOLx:BB1
MAP S16:=VOLx:BB1/BBS
    ^^^.. Maps the next available search drive letter!
(Of course change the VOLx to whatever your system has and you are going
to use)

Personally, I don't use Multiple Login Accounts! I use Groups, And
IF MEMBER OF statements in my SYSTEM logon script. Then all I have to do is
add whomever I want to be able access the BBS to the BBS group!

In my writings above I used 'MAP S16:=VOLx:BB1/BBS' to show how to
setup a search drive for the BBS dir!!  You will see that I'm not practicing
what I preach!! I am FORCING my search drives to be specific versus using
S16 which just uses the next available search drive letter! :) Increases
management time, reduces debug time..

Here is part of my Novell Netware 3.11 SYSTEM Login script. I have trimmed out
alot of items that don't pertain to wwiv. I will comment this script with
Novell legal comments '#'

# Setting up the PROMPT and USERN variables!!
# Not much needs saying about the prompt! (Besides I like it)
# You will notice that it shows the username!
# This is what it looks like:
#   TCGUY: Mon 02-19-1996 @ 3:56:25
#   P:\BBS=> _
# The USERN variable, Welp, It's kinda handy..
SET PROMPT="%LOGIN_NAME: $d @$t$h$h$h$_$p$q$g "
SET USERN="%LOGIN_NAME"

# I use a Group! If you are a member of it then you can access it!
# 1) map root the drive
# 2) setup a search the BBS directory
# 3) setup a search to the BBS's .BAT directory
IF MEMBER OF "BBS" THEN
  MAP ROOT P:=VOL3:BB1
  MAP INS S8:=VOL3:BB1\BBS
  MAP INS S9:=VOL3:BB1\BAT
ENDIF

# A second copy to play with! Why crash the good one.. :)
IF MEMBER OF "BB2" THEN
  MAP ROOT P:=VOL3:\
  MAP INS S8:=VOL3:BB2\BBS
  MAP INS S9:=VOL3:BB2\BAT
ENDIF


My BBS batch file (BB.BAT)
I have cut some repeated stuff out to shorten it!
(and have added a few comments!)
-=-=-=-=-=-=-=-=-=-=-=-=- BB.BAT
@echo off
rem **** BB.BAT = BBS inst = Next
SET PKNOFASTCHAR=YES
p:
cd\bbs
REM **** inst_loc.xxx prevents one from running Multiple copies of
REM **** the same instance!
if not exist inst_loc.1 goto inst1
if not exist inst_loc.2 goto inst2
REM **** Cut to shorten!
goto allused

REM **** set the WWIV instance number
:inst1
SET WWIV_INSTANCE=1
goto okdoit

:inst2
SET WWIV_INSTANCE=2
goto okdoit

REM **** cut to shorten
goto allused

:okdoit
REM **** Safety check!
if exist inst_loc.%WWIV_INSTANCE% goto no2run
REM **** echo 'Instance in use' to INST_LOC.xxx file
echo Instance %WWIV_INSTANCE% is already running!>inst_loc.%WWIV_INSTANCE%
REM **** run the BBS
P:\BBS\BBS.EXE /I%WWIV_INSTANCE% /N0 /A1 %1 %2 %3 %4 %5
REM **** delete the INST_LOC.xxx file
del inst_loc.%WWIV_INSTANCE% >nul
goto done

:no2run
REM **** If saftey check fails
REM **** display the inst_loc file to show that instance is already in use
type inst_loc.%WWIV_INSTANCE%
goto done

:allused
REM **** Tell them all instances are used!
echo !!! NOTICE !!! All Instances are currently used!

:done
REM **** exit cleanup
SET PKNOFASTCHAR=
SET WWIV_INSTANCE=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=- End BB.BAT
The only problem with this batch setup is if you have to BOOT out of a
locked WWIV the INST_LOC.xxx file doesn't get deleted!  My work around for
this is 'del inst_loc.xxx' in each workstations autoexec.bat according to what
instance that workstation's primary instance is! I know, Clumsy but simple!
Without some sort of prevention, you'll end up running multiple SAME instances
of WWIV at the same time on two (or more) different workstations!! This will
cause MAJOR wwiv file damage!! Thats why the INST_LOC.xxx file is echoed to
the WWIV main dir! And the BB.BAT check for their existence!!

I'm sure there is a better method, This works without a hitch for me!!

If you anyone needs more, E-Mail me your VOICE number and a good time
to call and I'll help you out! I will NOT call during daytime hours!!,
Nights, weekends only!!

                   -=��

ńńńńńńńłńńńńńńńńńńńńńńńńńńńńńńłńńńńńńńč
           Ӡ       Running WWIV Under Windows 95        Ӎ
           Ӡ          By Wild Thing (1@11753            Ӎ
           Ӊ     bdiamondz@aol.com               Ӎ
           Dńńńńńńńńńńńńńńńńńńńńńńٍ



                 DISCLAIMER:
       I take no responsibility for damages that may occur to your
           computer when following these instructions!


This is for those of you who have installed Windows 95 and wish to multi-task
your BBS with it.

I have been running WWIV v4.24a in Windows 95 for quite a while now.  I'm
using a PENTIUM 100mhz with 16 megs of RAM.  My BBS has two nodes, one uses a
28.8 Sportster modem and the other is a local node I have for personal use.

An advantage to running your BBS in Windows 95 is that it is very easy to get
your BBS going for the first time, and any problems you come across (which
shouldn't be any) can be easily resolved.  Most full-screen editors will work
with perfection.  I suggest Fedit or WWIVEdit.  They seem to run the
smoothest.  I have also ran many other programs such as Microsoft Works and
games like Civilization without the BBS slowing down.  Things like virus
scanners also work well while the BBS is in use.

I have yet to find any doors that will not run in WIN95.  This is a good sign,
but doesn't mean that there are not some out there that won't run.  I have
found that most of the popular doors like LORD and USURPER will work fairly
well.  DSZ works VERY good along with most Transfer Protocols.

I have almost no experience with fossil drivers.  I use BNU 2.02, and it has
met my needs, so I haven't tried anything else.  BNU works with perfection in
Windows 95, I haven't had a single problem with it.  However, I can't say much
about other drivers.

In my own opinion, Windows 95 is a much better multi-tasker than OS/2 WARP.
I have tried both (however, I did not try WARP as extensively as I did WIN95).
I found that OS/2 WARP was a lot less user friendly and more confusing to use.
I was also in constant fear that WARP would do some kind of harm to my system.
Windows 95 will multi-task just as well as WARP, with a little more ease and a
lot less effort.

There are some problems that I have come across with running my Bulletin
Board in WIN95 that you may or may not run across.  One of the major
problems, is that when I run my tape backup to backup my hard drive, it will
slow the BBS down considerably to about a 1200 baud crawl.  During this time,
or if I am running 5+ programs at once, LORD will slow itself so that you
must type a command twice in order for LORD to actually carry out that task.
This creates a big problem for users.  I have yet to find a way around this
problem, but I hope to get it resolved soon.  Like most OS's, you can't run two
programs that require the same comm port at once.  You must quit your BBS in
order to run a COMM program.

Do not use QEMM with Windows 95!!  For one, QEMM is almost completely
incompatible with WIN95.  Also, if you use QEMM, there is a good chance that
your BBS will run choppy and slow.  I have found it better not to use QEMM,
but to run WIN95 and as many drivers as you can in high memory.  This should
leave enough extended memory for all nodes of your BBS.

Enough jabber!  Lets set up your system!

First, you need to make some changes to your CONFIG.SYS.  The following should
be enabled:

DOS=HIGH,UMB
FILES=100
BUFFERS=30

The best way that I found to run a BBS in Windows 95, is to create a .PIF for
it.  This can be done by using any standard PIF editor.  This is what mine
looks like:
-------------------------------------------------------------------------------
Program Filename:  <Path to your BBS.EXE or .BAT file for more than one node>
Window Title:      <Title of your BBS Icon>

Video Memory:         [X] Text     [_] Low Graphics    [_] High Graphics

Memory Requirements:    KB Required     [448]         KB Desired       [640]
EMS Memory:             KB Required     [348]         KB Limit         [1024]
XMS Memory:             KB Required     [448]         KB Limit         [1024]

Display Usage:     [_] Full Screen        Execution:  [X] Background
             [X] Windowed                                [_] Exclusive

[X]  Close Window on Exit

Advanced Options:

Multitasking Options:
Background Priority:  [1000]            Foreground Priority:  [1000]
                 [X]  Detect Idle Time

Memory Options:
[X]  EMS Memory Locked             [_]  XMS Memory Locked
[X]  Uses High Memory Area         [_]  Lock Application Memory

Display Memory Options:
Monitor Ports:          [X]  Text    [_]  Low Graphics    [_]  High Graphics
        [X]  Emulate Text Mode       [_]  Retain Video Memory

-------------------------------------------------------------------------------
That's it!  Now if you want to run a second node for your users, then I would
suggest using the same settings as above.  If you wish to run a local node
for yourself, then you want to make another .PIF.  This is what mine looks
like:
-------------------------------------------------------------------------------

Program Filename:   <Path to your .BAT file>
Window Title:       <Title of your BBS Icon>

Video Memory:         [X] Text     [_] Low Graphics    [_] High Graphics

Memory Requirements:    KB Required   [350]           KB Desired       [640]
EMS Memory:             KB Required     [0]           KB Limit         [4069]
XMS Memory:             KB Required     [0]           KB Limit         [4069]

Display Usage:     [_] Full Screen         Execution:   [X] Background
             [X] Windowed                               [_] Exclusive

[X]  Close Window on Exit

Advanced Options:

Multitasking Options:
Background Priority:   [100]         Foreground Priority:    [100]
                  [X]  Detect Idle Time

Memory Options:
[X]  EMS Memory Locked             [_]  XMS Memory Locked
[X]  Uses High Memory Area         [_]  Lock Application Memory

Display Memory Options:
Monitor Ports:          [X]  Text      [_]  Low Graphics   [_]  High Graphics
          [X]  Emulate Text Mode       [_]  Retain Video Memory

-------------------------------------------------------------------------------

If you want to run more then one node, you need to setup a .BAT file for each
node in your main BBS directory.  Mine look like this:

----------------------------------------------------------------------------
               WWIV.BAT
REM Node 1:
set wwiv_instance=1
bbs -I1
----------------------------------------------------------------------------
               LOCAL.BAT
REM Node 2 (local):
set wwiv_instance=2
bbs -M -I2
----------------------------------------------------------------------------

These .BAT files would be the program filename in the .PIF's you just created.
Mine are called WWIV.BAT for my user's node and LOCAL.BAT for my personal
node.  You can find more information about these .BAT files in the WWIV docs.

Next, you need to setup an Icon for each node in Windows 95.  Do this by
clicking on Start, and then Settings.  Choose Taskbar and then Add.  Give the
path and name to your .PIF and the name of your Icon, and put it in a program
group or create a new one.

The last thing you need to do, is to run your BBS and see how it works.  Just
click on the icon you just made and your BBS will boot right up!

I hope this has helped you to get your BBS setup in Windows 95 with great
performance, but if you encounter any problems at all, please feel free to
e-mail me at 1@11753.WWIVNet or bdiamondz@aol.com.


                  -=��

컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?            Understanding Viruses           ?
           ?          Compiled by Sam (1@2863)          ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

[This was taken from an FAQ I picked up on the net. It is a rather large
      article, which I'm posting in parts over several newsletters.]

            = Protection Against Viruses =
              袴袴袴袴袴袴袴袴袴袴袴袴袴

 What is the best protection policy for my computer?

There is no "best" anti-virus policy.  In particular, there is no program that
can magically protect you against all viruses.  But you can design an
anti-virus protection strategy based on multiple layers of defense.  There are
three main kinds of anti-viral software, plus several other means of protection
(such as hardware write-protect methods).



1) GENERIC MONITORING programs.  These try to prevent viral activity before it
happens, such as attempts to write to another executable, reformat the disk,
etc. Examples: SECURE and FluShot+ (PC), and GateKeeper (Macintosh).


2) SCANNERS.  Most look for known virus strings (byte sequences which occur in
known viruses, but hopefully not in legitimate software) or patterns, but a few
use heuristic techniques to recognize viral code.  A scanner may be designed to
examine specified disks or files on demand, or it may be resident, examining
each program which is about to be executed.  Most scanners also include virus
removers.

   Examples: FindViru in Dr Solomon's Anti-Virus Toolkit, FRISK's
   F-Prot, McAfee's VIRUSCAN (all PC), Disinfectant (Macintosh).
   Resident scanners: McAfee's V-Shield, and VIRSTOP.
   Heuristic scanners: the Analyze module in FRISK's F-PROT package,
   and SCANBOOT.

3) INTEGRITY CHECKERS or MODIFICATION DETECTORS.  These compute a small
"checksum" or "hash value" (usually CRC or cryptographic) for files when they
are presumably uninfected, and later compare newly calculated values with the
original ones to see if the files have been modified.  This catches unknown
viruses as well as known ones and thus provides *generic* detection.  On the
other hand, modifications can also be due to reasons other than viruses.
Usually, it is up to the user to decide which modifications are intentional and
which might be due to viruses, although a few products give the user help in
making this decision.  As in the case of scanners, integrity checkers may be
called to checksum entire disks or specified files on demand, or they may be
resident, checking each program which is about to be executed (the latter is
sometimes called an INTEGRITY SHELL).  A third implementation is as a
SELF-TEST, i.e. the checksumming code is attached to each executable file so
that it checks itself just before execution.

   Examples: Fred Cohen's ASP Integrity Toolkit (commercial), and
   Integrity Master and VDS (shareware), all for the PC.

3a) A few modification detectors come with GENERIC DISINFECTION.  I.e.,
sufficient information is saved for each file that it can be restored to its
original state in the case of the great majority of viral infections, even if
the virus is unknown.

   Examples: V-Analyst 3 (BRM Technologies, Israel), marketed in the
   US as Untouchable (by Fifth Generation), and the VGUARD module of
   V-care.

Of course, only a few examples of each type have been given.  All of them can
find their place in the protection against computer viruses, but you should
appreciate the limitations of each method, along with system-supplied security
measures that may or may not be helpful in defeating viruses.  Ideally, you
would arrange a combination of methods that cover the loopholes between them.

A typical PC installation might include a protection system on the hard disk's
MBR to protect against viruses at load time (ideally this would be hardware or
in BIOS, but software methods such as DiskSecure and PanSoft's Immunize are
pretty good).  This would be followed by resident virus detectors loaded as
part of the machine's startup (CONFIG.SYS or AUTOEXEC.BAT), such as FluShot+
and/or VirStop together with ScanBoot.  A scanner such as F-Prot or McAfee's
SCAN could be put into AUTOEXEC.BAT to look for viruses as you start up, but
this may be a problem if you have a large disk to check (or don't reboot often
enough).  Most importantly, new files should be scanned as they arrive on the
system.  If your system has DR DOS installed, you should use the PASSWORD
command to write-protect all system executables and utilities.  If you have
Stacker or SuperStore, you can get some improved security from these compressed
drives, but also a risk that those viruses stupid enough to directly write to
the disk could do much more damage than normal; using a software write-protect
system (such as provided with Disk Manager or Norton Utilities) may help, but
the best solution (if possible) is to put all executables on a disk of their
own, protected by a hardware read-only system that sounds an alarm if a write
is attempted.

If you do use a resident BSI detector or a scan-while-you-copy detector, it is
important to trace back any infected diskette to its source; the reason why
viruses survive so well is that usually you cannot do this, because the
infection is found long after the infecting diskette has been forgotten with
most people's lax scanning policies.

Organizations should devise and implement a careful policy, that may include a
system of vetting new software brought into the building and free virus
detectors for home machines of employees/students/etc who take work home with
them.

Other anti-viral techniques include:
(a) Creation of a special MBR to make the hard disk inaccessible when booting
from a diskette (the latter is useful since booting from a diskette will
normally bypass the protection in the CONFIG.SYS and AUTOEXEC.BAT files of the
hard disk).  Example: GUARD.

(b) Use of Artificial Intelligence to learn about new viruses and extract scan
patterns for them.

    Examples: V-Care (CSA Interprint, Israel; distributed in the U.S.
    by Sela Consultants Corp.), Victor Charlie (Bangkok Security Associates,
    Thailand; distributed in the US by Computer Security Associates).

(c) Encryption of files (with decryption before execution).


Is it possible to protect a computer system with only software?

Not perfectly; however, software defenses can significantly reduce your risk of
being affected by viruses WHEN APPLIED APPROPRIATELY. All virus defense systems
are tools - each with their own capabilities and limitations.  Learn how your
system works and be sure to work within its limitations.

From a software standpoint, a very high level of protection/detection can be
achieved with only software, using a layered approach.

1)  ROM BIOS - password (access control) and selection of boot disk. (Some may
consider this hardware.)

2)  Boot sectors - integrity management and change detection.

3)  OS programs - integrity management of existing programs, scanning of
unknown programs.  Requirement of authentication values for any new or
transmitted software.

4)  Locks that prevent writing to a fixed or floppy disk.

As each layer is added, invasion without detection becomes more difficult.
However complete protection against any possible attack cannot be provided
without dedicating the computer to pre-existing or unique tasks.  The
international standardization of the world on the IBM PC architecture is both
its greatest asset and its greatest vulnerability.


Is it possible to write-protect the hard disk with only software?

The answer is no.  There are several programs which claim to do that, but *all*
of them can be bypassed using only the currently known techniques that are used
by some viruses.  Therefore you should never rely on such programs *alone*,
although they can be useful in combination with other anti-viral measures.


What can be done with hardware protection?

Hardware protection can accomplish various things, including: write protection
for hard disk drives, memory protection, monitoring and trapping unauthorized
system calls, etc.  Again, no tool is foolproof.

The popular idea of write-protection may stop viruses spreading to the disk
that is protected, but doesn't, in itself, prevent a virus from running.

Also, some of the existing hardware protections can be easily bypassed, fooled,
or disconnected, if the virus writer knows them well and designs a virus which
is aware of the particular defense.


Will setting DOS file attributes to READ ONLY protect them from viruses?

No.  While the Read Only attribute will protect your files from a few viruses,
most simply override it, and infect normally.  So, while setting executable
files to Read Only is not a bad idea, it is certainly not a thorough protection
against viruses!


Will password/access control systems protect my files from viruses?

All password and other access control systems are designed to protect the
user's data from other users and/or their programs.  Remember, however, that
when you execute an infected program the virus in it will gain your current
rights/privileges.  Therefore, if the access control system provides *you* the
right to modify some files, it will provide it to the virus too.  Note that
this does not depend on the operating system used - DOS, Unix, or whatever.
Therefore, an access control system will protect your files from viruses no
better than it protects them from you.

Under DOS and Windows 95, there is no memory protection, so a virus could
disable the access control system in memory, or even patch the operating system
itself.  On the more advanced operating systems (Unix and OS/2) this is not
possible, so at least the protection cannot be disabled by a virus. However it
will still spread, due to the reasons noted above.  In general, the access
control systems (if implemented correctly) are able only to slow down the virus
spread, not to eliminate viruses entirely.

Of course, it's better to have access control than not to have it at all.  Just
be sure not to develop a false sense of security and to rely *entirely* on the
access control system to protect you.


Will the protection systems in DR DOS work against viruses?

Partially.  Neither the password file/directory protection available from
DR DOS version 5 onwards, nor the secure disk partitions introduced in DR DOS 6
are intended to combat viruses, but they do to some extent.  If you have
DR DOS, it is very wise to password-protect your files (to stop accidental
damage too), but don't depend on it as the only means of defense.

The use of the password command (e.g. PASSWORD/W:MINE *.EXE *.COM) will stop
more viruses than the plain DOS attribute facility, but that isn't saying much!
The combination of the password system plus a disk compression system may be
more secure (because to bypass the password system they must access the disk
directly, but under SuperStore or Stacker the physical disk is meaningless to
the virus). There may be some viruses which, rather than invisibly infecting
files on compressed disks in fact very visibly corrupt the disk.

The "secure disk partitions" system introduced with DR DOS 6 may be of some
help against a few viruses that look for DOS partitions on a disk.  The main
use is in stopping people fiddling with (and infecting) your hard disk while
you are away.

Furthermore, DR DOS is not very compatible with MS/PC-DOS, especially down to
the low-level tricks that some viruses are using.  For instance, some internal
memory structures are "read-only" in the sense that they are constantly updated
(for DOS compatibility) but not really used by DR DOS, so that even if a
sophisticated virus modifies them, this does not have any effect.

In general, using a less compatible system diminishes the number of viruses
that can infect it.  For instance, the introduction of hard disks made the
Brain virus almost disappear; the introduction of 80286 and DOS 4.x+ made the
Yale and Ping Pong viruses extinct, and so on. And there are only about 35
viruses that plague the Macintosh's, while there are over 7,000 known to the
PC world.


Will a write-protect tab on a floppy disk stop viruses?

In general, yes.  The write-protection on IBM PC (and compatible) and Macintosh
floppy disk drives is implemented in hardware, not software, so viruses cannot
infect a diskette when the write-protection mechanism is functioning properly.

But remember:

(a) A computer may have a faulty write-protect system (this happens!) - you can
test it by trying to copy a file to the diskette when it is presumably write-
protected.

(b) Someone may have removed the tab for a while, allowing a virus on.

(c) The files may have been infected before the disk was protected. Even some
diskettes "straight from the factory" have been known to be infected in the
production processes.

So it is worthwhile scanning even write-protected disks for viruses.


Do local area networks (LANs) help to stop viruses or do they facilitate their
spread?

Both.  A set of computers connected in a well managed LAN, with carefully
established security settings, with minimal privileges for each user, and
without a transitive path of information flow between the users (i.e., the
objects writable by any of the users are not readable by any of the others) is
more virus-resistant than the same set of computers if they are not intercon-
nected.  The reason is that when all computers have (read-only) access to a
common pool of executable programs, there is usually less need for diskette
swapping and software exchange between them, and therefore less ways through
which a virus could spread.

However, if the LAN is not well managed, with lax security, it could help a
virus to spread like wildfire.  It might even be impossible to remove the
infection without shutting down the entire LAN.

A network that supports login scripting is inherently more resistant to viruses
than one that does not, if this is used to validate the client before allowing
access to the network.


What is the proper way to make backups?

Data and text files, and programs in source form, should be backed up each time
they are modified.  However, the only backups you should keep of COM, EXE and
other *executable* files are the *original* versions, since if you back up an
executable file on your hard disk over and over, it may have become infected
meanwhile, so that you may no longer have an uninfected backup of that file.

  Therefore:

  1. If you've downloaded shareware, copy it (preferably as a ZIP or other
original archive file) onto your backup medium and do not re-back it up later.

  2. If you have purchased commercial software, it's best to create a ZIP (or
other) archive from the original diskettes (assuming they're not copy
protected) and transfer the archive onto that medium.  Again, do not re-backup.

  3. If you write your own programs, back up only the latest version of the
*source* programs.  Depend on recompilation to reproduce the executables.

  4. If an executable has been replaced by a new version, then of course you
will want to keep a backup of the new version.  However, if it has been
modified as a result of your having changed configuration information, it seems
safer *not* to back up the modified file; you can always re-configure the
backup p
copy later if you have to.

  5. Theoretically, source programs could be infected, but until such a virus
is discovered, it seems preferable to treat such files as non-executables and
back them up whenever you modify them.  The same advice is probably appropriate
for batch files as well, despite the fact that a few batch file infectors have
been discovered.


The next issue will deal with facts and fibs about computer viruses


                    -==-
컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?               Type 2/0 Forum               ?
           ?            Edited by Sam (1@2863)          ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

Have a comment?  Got a beef?  Wanna issue long-overdue kudos?  Here is the
for it!  Send your letters/comments/questions to Sam, 1@2863, for publication
in WWIVNews.


컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?          Netlimit: Good or Bad             ?
           ?    Editorial Commentary By Sam (1@2863)    ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?


Note: The author of Netlimit was invited to submit his comments for this
article but did not do so.

Recently the talk on all the major sysop subs has been fueled by the
controversy surrounding a program called Netlimit. For anyone who does not
know, Netlimit is a program that is used to prevent nodes (referred to here
as a "limited" node) that connect to and depend upon another node for their
network packets (referred to here as a "limiting" node) from being able to
receive any subs other than those permitted by the limiting node.  Netlimit
analyzes and traps any sub requests sent out from the limited node, and any
sub add requests coming into the limited node from outside nodes wishing to
subscribe to subs hosted by the limited node (again, other than those express-
ly permitted by the limiting node). Since Netlimit does not block email,
limited nodes are still free to email requests to be added to subs, but when
Netlimit detects that this has occurred, it will then attempt to send out an
auto-drop packet in an effort to de-subscribe the limited node from the sub
they are receiving.

The idea behind Netlimit is noble. It is designed to prevent the limited nodes
from being able to have a free ride at someone else's expense. Without Netlimit
being in place, end nodes are completely free to pick up as many subs as they
like. If they are not the ones doing the long-distance callout to pick up the
network packets, that forces another person to have to pay to pick up the
packets for them. In the perverse entitlement-mindset of today's society, one
would think that a program such as Netlimit would be welcomed with open arms.

But that has not happened.  And with good reason.

WWIVNet is not a social experiment gone haywire, ala The Great Society. It is
a private network, supported by a group of private sysops. While none of them
should be expected to have to pay to support the hobby of another, allowing
programs on the network that, in reality automate censorship, is not the right
answer to the problem.

Those who defend Netlimit's use claim that it's better to have Netlimit in
place so that the limited nodes can at least have email and the subs permitted
by the sysop calling out to pick up the network packets.  On the surface, that
seems all well and good.

In reality it is censorship, and such programs can lead to devastation of the
network.

Assume I have a distaste for liberals. Assume I have 25 connections to me, and
that each of those nodes have three connections. They may have other
connections too, but through me, then through those 25 connections, four
liberal-oriented subs get sent to 75 nodes downstream of me.

Using Netlimit, I could easily block all of those nodes from receiving those
subs.  Further, by editing the outbound packet (with the Netlimit SSM's <or
whatever>) in it, I could prevent anyone from ever knowing what happened.

Netlimit supporters say that that is possible right now. While this is a true
statement, it wold require hours of tedious work using lnet (or similar
program) and manual intervention on the part of the sysop on each and every
transient packet routed through his or her node. By using Netlimit, the process
can be set up once and forgotten about.

Netlimit supporters claim the network documentation allows them to limit the
amount of traffic end nodes may pick up. This is true. But network policy also
expressly states that transient packets (those coming through a node but that
are not addressed for that node) may not be tampered with (other than to prevent
file transfers via the net) which is exactly what Netlimit and programs like it
do...tamper with packets. Based on these two points (one which allows a sysop
to limit what a node may receive through him, and one which states that
transient packets may not be tampered with) one can only conclude that when the
policy was written, it was intended to mean that a sysop who carries the long
distance traffic for another node may require that node to either limit what he
subscribes to, pay a fee, or find another connection. Nowhere does it state in
the network policy that the transient packets may be edited (other than as
previously stated) in order to limit network traffic.

The final decision regarding the future of Netlimit and other renegade software
like it rests in the hands of Wayne. Presently, the use of Netlimit seems to
be fairly confined to the 310 area code. They are set to have a meeting in
early May to discuss the future of network traffic in that area. Let's hope for
the good of everyone involved that they use their heads and come up with the
right solution and stop tampering with transient network packets. For once a
policy is put in place that allows for such events to occur, the beginning of
the end of WWIVNet will be set into motion.

                  -==-

컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?          Filo's Mod of the Month           ?
           ?             by Filo (1@4000)               ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

The Mod of the Month is selected by Filo and represents his choice of what
appears to be the most promising mod posted during the past month on Mod Net
(subtype 2370). UUencoded mods are not considered for selection as part of the
mod of the month due to the difficulty of including them in the WWIVnews. Mods
which involve the use of related files such as ENHANCE.C, or any of the
various COMMON type files are also not considered due to the amount of space
required to include them here.  Many of these mods have NOT been tested by
Filo and are selected based on their description as a promising, practical
mod.

This month's selection is written by Frank Reid.

旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?
?Mod Name: FR054.MOD         Mod Author: Frank Reid WWIVnet @8213          ?
?Difficulty: Intermediate          Date: March 4, 1996                     ?
?WWIV Version: 4.24a                                                       ?
?Description: Searches for sub posts directed at user (a "To:" kludge).    ?
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

1.  Back up your source!  I take NO responsibility for ill effects of this or
any of my mods.  I'd be happy to help you get it working, though.  This is a
very tricky mod, at least in its interface with user qscan and such!

2.  Description:  WWIV lacks a "To:" field in its message base structure, so I
set out to provide some equivalent functionality.  This mod will search the
subs in a user's configured qscan for "directed" replies, i.e. messages which
respond to something that user posted.  If the user's name is found, it
displays the message and gives an opportunity to post an immediate reply.
When a scan is complete, the user can clear qscan pointers and mark all subs
as read.  If he chooses not to do so, the qscan remains unchanged, and all
messages still reflect as new.  This routine works equally well on subs
requiring "Real Name" in //BOARDEDIT, e.g. subs imported from Fido-type
networks.

3.  Mechanics:  A great deal of code is from v4.24's <F>ind routine from the
normal message base scan.  Because I didn't want to reset qscan pointers
automatically (I read all messages when I have time), and I didn't want to
track global variables, it incorporates direct calls to the read message and
post reply routines.  For speed, searches are limited to the first 320
characters of a message (where the BY: line or something similar usually is).

4.  Enhancements:  Stock "get_post()" and "readfile()" routines necessarily
allocate memory and read an entire message, as the resulting pointer is used
to find the offset for subsequent messages.  I didn't see a way of changing
this without rewriting redundant routines.  So, as is, this is fast on a
Pentium and slow on a 286.  Searchable text is "clipped" at 320 characters
within the added function only.  If someone wants to tackle a retrieval
routine for type 2 storage which only allocates a small buffer, have at it!
It will certainly speed it up!

Open <MSGBASE1.C>

At the very bottom of the file, add this function:

void find_user_msgs(void)
{
  char           *b, ch, s[81], s1[251];
  static char     findstr[31];
  int             i, i1, i2, os, a, nn, fnd, new, sn, ac, abort, next;
  long            len;
  unsigned long   qscnptrx, sd;
  postrec         p;
  slrec           ss;

  abort = new = 0;
  nl();
  if ((uconfsub[1].confnum != -1) && (okconf(&thisuser))) {
    ac = 1;
    tmp_disable_conf(1);
  } else
    ac = 0;
  os = cursub;
  for (i2 = 0; (usub[i2].subnum != -1) && (i2 < num_subs) && (!abort) &&
      (!hangup); i2++) {
    cursub = i2;
    sn = usub[i2].subnum;
    if (qsc_q[sn / 32] & (1L << (sn % 32))) {
      next = fnd = 0;
      ansic(1);
      npr("\rSearching %s ", subboards[sn].name);
      if (okansi())
        outstr("\x1B[K");
      else {
        outstr(charstr(79,32));
        outchr('\r');
      }
      qscnptrx = qsc_p[sn];
      if (!sub_dates[sn])
        iscan1(i2, 1);
      sd = sub_dates[sn];
      if ((!sd) || (sd > qscnptrx)) {
        new = 1;
        if (!iscan(i2)) {
          nl();
          pl(get_string(1195));
          continue;
    }
    qscnptrx = qsc_p[sn];
        if (subboards[sn].anony & anony_real_name)
          strcpy(findstr, strupr(stripcolors(thisuser.realname)));
        else
          strcpy(findstr, strupr(stripcolors(thisuser.name)));
        for (i = nummsgs; (i > 1) && (get_post(i - 1)->qscan > qscnptrx); i--);
        if ((nummsgs > 0) && (i <= nummsgs) &&
            (get_post(i)->qscan > qsc_p[sn])) {
          ansic(2);
          for (i1 = 0; i1 < 5; i1++)
            outchr(32);
          while ((i != nummsgs) && !abort && !hangup) {
            i++;
        checka(&abort, &next);
            if (!(i % 5) && (wherex() > 1)) {
              for (i1 = 0; i1 < 5; i1++)
                outstr("\b");
              npr("%5.5d", i);
              if (!(i % 100)) {
        tleft(1);
        checkhangup();
              }
            }
            b = strupr(readfile(&(get_post(i)->msg), subboards[sn].filename,
                &len));
            memcpy(s1, b, 250);
            bbsfree(b);
            fnd = (strstr(strupr(stripcolors(get_post(i)->title)), findstr) ||
                strstr(s1, findstr));
            if (fnd) {
              p = *get_post(i);
              if ((p.ownersys != 0) || ((p.ownersys == 0) &&
                  (p.owneruser != usernum))) {
        msgheader(1);
                nl();
                if (E_C) {
                  sprintf(s, "1%u/%u0", i, nummsgs);
                  strcat(s, charstr(12 - strlen(stripcolors(s)), '.'));
                  strcat(s, " 2");0
        } else {
          sprintf(s, "%u/%u: ", i, nummsgs);
                }
                osan(s, &abort, &next);
                ansic_x(sysinfo.msg_color);
                if ((p.status & (status_unvalidated | status_delete)) &&
                    (!lcs()))
                  continue;
                strcpy(irt, p.title);
                irt_name[0] = 0;
                plan(p.title, &abort, &next);
                if (!abort) {
                  ss = syscfg.sl[actsl];
                  if ((lcs()) || (ss.ability & ability_read_post_anony))
            a = 1;
                  else
                    a = 0;
                  nn = net_num;
                  if (p.status & status_post_new_net)
                    set_net_num(p.title[80]);
          setorigin(p.ownersys, p.owneruser);
          read_message1(&(p.msg), (p.anony & 0x0f), a, &next,
                      (subboards[curlsub].filename));

                  if (nn != net_num)
                    set_net_num(nn);

                  prt(5, "Reply to message? ");
                  ch = ynq();
                  switch (ch) {
                  case 'Q':
                      abort = 1;
                      break;
                  case 'Y':
              p = *get_post(i);
                      grab_quotes(&(p.msg), subboards[cursub].filename);
                      post();
                      resynch(cursub, &i, &p);
                      grab_quotes(NULL, NULL);
                      restore_msg_menu();
              break;
          case 'N':
          default:
                      nl();
                      break;
                  }
                }
              }
            }
          }
        }
      }
    }
  }
  if (abort) {
    nl();
    pl("Aborted.");
    nl();
  } else {
    nln(2);
    prt(5, "Search complete...");
    if (new) {
      prt(5, " mark messages on all subs as read? ");
      if (yn()) {
        read_status();
        for (i = 0; i < max_subs; i++)
          qsc_p[i] = status.qscanptr - 1L;
        nl();
        pl(get_string(25));
        nl();
      }
    } else {
      ansic(5);
      pl(" no new messages found.");
    }
  }
  if (ac)
    tmp_disable_conf(0);
  cursub = os;
}

Save <MSGBASE1.C>

Open <LILO.C>

This is where the user is prompted to scan for replies at logon.  Search for
"void logon(void)" and add these lines near the bottom of the function:

==    if (usub[0].subnum==-1) {
==      curconfsub=0;
==      setuconf(CONF_SUBS, curconfsub, -1);
==    }
==  }
++  nl();
++  prt(5, "Search subs for responses to your posts? ");
++  if (yn()) {
++    nl();
++    ansic(2);
++    pl("Space aborts search...");
++    nl();
++    find_user_msgs();
++  }
==  rip_cls();
==  autox = -1;
==}

Save <LILO.C>

Open <MMENU.C>

Finally, we'll add a command to the main menu called //REPLIES which allows a
user to search after he's logged on.  Search for "void mainmenu" and add the
indicated lines:

==  if ((strcmp(s,"NET")==0) || (strncmp(s,"NET=",4)==0))
==    print_net_listing(0);
++  if (strcmp(s, "REPLIES") == 0)
++    find_user_msgs();
==  if (strcmp(s,"QSCAN")==0) {

Save <MMENU.C>

Open <FCNS.H>

Note:  If you can use "MAKE FCNS" to rebuild your prototypes in FCNS.H, this
step is unnecessary.

Search for msgbase1.c and add the new function:

==void remove_post(void);
==int external_edit(char *fn1, char *direc, int ednum, int numlines, char *dest
, char *title, int flags);
==void grab_quotes(messagerec *m, char *aux);
++void find_user_msgs(void);
==
==
==/* File: share.c */

Save <FCNS.H>

5.  Recompile and drop me a note to say you like the mod!

                    -==-



컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?           A Warning Concerning             ?
           ?             Motherboard Cache              ?
           ?           By Burmese (1@15111)             ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?


This is a warning about the stated cache size on many motherboards:

  Some motherboard OEM's are cranking out motherboards whose SRAM cache (L2)
sizes are not what the manufacturer claims they are.  Many are only putting
128k of cache on the motherboard and then tweaking the BIOS to say on startup
that it is 256k (the most common size stated industry-wide).  A few are even
leaving out the L2 cache altogether.

How to identify a motherboard with less-than-stated cache:

  It is almost impossible to identify whether of not a motherboard has 256k of
cache on it or just 128k (or even none at all) just by looking at it.  The
manufacturer's typically fill up all the cache sockets with chips.  Some
individuals have stated on the internet that some of the 'fake' chips can be
identified from their 'cheap' appearance or from the numbers stamped on the
topside of each chip.  This is not reliable in all cases, though.  There are
two basic approaches that can be used to properly identify a motherboard that
is short-cached.

1) Pull the SRAM chips and test them in a chip-testing device.  Some dealers
have such testing equipment, most do not.  Also, the manufacturer will usually
have some sticker plastered over the SRAM cache chips stating that removal of
said sticker will void the warranty (gee, wonder why they don't want you to
poke at their chips?).  Defective and fake chips, of course, will fail in such
a testing device.

2) There are a number of programs available (many of which are shareware) which
are designed to examine your system and detail it's components and
capabilities.  I use the shareware program PC CONFIG (german author).  This
program and some others will properly identify the size of your motherboards'
SRAM L2 cache (found here & there recently as CONF802E.ZIP).

  Another program which will >graphically< demonstrate how large your cache is
is the shareware program CCT386 (Calem Cache Tester, of french origin).  This
program, when run will run a benchmark program over and over, each time in a
smaller 'table'. As the size of the program table shrinks, it eventually
reaches a point where it is contained entirely within the L2 cache and, after
that, within the processors' internal (L1) cache.  As it reaches these points,
the processing speed increases as less wait states are needed to retrieve data
& code from the main system memory (the whole point of the L1 & L2 caches,
anyway).  The program will draw out a graph showing the relationship between
the size of the program and the speed of execution.  In a machine with 256k
cache enabled the chart will show a rapid upward turn from between 512k and
256k, leveling off below 256k; and another jump between 10k & 8k.  If the cache
is only 128k, the initial acceleration in performance will occur between 256k
and 128k.

  Even before performing any of these tests on your system you can get a
possible indicator by browsing through the manual for the motherboard.  These
manuals typically contain information on how to set motherboard jumpers to
accommodate various configurations, including various cache sizes.  If the
manufacturer doesn't want you to be able to fiddle with the cache configuration
they will usually put in something like 'see your distributor regarding cache
upgrades' and they will leave out crucial information relating to adjusting the
jumpers for different cache sizes.

The reason that the BIOS can state on bootup that the cache size is '256k' is
because the manufacturers normally receive a 'base' BIOS code from the BIOS
manufacturer (like AMI) and then 'tweak' that code to work with their
particular motherboard.  It is a simple thing for them to at that point 'fix'
the BIOS so that is states that the cache size is 256k when it is, in
actuality, not 256k but rather 128k or perhaps none at all.

NOTE: Obviously, I am (submitting) this because, after reading some
conversation on the comp.ibm.pc.hardware.chips usenet group on the topic, I
decided to test my own 486-100 system (motherboard was a self-installed
upgrade) and discovered that it only had a 128k cache and not the 256k cache
it was supposed to have (as stated in the manual as well as on the packaging).

컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?                 Dear Abby                  ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

[Got a letter for Abby? Send it to me, and I'll see that she gets it, and that
your letter along with her response get published in the next WWIVNews!]


컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?                 Classified                 ?
           ?                    Ads                     ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

A new feature here in WWIVNews is the Classified Ads Department. It's a place
where utility authors can let everyone know about their most-recent offering
to WWIV.  This issue is a little skimpy due to negative replies, but look
forward to a more-complete list next time.

(Note to shareware/utility authors:  If you would like you products listed
here, please include a *brief* description of them <including registration
fee, if any> and I will be happy to include them in the next issue, due out
around March).

                   -==-

컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?           On the Lighter Side              ?
           ?       A Compilation by Sam (1@2863)        ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?


How many of these quotes from (mostly) cyber-movies can you identify?  Name
the movie they came from.  At the end there is a tiebreaker.  Beyond that, if
there is still a tie, the winner will be decided by random drawing.

The prize is a yet-to-be-determined registration for a WSS product, and your
name up in lights in the next WWIVNews!

1) "I never learned how to swim. I always thought there would be more time."

2) "It's Czechoslovakia!  It's like going into Wisconsin!"

3) "Joey, do you like movies about gladiators?"

4) "Thank you sir, may I have another?"

5) "It bleeds. We can kill it."

6) "Great shot kid!  That was one in a million!"

7) "Be the ball, Danny."

8) "Heeeeeeeere's Johnny!"


Tiebreaker:

"Help you? Who do you think brought the rope?"

                   -==-

컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컫컴컴컴컴컴컴컴?
           ?             Closing Thoughts               ?
           ?       Editor's Notes by Sam (1@2863)       ?
           읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

Well, this concludes another (albeit abbreviated) edition of WWIVNews.  As many
of you are aware, I recently moved from Texas to Kansas to take on a new job
as WAN administrator for a multi-national corporation. Getting moved and 
settled in has taken a great deal of my time, and I apologize for the delay in
getting this edition out.

One major change is taking place here at WWIVNews. It has been decided by both
Wayne and myself that WWIVNews should have a staff. So, we are officially
taking applications for interested people to become a part of WWIVNews. All
interested parties should email me at 1@2863. We will probably limit the
number of people to five or less, so don't be disappointed if you are turned
down.

                   -==-

旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?
?                            Closing Credits                               ?
쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?
?WWIVNews is an independent newsletter published every two-three months as ?
?a service to the WWIV community of sysops & users. The opinions & reviews ?
?expressed herein are the expressed views of the respective writers, & do  ?
?not necessarily reflect those of the WWIVNews staff. Reproduction in whole?
?or in part is allowed provided credits are given. All rights reserved by  ?
?WWIVNews, and all articles are copyright of their respective authors.     ?
쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?
?The source site for WWIVNews is Sam's BBS (913-859-9358 or 859-9476)      ?
?WWIVNet Node @2863. Requests for information regarding articles & other   ?
?editorial submissions, as well as back issue requests and the WWIVNews    ?
?Writer's Guide, can be sent E-Mail to the WWIVNews editor, c/o 1@2863     ?
쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?
?           WWIV and WWIVNet, copyright 1986,1996 by Wayne Bell            ?
? Any product or company mentioned or reviewed herein are copyrighted of   ?
? their respective owners, creators, and other corporate pseudoentities.   ?
읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴?

Who is General Failure and why is he reading my disk?

     Computer analyst to programmer: "You start coding.  I'll go
     find out what they want."

    I modem, but they grew back.

       Modem:  How a Southerner asks for seconds.