Windows 3.0 and Dos 5 Setup for Wildcat version 3
--------------------------------------------------

Revised : 05/10/92  (This SHOULD be the final version for Windows 3.0)

Multi-Node is here!!
---------------------

Yes, I have three nodes running now.  Two with a modem, and one local.  The
only sad part is that I can't run the second line all the time, because I
have to use my voice line.  Not enough wires in the phone cable!  However,
I can say it all works, for the limited amount of time that I've had all
three nodes up.  I've included all my latest tips & observations on how to
run multi-line under Windows.


Before you start
------------------

This version of Wincatmn.txt superceedes all previous versions.  If you
have a previous version, and you find some statements that contradict each
other between the two, believe this one!  (g) I just means that I've
learned something that I didn't know before.  Not an exact science, this
learning process.

Also, all responsibility and liability for using these tips rests with the
user.  I will not be held accountable for any kind of damages incured by
you when you use this document.  I will tell you that I have tested these
tips on my machine, and they do work on my machine.  I haven't destroyed
anything yet.  I fully expect them to work on just about any 386 machine
that generally equals or exceedes my configuration.  However, no guarantees
are made.

Setting it all up...
--------------------

I have been running Wildcat V3.02m under Windows 3.00a quite successfully.
I am running it on an Fast Data 386/25 DX with 8 Megs of Ram, and MS-Dos
5.0.  This document explains my implementation.

There are some support files provided with this package:

CAT1.PIF - This Windows PIF runs CAT1.BAT in 386 Enhanced mode under
Windows 3.0.  I set it up to run full screen in background and foreground
mode.  I also set the multi-tasking options to 125,125.  This gives Wildcat
the same percent of CPU time regardless of whether its the forground task
or a background task.  Generally your users will not notice any performance
degradation if you are running another task with Wildcat in background.
The reason for the "1" in the name:  Its is an easy way to identify which
node is which under Windows, as well as keeping everything separated that
has to be separate for each node.

CAT1.BAT - This is the batch file to run Wildcat Node 1.  Node 1 is the
node that is connected to the HST phone line.  Its pretty straight
forward.

CAT2.PIF - This Windows PIF runs CAT2.BAT in 386 Enhanced mode under
Windows 3.0.  I set it up to run full screen in background and foreground
mode.  I set the multi-tasking options to 100,10 for this node.  This
gives Wildcat Node 2 slightly less priority than node 1, because
its a local node.  Since it IS a local, it doesn't need very much priority
when its in background, since I'm the only one who uses it.

CAT2.BAT  -  This is the batch file to run Wildcat Node 2. Its pretty
much like CAT1.BAT. The only changes to this file is that it is set to a
port id of 0, which identifies it as a local node, and it assigns a node id
of 2 for its copy of Wildcat.

CAT3.PIF - This Windows PIF runs CAT3.BAT in 386 Enhanced mode under
Windows 3.0.  Its pretty much a carbon copy of CAT1.PIF. This gives it
equal priority with Node 1.

CAT3.BAT - This is the batch file to run Wildcat Node 3.  Node 1 is the
node that is connected to the 2400 phone line.  Note that I used the WCMDM
variable to save on environment space. That's why I don't need all the
other variables in there.

WCSYSOP.GRP - This is a program group for the Wildcat MAKEWILD, MAKEWILD
READ ONLY, MAKEQUES, WCPRO, WCREPAIR, WCFILE and CATCOLOR utilities, plus a
few other goodies.  You can add this program group by using the Windows
PROGRAM MANAGER FILE option and select "NEW..." and then select "Program
Group".  On the next panel enter whatever title you choose and then enter
C:\WC30\WCSYSOP.GRP if you put it in the C:\WC30 directory.

CONFIG.SYN - My current config.sys file, renamed to avoid any uplanned
overwrites when you unpacked this archive. You might want to print it and
refer to it while reading the config notes later in this document.


AUTOEXEC.BAN - My current autoexec.bat file, renamed to avoid any uplanned
overwrites when you unpacked this archive. You might want to print it and
refer to it while reading the config notes later in this document.


Configuration notes:

For Dos:
---------

Config.Sys
------------

Some quick notes here - The d=48 on the EMM386 line. This increases the size
of the DMA buffer used to communicate with the EMS and UMB areas. It speeds
everything up, and may allow you to run some applications under Windows that
wouldn't run otherwise, like Fastback 2.x.  Also, the 99,8 on the buffers
line.  Even though the Windows book says you can get by with as little as
10 buffers with Smartdrive in place, I found this not to be true.  I multi
task a lot of Dos applications, and some of them just won't go without a
goodly amount of buffers.  Besides, Windows REALLY took off when I maxed
the buffers!  The ,8 enables "look ahead" buffers for disk access, and
should always be included.  This option first appeard in IBM PC-Dos 3.3
(undocumented) and was also in some versions of Dos 4.0.  Ms-Dos 5.0 should
have it in all versions.  It does quite a job in speeding up disk access,
especially when you have older, slower components.


Autoexec.bat
-------------

Notice the LOADHIGH SHARE line. Be sure to ALWAYS load SHARE when in a
multi-tasking environent. When running Wildcat 3, be sure to provide 120
locks because each Wildcat can have up to 40 files open at once. And, since
you're quadrupling the number of locks over the default of 20, its best to
do the same to the area to hold those locks, hence, the /f:8192 switch.

A quick note on the WIN command line. I put the /3 on there just to be sure
that Windows always starts up in 386 Enhanced Mode, or dies in the attempt.
Even though Win is smart enough to determine startup mode by itself, based
on machine configuration, I take no chances. If for some odd reason Windows
comes up in Standard Mode (like on a 286, or a 386/486 with only 1 meg of
ram), then it only multi-tasks Windows aplications. Wildcat is a Dos
application, so if you switch away from Wildcat in Standard Mode, it
freezes. Not good for the caller on the other end of the line!

If you've seen previous versions of this file, I used to have CAT1.BAT on the
WIN /3 line.  If you really want to run Wildcat in a window, this is the only
way I know of to make Wildcat start up properly.  If you run Wildcat in full
screen mode, by setting the correct PIF option, you can start Wildcat a
different way.  Put CAT2.PIF and CAT3.PIF in your WIN.INI file, on the LOAD=
line to run minimized, and put CAT1.PIF on the RUN= line to run non-minimized.
This puts the local node in the background, so your dial-up lines will get
maximum time from the CPU.

For Windows
------------

First (and foremost) the PIF!

If there's a heart to Windows, the Program Information File is it.  The
options you set in the PIF will determine whether an application runs well,
poorly, or not at all!  Yes, the book says you can run programs without
defining a PIF, but in that case, Windows will use either its default
internal settings (from the Control Panel) or the settings in
_DEFAULT.PIF.  So either way, your program WILL be using a PIF of some
sort.  Might as well take a few minutes and create a PIF that matches your
program's operation as much as possible. You'll get the most out of it
(your program AND Windows) that way!

CAT1.PIF in detail: (start the PIF editor and look at CAT1.PIF if you want)

First screen of the PIF editor - The first few boxes pretty much explain
themselves.  CAT1.BAT tells Windows what file you're going to run, Wildcat
Node 1 names the icon when its on the screen, and the directory tells
Windows where to find CAT1.BAT.  The next few items get interesting.
Here's what they say:

The conventional memory options tell Windows to always try to start
Wildcat, no matter what, and the Dos session that runs Wildcat can take up
to 640k memory (important for Dos shells, doors, Tomcat, etc.).

We are going to run Wildcat full screen, and we want it to run constantly,
even if its in the background.

Close the window when Wildcat is shut down.  Always check this box.  No
sense clutering up your screen with inactive items.


Second screen of the PIF editor (Advanced Options)

Multi-tasking Options:  The default priorities are 50 and 100.  I set them
to 125,125, so that Wildcat will get the same precentage of system
resources regardless of whether its running foreground or background.  And,
I want Node 1 to have a slight priority advantage over Node 2, because Node
1 handles incomming calls.  Exactly what the percentage will be is
hard to determine, since it will depend on what other tasks are running
with Wildcat, whether they are Windows or Dos applications (because of the
way Windows does time slicing) and what forground / background priorities
they have.  The important thing is that Wildcat always needs to get its
fair share of time, while not slowing your work down too awfully much at
the keyboard.  This is why Detect Idle Time is set, so Wildcat will return
resources to the system while he's not doing anything (like while the
caller is reading a message or looking at a list of files).  All of your
other PIFS should have Detect set on too, so they can give resources to
Wildcat when THEY aren't busy.

Memory Options:  The 184k EMS memory is for Wildcat's overlay file.  This
is for the "Hold overlay in EMS if available" question in Makewild.
Keeping the overlay in EMS is always a good deal, because it speeds Wildcat
up a lot.  In the Windows environment, the faster an application runs,
especially a Dos application, the better.  The 300k XMS memory is a new
wrinkle for Wildcat 3.02 and later.  The Makewild questions about enabling
swapping Wildcat out of memory and where (DISK, EMS, XMS) prompted this.  I
used to have all "extra" memory assigned to EMS, but I picked the XMS
option for v3.02 because Windows likes to use XMS memory over EMS whenever
possible.  Since making the change, Wildcat takes less system resources and
seems to run much smoother under Windows with other tasks running at the
same time.  I set the High Memory option mainly because the Windows book
suggested it.  It supposedly will free up some more conventional memory in
the Wildcat session, and I'm all for that.  Notice also that I set all of
the LOCK options.  This ensures that all of Wildcat is in main memory at
all times.  This is VERY important for any communications type program.
Even though it takes only a few milliseconds to swap a program page in from
disk, a comm program or BBS just can't afford the time to wait.  So lock
Wildcat in and let everything else swap around it.  It will cost you
memory, and maybe some speed on other tasks, but when the modem speaks,
Wildcat just HAS to be there with an answer.  If locking Wildcat in memory
really kills your system's performance, about all I can suggest is another
meg or two of memory.  Sorry, fortunes of war.

Video Options:  Its VERY IMPORTANT that you set Low Graphics here, and run
Wildcat in 80x25 screen mode.  I know, if you're running Windows, you've
most likely got a VGA monitor, and you're itching to run Wildcat in 43 line
mode or greater with the Fireworks screen blanker.  But remember - Windows
will only run a high-res graphics application as a full-screen, forground
task.  If you try to put high-res stuff in background or in a window, you
get that neat little Windows message about the application being frozen
untill you switch back to it.  Once again, not good for the poor person
hanging on the other end of the phone line.  To avoid this, run Wildcat in
80x25 mode always, and use a screen blanker other than Fireworks.  The
Fireworks are high-res too, as far as Windows is concerned!  I use the ol'
reliale Box myself.  Also, don't select any of the Monitor Ports options.
You'll just slow down BBS operations, because Windows will be in there port
checking every time a local screen update is made.  Try the Emulate text
mode. It may speed up the screen updates. No need to retain video memory.

Other Options:  I left this section set at the defaults.  Fast paste is ok,
but I wouldn't allow closing the window while Wildcat is active.  Never
tried it myself, but I'm a little nervous about letting Windows close a Dos
application.  Especially if it has lots of files open.  I defined the
CTRL-Q, CTRL-W and CTRL-E shortcut keys to switch directly to Wildcat Node
1, 2 and 3 respectively.  You can change them if you want.

The Windows Desktop:  You'll need to make a couple of changes in the
Control Pannel to be sure that your Wildcat nodes are getting all they can
out of the CPU.  The Windows in Forground option need to be set to 62 and
the Background option needs to be set to 10.  Don't check the Exclusive in
Foreground option.  Also, when you are not doing anything on the Desktop,
keep it in background.  Doing this will make your dial-in nodes the
"featured performers" on your system.  Each one will get 46.3% of the CPU,
assuming you haven't changed any of the CATx.PIF settings.


For Wildcat
------------

I've pretty much covered this stuff already, but here's a qiuck review:

In Makewild: Set things up like you are going to run in native Dos. Be sure
to set the Swap options to Y and swap to XMS on version 3.02 or EMS in
earlier versions. Also, hold the overlay in EMS. Do NOT use the Fireworks
screen blanker. For multi-line, set the Network type to Dos Share.

Before you start up: Use the ATTRIB dos commmand to set all of your EXE
and OVL files in the Wildcat home directory to read only:

ATTRIB +R *.EXE
ATTRIB +R *.OVL

This is to keep SHARE happy. If you don't do this, you will get TONS of
sharing violations when you try to start up more that one node.

Opertaions:  When running Wildcat, keep it in 80x25 screen mode.  Wheter
you run it in full-screen mode or a window is up to you, but there does
appear to be some overhead for local screen writes when Wildcat is
windowed.  This seemed to slow down response for callers with high-speed
modems.  Don't put Wildcat into 43 line high-res mode under Windows in any
case.

Be carefull about poking around in the Wildcat direcories while someone is
online.  Share should keep you out of any real trouble, AKA trashed files
and the like, but what happens if you are in a full-screen application,
like a text editor?  You're working on a display screen that Wildcat wants
to send to the caller.  Ooops - sharing violation - but you don't know it,
because your editor has update rights to the file.  The caller doesn't know
it either, because Wildcat is hung up waiting on you to answer the Abort,
Retry, Fail message from Share on the local screen - the local Wildcat
screen - that you can't see, because your editor is in full-screen mode!
When in doubt, shut Wildcat down, even when you run single line.


Performance Notes
------------------

Here is info on my setup and the speed I've been able to obtain. First, a
review of my priority time slice settings:

               Win Desktop   WC Node1   WC Node2  WC Node 3
-------------------------------------------------------------------------
Foreground        62           125         100       125
Background        10           125          10       125


Next, we look at the total number of time slices demanded of the system, and
the percentage of CPU time allocated when each task is in Foreground:

Node 1 -  Total slices : 270

Node 1 CPU time  : 46.3%           (This is the way I usually run things)
Node 2 CPU time  :  3.7%
Node 3 CPU time  : 46.3%
Desktop CPU time :  3.7%

Node 2 -  Total slices : 360

Node 1 CPU time  : 34.7%           (This is when I'm online locally)
Node 2 CPU time  : 27.7%
Node 3 CPU time  : 34.7%
Desktop CPU time :  2.8%

Node 3 -  Total slices : 270

Node 1 CPU time  : 46.3%           (This is the same as Node 1 in FG)
Node 2 CPU time  :  3.7%
Node 3 CPU time  : 46.3%
Desktop CPU time :  3.7%

Desktop -  Total slices : 322

Node 1 CPU time  : 38.8%           (This is when I'm running a Windows App)
Node 2 CPU time  :  3.1%
Node 3 CPU time  : 38.8%
Desktop CPU time : 19.3%

With this setup, I've been able to get Zmodem download CPS rates of 1436 to
1490.  Upload rates are less, about 1250 to 1325.  Note that this is
without the benefit of a 16550afn Uart, or fast comm drivers, like
Turbocomm.  I expect these numbers to improve once I get a serial card that
will support the buffered Uart and a better comm driver.  Windows 3.1
should also help.  I understand its a good bit faster than 3.0.

Be advised that these percentages (and the assoiated performance) will drop
off fast as you launch more programs - especially Dos programs.  Reason -
because each new Dos program will add to the total time slices required of
your system, and the 125 that Wildcat gets will become a smaller part of
the whole.  Windows programs aren't quite as bad because they will share
the Desktop's set of slices.

Hardware Note
--------------

Bus Mouse - If you have one of these, you should set the IRQ jumper so it
will use 5 instead of 3. Doing so will allow you to use Com2: for a second
modem or other device. It will make things easier for installing multi-line
Wildcat later, or using a comm program while someone is on line now. DO NOT
use IRQ 1! This causes most systems to generate a false "battery low"
condition, and loose all the CMOS settings (type of hard drive, date/time,
etc.). Not the thing to do...


In Conclusion
--------------

That's about it - hope this is of help to some of you. If you follow my
setup exactly, you should be able to run three Wildcat nodes under Windows
and still have pretty decent response for non-BBS applications, be they Dos
apps or Windows apps. If you run into any problems, drop me a line on
Mustang's HQ BBS or call my board directly:

The Comm * Port BBS
614-870-6544
HST 14400 non-v32, v42

Also, if you find this archive valuable, a donation would be welcomed,
mainly as a thank you for the SEVERAL hours of work I've put in on this
not-so-little project. Send $5 to:

Joe Rhinehart
760 Cherryhurst Dr.
Columbus, Oh 43228

