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! ... 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... .. 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!