Except as noted below, the OS/2 Version is a direct port of THD ProScan
Version 13.0 [DOS]. All new functions should be operable in BOTH the DOS and
OS/2 Versions.
First and foremost...
I KNOW THE ICONS SUCK!! But I'm no artist. They're there just in case you
want to put them on your desktop. Files (and folders with the registered
version) can be dragged and dropped on the desktop to test them. Oh, and feel
free to send me some better icons if that's your bag.
While the OS/2 version is "basically" a direct port from the existing
source code, the OS/2 compiler does have some things which it handles
differently. While I have tried to account for all of these "quirks", it is
possible that I have missed some of the minor points. So please keep me
informed of problems, Runtime errors and quirks (include as much detail as
possible). If you find anything that doesn't work... Please let me know.
WARP REQUIRED
-------------
Version 13.0+ of THD ProScan requires OS/2 WARP version 3.0 or later.
LONG FILENAME SUPPORT
---------------------
"Officially" speaking... THD does not support Long Filenames. However, a
number of changes have been made to better handle them than previous versions
have. The reason the support is unofficial is because MANY of the things
required for this support were thrown in at the last minute and not well
tested.
If it's any consolation it seems to handle them fine as long as it is
ONLY allowed to use HPFS drives for testing of files. THDPRO.EXE does NOT
check for the presence of HPFS drives for this purpose. While this is
"officially" unsupported feedback is welcome as this is an intended feature
for the future.
If you will be testing files with long filenames then you MUST set your
test drives in order so that HPFS drives occur first on the list (in the
installation portion of THDCFG.EXE).
Despite what may be documented elsewhere, wildcard support was modified
at the last minute to properly match wildcards with more than 1 "." in them
and is no longer restricted to the standard dos 8.3 format. Rules for
wildcards are that no section between periods (".") may contain more than 1
"*" character (ie. "w*.*.*" is valid and "*w*.*.*" is not).
RUNNING THE OS/2 VERSION FROM DOS
---------------------------------
The OS/2 version of THDPRO.EXE "can" be launched from a dos session (under
OS/2). This will allow BBS programs which are native to DOS to spawn an OS/2
session without calling the command processor. The only advantage to this is
so that DOS based BBS programs can perform this action "in the background"
while normal operations of the BBS continue. The disadvantage is that calling
the OS/2 version from a dos based BBS (or other program) will effectively pass
an errorlevel of "0" back to the BBS (or calling program) in literally all
cases. In most cases this will signify to the BBS that the file tests have
passed. There is also the possibility that the child process created by
THDPRO.EXE (or it's companion utilities) may cause the DOS communications to
become less reliable, so test this aspect before using it in this manner with
a DOS based BBS. If this problem exists, use the DOS version(s) so that no
extra process is spawned. Also, THDPRO.EXE will not attempt communications
when run in this fashion from a dos based BBS as it will be unable to control
the comport, so the user output will not be seen remotely, and the BBS will
continue to operate for the user while the file test(s) proceed. Also keep in
mind that a DOS BBS may invoke multiple instances of the THDPRO.EXE window
(one for each uploaded file) which "could" result in some serious slowdowns on
systems with limited resources.
It is "not" recommended to use this approach but is available for those of
you who do have the resources and/or do have alternate ways of handling files
tests which may incorrectly be determined by the BBS as "passed".
*****************
* SCREEN OUTPUT *
*****************
This version introducess redirected screen output for the OS/2 version.
This particular option did cause some problems with early betas and a switch
has been added to the THDOPT environment variable to bypass this redirection
if those problems resurface. If you have persistent problems, try ...
SET THDOPT=DIRECT
to see if that helps to elimate the problem. You can also use this switch if
you simply don't like the redirected output (which holds OS/2 processes to the
lower portion of the screen). Using this switch "may" also speed execution by
a couple of milliseconds per file.
************
* COMPORTS *
************
OS/2 has an "odd" way of handling comports. As a result BBS'es which leave
their comports "open" on a shell will not be accessible by a child process
without some special consideration. (That's not entirely true, as OS/2
actually uses a very sensible approach which is only odd in comparison to the
DOS methods I have become so familiar with.)
OS/2 Users should configure both of the comports in THDINSTL.EXE to "0"
unless your BBS releases the comport upon a shell to THDPRO.EXE (few if any
OS/2 programs would ever do this).
The first (and most reliable) way to inform THDPRO.EXE what file handle
to use for communications is to pass that file handle on the command line by
using the /H# convention (where "#" is the file handle number NOT the comport
number).
In the absence of a file handle being passed on the command line,
THDPRO.EXE is designed to look for the environment variable "THDPORT". The
general idea is that you "SET THDPORT=ENVNAME" where "ENVNAME" is the name of
the environment variable set by the BBS which points to the file handle.
If your BBS does not set such an env variable and is unable to pass the
comport on the command line (then get another BBS), SET THDPORT=DETECT will
cause THDPRO.EXE to "hunt" for an open comport and use the first one found.
The "DETECT" method is generally NOT recommended. It works by "searching"
the open file handles for one with a valid Device Control block with a BPS
rate in excess of 300. While this may work in many cases, there are a number
of cases where it might cause problems. Use this ONLY if there is no other
alternative and monitor the system closely to ensure it's not causing
problems.
****************
* ZIP archives *
****************
- The default support is for DOS' PKZIP/PKUNZIP, however some hooks have
been added in which "should" allow the use of OS/2 "ZIP" and "UNZIP". Note
that the parameters used for OS/2 specific "ZIP" and "UNZIP" are as follows.
The "ZIP" parameters are designed around INFO-ZIP's "ZIP.EXE" v2.0.1. It
may or may not operate correctly with other programmer's "ZIP.EXE" or
possibly other versions.
The "UNZIP" parameters are designed around INFO-ZIP's "UNZIP.EXE" v5.12.
It may or may not operate correctly with other programs or versions (changes
were made in THD ProScan Version 13 for compatibility with v5.20). No special
changes were made to accommodate 5.32 although it appears to work here.
No OS/2 support for "PKZIP OS/2" is present. If the exe files are OS/2
executables, they will treated as INFO-ZIP Programs.
If they are DOS executables, they will be treated as PKZIP/PKUNZIP.
NO COMMENTS will be added to ZIP archives unless the native OS/2 "ZIP.EXE" is
used as redirection is required and not possible with a dos app running under
an OS/2 shell.
****************
* LHA archives *
****************
- The default support for LHA archives is for Peter Fitzsimmons' LH32.EXE
or for the DOS LHA.EXE. If the executable is a DOS file then the dos LHA
parameters are used.
If the archiver is an OS/2 executable, then the parameters for LH32
Version 2.22 is used. This may or may not work correctly for other archivers
or versions.
****************
* RAR archives *
****************
- At last check the command lines for the OS/2 Version of RAR precisely
matched the DOS version so no changes are made for the OS/2 version vs the DOS
version. Although RAR does "allow" some OS/2 only variations of the command
line, THD ProScan does not make use of these features.
*******************
* Other Archivers *
*******************
NO other "OS/2" native archivers are supported.
"Some" archive types may not have their comments stripped during
THDPRO.EXE's normal running due to a redirection problem. Remember though that
other native OS/2 archivers can be added using the External Archive Editor in
THDCFG.EXE.
Anyone who wishes to send newer versions of OS/2 Archivers or archivers not
covered here (OS/2 native apps only) can feel free to send them to me at
1:259/423.0 (Fidonet) or dmuir@idigital.net (internet email). If sending via
Fidonet, please include a small cover letter so I can ask the sysop to attach
them for me. Likewise for native OS/2 Virus scanners.
************
* SCANNERS *
************
SCAN.EXE -
THDPRO.EXE determines if the files is an OS/2 or DOS executable and sends
the appropriate command line for the OS/2 or DOS version of McAfee's Virusscan
Version 2.2.3.
Other internal scanners are supportive of the DOS versions only.
If you have OS/2 versions of other scanners, add them using THDEXARC for
native OS2 support (or take your chances, they just might work with the dos
command lines).