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).