ForceFeed Version 3.5 A DoorFrame Door (Requires BRUN45.EXE In The Path) Written by Shawn McGill The IMPROV BBS (502) 893-8102 USR/DS Wildcat 3.01 July 5, 1992 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 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. Version 3.5 expires on 9/1/92. This should be sufficient time to see if it will run on your system, and if it meets your needs. After this time, it must be registered. 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.TXT and SENDFORM.TXT 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" filed 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. CAVEAT: One sysop I know says he uses DSZ and in particular the DSZLOG function for recording upload and download stats with his com program. 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. There has also been an announcement that version 3.5 of Wildcat! will support any protocols that use the standard DSZ.LOG format. I can only think that this will cause some interference, so setting the DSZLOG environment variable in the calling batch file, and releasing it when the door is done might prove to be necessary to preserve FFEED's compatibility when WC 3.5 appears. 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, any 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: FFEED35.CFG The FFEED35.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: Full path to DOOR.SYS The BBS's Name Sysop's First Name Sysop's Last Name Full path to USERINFO.DAT The name of your application file The security profile name to upgrade to (or "NOCHANGE") The Full path/name of the display file created Optionally, you can run FFINSTAL.EXE from your door directory, and this CFG file will be created for you. As you can see, it's much like every other door you ever set up, except that it looks for DOOR.SYS and USERINFO.DAT instead of CALLINFO.BBS. 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. A sample FFEED35.CFG file might look like this: C:\WC30\WCWORK\NODE1\DOOR.SYS The IMPROV BBS Shawn McGill C:\WC30\WCWORK\NODE1\USERINFO.DAT IMPROV.APP TEMPORARY C:\WC30\DISP\HELLO1N.BBS 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 (MSG1.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) FFEED35 FFEED35.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) FFEED35 FFEED35.CFG (Run the program) SET DSZLOG= (This releases the variable) 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, and also matches line 6 of your configuration file, you may notice. SENDFORM.TXT & HELPFILE.TXT These are the ascii text files that are sent to the caller to explain the purpose of the door, and if he hits the HELP option from the menu. You can read my examples that are included, and should be able to get a good idea of what these files are intended to convey. If you're using this door for something other than forcing registration downloads, you'll certainly want to edit them to suit your purposes. Just make sure you use the filemanes SENDFORM.TXT and HELPFILE.TXT. According to the DoorFrame Docs, these files can be ANSI color files, if you like, but I haven't tried that, and I don't know what a non-ansi caller would see. If it works, let me know ! STEP 3. Since FFEED uses Zmodem protocols, you must have DSZ.EXE or DSZ.COM in your FFEED directory. I suppose you could simply have it somewhere on your path, but I have only run this door with a copy of DSZ in the same directory, and since it worked, I didn't try it anywhere else. 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.TXT. 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 FFEED35 FFEED35.CFG SET DSZLOG= CD\WC30 POSTMSTR /I:C:\FFEED\LASTCALL.TXT /T:SYSOP /F:DOOR /S:FFEED ACTIVITY /P DEL C:\FFEED\LASTCALL.TXT The reason I delete the LASTCALL.TXT file after each run is because if a user just went into the door, and came right back out, a new LASTCALL.TXT 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: FFEED35.EXE FFEED35.CFG HELPFILE.TXT SENDFORM.TXT Your Application File DSZ.EXE or DSZ.COM 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.TXT 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.TXT 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.TXT and HELPFILE.TXT 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! SUPPORT I will support this door through my BBS, The IMPROV at (502) 893-8102 (USR/DS). I am a member of ThrobNet (known as "Al Bundy"). I also call the MSI Support Board on a regular basis. REGISTRATION This door will expire on 09/01/92. That should be sufficient time to see if it will run on your system, and whether it meets your needs. After a reasonable evaluation time, you must either register it, or delete it from use on your system. Registration is $20.00. When you complete the registration form, I will pre-register you on my BBS, and make your registered copy available for you to download when it's ready. Future updates will also 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. Those who register will receive a copy without the expiration routines, and their name and registration number will be included on the initial intro screen. Registered users will also be entitled to any future versions of this program, which will be available for download on my BBS at V.32 & HST speeds (USR/DS). ------------------------------ Tear off Here ---------------------------------- ForceFeed Registration v 3.5 Name:________________________________________ BBS NAME:____________________________________ 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 copy ready for download the next day after I receive this form and your payment. NAME:_____________________________________ PASSWORD:_________________________________ D.O.B:_______/_______/_______ Registration: $20.00 Please check one: Check_____ Money Order_______ Make Payable to: Shawn McGill P.O.Box 6148 Louisville, KY 40207 Thanks for supporting Shareware!