Simtel MSDOS 1992 June

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

/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / opus / fview620.arc / FVIEW.DOC < prev next >

Wrap

Text File | 1989-05-26 | 14.6 KB | 397 lines

FVIEW.EXE Version 6.20 May 26, 1989 Copyright 1989, 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 is an attempt to deal with the proliferation of file archive formats that are coming out right now. 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 and Rahul Dhesi's ZOO files. It will also allow users to list the text in those files online, 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. ***************************************************************** There is nothing "political" about my choices of programs to shell for FVIEW.EXE. My reasons are: 1) Zoo unpacks to the local directory, you can't redirect it. Since FVIEW has to reside in the directory where all your SYSTEM*.BBS files are, and USER.BBS is probably there, unpacking files to this directory would be terrible. FVIEW always deletes the files it unpacks after the user reads them, but you can see how this would be a problem. If you know how to get ZOO.EXE to unpack to another directory, send my Email to explain it and I'll add ZOO handling. 2)NoGate's PAK.EXE will unpack any SEA<tm>'s ARC<tm> files, but SEA<tm>'s ARC<tm> can't unpack all the files created by NoGate's PAK program. FVIEW reads the file headers to find out which unpacker to use, it doesn't look at file names, and both SEA<tm> and NoGate use the same file header so I can't tell them apart until you actually get to the point where you'd get an error message about an unrecognized packing method. 3)The only other MS-DOS archive format I know of is Dean Cooper's DWC, however, I don't see any DWC files floating around so I didn't think it was worth putting in. If you use DWC files, send Email and I can fix up a special version for you. 4)There are other operating system archiving systems, however no one has ever been able to explain what the file format is like. If anyone ever sends my some documentation on them, I'll try to add them. ** Opus 1.03 does NOT pass any parameters to the program. All the ** hard-coded sections have to be used. FVIEW MUST be in the same ** directory as your SYSTEM*.BBS files! The command line options are very simple: -Bbaud# (Supplied by Opus) -Ttask# (Supplied by Opus) -Pport# (Supplied by Opus) -LFview_Log Shows user activity. DO NOT INCLUDE THE EXTENSION!! -W Use FOSSIL watchdog. -DTemp_path Path where unarchived files will go. -SSystem_Path Path to SYSTEM*.BBS and LASTUS*.BBS. -N Don't allow users to read files online. -G Extended debugging to LOG file. The defaults are: Task 1 Port 0 Baud 2400 Log FVIEW Running Opus 1.10 beta/gamma C:\Dearc\ as the temporary path. 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. 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 running 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 shelling the appropriate program, and then the files are deleted as soon as the user is done listing them. That's why you can use wildcards when listing the members of archives, but not when picking which text file to list. The default is C:\DEARC\. THIS MUST BE A BLANK DIRECTORY FOR YOUR SAFETY!! FVIEW will over-write 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\member) from (Source file). This was done to prevent any collisions among multi-line systems. In my control file, all I have is: _OUTSIDE Disgrace "Kontents" = RUN C:\Opus\Fview.Exe -dc:\dearc\ Opus automatically provides the rest of the command options, and actually, since I use the default C:\DEARC\, I don't need even that one the command line. 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. If a user drops carrier, FVIEW returns to Opus, unless you've used the "-W" option to turn on the FOSSIL Watchdog. If you'd like to send questions, comments, improvements, code, contributions or whatever, I can be reached any of the following ways. 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 Hexadecimal 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" statement 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 backspaces 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, primarily 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 overlays. 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. 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 hardware resources are also limited. (Want color? Send EGA. :-) Want more mult-user operations? Send machine/memory/multi-tasker/modems...) Want some spiffy new feature? Send code. Thank You.