Contents of the FVIEW.DOC file
March 2, 1989
Copyright 1989, Doug Boone
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 ARC 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 ARC compatible or
PKZIP files. PAK.EXE and PKZIP.EXE are hard-coded as the
unpackers so they must be available in the PATH for this program
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's ARC files,
but SEA's ARC 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 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
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
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:
-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:
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.
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
(916) 893-9019 (data)
(916) 891-0748 (voice)
P.O. Box 5108, Chico, CA, 95928
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
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 paramaters to FVIEW so don't use this with 1.03. Instead
keep FVIEW.EXE in the same directory as your SYSTEM*.BBS files
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.