===========================================================================
Date: 12-03-93              
From: JIMI MCDUFFIE              
  To: ALL                         
Subj: TRIBBS UNDER WINDOWS
---------------------------------------------------------------------------

FORETHOUGHTS
-------------
 This was originally posted in the TriBBS Support conference. It has been
re-edited and added to prior to posting here on The Lobster Buoy BBS.
I had a post written for a guy who was having comm probs running
under Windows. This covers the problem he had described as well as some
solutions for multi-tasking problems and also contains many other 
tid-bits gleaned from some intense pruning and chopping I had done to get 
my BBS set up under Windows. While all of the information here is only as
accurate as the source from which I've drawn it, you could conceivably
trash something. Be careful. Spelling and typing counts big-time when 
altering .INI files. I won't be responsible should you trash your copy
of Centipede or whatever. All information here is 'as is'. No guarantees,
no warrantees. (gotta be sure to cover my butt, there aren't many original
copies of Centipede left.....)

STUFF YOU OUGHT TO KNOW
-----------------------
 As a forenote: I am running TriBBS 5.01 General Release under Windows 3.1 
on a 386/DX40 with 4 megs of memory and am using QEMM, HIMEM.SYS, and 
CYBERCOM.DRV as a replacement for COMM.DRV.
 CYBERCOM.DRV is FREEWARE. It is available from various BBS's (including 
The Lobster Buoy) as CYBERDRV.ZIP. Other replacement drivers are available
(some free most not) and a little hunting will turn them up. Two that I am
personally aware of are: TURBOCOMM and WFXCOMM. I haven't tried either, but
do know that other TriBBS sysops are currently using them. To run a system
at a rate higher than 19200 bps I would highly recommend your finding one
that suits you. Windows' "stock" COMM.DRV does not support baud rates above
19200 bps and have no built in support for the 16550 buffered UART chip.
These replacement drivers allow for high-speed transmission utilizing the 
16550 UART and it's FIFO (First In First Out) buffer. But if you don't have
a 16550....fear not. There are a few things that Windows allows you to tweak
which will allow your serial communications to run a little smoother. By the
way, those of you who have internal modems....don't worry about this UART 
stuff. That only applies to those of us with external hi-speed modems. If 
you have an internal or 9600bps and below modem.....you've just read a lot
of stuff that will do you no good. Sorry. (grin)

 **************************** ABOUT MODES *********************************
 * As a note to anyone just setting up, please GOD don't expect           *
 * to run in standard mode and have any success. Standard cannot Multi-   * 
 * task. Don't let ANYONE try to tell you different. This is inherently   *
 * IMPOSSIBLE! Make sure your system is in 386 Enh. mode. Check under     *
 * About Program Manager to make sure) This file deals only with 386Enh   *
 * Mode. Also make sure that your CONFIG.SYS specifies STACKS=9256.       *
 * If for some reason you expected to be in 386Enh Mode and find that you *
 * are instead in Standard Mode....start looking for memory problems.     *
 * I'd start with MemMaker (from DOS) and see what it says. Also pull up  *
 * (again, from DOS) MSD.EXE, the MicroSoft Diagnostics Program.          *
 * Sorry to be so vague, but that is a problem I haven't had to deal with *
 * and most who have had to are now stark-raving lunatics. Good Luck.     *
 * (It IS a 386 or 486, right? <grin>)                                    *
 **************************************************************************


Before you start, select new (program item), browse and find SYSEDIT.EXE.
Select it and put it somewhere handy, say in your Main group.
It's an undocumented editor for your CONFIG.SYS/AUTOEXEC.BAT/WIN.INI
and SYSTEM.INI files. It will save you LOTS of headaches and time. It's
easy to use and can be found in your WINDOWS\SYSTEM directory. What's nice
is that you can work on all four without shelling out or having 4 notepads
open. This can make any of the following changes pretty painless. OK. Enuff
preliminaries.....let's get to it.


TriBBS AS A BACKGROUND TASK in 386 Enhanced Mode
------------------------------------------------

SHARE
-----
The SINGLE most important thing you MUST do is add SHARE.EXE to your
AUTOEXEC.BAT. TriBBS will NOT function AT ALL without it under Windows.
Got a blank screen and a blinking cursor that won't do anything? Install
SHARE. In my opinion, though Mark didn't intend this, it turns out to be
a good thing. I have already had SHARE save me from trashing a file or two. 
You may get locked out of file access if you screw up while shelled to DOS  
from TriBBS, but that's pretty small peanuts when compared to an obliterated
file. If you get locked out, just Ctrl-Alt-Del. Windows will terminate TriBBS
and you can just go right back.

386 Enh
-------
You will probably need to adjust your settings for CPU slices. (please refer 
to your Windows docs or some other dusty tome for explanation of a slice) 
Under Control Panel find the  386 Enh icon. Double-click on it and look down 
at the bottom of it's window. The Minimum Timeslice (in msec.) is set here. 
I am currently running at 10. You may want to experiment depending on your 
machine and it's processor speed and memory. (20 works for me also, so....) 
What you are essentially doing is telling your CPU to move from app to app
a little faster. the faster it moves around, the less likely it's gonna miss
something. If users have problems with jerky or slow downloads, check this.
If you are like me, you aren't looking for ten things to run all at once in 
orderly fashion. What most of us want is for TriBBS to run as well and fast 
as possible be it one node or two or three. Everything else can take a little 
longer if necessary. It IS possible to run TriBBS in the background and have 
your foreground tasks clip along at a rather brisk speed. But...your users
would not have very nice things to say about your pokey BBS. Especially if 
you have more than one node.......

PIFS
----
Most important thing #2: your PIF. Read up on them in your docs first.
There are a couple of things you can do to make Windows more watchful of
your background Comm tasks. Some are documented...others not.
The first is to make SURE that you give a HIGH background priority to
TriBBS. The standard PIF setting of 50 is no where near high enuff, as 
most applications already have at least that much priority. 
Keep in mind that PIF settings are relative. If you set TriBBS to 200 or even
10000 in background and have another program running background with the 
same or a higher priority, TriBBS will suffer and you (or your users more 
likely) will experience slow-down, sluggishness or download problems.
Try setting to at LEAST 150 and above. (200-400 may be better depending on
your system speed and comm throughput) While this will definitely cause
foreground tasks to show a visible slow-down (again, depending on your
system speed), it may be necessary for your particular set-up. Play
around til you get it as low as possible with no errors or dropouts)
Keep in the back of your mind that you are trying to make a balance here.
And for clean operation of your board, triBBS should be the heavy side.
Then make sure that no other application will 'take' it's priority by having 
a higher setting. Bob Bier (a TriBBS sysop) has set his priority to 1500.
This may be a good idea for you also. It makes certain that no other app will
get first dibs on processor time. I don't know of any application which comes
out of the box with a priority that high. Be sure to reset and other apps you
use while TriBBS is active a little higher if you need to. This may be 
necessary for your sanity. 

While this may seem like common knowledge, I know that PIF's are still
kinda foreign to a lot of Win users. Also, instead of calling Board.bat
from your TriBBS icon, call the PIF for BOARD.BAT. We don't want
Windows ignoring your PIF settings and using _DEFAULT.PIF. To do this the
line under Properties would go something like Command Line:
C:\TRIBBS\BOARD.PIF  Make sure your PIF is there and that your PIF has
under Program Filename BOARD.BAT and NOT  BBS.EXE! (see TriBBS Docs)
Also, be certain to Lock Application Memory for Board.bat's PIF.

Again: Read the Windows Manual section on PIF's. It DOES contain the
information you need. Really. No I'm serious. Yes, I know Microsoft wrote
it, but....trust me. (grin)

SYSTEM.INI
----------
There are a couple of things you can change/add to your SYSTEM.INI file to 
help out. Find what's right for you, you may not need any of them or only 
one adjustment may be necessary.

 One is a little known command for adding more buffer space to the comm
driver. Add (or change if it's there) the following line to your
[386 Enh] section: COMxBuffer=n - where x is your port number and n is
the amount of buffering you'd like it to have. (i.e.- COM2Buffer=2048)
Windows defaults to 128 (or maybe 256). So a value of 1024 or 2048 is
more in line. If you are using a comm driver other than COMM.DRV, refer to
the it's documentation for changing buffer size. The above, as far as I know,
refers only to COMM.DRV. Adding this when using a third-party driver may not
do anything but eat up a little memory. And we all know how precious THAT is.

Another change you can make is to boost the amount of time your CPU will
allot for DOS programs using a com port. It is reception sensitive,
which means that it doesn't allot the time until it sees a character
received. But, once it sees that character it will give you more slices
to handle the input. As for output.... Since error correcting
protocols keep up a pretty constant (relatively speaking) chatter when
someone is downloading from you, this is a quick way to grab more
processor time when a transfer is happening in background.
The line is: COMBoostTime=n - where n is the increment you'd like to
boost to. Windows defaults to 2, so for a background BBS task 4 or even
6 may make your users happier.

Well, here's how this section originally read:
"Finally, as a sort of last resort you can make sure that DOS apps that
are running background (like TriBBS) don't go idle on you. AGAIN, I
don't recommend this unless TriBBS just plain snoozes on your users when
it's background." 
Matt Nall was having trouble with TriBBS snoozing on him during downloads.
He used the following, and it is so far keeping his board sober.
So, I may have to change my stance. I still think it should only be used
if you just can't keep the board awake. It's not gonna melt your monitor
or anything, but it would be best to exhaust all other steps first. 
OK, so here it is. Matt's Coffee:

Under [386 Enh] add the line: IdleVMWakeUpTime=n 
where n is the timer interrupt value based on seconds. These can ONLY be
the following values: 1,2,4,6,8,16,32,64. (see a pattern? <grin>) 
Windows defaults to 8. A value of 6 would be a good starting point. BUT! 
if your app IS going to sleep, I would look for another cause before changing 
the Idle Wakeup. (interrupt intensive foreground apps, frequent DMA access 
from apps, heavy video use, another DOS app running in a window foreground or  
background with too high a priority, etc...)
By the way, Matt is running it at 1. see what I mean?......It's not for 
everybody. Two node and higher systems could possibly need this kick in the
pants. Most probably if their are any other apps or thing-a-ma-bobs running 
as well.

Something many overlook is throughput from your Hard drive or CD Rom
drive. If you are using SmartDrv or whatever, make sure it's
slingin out bits fast enuff. Keep in mind that in a multi-tasking
situation more than one program can be asking for data at a time. And
with a high speed modem it's possible for a bog down to drop the
receivers % rate down a few points.

If you'd like to gain a little speed so that all your DOS apps are a
little zippier, change (or add) the line FileSysChange=Off to your
[386Enh] section. But, File Manager (Windows File Manager, not TriBBS' 
Fileman) will not be aware of any file movement or updating done by DOS 
programs if it is open. Don't worry, though. This only applies when File 
Manager is actually open and in the same directory as the change.
 
AFTERTHOUGHTS
-------------
In closing (well, almost) nothing beats your installing a 16550AFN
buffered UART on you com port. (again, for externals only)
Also, a new comm driver can make a lot of difference. Windows is NOT 
set up out of the box to go higher than 19200bps. Without installing a 
new com driver I wouldn't try to go any higher and expect to not have errors 
or lost data. BUT! I do know of someone running at 56700 with a 16540. He
has his comm buffers pumped up on steroids and is using the magic words
below in his SYSTEM.INI:
Com?Baud=3 - where ? is the Com port your modem is on and 3 specifies
56700 bps. Leave the setting under Control Panel's Ports set at 19200.
Then in WIN.INI change Com?=19200 to Com?=56700 w- where ? is your com port
number.
Now, who could this be....? Matt????? <grin> (thanks for the tip)

[Standard] MODE (ugh.....)
--------------------------
Finally, if you just HAVE to run TriBBS under Windows on a 286 (which I
doubt anyone would recommend) make sure to set your FasterMode Switch to
1. (under [Standard] add line FasterMode Switch=1) This will greatly
enhance your interrupt handling time.

BUT REMEMBER! WINDOWS' STANDARD MODE IS MULTI-TASK ILLITERATE! FORGET IT!


If any Windows type gurus spot any errors here, PLEASE let me know! I'm
also running under Win 3.1 and am still learning all the tricks.
Any corrections would be appreciated. Hope I've been some help.

Jimi McDuffie
c/o Terminal Entry BBS (fido 1:3634/32)

PS-anyone wishing to have the settings for my BOARD.PIF...just ask:>

TIDBIT-By adding MaxCOMPort=n to [386Enh]  you can get Win 3.1 to
address more than 4 ports. ;>

 * SLMR 2.1 * ۲ IN STEREO WHERE AVAILABLE 
