			   StandAlone ForceFeed
			       Version 4.0sa

			     A DoorFrame Door
		     (Requires BRUN45.EXE In The Path)
			    

			       Written by

			      Shawn McGill
			     The IMPROV BBS
			     (502) 893-8102
			      USR/DS/16800

			      Wildcat 3.60

			    October 16, 1993


I hate writing Docs, so I'll keep this as short and sweet as possible.
Forcefeed was conceived as a way to make my new callers download my
application file that is required for access to the IMPROV BBS. 

Despite several screens telling them that I required them to download
the file, many still did not. Some because they weren't about to, but
some were simply new modemers, and didn't have the vaguest idea what a
download even was!

I decided to write a door that would force them to download the
application file, and Forcefeed was born. I use it as a menu hook off
the main menu. My new callers have only three choices: they can press
[G]oodbye, [C]omment, or [A]uto-Application Download.

If they select "A", they enter this door, which leads them through the
download procedure, and sends them the file. If they successfully
download it, their security profile is upgraded, and the size of the
file is added to their user record KBytes total, as well as one file.

When they come back out of the door after a successful download, they
re-enter the system as a temporary user. If they did not successfully
download the file, they are given another chance. If the file is not
sent, no changes are made, and they're still looking at that 3-option
new user main menu.


WHAT'S NEW WITH VERSION 4.0sa:

This new version is one of a trio of related programs. This particular
one is the stand-alone version. It simply facilitates the process of 
getting your registration files in the users' hands. The companion 
programs are the Charge Door, which allows you to accept major credit
cards through Andy and Betty Rose at Dragon BBS, and the deluxe
ForceFeed, which combines both the ForceFeed functions and the Charge
Door functions into one convenient package.

This new version of FFEED is much more attractive, complete with 
graphical screens, and some cursor positioning. I thought that a user
is likely to feel more comfortable giving his money (and especially
giving you his credit card number!) if the door presented a polished,
professional look.

Many users that called my board have indicated that they might be more
willing to gamble the cost of a subscription to the system if they had
some idea what was here. That presented a dilemma. There wasn't any easy
way to show them what was here without actually giving them access to it.
I have some adult material online, so I was not about to give anyone 
access to that until I had their registration file and proof of age in my
hands.

That's why I built in the ability to display a description file of the 
system, a file listing, and a subscription rate schedule, all of which 
they can view while in the door. I also included the ability to let them
download a file list. The door will even check to see if they have enough
time left online to get the file list, based on their baud rate, before
it will let them have it.

Of course, all of these goodies can be toggled on and off with switches
in the CFG file.

The security level checking features introduced in version 3 are still in
place, as is the last caller text file notification feature.



WHAT'S NEW WITH VERSION 3.51:

In Version 3.51, I tried to provide a mechanism for those sysops who
were having trouble with existing users entering the door, and being
"demoted" when they downloaded the application files. I don't understand
why an existing user would feel the need to go through ForceFeed, but 
some were, and when they returned, an existing user might be lowered 
from SUBSCRIBER level to TEMPORARY level (or whatever).

I have added two lines to the end of the FFEED.CFG file to help keep 
"over qualified" users out of the door, and therefore prevent them from
being "demoted."

By putting the security profile names that you wish to allow into ForceFeed
on these lines, you effectively lock out anyone whose profile name
does not match. In other words, to allow only NEWUSER and TEMPORARY profile
users into the door, put NEWUSER and TEMPORARY on the last two lines of
your FFEED.CFG file. Anyone whose security profile name is not one of those
will be kicked back to the BBS unchanged.

If you only want to allow one profile name into the door (NEWUSER, for 
example), then put NEWUSER into *BOTH* lines. I provided the ability to
specify two profiles just to allow you more configuration flexibility.

If you want to disable this feature, enter NONE on *BOTH* lines, and the
door will allow anyone in. You would probably want to disable this feature
if you're disseminating some file other than a registration form, and you're
using the NOCHANGE feature described below.

(If you're using FFEED to disseminate files other than your BBS application
files, you may be interested in my new door (DISSEMINATOR) which will be out
by the end of August, 1992. DISSEMINATOR works in a very similar fashion to 
FFEED, but allows you to specify any number of files to offer. Check for it
at a BBS near you!)



WHAT'S NEW WITH VERSION 3.5:

Version 3.5 is updated to work with the new release of Wildcat (3.5).
The boys at MSI added a line to USERINFO.DAT, so version 3.3 of FFEED
will no longer work with it. I recompiled the door with a newer version
of DoorFrame that takes this added USERINFO.DAT line into account, and
all should be fine now.

Other than a couple of clean-ups to the original source code, no other
changes to FFEED were made. The newest features of version 3.3 are
outlined in the section that follows this one.


WHAT'S NEW WITH VERSION 3.3:

With version 3.3, I moved the help file, and introduction screen
to external text files. The main reason I did this was to allow users
to be able to use the door for other things than simply forcing a 
caller to download your application file. Most of the wording has been
made unambiguous enough that you could send about any file to your
callers. With the presidential elections coming up, you could have your
callers download your favorite candidate's speech, or you could have your
field representatives download new price sheets, or your users could 
download your club's newsletter. You could start a "GIF of the Week Club"
and set up the door to send a features GIF file at the touch of a key!

You know your needs better than I do, of course, and I think with the 
new generic screens, and the sysop-creatable help and introduction screens, 
you should be able to find any number of uses.

I have included generic example screens that I use to upgrade new callers.
You can edit these screens to your own uses with any ascii text editor, but
they must be named HELPFILE.FFD and SENDFORM.FFD respectively.

In conjunction with the above-mentioned desire to make FFEED more useful,
I also made it possible to NOT change a user's security profile level.
If you were allowing users with several different security levels to use
the door before, they would have all ended up with the same level you
specified in the CFG file. No more! Sometimes you don't want to change the
level, and if you put "NOCHANGE" in the proper field in the CFG file now,
it will leave the user's level at whatever it was when he entered the door.

Of course, anything else in the "Upgrade Security" field of the CFG file 
will cause the program to change the user's level to that profile, just
as it did before.


WARRANTY:

None. I don't guarantee anything about this software. It may not even
run. It is running on several systems beautifully, including my own,
but I don't guarantee that it will on yours. I won't even guarantee 
that it won't trash all your datafiles, and render your hard drive
unusable for the next three generations. All I can tell you is that 
it hasn't hurt mine. In other words, you are using this software entirely
at your own risk. There are no warranties expressed or implied.

This door has been successfully run on a single node system under DOS,
on a three node system under Desqview, and a three node system under
4-DOS that I know of. During testing, files were successfully transferred 
at speeds from 300 baud to 14,400.



CAVEATS:

One sysop I know says he uses DSZ and in particular the DSZLOG function
for recording upload and download stats with his com program. 

This DSZLOG feature is also needed for using HS-Link as an external
protocol, and there may be others.

If you are using the DSZLOG feature of true DSZ (not the zmodem that is 
built into Wildcat or many terminal programs, but as an external protocol), 
then you may want to set up your batch file differently than the one I have 
as an example below. 

It is possible to set the DSZLOG environment variable at the
beginning of the DOORx.RUN, and release it before returning to Wildcat after
executing the door, but unless you increase the default environment size a
bit, you'll likely run out of environment space. ForceFeed needs to parse 
the DSZLOG to determine if a download went through, and deletes the log 
when it is finished.

When I tried to set the environment variable for setting DSZLOG (explained 
later) in the calling batch file, and then release it before returning to the
board, I ran out of environment space. By including the line:

	   SHELL=C:\COMMAND.COM /P /E:2048

in my CONFIG.SYS, I was able to give my environment enough room to add the
SET DSZLOG= variable (explained later) from the DOORx.RUN file instead of
setting it in AUTOEXEC.BAT. Consult your DOS manual for a more detailed
explanation. Remember, for any changes to your CONFIG.SYS file to take 
effect, you must reboot your machine.




SETUP:

The setup of this door is a little unusual, but nothing too bad. The
following steps should have you up and running in no time (I hope!)...


Step 1.

Create a directory and unzip all the files in this archive into it.


Step 2.

Edit the following files:
	
NOTE! DON'T EDIT THE FILE CALLED FFD40ASA.SCR! This contains the various
screens used by FFEED. If you do try to edit this file, please keep an
original, unaltered copy on hand!


	FFD40ASA.CFG

	The FFD40ASA.CFG file's name is not critical, since you will pass
	it to the program on the command line, but it must contain the
	following lines:

	c:\wc30\wcwork\node1\userinfo.DAT  (Path to drop file)
	The IMPROV BBS                     (Name of your BBS)
	Shawn                              (Sysop's First Name)
	Mcgill                             (Sysop's Last Name) 
	4                                  (IRQ for this node)
	03E8                               (Hex Addres for this node)
	IMPROV.APP                         (Name of Registration file)
	TEMPORARY                          (SecLevel to upgrade him to)
	Y                                  (Offer a file list to view?)
	FILES.TXT                          (Name of viewable file list)
	Y                                  (Offer downloadable file list?)
	FILES.ZIP                          (Name of downloadable file list)
	Y                                  (Offer a bbs description?)
	DESC.TXT                           (Name of description file)
	Y                                  (Offer a viewable rate schedule?)
	RATES.TXT                          (Name of rate schedule file)
	NEWUSER                            (1st SecLevel allowed in) 
	EXPIRED                            (2nd SecLevel allowed in)
	HELLO1N.BBS                       (Display file to create)




	If you don't want a bulletin created of who's been
	successfully through the process, just put any filename on that
	line, and delete that file in your calling batch file when you
	return from the door. For example, you could enter BOGUS.TXT on
	that line, and make the last line of your calling batch file
	delete it every time it runs. 

	You can also delete FFEED.DAT, which is created by ForceFeed to
	keep track of the door's transactions, if you don't want to
	maintain a display screen. I reset my ForceFeed door every month by
	simply deleting the FFEED.DAT file on the first of each month.




	MAIN1.RUN

	This is the batch file that calls ForceFeed from your main menu
	"hook". Of course, it could also be run from the doors menu
	(DOORx.RUN), or from the File menu (FILEx.RUN) or Message Menu
	(MSGx.RUN), but that kind of defeats the purpose, doesn't it?

	Anyway you choose to run it, it's pretty straightforward. 

		CD\FFEED (or whatever directory you created)
		FFD40ASA FFD40ASA.CFG

	If you choose to enlarge your environment space as discussed
	above, and set the DSZLOG environment variable from the batch
	file, then your MAINx.RUN would resemble:

		CD\FFEED
		SET DSZLOG=C:\FFEED\DSZLOG.LOG (This sets the variable)
		FFD40ASA FFD40ASA.CFG            (Run the program)
		SET DSZLOG=                   (This releases the variable)


	If you're still running a version of Wildcat! prior to 3.5 (why!?),
	see the WC35TO30 docs included in a separate zip file in this 
	archive, or download WC35TO30.ZIP from the main WC board, or
	from The IMPROV. It will convert your 18-line USERINFO.DAT to
	the 19-line one needed for WC35 doors and utils, and restore it
	after the door is finished.


	That's it! This file (if it's a "RUN") should be in your node
	directory. If you elected to make it a "BAT", then put it in
	your main WC directory (eg. C:\WC30).


	FFEED.DEF

	FFEED.DEF is a "dummy" file that is used to help determine if a
	download was successful. In the event a caller drops carrier
	before the transfer ever starts, DSZ does not create the LOG
	file that FFEED uses to determine the success of the transfer.
	Since the LOG won't exist at this point, it would be impossible
	to tell if things went wrong. This file must exist in the FFEED 
	directory so that FFEED can tell if a caller dropped carrier 
	before the download began.

	It should contain the name of the application file you want the
	door to send to the caller. One line, that's it.

	A sample FFEED.DEF file on the IMPROV BBS might contain:

		IMPROV.APP

	which is the name of my application file.



STEP 3.

Since FFEED uses Zmodem protocols, you must have DSZ.EXE or DSZ.COM on 
your DOS path. As best I can tell, there were two versions of DSZ released
in May of 1993. If you run into problems when DSZ is called, and you are
using non-standard IRQ's on some of your upper nodes, it's possible that
you have an older version of DSZ. The version released in early May, 1993, 
did not support high IRQ's correctly, but the one released late in the 
month corrected this problem. One of my registered users was running his
third dial-up node on COM4, IRQ 10, and the program ran fine until DSZ
was invoked, when it just locked up. Replacing his DSZ with the version
that was released in late May resolved the problem.

If you are using a non-standard IRQ, it's necessary to tell FFEED. On the
command line, if you're using IRQ 10, for example, you should use:

door door.cfg /10

This tells the DoorFrame routines what IRQ to use. DSZ uses the information
you supply in the cfg file.



The final step is to edit your AUTOEXEC.BAT to include the following line:

		SET DSZLOG=C:\FFEED\DSZLOG.LOG

This is very important, as it activates DSZ's log function, and FFEED
uses this log to determine whether the caller successfully downloaded
the file you have specified. Remember that you must reboot after making
this edit for it to take effect.

You can either set this environment varaible in your AUTOEXEC.BAT file as
described here, or you can set it in your calling batch file, as discussed
in the "CAVEAT" section above, provided you have enough environment space
set up to hold it. It MUST be set, whichever way you decide to go, so that
FFEED will work properly.

The path in the SET statement above is intended to path to the
directory you created for ForceFeed. We want DSZ to create the log in
the ForceFeed directory, so make the above line point to the directory
you created for the ForceFeed files! The log file must be called
DSZLOG.LOG, though!!!

PLEASE READ CAREFULLY THE "CAVEAT" SECTION ABOVE IN REGARDS TO USING
DSZLOG AND THIS DOOR!!!

DSZ is the property of Omen Technology, INC, and in my opinion is the
finest transfer protocol driver available. It is available for download
on most every BBS in the country, if you don't already have a copy of it.
I encourage you to register your copy of DSZ, although this door will
run with the features available in the shareware versions.


AUTO-NOTIFICATION FEATURE:

I have made FFEED send a short text file each time it runs. This file
will be created in the default FFEED directory (the one you run the 
door from). It includes the user's name, the time, and the date, and
whether or not he was successfully ForceFed. This text file is suitable
for importation into a message. The reason I did this, was so that anyone
who uses a program such as PostMaster could send themselves a message to
let them know that someone had used the door.

If you use a program such as PostMaster, you can send yourself (or your
userbase co-sysop, for example) a message using this text file. This
file is called LASTCALL.FFD. It is overwritten each time ForceFeed runs.

A batch file such as the following would send me a message each time the
door runs:

 CD\FFEED
 SET DSZLOG=C:\FFEED\DSZLOG.LOG
 FFD40ASA FFD40ASA.CFG
 SET DSZLOG=
 CD\WC30
 POSTMSTR /I:C:\FFEED\LASTCALL.FFD /T:Shawn McGill /F:DOOR /S:FFEED ACTIVITY /P
 DEL C:\FFEED\LASTCALL.FFD

The reason I delete the LASTCALL.FFD file after each run is because if a 
user just went into the door, and came right back out, a new LASTCALL.FFD
wouldn't be generated, and PostMaster would send you a second copy of the
previous caller's notification. If you delete LASTCALL each time, and a user
goes in and out without trying to dl your app, PostMaster simply won't find
the source file, and no message will be sent.

Please consult the PostMaster Docs for an explanation of the various command
line switches used by PostMaster.

PostMaster is a great Wildcat! utility written by Dave Cody of Boardwalk
Software. It is copyright 1992 by Dave Cody. PostMaster is available for
download on many Wildcat systems, or directly from Dave Cody's board,
The Boardwalk at (206) 941-3124.



RECAP:

To recap, the following files should be found in your Door directory:

		FFD40ASA.EXE
		FFD40ASA.CFG
		Your Application File
		FFD40ASA.SCR
		Any text files you've elected to offer
		FFEED.DEF

The Batch file that you call the door with should be in your main WC30
Directory if it's a ???.BAT file, and in your node directory if it's a
???.RUN file.



HISTORY:

The original Catpatch version was released on April 5, 1992. It had
some problems on non-standard platforms, probably because of the
Catpatch routines, themselves.

Version (3.1) was released on April 26, 1992. I rewrote the door, this
time using DoorFrame routines. This was done in an effort to give it
some improved I/O routines, and wider compatibility. Non-standard IRQ's
are now supported, along with much higher baud rates.

Version (3.1a) was released on May 6, 1992. Nothing was changed about the
door itself, but I updated the docs to include an explanation of
the need for the FFEED.DEF file, which was left out of the previous
DOCS. I also added a warning about FFEED's use of the DSZLOG function.

Version (3.2) was released on May 29, 1992. I added the ability to interface
with programs such as PostMaster by having ForceFeed create a small text
file called LASTCALL.FFD which contains a message telling if a user either 
did or did not successfully download the app file. By using a program such 
as PostMaster, you can send yourself or your userbase co-sysop a formal 
message notifying of FFEED activity. This saves your having to go looking
for the information. It will be "ForceFed" to you! <g>... LASTCALL.FFD is
overwritten each time the door runs, so if you choose not to use this 
feature, you can just ignore it, and the file will never grow any bigger.

Version (3.3) was released on June 5, 1992. I added the capability to NOT
change a user's security level by putting NOCHANGE in the upgrade profile
level in the CFG file. I also changed the internal screens to more
generic wording and moved the SENDFORM.FFD and HELPFILE.FFD screens to 
external ascii text files to allow the sysop to use the door for a wider
range of possible applications.

Version (3.5) was released on July 5, 1992. FFEED was recompiled with an 
updated version of the DoorFrame routines. Since Wildcat added a line to
the USERINFO.DAT file with version 3.5, I had to change a line or two of 
code, and use the newer DF routines to deal with this change. No other 
changes in the program were made, except to make it compatible with the
new Wildcat release. This version will not work with versions of Wildcat
earlier than version 3.5!

Version (3.51) was released on July 12, 1992. I added the capability of
"locking" all but two specific security profile names out of the door.
This was necessitated by the fact that some fully validated users were
going into the door, downloading the app files, and getting "demoted".
The sysop can now specify up to two profiles that will be allowed in the
door. This should prevent accidental reductions in access levels, if a
previously-validated user wanders into the door. Of course, this feature
can be disabled, if the sysop wants to use the door for something other
than forcing registration downloads. Also changed the filename extensions 
on the three ascii files FFEED uses (LASTCALL, SENDFORM, and HELPFILE) from
"TXT" to "FFD". Since I am soon releasing DISSEMINATOR, which is very similar
in operation to FFEED, I renamed these text files to allow a sysop to run
them from the same directory, if he wished.

Version (3.53) was released in late 1992 to try to address some of the 
problems some users were having with odd port assignments. I changed the
way I was calling DSZ from within the program, and added the IRQ and
HEX address to the CFG file.

Version (4.0a) was released on October 16, 1993. This is a nearly complete
rewrite of the door. It now features a wider array of informational
capabilities, including the addition of a file list, downloadable file
list, board description file, and rate schedule file. This is the first
version that uses a key file scheme for registration, allowing those
who register to simply download a registered key, rather than having
to download an entire new program.


SUPPORT

I will support this door through my BBS, The IMPROV at (502) 893-8102
(USR/DS/16800). I am a member of ThrobNet (known as "Al Bundy"). I also
echo the MSI Support conferences, Wildnet, and RushNet.


REGISTRATION

This door will expire. If the key in this archive is already expired
when you get it, please call my board for a fresh demo key.

Many of the features of FFEED will only be activated if the copy is
registered.

After a reasonable evaluation time, you must either register it, or
delete it from use on your system.

Registration is $25.00. If you are a previously-registered owner of 
FFEED 3.xx, you can upgrade to version 4.0A for $10.

There are two ways to register. You can either fill out and mail the 
registration form below, or you can charge your registration with your 
major credit card by calling my board, The IMPROV, at (502) 893-8102 and
going into the charge door.

When you complete the registration form, I will pre-register you on my
BBS, and make your registered key available for you to download when
it's ready. Future updates to version 4.xx will be made available for 
you to download as they are released. It'll be up to you to call in 
from time to time to check for updates.


------------------------------ Tear off Here ----------------------------------


			    ForceFeed Registration
				   v 4.0a


Your Name:________________________________________


BBS NAME:____________________________________ (as you want it to appear on the
							Registration screen)

BBS PHONE:___________________________________


Mailing Address:______________________________________________


City:_____________________________________ State:_____________________


Date:_______/_______/________


Please enter a name so I can pre-register you on my BBS. I check my P.O.Box
about once a week, so be patient... <g>.. I will have your key ready for
download the next day after I receive this form and your payment.



	NAME:_____________________________________

	PASSWORD:_________________________________

	D.O.B:_______/_______/_______


Registration: $25.00  Please check one:   Check_____    Money Order_______


Make Payable to:

	Shawn McGill
	P.O.Box 6148
	Louisville, KY
		40207

Thanks for supporting Shareware!


