Possibilities - Realities 8/92

Contact:   eSoft, Inc. (Makers of TBBS)
           15200 E. Girard Ave., Suite 3000
           Aurora, CO  80014
           (303) 699-6565      Voice
           (303) 699-6872      Fax
           (303) 699-8222      BBS
           support@esoft.com   E-Mail

REALITIES 8/92
--------------

*** From August 1992 Possibilities Newsletter ***
*** Copyright 1992 by eSoft, Inc.  All Rights Reserved ***

REALITIES...how to make it work
by eSoft Technical Support Staff

From the moment you first install TBBS, it's easy to see the possibilities are 
almost endless.  Turning those possibilities into realities can bring up 
questions.  For this reason, quality customer support is at least half the 
overall value of any software package. 

We recommend you call the eSoft Support BBS (303-699-8222) and read through 
the messages in each of the various support areas.  You could find answers to 
your questions, even before you've asked them!  You'll definitely get some 
useful tips and ideas for bringing possibilities to life with TBBS.  In this 
section of the newsletter, we will answer some of the more commonly asked 
questions we receive. 

Playing Hide and Seek...

Q. I have used the UPDATE program and the latest UPDATE.BIN file to make sure 
that my system is fully current on mods.  Tech Support has assured me that my 
problem with MFSQZ has been fixed with mods, but it persists.  I keep getting 
a "memory allocation error" and the system locks up.  Isn't there ANYTHING you 
can do to fix this? 

A. The most common cause of a mod appearing not to "take" is that you have 
multiple copies of your system utilities installed in multiple directories. 

The UPDATE program follows the SET TBBSPATH= directory list to find the 
programs it will modify, but it DOES NOT and CANNOT modify multiple copies of 
the same program.  When looking for utilities like MFSQZ, UPDATE stops looking 
when it finds the first copy, either in the current directory or on the 
TBBSPATH.  Only that one copy of each program is modified, leaving any 
additional copies unmodified -- and in a potentially problem-causing position.  
Use a find-file function, like that in Norton Utilities or PC Tools, or the 
SYSOM option module to find all copies of TBBS utilities.  Delete any 
secondary occurrences of the utilities, and reconfigure your system batch 
files if they were designed to depend on them.  This ensures that you're left 
with only one copy of each program (located preferably in your main TBBS 
directory) so that they can dependably be kept up-to-date by the UPDATE 
program. 

Preventing Infection...

Q.  My users are concerned about getting computer virus infected files from my 
TBBS system.  I'm concerned about it happening to me when users upload things.  
I'd like to use one of those memory-resident virus scanners so I never have to 
worry about my system getting infected.  Which one should I use? 

A. A little background is necessary to answer this question.  First, you must 
understand how viruses work.  A user could upload dozens of files infected 
with dangerous computer viruses to your TBBS system, and your system will NOT 
become infected with any of them -- Until you run one of the infected 
programs.  The only way a computer virus can spread is when you run a program 
which is infected.  The act of simply copying an infected program does not 
actually spread the infection to the target machine. 

If you never actually run the programs your users upload, then there's no risk 
of infection -- at least no risk to you.  If other users download those 
programs, and then run an infected program, their system will be infected with 
a computer virus even though you and your TBBS system got off scot-free. 

To protect your users (and yourself, if you sample the uploads people make to 
your system) you may wish to scan uploaded files for virus infections.  Anti-
virus software suppliers offer two basic ways to handle this (most packages 
have both):  resident, and batch process. 

Resident scanners are installed as TSR (terminate and stay resident) programs.  
They intercept all disk I/O calls, and scan programs in real-time as the 
system operates.  DO NOT USE THIS METHOD WITH TBBS!  It will cause serious 
system performance problems, and in many cases has actually damaged critical 
system files!  TBBS legitimately does things that can trigger virus scanners 
and many of these TSR programs "fight" with TBBS for control of the computer. 

You will also have problems with using the UPDATE program if you have a TSR 
virus detector loaded.  The job of UPDATE is to modify the .EXE and .COM files 
which make up the TBBS system.  A virus TSR will always activate and prevent 
any modifications to executable files.  This will prevent UPDATE from working 
as it should (note it also means it isn't a problem if you leave such a 
program active when you run UPDATE, although it can look quite scary). 

Batch process virus scanners work offline.  You run a program from DOS which 
scans files, directories, and/or entire drives.  Most of these programs can be 
run unattended with command line switches.  If your virus scanner can be run 
unattended, then you can schedule its execution as an external event.  Refer 
to Chapter 9 of your TBBS manual to see how external events work. 

Finally, most software uploaded to bulletin boards is compressed with 
utilities like ARC and ZIP.  Viruses are actually small pieces of computer 
code, and like any computer code, ARC, ZIP and others will compress it where 
possible.  Unless your virus scanner knows specifically about compressed files 
in the format(s) you use (ZIP, ARC, LZH, PAK, etc.) it may MISS infected 
programs during a scan.  Check with your virus scanner vendor to ensure that 
their scanner can scan programs inside of compressed files -- many don't!  If 
yours doesn't, running the scanner is of no practical benefit to you or your 
users if you're passing compressed files. 

SCSI Controllers, Big Hard Disks, Memory Managers, and Big Headaches... 

Q. I'm running a large, 20-line TBBS.  I recently changed from an ESDI to a 
SCSI hard disk system so that I could add more hard disk space than I could 
with ESDI.  Since the change, I've been having all sorts of problems.  The 
system arbitrarily locks up, I've had corrupted files, and many other 
problems.  I called eSoft's Tech Support, and they said I need a driver for my 
SCSI disk controller.  This disk doesn't need a driver to operate (and it 
works fine with all my other software).  What's the real story here? 

A. The cause of the problem here is a conflict between your SCSI disk 
controller and your EMS memory manager.  The SCSI disk controller may not need 
a driver to operate in the general case, but it may need one to be compatible 
with your 386/486 memory management driver (QEMM, 386Max, etc.), DOS and TBBS. 

SCSI controllers are so-called "bus mastering" devices, which "talk" directly 
to memory in your system.  In order to emulate EMS on an 80386 (or higher) 
CPU, however, the memory manager you're using takes control of your system's 
memory -- mapping it to different locations than its true physical address. 

TBBS uses EMS memory to break the 640k DOS barrier.  In this process, TBBS 
reads and writes disk directly to EMS memory.  If your SCSI disk controller 
(or other high speed disk controller) uses DMA memory accesses, it is not 
always aware of this special EMS memory mapping and may read or write disk 
sectors to the wrong memory location.  This data then overwrites other memory 
and causes serious system malfunction. 

In order for the EMS memory manager and a DMA access SCSI controller to know 
about each other and live together without conflict, you DO need a driver for 
your SCSI controller.  Contact the manufacturer and ask them for a driver 
which implements the VDS (Virtual DMA Services) specification.  Once such a 
driver is installed, the conflict will vanish.  NOTE:  You may need to 
reconfigure or reinstall the memory manager so that it can detect and 
compensate for the newly installed SCSI driver!  Such drivers are available 
for most SCSI controllers -- contact the manufacturer of the controller. 

Some DMA access controllers don't have such drivers available, however.  In 
these cases, the "fix" depends on the card in question.  Such controllers may 
require the use of the DISKBUF parameter if you're using QEMM for your memory 
manager, for example. 

Even if there isn't a direct DMA conflict, some SCSI controllers (like many 
network controllers) use a memory region in upper memory for bufferring.  Such 
buffers may not be detected by EMS managers when they are installed, and these 
managers may try to use this memory as Upper Memory Blocks (UMBs) again 
causing memory conflicts.  If you have this sort of conflict you need to 
determine the memory region used by the card and then ensure that this region 
is excluded from use for other purposes by your memory manager.  (In QEMM, 
this is accomplished with the EXCLUDE parameter.) 

Not all SCSI controller cards use DMA access and create such conflicts.  The 
problems of configuring disk controllers for use with 80386 EMS memory 
managers is usually understood by the controller manufacturer.  So you should 
contact the manufacturer of your SCSI controller to find out how best to 
configure the card for use with such a memory manager. 

There is one final (and somewhat ironic) twist to this tale of conflicts, 
which can occur if you use the 386MAX memory manager.  In an attempt to help 
make these DMA SCSI contoller conflicts less of a problem, 386MAX attempts to 
automatically detect SCSI controllers which need special handling like that of 
the DISKBUF option in QEMM.  In some cases it will add this handling when it 
isn't proper to do so and actually CAUSE a conflict that wouldn't have 
existed.  You must use the NOSCSI option on the 386MAX command line for proper 
operation in this case. 

Unfortunately memory conflicts of this type are a growing problem as the PC 
I/O system and memory management are expanded.  We try to keep on top of them 
but it is an endless and difficult task.  If your TBBS is acting very strange 
(producing "impossible" errors) and you have a system large enough to use EMS 
memory, this type of conflict is usually the reason.  With some detective work 
these problems can usually be found and the proper installation achieved, but 
they can be very frustrating indeed to locate. 

- END -
PS0892-2
Rev. 8/92

Copyright (C) 1994 eSoft, Inc., All Rights Reserved.  Permission granted
to distribute this file in its entirety, without modification, to any
interested party.  Any other use requires the written permission of
eSoft, Inc.

IMPORTANT:  The information herein is subject to change without notice.
Please call or write to confirm factual information of importance to you
or your organization.

