home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 June / SIMTEL_0692.cdr / msdos / dirutl / sf33.arc / README next >
Encoding:
Text File  |  1989-03-30  |  7.4 KB  |  163 lines
  1. Readme file update for Subtree Find 3.3         Thursday  March 30, 1989
  2.  
  3.  
  4. Hilights
  5. ────────
  6.  
  7.     All the changes are listed in the documentation, but let me just
  8. mention a couple of the more important ones:
  9.  
  10.     - network compatibility
  11.     - matching of files inside ARCs and ZIPs by all criteria (not just name)
  12.     - a batch mode for unattended use
  13.     - better memory management, SF now requires less RAM
  14.     - miscellaneous fixes and lots of new minor user configurable settings
  15.  
  16.     Best of all, SF 3.3 only requires 1K more than SF 3.21. Van Buerg's
  17.     ZIP viewer (ZIPV107) requires ~55K RAM, the same as SF 3.3, and it
  18.     only searches ARC files...
  19.  
  20.  
  21.  
  22. Last minute info
  23. ────────────────
  24.  
  25.     I am aware of one flaw in SF: if output is redirected, the file has
  26. CRCRLF sequences at the end of each line instead of CRLF. Turbo C's
  27. console i/o functions do not interpret \n as a CRLF, so I have to force
  28. it to output the CR (\n is interpreted as just a LF). The only way to
  29. 'fix' this is to convert CRCRLF to CRLF via some external program.
  30. Registered users can request a specially compiled version of SF that
  31. only uses redirectable output. No color displays are available, but
  32. it is suitable for use by BBSes without having to convert anything.
  33. If a registered user requests this special compile, a slight fee ($5)
  34. for shipping and handling is required.
  35.  
  36.     A specially compiled version of SF for 286 machines is available
  37. to all registered users for a slight fee ($5) for shipping and handling.
  38.  
  39.     The only files considered .ARC or .ZIP files are those ending in .ARC
  40. or .ZIP. If the file PKZ092.EXE is a .ZIP file, SF will not recognize it
  41. as a .ZIP file and not search inside it. Currently under development...
  42.  
  43.     Regarding .ZIP files: the user should be aware of two things concerning
  44. how Subtree Find searches .ZIP files: ZIPs spanning multiple disks and
  45. how ZIP files are searched.
  46.  
  47.     I have no idea how multiple disk .ZIP files would be searched. Currently,
  48. SF will only search one .ZIP file. As more information becomes available,
  49. I shall try to upgrade Subtree Find.
  50.  
  51.     A .ZIP file is arranged as follows:
  52.  
  53.     [[local_header][...][local_header]] [cetneral_directory] [end_of_central]
  54.  
  55.     SF will search a .ZIP file by the local headers. Why? you may ask.
  56. So damaged .ZIP files can be searched. PKZIP/PKUNZIP 0.92 can not look
  57. inside .ZIP files that have a damaged central_directory. I have heard
  58. that version 1.0 will change that, but for now, a damaged .ZIP file must
  59. be repaired with PKZFIX and then examined. I prefer being able to see
  60. what I do have without having to fix the file first. Future versions
  61. of SF will probably support both methods (searching by local headers or
  62. using the central directory) due to several reasons, but I'd like to keep
  63. memory down. For now, SF searches a .ZIP file from the beginning.
  64.  
  65.  
  66.     Here's the list of valid distributed files:
  67.  
  68.         README           7580   3-30-89
  69.         SF       DOC    80830   3-30-89
  70.         SF       EXE    60762   3-30-89
  71.         SF       GEN      496   3-30-89
  72.         SF       MSG     1131   3-30-89
  73.         SF       PRO      219   3-30-89
  74.         SF       REG     3280   3-30-89
  75.         SF-PIF   DVP      416   3-30-89
  76.         SFPERF   DOC    13974   3-30-89
  77.  
  78.     Yes, I know, some files have no time stamp. It's intentional.
  79.     If the time stamp is 0:00:00 then DIR will display nothing.
  80.  
  81.     SF.MSG is a general overview of Subtree Find 3.3
  82.     SF.PRO is a file description of SF33.ZIP for ProDoor
  83.     SF.GEN is the description of SF 3.3 posted on GEnie
  84.  
  85.  
  86.     Just for the record, the official distribution file is SF321.ZIP. If you
  87. wish to convert this .ZIP file to some other format, you may not add or
  88. remove any files, change any date/time stamps, etc. The distributed files
  89. may NOT be modified in any way, only the method of distribution regarding
  90. compression/archiving/etc.
  91.  
  92.  
  93.       Howard Kapustetin
  94.  
  95.       Author of Subtree Find
  96.  
  97.  
  98.  
  99. A quick note regarding the .ARC format and SEA:
  100. ───────────────────────────────────────────────
  101.  
  102.                                                 December 27, 1988
  103.  
  104.         Recently there has been a great turmoil in the BBS community
  105.     over SEA's insistence that the .ARC format is proprietary, and that
  106.     anyone planning on using the .ARC format must license through them.
  107.     The legality of this has not yet been tested. Unfortunately, where
  108.     there was a standard, we are now seeing confusion and fragmentation.
  109.     Phil Katz, the author of PKPAK and PKUNPAK (previously PKARC and
  110.     PKXARC) is hard at work on a new compression program that supposedly
  111.     will yield greater results than the current .ARC format. Considering
  112.     the talent involved, and the potential upon deviating from SEA's .ARC
  113.     format, I do not find this surprising. The last I heard, his new program
  114.     will be released on IBM micros, the Amiga and Unix, at least. Sadly,
  115.     I have not heard of any potential Macintosh release, but hopefully
  116.     if his program takes off, he will port it over. Since it will have a
  117.     single de/compression engine, and a command line and shell version
  118.     will be released, I have no doubt it will become popular. Especially
  119.     since he plans on making the format public domain.
  120.  
  121.         What does all this mean to me? Well, right now I do not know if
  122.     I am violating any laws by merely looking inside .ARC files. Since
  123.     most word processors can read from other formats, I doubt it, otherwise
  124.     Micropro could sue everyone and his mother for illegally using the
  125.     Wordstar format. When PK announces his new compression scheme,
  126.     I plan on supporting it, since there is very little doubt that his
  127.     new program will be a success. In the meantime, I would be interested
  128.     to learn if other authors of .ARC readers (Keith Graham's Fast [File]
  129.     Finder, to name one) have been contacted by SEA.
  130.  
  131.  
  132.                                                 February 26, 1989
  133.  
  134.         Well, PK has released ZIP and I for one am happy with it. In
  135.     case you can't tell, I plan on supporting the .ZIP file format.
  136.     People have mentioned PAK as an alternative compression program, and
  137.     I have implemented limited support for PAK files. I do not currently
  138.     plan on supporting .PAK any more than I do now, since .PAK files are
  139.     really supersets of .ARC files, and anyone who remembers the heat
  140.     Phil Katz got for inventing Squashing (a slightly improved
  141.     compression method that was not supported by ARC) will realize its
  142.     only a matter of time before SEA gets on NoGate Consulting's
  143.     (authors of PAK) case for bastardizing "their" file format. I will
  144.     not comment on the legal or ethical foundations for any potential
  145.     harassment (litigation, etc.) except to ask two simple questions:
  146.  
  147.     1: If Lotus invented the .WK1 file format, why can Quattro, Excel,
  148.        Harvard Presentation Graphics, etc. read and write .WK1 files?
  149.  
  150.     2: Why doesn't Micropro (authors of Wordstar) sue everyone under the
  151.        sun for "look-and-feel"? (I wouldn't want to hazard a guess as to
  152.        how many programs emulate Wordstar key commands)
  153.  
  154.         I will support ZIP for two very simple reasons: 1) the format
  155.     is Public Domain, and 2) Phil Katz is more interested in improving
  156.     his program to be the very best than suing everyone else out of the
  157.     business.
  158.  
  159.  
  160.     Howard Kapustein
  161.  
  162.     Author of Subtree Find, TCHK and more
  163.