ftp.wwiv.com

home *** CD-ROM | disk | FTP | other *** search

/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / UTILITY / FVIEW736.ARJ / FVIEW.DOC < prev next >

Wrap

Text File | 1990-03-04 | 26KB | 735 lines

FVIEW.EXE Version 7.36 March 4, 1990 Copyright 1989, 1990, Doug Boone ************************************************************************ FVIEW is not for sale. If you'd like to make a _voluntary_ donation to the author, please do. FVIEW is not to be included in any commercial package, nor can you charge anyone anything for distribution. Not disk prices, not access fees to your BBS, not no nothing not no nohow. If you paid someone for this program, both you and I were ripped off, so let's get together and go get the person who sold it to you! ************************************************************************ This program was originally an attempt to deal with the proliferation of file archive formats that came out after the SEA/PKWARE lawsuit. It provides a listing of the contents of SEA <tm> ARC <tm> files, PKWARE's ZIP files, NoGate's PAK files, Dean Cooper's DWC files, Rahul Dhesi's ZOO files and Hauyasu Yoshizaki's LZH file. (Whew!) It also will allow users to list the text in those files on-line, provided the files are SEA <tm> ARC <tm> compatible or PKZIP files or LZH files. All the unpacking is handled internally, so you don't have to have any special programs available. This program is designed to be run from the Opus files menu. There is no need to provide it with any sort of "watchdog" or redirection, those are handled internally. If a user hangs up, FVIEW will exit and return control to Opus, which means that FVIEW won't "crash" multi-taskers if a user hangs up. All its input/output is handled through the FOSSIL if run remotely (and copied to the console) or directly from the console if run from the keyboard. To set FVIEW.EXE up: Copy FVIEW.EXE to the directory where Opus.Exe and the Sys- tem.BBS files are stored. Create a directory to hold the temporary text files that users will be reading on-line. Since FVIEW will be unpacking files to this directory, it definiately should ONLY be used for this purpose, otherwise a user might unarchive a file with an identical name and wipe out your file. The default directory name is C:\DEARC. With Opus 1.03b: Find the line in OPUS.CTL file that says: % External File_Management and change it to: External File_Management C:\Opus\Fview.Exe Recompile the OPUS.CTL file to OPUS.PRM. Edit the FILEPRIV.BBS menu file to change the Out- side option to something more appropriate like "Kontents" or "View" and set the privilege level to something your users can access. If you are NOT going to use the defaults listed later, or need to make some other modifications, you'll need to modify either the sample FVIEW.CFG file or your Autoexec.Bat file to add a "Set FVIEW=" variable to it. You do not "need" either the con- figuration file or to use a special environment statement if the defaults are acceptable, and you only need one or the other, not both. Opus 1.03b only passes along a single set of com- mand-line options to external programs. They are: -K Running from Keyboard, not from Modem. -B#### The baud rate of the connection. -P# The zero-based Port connection. -FVIEW.CTL The name of a control file that Opus generates when external programs are run. This parameter is used in two ways. First, just its presence tells FVIEW that Opus 1.03 is running THIS IS VE- RY IMPORTANT! Second, if you are running Opus with some Task number set, the "W" will be re- placed with the active task num- ber. With Opus 1.10: Edit FILE_MENU section of your OPUS.CTL file to include a line like: _OUTSIDE Disgrace "Kontents" = RUN C:\Opus\Fview.Exe Since Opus 1.10 allows you a lot of freedom to your menus, there's no need to put the command in any particular place, nor will there be any problem because you've added a new choice. You can add as many as needed. Unlike Opus 1.03b, Opus 1.10 will pass command-line options to external programs, and the active Task number is passed as a separate parameter. There is no FVIEW.CTL file generated by Opus. COMMAND LINE OPTIONS: These modify the way FVIEW works and can be added either to the command line (for Opus 1.10, external menu programs) or through the DOS environ- ment. If you're going to use the DOS environment, just add: Set Fview=<Your options go here> The command line options are very simple: -Bbaud# (Supplied by Opus) -Ttask# (Supplied by Opus 1.10) -Pport# (Supplied by Opus Com1: = Port 0) -LFview_Log Shows user activity. DO NOT INCLUDE THE EXTENSION!! -W Use FOSSIL watchdog. -DTemp_path Path where unarchived files will go. Default is "- C:\DEARC" -SSystem_Path Path to SYSTEM*.BBS and LASTUS*.BBS. -ULastUser_Path Path to Lastuser.bbs if it isn't in the local direc- tory. -NV Don't allow users to read files online. -NR Don't allow users to use the R)aw directory. -NF Don't allow users to do a F)iles command. -G Extended debugging to LOG file. -Otime Number of minutes to allow users to use FVIEW (de- fault = 5 minutes) -0 Using Opus 1.03b. This affects the file names in- volved! Remember: These ONLY apply to Opus 1.10 or to an external menu program. If you run Opus 1.03b with an external menu program and want to hook FVIEW.EXE to it, remember that you MUST include the "-FVIEW.CTL" para- meter so FVIEW will know its working with Opus 1.03b, or you must use "Set FVIEW=-0 -T#" in the environment (and supply the baud and port numbers via command line!), or uncomment the "OLD_OPUS" and "TASK" numbers in the configuration files. The defaults are: Task 1 Port 0 Baud 2400 Log FVIEW Running Opus 1.10 beta/gamma C:\Dearc\ as the temporary path. Except for the "-W" and the "-DTemp_path", Opus will automatically provide these when it runs the program, so I suggest you DON'T include them. If you include the Port# or the Baud#, FVIEW will think its run- ning remotely and will exit if you're running it from keyboard because it will detect that there's no carrier. Regarding "-DTemp_path": --------- -------------- This is where unarchived files for users to read will go. They are created by FVIEW, and then the files are deleted as soon as the user is done listing them. The default is C:\DEARC\. THIS MUST BE A BLANK DIRECTORY FOR YOUR SAFETY!! FVIEW will overwrite any existing files with the same name. If your task number is greater than 1, FVIEW will unpack files to a sub-directory of the Temp_Path named after the task. For example, if you use C:\Dearc as your temp_path and a user is on Task 4, Fview will unpack the temporary files to C:\Dearc\04\. If that directory does not exist the log will show an error message, ERROR Reading (temp_dir\mem- ber) from (Source file). This was done to prevent any collisions among multi-line systems. Regarding "Set PENGUIN=MY.CFG" This is an effort to deal with the fact that every program seems to need its own configuration file. I've decided that all the programs I'm maintaining will be able to use ONE configuration file, although I'm leaving the possibility to use seperate configuration files for each program. If you're using Opus-Fam 0.56+, the MLUPD.COM dated July 26, 1989, or FVIEW 7.25+, you can put "SET PENGUIN=SOME.CFG" into your Autoexec.Bat file and all three programs will look for "SOME.CFG" in- stead of their individual configuration files. If you choose to use this method, see PENGUIN.CFG included with this archive file for more information on how to use it, but basically you need to change your configuration file to include "begin fview" before the information that FVIEW.EXE will use, and "end fview" at the end of the information FVIEW.EXE will use. FVIEW.EXE will only read the lines that are between the "begin" and the "end", you can have multiple "be- gin" and "end" lines in the same file, and the "begin" and "end" for different programs can be interlaced. Users will only get 5 minutes to use FVIEW, then the next time they hit a menu or a More? prompt, FVIEW will exit and return to Opus. Of course if you've used the "-o##" command-line option, or either configuration file or the environment control, the users will receive access to FVIEW for the amount of time you've stated. For information on how to use the configuration file, read the supplied sample FVIEW.CFG file. When Fview.Exe is run, it will get its commands from: 1: The default settings. 2: The command line. 3: The FVIEW.CFG file. 4: DOS environment. This means that you can put in a temporary change (Like turning the full Debugging Log on!) by using the DOS environment and it will take prec- edence over anything else you've done. How much Memory is "Enough"? Versions of FVIEW.EXE 7.10 and 7.20 were largely re-worked to make them live in less memory. With a 280k DoubleDOS window, I could list ANY type of archive contents, and expand text from LZH and ZIP files. However, at that small amount of free memory (17k!) PAK and ARC files won't expand. I would guess that 280k is probably the lower limit if you don't carry any ARC/PAK files. If you want to be able to list ALL archive formats, you'll probably need 320k in the window that Opus/Fview runs in. The ERRORLEVEL of the exits are: 0 Normal, no problems 1 Can't find LASTUSER.BBS file. 2 Can't find SYSTEM*.BBS file. 3 User dropped carrier. 4 Memory allocation failure. Not enough free memory. If you'd like to send questions, comments, improvements, code, contri- butions or whatever, I can be reached any of the following ways. If you have problems, be sure to run the program at least once with the full Debugging log ON so you can tell me what information it was showing. Doug Boone 119/5 (916) 893-9019 (data) (916) 891-0748 (voice) P.O. Box 5108, Chico, CA, 95928 2-23-89 01.01 Fixups to make this program work with Opus 1.03. Got out of touch with how 1.03 works. It doesn't pass any control line parameters to the running program except the baud/port and a control file name. The task number has to be picked out of the name of the control file. That means that you can't change the name of the log file, whether or not users can read files online, or the directory where files are unpacked for users to read if you run Opus 1.03b. Sorry about that. March 2, 1989 Fixed bug with Opus 1.03 systems and areas > 9. Opus 1.10 uses Hexadeci- mal area numbers and FVIEW was too. Now it switches to decimal when it knows that its working with Opus 1.03b. Also added the ability to handle wildcards inside archives, so that a user doesn't have to have an exact match for a file name. However, I've only figured out how to handle '*'-type wildcards, no '?' wild-card matching has been added yet. I'll work on that next, but I wanted to get this released to fix the problem with hexadecimal area numbers. There are some other (I think) nice additions, but they're too complicated to explain. Try it and see. March 2, 1989 (3.10) Added ^S checking. Any key after a ^S will start FVIEW going again. Added more carrier checks in case user hangs up while in some intense searches. Added -SSystem_Path to command line. Should make it possible to run FVIEW from directories other than where the SYSTEM*.BBS files are in Opus 1.10. Opus 1.03 does NOT pass any parameters to FVIEW so don't use this with 1.03. Instead keep FVIEW.EXE in the same directory as your SYSTEM*.BBS files are in. March 8, 1989 (4.00) Added support for configuration file, FVIEW.CFG. FVIEW.EXE is hardcoded for that name. If you don't like the default configuration of FVIEW and are using Opus 1.03b, you can now use the CFG file to stick in what would be on the command line for 1.10. Check out the CFG file for more information. March 9, 1989 (4.10,4.20) Added environment support. Opus 1.03b users can now use a "SET" state- ment in their autoexec.bat file to handle most (except for baud, task, and port) of the command line options without any command-line options or configuration file. Just add something like this to your autoexec.- bat: Set fview=-dd:\dearc -g (Use d:\dearc for temporary storage while users read text from archives, full debugging information logged. Remember not to leave any spaces before or after the '=' sign!) The order of precedence when running fview is: 1) Environment 2) Config file 3) Command line. That is, the command line is read, then if a configuration file exists it is read, and then if there's a "FVIEW" in the environment, that will be read. March 29, 1989 (4.30) Increased the number of files that you can view out of one archive to 256. Hopefully no one's going to exceed that! If you run out, it still should be safe, earlier versions were doing weird things if the count they used (64) was exceeded. (Thanks to Glen Strecker (390/2) and John Souvestre (390/101) for pointing out the trouble.) April 13, 1989 (5.00) Added support for LZH (Lharc.Exe) files. I don't know how popular these are or will be, but FVIEW can list the contents of them now. However, Lharc is another program that only puts the contents of the archive in the local directory. Also fixed a bug in the validation of file names. May 8, 1989 (5.10) Changed the start-up code so only users with NOVICE help levels have to go through the opening help screen. The help screen is available to everyone by typing in a "?" or "H" or "HELP" to any prompt. Cleaned up the section that gets a string from the user so it will handle back- spaces better. May 17, 1989 (6.00) Added code (UNZIP.C by Samuel H. Smith) to get past the problem of users embedding ANSI commands inside ZIP archive comment fields. Since PKUNZIP is no longer being called, the comment is never unpacked, there won't be any danger. Also have added code to handle PAK/ARC files. Pretty good, only adds 10k of EXE space. Also, I'm not really thrilled with the UNZIP code, so I'll be working on something else, using UNZIP.C was just a quick, temporary solution. (It should also allow you to operate in less memory with ZIP files, as we aren't shelling yet another program. Anyone got any GOOD source code (not SEA's stuff) for unpacking ARC- style archives? I cheated and used the stuff from NoGate Consulting, but it would be much nicer if it included ALL the source here. Check the MAKEFILE files for information on how to compile this program without the GROW.OBJ, UTILITY.OBJ and COMPRESS.H files from NoGate Consulting. Now to go after ZOO and LZH! May 26, 1989 Version (6.20) Added code to unpack LZH files created by LHARC.EXE and display them. HOWEVER! The price for that was that FVIEW.EXE doubled in size, pri- marily because it went marginally over the 64k limit of a Compact model code segment, so I stayed with the Compact model, changed to Microsoft C, and used overlays. Unfortunately Borland's Tlink.Exe won't do over- lays. Gripe gripe gripe. FVIEW.EXE shouldn't need any extra memory, I hope. Maybe if I could go through some of the de-archiving code and clean it up...... ZOO looks really ugly. June 14, 1989 Version (6.25) Cleaned up the log file, should be neater looking. Added a command to set the user's time limit. From the command line (which only applies to Opus 1.10 at this time), or in the environment its "-Otime", in the configuration file its "ONLINE time". June 25, 1989 Version 7.00 Major re-write of the source code. Adding the source code to unpack LZH archives had expanded FVIEW.EXE to the point where I had to use Micro- soft's C 5.10 compiler, with overlays. This created a strange situation where the executable program suddenly doubled in size. I've re-organized the program extensively to use a linked list of archive members instead of a fixed array. Not only could I go back to using Borland's Turbo C, but the program went back to 48k! (Its still over 100k if compiled with Microsoft C, even though overlays are no longer needed.) FVIEW should be able to handle memory problems better, more error-checking takes place. I'll be interested in finding out if some of the problems users have been reporting with FVIEW/DoubleDOS go away in this version. June 30, 1989 Version 7.10 FVIEW _seems_ to be working properly under DoubleDOS, at least to me it does, and that's all I can gurantee. I'm using X00.SYS for the FOSSIL with the baud locked at 19200 for a HST. I had to run CAPTURE.COM after loading DoubleDOS and before loading Opus. Other than that, this version just fixes up some minor bugs (like put- ting totals in the wrong column) and adds the special environment/con- figuration file options for Opus 1.03b. Those are a special switch to tell FVIEW that you're running Opus 1.03b ("-0" on the command line or in the environment, or "OLD_OPUS" in the configuration file) and, if you use this method, the task number involved, ("-T#" on the command line or in the environment and "Task #" in the configuration file). July 2, 1989 Version 7.20 Rewrote the sections that expand text online to use less memory for multitaskers. If you don't have ANY ARC/PAK files for users, you can probably run with 280k of memory for Opus/Fview. If you want to be able to display ARC/PAK files, then you'll need about 320k of memory. July 17, 1989 Version 7.21 Added the -U variable to find LastUser.BBS if it isn't in the local directory or the same as where the SYSTEM*.BBS files are. Fixed a couple of minor cosmetics. Made sure Help worked from all menues. July 25, 1989 Version 7.22 Fixed bug in unzipping files. As reported by Lou Pascazi in the MEADOW, FVIEW 7.21 was having a problem with unpacking very, very small files that weren't compressed out of ZIP files. This was caused by a bug where I was sending the size of the memory buffer available, not the size of the file that was to be unpacked to the routine that handled this spe- cial case. Major Oops! Thanks Lou for showing me the problem. July 26, 1989 Version 7.25 Added F)ile and R)aw Directory listing for online users. They can now use R)aw and F)iles just like in Opus, with pattern matching and file searches. BUT when using the F)iles listing, ONLY the lines that actual- ly have a file in them will be displayed. No comment or "MISSING" lines will be displayed. Also added the "PENGUIN" environment variable. This will allow you to combine different configuration files together into one single file, saving you disk space (less wasted sectors) and easier to maintain as shared information can all be changed in a single file. August 9, 1989 Version 7.26 Added switches to configuration file to turn off the R)aw and F)iles commands, the default is "on" for both. Before you start complaining, Opus 1.03b and Opus 1.10 have different user privilege levels. I am not allowed to release source code for Opus 1.10 utilities until Opus 1.10 is released, including the code to read the different privilege levels. So R)aw and F)iles are either "on" or "off", individually. Also added a command to look for a file called "DESCRIBE" inside ar- chives. The purpose of this file is pretty obvious, it will describe what the file is for, what it does, and so on. Its an attempt at a standardized name for "READ.ME" files to give users a _short_ preview of what they're considering downloading. To use it, a user just types in: "D filename" or "Describe filename" Wildcards are allowed, and FVIEW will search "filename" for a file called "DESCRIBE", unpack it, and display it to the user. Also re-built the FOSSIL section to use X00.SYS versions 1.20+ with DesqView. Ray Gwinn is trying to get around DesqView's grabbing Int 14h, FVIEW should now work with either Int 14h if X00.SYS isn't loaded, or with X00.SYS if its taken over. (Still no support for PAK 2.0's new packing method, waiting to hear from NoGate Consulting.) August 10, 1989 Version 7.27 Added code to turn of F)iles and R)aw from environment and command line. August 22, 1989 Version 7.28 Fixed problem with FVIEW and Double DOS. Its a bit involved, but in- volved altering the startup code for Turbo C. Got it working. Also there are two versions of FVIEW.EXE included. One is smaller, 51k, and the other is more than twice as large. The big one, FVIEWPAK.EXE supports PAK 2.0's "distill" method. No answer yet from NoGate why it makes FVIEW so huge. Use whichever you feel is appropriate. September 9, 1989 Version 7.29 Returned to shelling to unpack ZIP, PAK and ARC files. Fixed bug in LZH (LZH still is handled internally) routine when handling document files larger that 32k. You again need PKUNZIP.EXE and PAK.EXE in the path. This might make memory problems tighter, but it gets around trying to keep up with archive format updates. October 29, 1989 Version 7.30 Fixed spawning PAK.EXE to work right, had the command line wrong. Fixed the F)iles listing to be more like what Opus uses, and the FVIEW.LOG file is formatted almost exactly like the Opus log file. The only dif- ference is that since the word "FVIEW" is wider than the word "OPUS", the actual comment is off by one space. Karma. November 24, 1989 Version 7.34 This version will only work with Opus beta version 18+. It knows about the new user record, the new SYSTEM*.BBS, and it will write out a dumb line that says: "Used FVIEW on mon day time". Its just a quick demon- stration of an external program being able to store information in the user record. If you want to play with it you have to turn on the "return secure" in your PRM file, any value > 0 and Opus will store the modified user record. Its just a gimmick in FVIEW that'll be removed later, but someone might find it useful.... January 1, 1990 Version 7.35 Fixed to work with Opus 1.03b and Opus 1.10.1c March 4, 1990 Version 7.36 Fixed FVIEW to do a screen clear if HITECH help is on. Removed code to alter LASTUSER.DAT files in 1.10. It was just there for test purposes. NOTE: ----- I have never received any reward for programming Opus/FidoNet utilities except for the friendship and respect of many people inside FidoNet. I am not asking for anything other than that. But you should realize that I am now trying to maintain over a dozen programs for the Opus Sysop, plus my responsibilities to the MEADOW, Opus 1.10, and so on. The amount of time I can devote to this or any other program isn't that great, and the resources are also limited. (Want some special multi-user oper- ations? Send machine/memory/multitasker/modems...) Want some spiffy new feature? Send code. <tm Wynn Wagner III> Thank You.