ZipTV version history

---------------------------------------------------------------------------
Revision History
---------------------------------------------------------------------------

2010.08.16 Revision(s)

1. Component(s) affected: TZipRun
Source unit: ztvZipRun
Demo Application: [ziptv install directory]\demos\maindemo\maindemo.dpr
Delphi palette tab: "ZTV Tools"
Delphi support: currently 2009+ (not necessary in versions prior to
Delphi 2009)

TZipRun has the functionality to extract a single file, a range of filenames,
range of files based on a file extension, or all files in the archive.
Applications that are compressed to an archive generally will also include
additional files necessary for the application to function property.
Therefore, for the application to run properly requires it’s support files to
also be extracted.

TZipRun1.Execute(ActionFile: String); The compressed filename that was being
passed via the Execute method’s ActionFile parameter was internally being
changed to the name of the last extracted file during the extraction process.
Fixed.

2010.08.15 Revision(s)

1. Component(s) affected: All
Delphi support:: all versions

Property editors have been updated to simplify editing of property values
in the Object Insector.

2. Component(s) affected: components inheriting TUnZip
Delphi Support: all verisons
Source unit: ztvUnzip.pas, ztvPPMDi1.pas
Demo Application: [ziptv install directory]\demos\maindemo\maindemo.dpr

PPMD was updated to include split archives.

3. Minor bug fixes.

2010.08.10 Revision(s)

1. Component(s) affected: TMakeSFX
Source unit: ztvMakeSfx.pas
Delphi Demo Application: [install]\demos\sfx\MakeSfx\MakeSfx.dpr
Delphi palette tab: "ZTV Tools"
Delphi support: currently 2009+ (revision for Delphi 5 thru 2007
expected soon)

The TMakeSFX component was originally designed to handle ZipTV’s SFX stub
files. It now supports 3rd party SFX stub files.

2010.04.08 Revision(s)

In a prior release, a bug-fix was included which related to the string value of
the extracted files being assigned to some Windows API functions that are used
in this component. The selected files were extracted ok, but the API functions
sometimes failed in finding the extracted files, when the length of
path\filename.exe was uncommonly long and included space characters. The prior
fix was to enclose the API lpParameters string field within quotation marks.
The API functions were then able to locate and execute the files properly.
However, the fix had the reverse effect when the value of TZipRun's OpenMethod
property was set as omOpenWith. The quotation marks have been removed (only
when OpenMethod=omOpenWith) and the Windows OpenWith dialog is displaying
normally again.

2010.04.06 Revision(s)

1. TZipTV_Clipboard: (new component)
The functionality to compress/decompress data streams to/from the Windows clipboard
has been in ZipTV for some time now; however, it was hard to understand and somewhat
difficult to use.

The code necessary to perform this funtionality is now compartmentalized into a single,
easy to understand and easy to use component.

Purpose: compress/decompress streams to/from Windows clipboard
Source unit: ztvClipboard.pas
Demo Application: [ziptv install directory]\demos\clipboard\clipboard.dpr
Delphi palette tab: "ZTV Tools"
Delphi support: all versions supported by ZipTV

We searched the internet for information regarding clipboard size limitations and have
been unable to conclude a specific limitation. It seems to depend on the Windows version
running, number of applications running, as well as space absorbed by other clipboard data
stored in other clipboard formats (available system memory). Some articles have claimed
the limit under some versions of Windows to be 64k (65536 bytes). Whatever the limitations,
it is up to the developer using this component, to include application level error trapping
in case a limitation is exceeded.

A clipboard limitation makes this a very attractive component to overcome many issues
associated with the size limitation. In our tests of this component using text streams,
compression ratios varied somewhere between the 90% to 98% range. Assuming the 90% ratio
(low end range), and compressing a text stream the size of 65536 bytes (64k), the
resulting compressed stream size (placed in the clipboard) would be 6553.6 bytes (6.4k).
Assuming this scenario, the clipboard limitation using this component has expanded the
65,536 byte (64k) limitation to a new limitation of over 655,360 bytes (640k).

We now use this component in many of our personal development projects as a layer between
clipboard copy & paste operations. We have used the functionality (in object form) for
quite a while now, so the technology is not new, unchartered, and untested.

Speed issues: since the use of clipboard operations always relate to a limited amount of
data, the time required to compress/decompression to/from the clipboard is generally not
noticeable.

2010.04.03 Revision(s)

1. TZipRun: there was a bug introduced due to in the following v2010.03.29 revision.
The AppendDirTail function in ztvGbls.pas was previously revised to use a Delphi
function to append a trailing directory character to a path name. If the string
passed to this function is null, Delphi's IncludeTrailingPathDelimiter(..) function
returns the path-delimiter as it's value. This is not the desired result. If the
string passed is null, the resulting value of the AppendDirTail function should
also be null.

Change the following function in ztvGbls.pas:
Function AppendDirTail(Path: _String): _String;
Begin
Result := SysUtils.IncludeTrailingPathDelimiter(Path)
End;

Change to
Function AppendDirTail(Path: _String): _String;
Begin
If Path <> '' Then
Result := SysUtils.IncludeTrailingPathDelimiter(Path)
Else
Result := '';
End;

2010.03.29 Revision(s)

1. Maintenance release related to all compressor/components. Upgraded to handle
characters in [UNC-path or drive]\dir\filename.ext that are not allowable
characters under the Windows OS. The greatest percentage of illegal characters
we found, were the result of the archive being compressed under other OS’s, but
many were found to have been created with archive applications that did not
include basic error checking before writing the filename. One example:
TDS:JRWS Vol.2\test.txt.

2010.03.22 Revision(s)

1. All components: upgrade of the FileSpec & RecurseDirs property. Refer to
www.ziptv.com\filespec_property.html for a more detailed description and
examples on narrowing the range of files to be viewed, compressed, or extracted.

2010.01.12 Revision(s)

1. PPMD compression/decompression: original release as non-beta. No known issues
remaining.

2. Maintenance release.

3. 7zip components still considered beta as support has not been added to all ZipTV
tool components.

2009.12.21 Revision(s)

1. PPMD compression: corrected issue of compatibility with other utilities when
compressed using PPMD and encrypted using AES (American Encryption Standard).
Only compression components supporting Delphi, that includes support for the
PPMD algorithm.

2. TArchiveSplitter and TZipSplit: when splitting .zip archives, ZipTV was
returning error 25215 (error opening file). Corrected.

3. TZipRun: unable to run/view a compressed file that was AES password encrypted.
Corrected.

4. TZipRun: added callback assignment of passwords TStringList property to prevent
having the OnGetPassword event from activating and requesting a password with
each attempt to view/run files within the same archive. Once the password is
entered, the same password will not be required again until the archive is closed.

2009.11.24 Revision(s)

1. BETA RELEASE – PPMD compression & decompression for Zip files. Although a
slightly bit slower than other compression algorithms in the ZIP format, PPMD
at times offers very impressive compression ratios, especially when compressing
text files. The original C++ source code for PPMD were obtained from
http://www.compression.ru/ds/.

2009.7.28 Revision(s)

1. TFindFile: when the RecurseNestedArchives boolean property is true, the
ParentArchive string property use to return only the topmost archive name in
which filename resides. ParentArchive now returns the fully qualified archive
hierarchy in which filename exists. Example: If myfile.txt exists in testc.zip,
testc.zip exists in testb.zip, testb.zip exists in testa.zip ParentArchive will
now return testa.zip\testb.zip\testc.zip\ instead of just the topmost archive
name testa.zip.

2009.6.16 Revision(s)

1. TUnSevenZip: added support for the UseStoredDirs and CreateStoredDirs properties.

o UseStoredDirs:
The ExtractDir property is a string property that specifies the directory in which
the extracted files are to be written. The UseStoredDirs is a boolean property that
specifies if ZipTV should use the directory that is stored in the compressed files
header, if it exists.

The following examples assume a 7-zip archive containing the following compressed
files:

font\arial.ttf
font\arialdb.ttf
font\cour.ttf

Example #1:
ExtractDir := ‘c:\myarchives’
UseStoredDirs := True;

The compressed .ttf files will be extracted to directory c:\myarchives\font, as
defined by the UseStoredDirs property.

Example #2:
ExtractDir := ‘c:\myarchives’
UseStoredDirs := False;

The compressed .ttf files will be extracted to directory c:\myarchives. Notice
the “font” directory name stored with the compressed filename (font\arial.ttf)
has been removed and the files were extracted to the directory specified in the
value of the ExtractDir property.

o CreateStoredDirs:
CreateStoredDirs is also a boolean property that handles directories that are
stored in a 7-zip archive separate from a compressed file. A stored directory
includes a file header much like a compressed file. Unlike a compressed file that
can include both the path\filename, a stored directory contains only the name of a
directory. A stored directory name will never include a filename.

Consider a 7-zip archive containing the following files:

font\arial.ttf
font\arialdb.ttf
font\cour.ttf
font\
myfonts\

The last two name listings are directories stored in the archive. If
CreateStoredDirs = true, the directory will be recreated upon extraction of the archive,
even if there are no files to be extracted to directory (note the myfonts directory).
If CreateStoredDirs = false, the stored directories will not be recreated.

One thing to consider: refer back to the above Example #2. The files are extracted
to c:\myarchives in this example. Using that example combined with
CreateStoredDirs = true, the “font” and “myfonts” directories will be created with no
files extracted to either directory.

2009.6.15 Revision(s)

1. Support for 7-zip multi-volume added in all components now supporting the 7-zip
format.

2. The OnGetPassword event was installed in the TUnSevenZip and TZipCheck components
for password protected 7-zip archives.

3. The 7-zip format does not store a compressed file’s PackedSize when a file in a
7zip archive was not able to be compressed smaller than the original file. This
issue results in a blank value under the PackedSize column when attempting to
display the value of the PackedSize variable. Developers have requested that
when this condition exists, the value of the PackedSize variable be assigned the
value of the UnpackedSize, which is the true value.

2009.6.11 Revision(s)

1. Support for 7-zip archives are now supported in the ZipTV version for Delphi
2009+. The following components also include multi-volume support.

2. The following components have been updated and/or added for 7-zip support:
o TZipTV: (updated) retrieve 7-zip compressed file information.
o TUnSevenZip: (new) extract compressed 7-zip files.
o TZipCheck: (updated) perform a validity test on the compressed files.
o TZipSplitGlue: (updated) join 7-zip multi-volumes into a single archive.

3. New dll:
o ztv7z.dll

4. New source files
o ztvUn7zip.pas
o ztvJclCompression.pas
o ztvSevenZip.pas

2009.5.4 Revision(s)

1. TUnBZip
Source unit: ztvunbzip.pas
Procedure: _Extract(..)

Applies to all versions of ZipTV

Change:
ActualFilename := SysUtils.ExtractFileName(ArchiveFile);

To:
ActualFilename := Trim(SysUtils.ExtractFileName(ArchiveFile));

Delphi's ExtractFileName function incorrectly copies the null character located
at the end of the ArchiveFile property string, resulting in an incorrect false
result when comparing file extensions in the code following this line.

2009.4.14 Revision(s)

1. TArchiveSplitter: the archive was being created correctly; however, during
the splitting process, filenames were being written as double-byte character
strings. This issue affected ZipTV for Delphi versions 5 thru 2007 when
using the TNT_UNICODE conditional define. ZipTV for 2009 version was not
affected.

2009.1.1 Revision(s)

1. Beta version. Original release of ZipTV for Delphi 2009 with native
unicode support.

Thousands of archives have been tested and revisions included when
appropriate. ZipTV for Delphi 2009 is not backward compatible with any
prior versions of Delphi; however, we plan on continuing upgrades and
support for those versions as well. Even though prior versions of ZipTV
included support for unicode (via a conversion layer provided by the use of
a 3rd party unicode package), we strongly recommend ZipTV for Delphi 2009
for unicode support.

2008.12.13 Revision(s)

1. Included support for the proper reading and extraction of unicode
filenames stored in zip files that use extended headers as a method
of providing support for unicode filenames. Utility applications that
use this method, first write the ansi-string form of the filename to
the header, UTF8 encode it, and then write the UTF8 encoded string
value to an extended header. This method results in the writing of
one filename to a zip file four times.

There are many problems with this method. The first is the writing of
a filename four times as previously mentioned. With that in mind, if
it is determined that UTF8 encoding is required, reconstruction of the
stored ansi-string value is generally not possible anyway, so what is
the purpose of writing it to the archive? Another is that most utility
applications compressing files using this method, bypass the ansi-string
stored value and instead, read the UTF8 encoded string from the extended
header, providing no access to the stored ansi-string value - again,
what's the purpose of writing the filename four times? The zip format is
the only archive format that supports extended headers; therefore,
uniformity of unicode filename support across all supported archive formats
cannot be achieved.

The zip format contains three header types. The local header, central
header, and ending header. Filenames have always been written to a zip
archive, two times. Once in the local header and once in the central header.
With the use of an extended header to support unicode, one filename is
written to the archive four times, twice in the local header and twice in
the central header. Consider an archive containing a thousand compressed
files, a single filename has the capacity to hold up to 256 single byte
characters, and each filename stored four times.

There are three points here. Consideration for unicode in archives exists
only in the archive's compressed filenames. Compression algorithms remain
heavily byte oriented, so the compressed data will always be reconstructed
back to it's exact original decompressed state. Storing the ansi-string
version of the filename is wasted space because when an extended header flag
signals a UTF8 encoded filename, the stored ansi-string version of the
filename is bypassed, and the UTF8 encoded string value is used. Therefore,
if our default UTF8 encoding method fails, so will the method of using
extended headers. Second, the use of UTF8 encoding of filenames as the
default in ZipTV, is universal in all archive formats supported. Only zip
headers support extended headers; therefore, the method of supporting
unicode with the use of extended headers is possible only in zip files.
Third, the practice of bloating headers with junk data is reversing the
small gains that's been achieved over the years in compression ratios.

Not to imply it is not possible, but we have yet to test an archive
containing UTF8 encoded filenames that fails decoding and proper
reconstruction, even in double byte character set languages such as Arabic.
Unless we are provided with an instance where UTF8 encoded filenames in an
archive fails decoding, we favor UTF8 encoding as the default method for
writing filenames to all archive formats. ZipTV can properly read and
extract unicode filenames from a zip file compressed using extended
headers; however, we currently have no plans to pattern this method in
compressing new files to a zip file. Other utility applications wishing
to support default UTF8 encoded filenames, can simply test the stored
filename to see if it is UTF8 encoded.

Barriers in international communications are rapidly narrowing, and issues
regarding character translations between languages are lessening. Even
though great progress has been made over the past few years, it is not a
perfected science yet, especially with regard to signal to double byte
characters and reverse. We do not in any way, purport ourselves to be
experts on the subject of unicode, nor do we mean to imply that others are
wrong in their use of extended headers for unicode support. Only that we
will not unquestionably pattern our development to follow the lead of others
who have not proven a comparable level of understanding and uniformity in
their development regarding unicode issues, as the Delphi folks have in
their recent release of Delphi 2009.

We have listed our finding and reasoning for not agreeing with the use of
extended headers to support unicode filenames in zip files. As always,
opposing views are always welcome.

2. TUnGZip: this issue involved a gzip compressed tarball (.tar.gz), when
both the .gz file as well as the compressed .tar file contained stored
paths.

Archive name: distributor tar.gz

Properties:
UseStoredDirs property := true;
ExtractDir := 'c:\test';

a. Distributor.tar.gz contains one compressed file:
data01\eserverdata\contentitems\19\61\test.tar

b. data01\eserverdata\contentitems\19\61\test.tar has two files:
NRC\ NRC Handelsblad - Maandag 8 december.pdf
System\Inbox\test.001.desktop

When the UseStoredDirs property was true, the two files in test.tar were
extracted as:

1. c:\test\data01\eserverdata\contentitems\19\61\ NRC\ NRC Handelsblad - Maandag 8 december.pdf
2. c:\test\data01\eserverdata\contentitems\19\61\System\Inbox\test.001.desktop

Note the above extracted directory's combination of the values of the
ExtractDir property (c:\test), the pathname stored in the gzip archive
(data01\eserverdata\contentitems\19\61\), and the pathname stored in the tar
files (NRC\ and System\Inbox\).

Considering the property settings shown above, the correct files should be
extracted as:
1. c:\test\NRC\ NRC Handelsblad - Maandag 8 december.pdf
2. c:\test\System\Inbox\test.001.desktop

2008.9.29 Revision(s)

1. All compression components: adding files to an archive on a thumb-drive
were being handled using the objects for removable floppy drives. Fixed.

2008.8.4 Revision(s)

1. Maintenance update

2. TUnRar: A multi-volume stores an additional header at beginning offset 0
in every subsequent volume that spans a specific compressed file.
Previous versions returned the values from the first header. Values are
now obtained from a compressed file's last volume's header. Encrypted
headers are now supported.

3. FileInArchive: bug fix.

2008.4.21 Revision(s)

1. Added support for the FILE_ATTRIBUTE_REPARSE_POINT (1024) attribute:
http://msdn2.microsoft.com/en-us/library/aa365740(VS.85).aspx. This
attribute is now excluded from directory scanning when the RecurseDirs
property equals true (see the following conversation thread):

There are many reparse points (not dirs, just pointers/links to other
dirs) in Vista. The problem is, that Scan and ScanDir procedures repute
these links as normal dirs. This is not correct. For better understanding,
compress "C:\Users\MyDir" (with RecurseDirs := True) in Vista without
skipping reparse points, then open the archive and look at the content.

2008.4.20 Revision(s)

1. Unable to add/delete files from an archive with filenames containing
umlaut characters. Fixed.

2. WideString version of ZipTV & OEM encoded filenames: ZipTV was able
to manage (create/add/delete) OEM encoded files to/from an archive
created by other utilities, but some other utilities were unable read
the revised archive since the filenames were stored in widestring format.
Revised for compatibility.

2008.2.16 Revision(s)

1. TArchiveStream bug was recently introduced in this object. Fixed.

2008.1.21 Revision(s)

1. New component: TZipEncrypt. Flexability and highly configurability,
archive password management system for use with existing archives.
This originaly release supports Zip archives.

First and only component of it's kind. TZipEncrypt allows adding new,
changing existing, or assigning multiple passwords to individule or
defined range of compressed files.

No longer are you confined to only one password for all compressed
files in a Zip archive. Assign one password to a certain file, file
type, directory, or range of files and protect other files, allowing
access to only certain individules or groups.

* available as beta in registered versions. We strongly encourage
feedback and recomendations for enhancements of this component.

2007.9.24 Revision(s)

1. TUnBh: Buffer overflow when filename length is greater than 32k. Fixed.

2007.6.26 Revision(s)

1. Unable to delete a .zip's main archive comment. Fixed.

2007.5.29 Revision(s)

1. TZipRun & TZipSearch: added BZip support for utility/tool components.

2007.5.7 Revision(s)

1. TZip/TUnzip: this format can now contain more than 65536 files.

2007.3.12 Revision(s)

1. TUnGzip: bug fix: when a compressed filename matched the archive name
(with the exception of the .gz extension), the file opened for
decompressed data retained the .gz extension. Since most .gz utilities
do not store the output filename within the archive, this affected only
a select number of archives.

2007.3.8 Revision(s)

1. Compress components: added OnCreateDirectory event. In prior versions,
if the directory defined in the ArchiveFile property did not exist,
the archive was created in the current active directory. By default,
the directory defined in this property is now created if it doesn't
exist. To prevent the creation of the directory, set an OnCreateDirectory
event.

2007.2.26 Revision(s)

1. TZipTV & TUnLha: when using WideStrings (compiling with TNT_UNICODE
conditional define), .lha/lzh archives containing directories were
decoded properly. This bug appears only when compiling using
WideStrings. Corrected.

2007.1.31 Revision(s)

1. Resolves of all known permissions issues under Windows Vista.

2006.11.1 Revision(s)

1. TztvFindFile: wasn't returning file found results when the conditional
define TNT_UNICODE wasn't used. Fixed.

2. Revisit of Windows Vista permissions issue. If you come across any
drive or directory permissions issues, please report them and we'll
make the correction and send the revision to you via email. Any
permissions failures should route a E_PERMISSIONS error code (see
err_msgs.rc and err_msgs.pas) to the OnError event handler.

2006.10.26 Revision(s)

1. TZipSplitGlue: wasn't recognizing archives of type atZipMV.

2. Attempting to create an archive to a directory where user does not have
permission rights now handled correctly.

3. Compressors: storing empty directory names to an archive were failing
when the Windows Indexing Service was turned off.

2006.10.1 Revision(s)

1. IMPORTANT installation and distribution notes: (please read carefully):
a. two dll filenames have changed: TUnAce requires ztvUnace26.dll and
TUnRar requires ztvUnRar36.dll. You will have to make the necessary
revisions to your distributable application to reflect the correct
support files.
b. The following mentioned unicode support requires the source code
version, since the code needs to be recompiled using the TNT_UNICODE
conditional define to include widechar support.
c. UNICODE VERSION: ALL projects require a conditional define:
"TNT_UNICODE" (without the quotes). This includes all demos included
in the package for unicode / dbcs support. Unicode support is optional.
d. Installation of this package requires a 3rd party component package
(freeware)...the Tnt Unicode Controls (version 2.2.8). It can be
downloaded from the following location:
http://www.tntware.com/delphicontrols/unicode/.
** Unicode support is optional **

2. Source version only: all directory and filename strings have been converted
to WideStrings for support of DBCS and other languages not displayable under
various codepages. In ZipTV with unicode, these strings can be monitored
using unicode compatible functions. Languages tested include Russian,
Russian Cyrillic, Chinese, Japanese, Thai, Arabic (right to left ordering),
Czech, Danish, French, Korean, and Greek.

3. Unicode and DBCS support requires Delphi 6+. The Win95, Win98, and WinME
operating systems require the Microsoft Layer for Unicode. For further
information about the MSLU see:
http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx.

4. Tested and verified compatibility with Japanese versions of Windows.

5. In this version, we've gone back to the drawing board. We tested and
retested thousands of archives, updating many algorithms to correct
any inconsistencies that may have been introduced over a period of
years through simple revisions and the introduction of new components
to the suite.

6. Security update patch. For further information see:
http://www.securityfocus.com/bid/19884/references

2006.1.26 Revision(s)

1. TArchiveStream: this revision deals with the .cab and .rar formats.
Their respective dll api's require their functions open the archive
from disk. This requirement prevents sending the decompress components
for these types an untyped stream as an archive. We included a
workaround for these archives which flushes the untyped stream to a
temporary file in the (windows temp dir) and using this temp file as
the input stream.

2006.1.16 Revision(s)

1. TZipRun upgraded. Click here for more details.

2. TZipTV: after adding AES encryption to the .bh (TBlakHole) compression,
TZipTV was returning "Unsupported" compression algorithm. This did not
affect compression or decompression of .bh files.

2006.1 Revision(s)

1. Included support for C++ Builder 2006.

2005.6.4 Revision(s)

1. TUnCab (sfx's): installed routine to revise the offset of the compressed
data for sfx archives.

2005.6.3 Revision(s)

1. New component: TZipTV_Stream. Similar to the TZipTV component for reading
an archive's contents, but different in that an archive contents is saved
to a stream. Several methods have been included for reading the contents
stream.

2005.5.6.1 Revision(s)

1. TBlakHole & TUnBh: included support for the BZip2 compression algorithm.

2005.5.0 Revision(s)

1. New components: TTarGZ and TTarBZ. Compressors components that first create
.tar archive, then compress the resulting archive into a .tgz or .tbz
archive. A .tgz archive can be decompressed using the TUnGZip and TUnTar
components. A .tbz archive can be decompressed using the TUnBZip and TUnTar
components.

2005.4.0 Revision(s)

1. Maintenance release

2005.3.0 Revision(s)

1. TZipTV: OnRead event: Offset parameter changed from type Integer to Int64
in support of files > 4 gig.

2. TZipSplitter & TArchiveSplitter. Completed support for archives larger
than 4 GB

2005.2.1 Revision(s)

1. Maintenance release

2005.2.0 Revision(s)

1. New component (beta): TArchiveStream. Unit(s): ztvArchiveStream.pas. The
operation of TArchiveStream is to decompress files within an Archive
irregardless of the origin of the stream or it's type.

Since there are many development implications with this component
(internet/intranet streaming, port streaming, raw decompressed data handling
(data searches, virus scanning, etc) supporting multiple archive types,
we've developed this component with close adherence to the KISS principle,
thus providing the functionality with maximum flexibility.

2005.1.0 Revision(s)

1. TBZip & TUnBZip components added to component suite.

2. TZipSplitter, TZip, TUnZip: files can now be compressed to .zip files
using the BZip2 compression algorithm.

2005.0.2 Revision(s)

1. Added support for Delphi 2005.

2. TZipTV & TUnTar: Included support for tar filenames greater than
the header limitation of 100 chars.

3. Filenames for the 3 dll's that we support have changed. The new dll's
names now start with 'ztv'. ztvunrar3.dll, ztvcabinet.dll, ztvunace2.dll.

7.4 Revision(s)

1. Added support for a WinXP limited user account. When attempting to extract
to a directory the user does not have permissions for, a new OnLimitedUser
event is activated. This event passes both the name of the protected
directory and the users directory. Users directories are located off
"documents and settings" and are generally the only directory that holds
write protections for these user accounts.

7.3 Revision(s)

(beta due to ZipV2 encryption SeedKeys). Beta additions subject to change
without prior notice.

1. WinZip "v9 final" bug: in multiple disk spanned archives, the PackedSize
variable field is not assigned a value in the LocalHeader of each
compressed file that spans two or more diskettes. We've included a
workaround for this bug, but will not include workarounds for bugs found
in their application in the future.

7.2 Revision(s)

1. ZipV2 (zip version 2+) encryption now supports the revision of the three
previously constant seed-keys. These three keys have been hard coded in
every application supporting zip password encryption for decades,
leaving encrypted files vulnerable to the brute force hack attack.
Revising the value of these keys make the original zip encryption the
absolute most secure method of protecting compressed archives with a
password (even the new AES algorithm is vulnerable to the brute force attack).

2. Decompressors -> "OnGetPassword" event change:

Old:
TOnGetPassword =
Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString;
Var TryAgain: Boolean) Of Object;

New:
TOnGetPassword =
Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString;
Var HeaderKeys, DataKeys: TSeedKeyValues; Var TryAgain: Boolean) Of Object;

3. New properties:

a. SeedHeaderKeys (TZip, TJar, TBlakHole, TZipSplitter, TZipTV, TUnZip, TUnJar,
TUnBh TZipSearch TZipCheck, TZipRun components)
b. SeedDataKeys (TZip, TJar, TBlakHole, TUnZip, TUnJar, TUnBh, TZipSearch,
TZipCheck, TZipRun)

Both properties are of type TSeedKeys (defined in ztvCrypt.pas - requires source
version to see).

Type
TSeedKeyType = (skDataKeys, skHeaderKeys);

TSeedKeys = Class(TPersistent)
Private
SeedKeyType: TSeedKeyType;
Function GetKeyValue(x: Integer): Cardinal;
Function GetDefaultKeyValue(x: Integer): Cardinal;
Procedure SetKeyValue(x: Integer; Value: Cardinal);
Protected
Public
Constructor Create(sk: TSeedKeyType); Virtual;
Procedure SetKeys(k0, k1, k2: String); Overload;
Procedure SetKeys(k0, k1, k2: Cardinal); Overload;
Procedure SetDefaultKeys;
Property GetDefaultKey[x: Integer]: Cardinal Read GetDefaultKeyValue;
Property Key[x: Integer]: Cardinal Read GetKeyValue Write SetKeyValue;
Published
Property Key0: Cardinal Index 0 Read GetKeyValue Write SetKeyValue;
Property Key1: Cardinal Index 1 Read GetKeyValue Write SetKeyValue;
Property Key2: Cardinal Index 2 Read GetKeyValue Write SetKeyValue;
End;

4. New boolean method: IsSeedKeysSupported(TArcType);

Not all decompressors contain the above Seed[..]Keys properties. It is
good practice to always verify support with the component in use, prior
to their use. Improper use of either of these two properties with a
component which does not support them will result in an exception being
raised.

Example: If IsSeedKeysSupported(UnZip1.ArcType) Then ...

Note(s):
a. The ZipV2 encryption algorithm has always been a rock solid encryption
method for archives since it's introduction into the original Pkzip v2.0
DOS archive application. Since it's inclusion, there have been 3 seed-key
values hard coded into every zip application whose values are:

Key 0: 305419896
Key 1: 591751049
Key 2: 878082192

These values are hard coded into every application supporting the zip
archive format and password encryption. These three keys are the only
reason the Zipv2 encryption algorithm was open to the brute force hack
attack. Consider our findings with the use of the TZipKey component:

# |------ Possible combinations -------|
CharSets property Char set chars with 4 char pwrd with 5 char pwrd
--------------------------------------------------------------------------------
csNumeric | 0..9 -> 10 | 10,000 | 100,000 |
csAlphaUpperCase | A..Z -> 26 | 456,976 | 11,881,376 |
csAlphaLowerCase | a..z -> 26 | 456,976 | 11,881,376 |
csAlphaULcase | a..Z -> 52 | 7,311,616 | 380,204,032 |
csAlphaNumeric | 0..10, a..Z -> 62 | 14,776,336 | 916,132,832 |
csAlphaNumericU | 0..10, A..Z -> 36 | 1,679,616 | 60,466,176 |
csAlphaNumericL | 0..10, a..z -> 36 | 1,679,616 | 60,466,176 |
csFullSet | 0..255 -> 256 | 4,228,250,625 | 1,078,203,909,375 |
csNonAlphaNumeric | -> 193 | 1,387,488,001 | 267,785,184,193 |
--------------------------------------------------------------------------------

Note the csFullSet (using upper/lower case, and numeric chars) line
with a 5 char password. There are over 1 trillion, 78 billion possible
combinations of 5 chars which could possibly be the password! Even with
today's computers, it could take weeks or even months (never could wait
long enough really for a conclusive time) for a computer doing nothing but
scanning possible combinations to compromise a simple 5 char password.
This also is using the hard coded three seed-keys mentioned above. Now,
consider changing the seed-keys, using the same csFullSet, 5 char password.
The possible combinations are OFF THE CHART. Before we can begin a brute
force search for the characters in the password, we must have the encrypting
seed-keys values... possible key value combinations: 4294967295 *
(4294967295 * 4294967295). Not likely without first hand knowledge of the
key values. The possible combinations for the password are now ((4294967295 *
(4294967295 * 4294967295)) * 1,078,203,909,375). Not totally impossible, but
with numbers that huge, what is the probability?

I wrote the TZipKey component several years ago (a brute force encryption
attack) as a method of retrieving lost or forgotten passwords. It's the most
widely known password attack against zip encrypted archives known (to date,
I know of no one that has come up with a better or faster method of archive
password retrieval). As a test of the AES encryption algorithm, I recently
updated the TZipKey component to include the AES algorithm (not for
distribution... don't ask) . The AES encryption method has recently been
selected as the most secure data encryption method currently in use, but it
was just as vulnerable to the brute force attack as the original zipv2
algorithm was...with the exact findings as the above chart for the zipv2
algorithm It is my opinion that the most secure method of archive encryption
is the revision of the previously hard coded constant seed-keys. Study the
algorithm... it's simply irreversible... can't be done... impossible. The
only hole (a very small hole I might add) in the zipv2 encryption algorithm
was the hard coding of the 3 seed-keys.

The use of, and security of Seed-Keys:
The use of unique seed keys does come with a cost. Revise a seed-key,
password protect compressed files, lose the seed-key values the files were
encrypted with... there is absolutely no way to decrypt and decompress the
archive. The data is simply lost. Is this heightened level of security worth
the cost? The US Military thinks so. They have been using seed-keys for
encrypting classified and top secret data and communications for decades.
Unique seed-keys in encryption is at the top of the chain for data security.
Even if your company's unique keys were to be compromised, your back to a
pretty good level of security the original zipv2 encryption afforded you...
approx 95-99.9% depending on the number and mixture of chars used in the
password.

5. TArc2Arc: ztv[..].tmp files containing the read-only file attribute were not
being deleted during cleanup.

6. Compress disk-spanning: the OnClearDisk event was revised to activate every time
when FreeSpace < TotalSpace.

7. Support for extraction of files from .cab sfx's (self extractable). ArcType =
atCabExe.

8. TArc2Arc:
a. temp files, created from compressed files containing the hidden file-attribute
were not being cleaned up (deleted) when TArc2Arc finishes it's task.
Corrected.
b. added support for ArcType = atCabExe

9. Revised TFileScan to include support for filenames beginning with the '.' char.
I.e., ".testing".

7.1.3 Revision(s)

1. TArchiveEditor: previous versions were unable to correctly edit archives created
using pkzip v2. Corrected

7.1.2 Revision(s)

1. TZipRun Component: added OpenWith property.
TOpenWith = (omRegistryAssoc, omCmdLine, omOpenWith);

a) omRegistryAssoc: extracts and runs the specified file using extension
associations in the registry.
b) omCmdLine: extracts and runs the specified file allowing the user to specify
a specific application to run the extracted file via command line.
c) omOpenWith: displays the OpenWith dialog for the user to select an application
to run the extracted file.

7.1.1 Revision(s)

1. ztvGbls.pas: Added atB64 to TArcType for support of Base64 decoding.

2. ztvConsts.pas: Added the .mim extension to ExtArray for support of Base64
registry association.

3. TRegArchive (ArcExtensions property): in the Delphi object inspector, either
add the .mim extension, or clear all default extensions from this property.
The next time your project is run, the .mim extension will be automatically
added to this property, and registry associations for this extension will
be supported.

4. We're in the beginning stage of supporting double-byte and unicode char sets.
If you use any of the following functions in your projects, add an preceding
underscore to the function name. There may be some name changes that aren't
listed. If looking for a function that was in a previous version, none have
been removed... just postfix an underscore to the name:

AppendDirTail -> _AppendDirTail
GetFileType -> _GetFileType
EraseFile -> _EraseFile
ChangeFileExt -> _ChangeFileExt
ztvFileExists -> _FileExists

7.1.0 Revision(s)

1. The ArchiveComment comment was changed to a stream object
(ztvStreams.TCommentStream). It is now much easier to view & edit the
archive main comment.

2. SetComment method changed to SetFileComment (differenciate between a file
and archive's main comments).

3. GetComment method changed to GetFileComment (differenciate between a file
and archive's main comments).

7.0.8 Revision(s)

1. Compress Components - StoreDirNames property:

Affects:
StoredDirNames = sdExplorer_Auto or
StoredDirNames = sdExplorer_UserDefineDefaultDir

Compression component's property values for testing:
[CompressComponent].StoredDirNames = sdExplorer_UserDefineDefaultDir;
[CompressComponent].RecurseDirs := False;
[CompressComponent].DefaultDir := 'D:\12test\Sub1\;

Using the following batch file content (test.bat) create the following
directory / file structure for testing:

mkdir d:\12test
mkdir d:\12test\Sub1
echo "aaa" > d:\12test\Sub1\test1.txt
echo "aaa" > d:\12test\Sub1\test2.txt
mkdir d:\12test\Sub1\Sub2
echo "aaa" > d:\12test\Sub1\Sub2\test3.txt
echo "aaa" > d:\12test\Sub1\Sub2\test4.txt

The resulting file structure will be:
D:\12test\Sub1\Test1.txt
D:\12test\Sub1\Test2.txt
D:\12test\Sub1\Sub2\Test3.txt
D:\12test\Sub1\Sub2\Test4.txt

Value of the FileSpec property (same as the above dir structure):
D:\12test\Sub1\test1.txt
D:\12test\Sub1\test2.txt
D:\12test\Sub1\Sub2\test3.txt
D:\12test\Sub1\Sub2\test4.txt

Previous versions: stored structure in the resulting archive was:
Test1.txt
Test2.txt
D:\12test\Sub1\Sub2\Test3.txt
D:\12test\Sub1\Sub2\Test4.txt

Current version: stored structure in resulting archive is:
Test1.txt
Test2.txt
Sub2\Test3.txt
Sub2\Test4.txt

Note(s)
1. Notice the Sub2\Test3.txt and Sub2\Test4.txt names stored in the
archive are sub-directories of the value assigned to the DefaultDir
property above ('D:\12test\Sub1\').
2. The use of the sdExplorer_UserDefineDefaultDir setting requires
assigning the DefaultDir property a valid existing directory name.

7.0.7 Revision(s)

1. AES (block cipher Rijndael) encryption revisited.

7.0.6 Revision(s)

1. TUUEncode and TUUDecode.pas: added Base64 encoding/decoding.

7.0.5 Revision(s)

1. Bug found in the extraction of AES encoded "stored" (no compression)
files. Fixed.

7.0.4 Revision(s)

1. [Compress Component].StoredDirNames property: UserDefineDefaultDir
changed from case sensitive to case insensitive.

Example:
The following would fail due to case sensitivity.
ZipSplit1.DefaultDir := 'E:\';
ZipSplit1.FileSpec.Clear(); ZipSplit1.FileSpec.Add('e:\test\*.*');
ZipSplit1.Compress();

2. [Compress Component].ExcludeSpec property: this property no longer
requires a fully qualified path.

Example:
ZipSplit1.FileSpec.Clear();
ZipSplit1.FileSpec.Add('e:\temp10\*.*');
ZipSplit1.ExcludeSpec.Clear();
ZipSplit1.ExcludeSpec.Add('cache\*.*');
ZipSplit1.RecurseDirs := True;
ZipSplit1.DefaultDir := 'e:\';
ZipSplit1.StoredDirNames := sdExplorer_UserDefineDefaultDir;
ZipSplit1.Compress();

e:\temp10\cache: cache is a sub-directory of e:\temp10.

Previous versions of ZipTV required the ExcludeSpec property to contain
the fully qualified path e:\temp10\cache in order to exclude files from
this directory. Note in the above example that 'cache\*.*' is not
allowed. However, it must be a subdirectory of one of the strings
defined in the FileSpec property.

7.0.3 Revision(s)

1. TUnRar: bug developed in v7.0.2 due edits done in that version.

7.0.2 Revision(s)

1. TUnGzip: updated to support unix created multi-header compressed .gz
archives. Don't confuse this with multi-file. The .gz format is still
a single file compressor, but some versions of the UNIX / LYNIX gzip
utility, the compressed data stream is broken into multiple segments
and separated by these headers.

Example test files:
http://www.ziptv.com/TestFiles/gc5.0alpha3.tar.gz
http://www.ziptv.com/TestFiles/old_access_log.2000Aug.gz
http://www.ziptv.com/TestFiles/old_access_log.2001Jan.gz
http://www.ziptv.com/TestFiles/old_access_log.2002Apr.gz

7.0.1 Revision(s)

1. TZip, TUnZip, TZipSplitter, TJar, TUnJar Components:
a) added the much requested AES (block cipher Rijndael) encryption.
The zip AES standard is now based on Dr. Brian Gladman's implemen-
tation of the Rijndael algorithm.

2. TZip, TZipSplitter, TJar:
a) ztvBase.pas new property: TZipCommon.GetEncryptionMethod():
TEncryptionMethod.
Returns one of the following TEncryptionMethod members:

TEncryptionMethod = (emNone, emAES2_ 1 28, emAES2_ 1 92, emAES2_256,
emZIP_v2, emUnsupported);

b) EncryptionMethodStr (ztvGbls.pas). Returns the string equalivant of
the above TEncryptionMethod.

3. Linking ZipTV AES into the ZipTV Components:

In BCB's project options, set the conditional define as MCSREG. In the
source version, failure to follow this step will result a failure to
compile with error message "[Fatal Error] ztvBase.pas: Unit ztvRegister
was compiled with a different version of ztvBase.TZipCommon.

NOTE(s)
* The sources for AES encryption are not yet available.
* Our AES implementation require no external dll's!

6.8.4 Revision(s)

1. All compress components - OnDeleteFile Event
a) the value of this event's "count" parameter (count of files deleted.
including the current file) started at 0 instead of 1. Fixed.
b) when the value of the Switch property is "swMove" and the file
already exists in the archive, the file was not deleted from disk.
Fixed.

6.8.3 Revision(s)

1. TUUEncode & TUUDecode
Updated for compatibility with .zip multi-volume archives.

2. All compression components -- VerifyBeforeDelete property
When the Switch property equals swMove and the VerifyBeforeDelete
boolean property was true (default = false), files were properly added
to the archive, but not deleted from disk.

6.8.2 Revision(s)

.zip disk-spanning bug fix.

6.8.1 Revision(s)

Decompression components - ExtractToFileStream method bug fix

6.8.0 Revision(s)

This revision changes some event parameters! Please read!

When loading projects developed under previous versions, BCB will report
these event changes and request to remove the reference to the event.

When loading a project in this version and Delphi reports these event errors:
a) Write down the component and event names so you can re-install the code
from the old, to the new event handler.
b) Let Delphi remove the reference.

After the project is loaded:
a) Delete the event defination (but not the event handler - containing the
event's code).
b) In the object inspector, double click on the event name (BCB should have
already removed the reference, so it should be blank).
c) Copy your code from the old to the new event handler.
d) Delete the old event handler (including the code you've copied to the
new handler).
e) Inspect the new event handler for changes which may affect the code you
have copied to the new handler.

1. TRegArchive Component - OnAssociation event.
Parameter revision:

Old declaration:
TOnAssociation = Procedure(Sender: TObject; Appname: String)
Of Object;

New declaration:
TOnAssociation = Procedure(Sender: TObject; Appname: String;
Var Cancel: Boolean) Of Object;

Previous versions:
This event was activated if the ActivateOnStartup property was true.
When true, during application startup, this event activated. Within
this event, the "install method" would be assigned to install the file
extension associations into the registry. In this version, a cancel
method was installed to the OnAssociation event. If cancel is true
(default), the install method will not be called internally, and the
association process is canceled.

This version:
The OnAssociation event MUST be set and the value of the "cancel"
parameter must be false, for user confirmation of the registry
association edits. If it is not set, and the cancel parameter is true
(default) no file associations in the registry will take place.

DO NOT CALL THE "INSTALL METHOD" FROM WITHIN THIS EVENT. SET ONLY THE
CANCEL PARAMETER TO FALSE, IF REGISTRY ASSOCIATIONS ARE TO TAKE PLACE.

2: TRegArchive Component - Install method
The "install method" is now a function of type ShortInt, returning the
following result codes:

raComponentState = ComponentState is in csDesigning mode
raCancel = OnAssociation's "cancel" boolean parameter was true (default)
raOnAssociation = OnAssociation event was not set
raOk = associations was written to registry
raNoneRequired = no associations were required (already associated)

3: TZipTV, TZipRun, all decompression components
Added property ExcludeSpec
Added event OnExcludeFile
This property and event has always been present in the compressor
components, now added to the above mentioned components. Their
function is to narrow the specification of files for processing in
conjunction with the FileSpec property.

Using the decompressor components as an example, the FileSpec property
might contain the wildcard '*.*' (which means to include all files for
processing). The ExcludeSpec property is assigned the wildcard '*.txt'
which means to exclude all files for processing which has the .txt file
extension.

The OnExcludeFile event is activated once for eah file found to match
the FileSpec specification, but is in the list of files to be excluded.

4. TArchiveEditor Component - OnBatchSkipFile event
Parameter revision:

Old declaration:
TOnBatchSkipFile = Procedure(Sender: TObject; NewFileName: String;
Index: Integer; Var SkipChange: Boolean) Of Object;

New declaration:
TOnBatchSkipFile = Procedure(Sender: TObject; OldFileName,
NewFileName: String; Index: Integer; Var SkipChange: Boolean) Of Object;

The original name of the compressed file (OldFileName) was also
necessary to better determine which file names to skip revisions.

5. ztvInflate.pas and ztvDeflate.pas
ztvInflate.ztvDecompress_StreamToStream revised
ztvDeflate.ztvCompress_StreamToStream revised

6. TZipSplitter Component - OnSplitEnd event
Parameter revision:

Old declaration:
TOnSplitEnd = Procedure(Sender: TObject) Of Object;

New declaration:
TOnSplitEnd = Procedure(Sender: TObject; VolumesCreated: Cardinal) Of Object;

6.7.1 Revision(s)

TOnNextVolume event: changed parameter VolumeID from data type
AnsiString to Integer.

Old declaration:
TOnNextVolume = Procedure(Sender: TObject; Var VolumeName: AnsiString;
VolumeID: AnsiString; fExists: Boolean; Var Cancel: Boolean) Of Object;

New declaration:
TOnNextVolume = Procedure(Sender: TObject; Var VolumeName: AnsiString;
VolumeID: Integer; fExists: Boolean; Var Cancel: Boolean) Of Object;

6.7.0 Revision(s)

New component: use TZipSplitGlue, combine a multi-volume .zip achive into a
single (non-volume) output .zip archive.

6.5.5 Revision(s)

1. TUnZip: disk-spanning bug arose during development of TarchiveSplitter
and TZipSplitter components. Fixed.

6.5.3-4 Revision(s)

1. Delphi revisions only

6.5.2 Revision(s)

1. All compressor components OnStoreFilesOfType property:

a) On creation of a compressor component, this TStrings property was
incorrectly inserting a blank line, resulting in files without
extensions to be stored in an archive with no compression.
b) If this property was set in Delphi's object inspector, an exception
will raise.
c) If this property wasn't set in Delphi's object inspector, the problem
will not show.

6.5.1 Revision(s)

1. TZipSplitter: added support for the CompressionMethod property
(supported by all other compressors). Prior versions could not
successfully compile zip archives with CompressionMethod = cmInMemory.
There are two possible settings for ths property, cmTempFile and
cmInMemory.

August 29, 2003 - 6.5.0 Revision(s)

1. TZipSplitter: this is the first version where this component can
actually and reliably replace the TZip component. It has the ability
to add and delete files from multi-volume zip files.
2. Messages passed to the OnError event were updated.
3. TArchiveEditor: bug found and fixed when editing .tar file filenames
and dates.
4. TUUEncode and TUUDecode : bug found and fixed.
5. TZipKey : bug found and fixed.

Note 1: The secret to TZipSplitter is it’s OnSplitBegin event. When this
event handler is activated, a form can be displayed, requesting
volume size (no volume split is an option) number of output
volumes etc. TArchiveSplitter and TZipSplitter do not at this time
support files greater than 4 gig. If this feature is required,
use the TZip component.

Note 2: To enable debug of ZipTV, change the following line in ziptv.inc
unit: {.$define ENABLE_DEBUG} to {$define ENABLE_DEBUG} (dot
before $define removed)

Note 3: Zip volumes created using TArchiveSplitter and TZipSplitter are
compatible with volumes created by WinZip. ZipTV takes zip split
volumes a step further in the ability to split zip volumes during
the creation of an archive. Not available in any other archive
format is the ability to add and delete files from volume
archives (TZipSplitter).

Note 4: Projects developed with the registered version of ZipTV must
always be compiled using MCSREG as a conditional define. This
conditional isn’t mandatory in the current release, but will
be so in future versions.

6.4.1 Revision(s)

1. TArchiveSplitter and TZipSplitter upgrade
2. Some constants were moved from various units to the ztvConsts.pas
unit. If you encounter a "undeclared identifier" error, add ztvConsts
to that units uses clause.
3. Error reported editing zip archive and file comments. Fixed.

6.4.0 Revision(s)

1. Maintenance release.

July 14, 2003 - 6.3.2 Revision(s)

1. TZipSplitter: merged into parent objects for basic usage simularity with
other compressor components.

2. TZipTV and TUnZip updated for compatibility with WinZip 9.0 support of
unlimited sized archives.

3. Bug fix: v6.3.1 introduced a compatibility issue with Win9x OS's. We
used a function to handle the compressed output temp file which was not
compatible with Win9x. Fixed.

June 9, 2003 - 6.3.1 Revision(s)

1. Bug created in the May 29th release. Procedure
TZipCommon.TempFileMoveFile(...) (in ztvBase.pas) was added for seamless
handling of moving of the created temp file with all compressors. When
attempting to create archives on seperate fixed drives, the temp file
was not moved. Fixed.

May 29, 2003 - 6.3.1 Revision(s)

1. TArchiveEditor: we've spent alot of time on the update of this
component. It is no longer being considered beta.

May 2003 - 6.3.0 Revision(s)

1. TUnAce: when renaming extracted files (via the OnRename event),
directories contained in the unrenamed file were created.

2. TZipTV: updated to support unicode rar filenames.

3. TUnRar: updated for proper extraction of unicoded filenames.

4. TArcSplitter: internal properties were updated to interact with other
related properties. The revision greatly reduces the number of improper
set property values.

April 29, 2003 - 6.2.0 Revision(s)

1. In version 6.1.1 we revised the ExtractDir property to default to the
path where the extracting archive resides. This change was implemented
to account for a blank value of ExtractDir. However, it created a bug
in the TArc2Arc component.

April 14, 2003 - 6.1.1 Revision(s)

1. ZipTV supports the extraction of specific files even from split .zip
archives.

April 1, 2003 - 6.1.0 Revision(s)

1. When attempting to compress archives to diskette which do not support
disk-spanning, a disk-full error is now routed through the OnError event.

2. Compression Components: if the values of TempDir property and ArchiveFile
property are located on the same drive, a FileMove is involked to move
the temporary output file, instead of a stream copy. This increases
completion speed dramatically.

3. TArchiveSplitter: the remaining issue with this new component was
resolved. If the size of the central directory exceeds the desired output
volume size, the central directory is now split correctly between multiple
output volumes.

4. Decompression Components: OnRenameFile event added.

5. All components (ztvFileIo.pas): ArchiveDate (or fArchiveDate in some
versions) reported time in UTC instead of local time.

February 25, 2003 - 6.0.0 Revision(s)

1. New component: TArchiveSplitter. Starting with v5.2, TZipTV & TUnZip
supported split archives created under WinZip. This new component now
includes support for the creation of these archives.

2. All components were edited for enhanced streaming support. ZipTV now
supports compression / decompression to and from the clipboard, strings,
buffers, etc. This support opens a wide range of usage for our components.

February 4, 2003 - 5.6.2 Revision(s)

1. Added support for .war archives. For more info on the .war format see
http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebApp3.html

February 3, 2003 - 5.6.1 Revision(s)

1. Added ability to read and display (TZipTV) .cab sfx (executable)
archives as well as the ability to extract (TUnCab) compressed files
within these sfx's.

January 31, 2003 - 5.6 Revision(s)

1. TRegArchive: when running an application through a network, the
computer name and drive was being improperly written to the reigstry
when associating archive extensions to the application.

January 29, 2003 - 5.5 Revision(s)

1. TZipTV and TUnRar: updated these two components to handle .rar
archives whose compressed and/or uncompressed file sizes exceed the
4 gig barrier.

January 24, 2003 - 5.4 Revision(s)

1. Compression Components (Attributes and AttributesEx properties): added
support for the FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and
FILE_ATTRIBUTE_ENCRYPTED file attributes.

2. TUnAce: rewrite of this component for better handling of the extraction
of specific (selected) files within an .ace archive.

3. TZipTV and TUnArj: added a 5000k buffer to search deeper into a file
for the .arj archive signature, allowing a more precise identification
of an .arj archive.

November 1, 2002 - 5.3 Revision(s)

1. TZip, TUnZip, TZipTV: added support for compression of files with sizes
greater than 4gb on NTFS formated drives. This revision will require
the following revisions to projects developed with prior versions:

Event: OnFileScanStatus
Parameter: FilesSize changed from type double to int64
Components effected: TZip, TBlakHole, TGZip, TTar, TMakeCab, TJar, TLha

Event: OnTotals
Parameter: UnpackedSize and PackedSize changed from type double to int64
Components effected: TZipTV

October 1, 2002 - 5.2 Revision(s)

1. Added support for WinZip's split volume archives. This version supports
the viewing and decompression of multi-volume zip archives, the next
revision will include the new component TArchiveSplitter which will
support the compression of compatible multi-volume split zip archives.

July 5, 2002 - 5.0 Revision(s)

1. Deflate64 method now supported

June 21, 2002 - 4.8.6 Revision(s)

1. All components interacting with SFX archives have been updated for the
current ztv_*.sfx stub files. These components (all decompression
components, TZipTV, TMakeSfx, TUnSfx) were updated also to include SFX
archives created by a greater number of non-ZipTV SFX archives.

2. Archive detection routines updated for smoother interaction between
components.

Be sure to download version 4.8.6 of the ZipTV sfx-stub files!

June 8, 2002 - 4.8.5 Revision(s)

1. ztv_lha.sfx: upgraded for support of the Frozen7 compression method.

2. TMakeSfx & TUnSfx: updated for compatibility with the latest
sfx-stub files.

June 3, 2002 - 4.8.4 Revision(s)

1. ztv_ace.sfx: upgraded for support of the ace version 2 archive format.
Requires unacev2.dll from the ZipTV Compression Components (installs
in your system dir when ZipTV is installed).

2. ztv_rar.sfx: upgrade for support of the rar version 3 archive format.
Requires unrar3.dll from the ZipTV Compression Components (installs
in your system dir when ZipTV is installed).

3. TZipTV, TUnAce, TUnRar: upgraded for support of the above two sfx
(executable) archives. These components can read, list, and extract
these new executable archives.

4. TUnLha: upgraded for support of the latest compression algorithm
(frozen7).

May 13, 2002 - 4.8.3 Revision(s)

1. small fix to the decompressor component's OnRecurseDirs property.

May 8, 2002 - 4.8.2 Revision(s)

1. Maintenance release.

2. First version for Borland C++ Builder 6!

April 13, 2002 - 4.8 Revision(s)

1. TArchiveEditor: new "beta" component. Edit an archive's compressed
filenames, dates, and file-attributes.

April 7, 2002 - 4.7.1 Revision(s)
1. TUnCab: modifications by the brilliant mathematician and programmer,
Alexey Chernobaev, to support the proper handling of nested .cab files
(archive within archive).

2. TArc2Arc: upgraded to include support of proper conversion of many
archive types to a .tar.gz arhive.

March 21, 2002 - 4.6.8 Revision(s)

1. Compression Components (TJar, TZip, TBlakHole, TLha): added property
StoreFilesOfType property. Add extensions (including the dot char '.'),
of file-types to store into the archive, instead of using compression.
For example, to store an already compressed .zip archive into another
archive (instead of attempting to compress it again) add the extension
.zip to this property.

2. StoreAlreadyCompressedFiles property removed. With the addition of the
StoreFilesOfType property, this property is now obsolete.

3. TStoredDirNames:
a. renamed set member sdExplorer as sdExplorer_Auto. Use this member
to add multiple FileSpecs from multiple directories. Any prior
setting of the DefaultDir property is ignored, and is set
automatically according the what directory is common to all
FileSpecs.
b. Added member sdExplorer_UserDefineDefaultDir.
sdExplorer_UserDefineDefaultDir requires the setting of DefaultDir
as the rootdir prior to calling the Compress() method. For example,
if you dropped files from the Windows Explorer, from directory
c:\windows\system, set the DefaultDir property as 'c:\windows\
system'. The dropped files directories will be stored into the
archive accordingly.

February 16, 2002 - 4.6.5 Revision(s)

1. TUnRar: added support for extraction of split files from diskettes.

February 14, 2002 - 4.6.4 Revision(s)

1. TUnRar: added support for RAR split files (filename.part1.rar,
filename.part2.rar, filename.part3.rar, etc.). Old multi-volume naming
convention is still supported (filename.rar, filename.r00, filename.r01,
etc.).

2. TZipRun: added OnNextVolume event for support of the new RAR split-file
/ multi-volume support.

3. TZipTV: revised to support RAR split-files.

February 12, 2002 - 4.6.3 Revision(s)

1. TZip / TUnZip: EncryptHeaders property. Foriegn characters in filenames
were not being property restored when the EncryptHeaders property was
true.

2. TTar: progress bar was not being updated properly when adding "huge"
files to a .tar file.

February 6, 2002 - 4.6.1 Revision(s)

1. TZip / TUnZip: installation of function to properly handle foreign
char sets.

February 5, 2002 - 4.6.0 Revision(s)

1. TUnRar: included main archive comment and password protected archive
support. This component, recently upgraded for compatibility with the
new .rar v3.0 format, is now complete.
2. TUnRar: renamed unrar.dll to unrar3.dll for version identification
purposes.

January 31, 2002 - 4.5.5 Revision(s)

1. TZip / TUnZip (EncryptHeaders property): a routine which handles a #0
char (end_of_string) in foreign chars sets, was interfering with the
compressed filename encryption routine. Encrypted filenames sometimes
contains this char... when altered for foreign char sets, naturally the
decryption function was not returning the proper decrypted filename.

January 28, 2002 - 4.5.4 Revision(s)

1. TUnRar: bug fix created in 4.5.3 revision which prevented extraction of
compressed .rar files from readonly drives, such as a cd rom.

2. TUnRar: installed error handler for .rar "broken archive". Previous
version terminated with no error reported.

January 25, 2002 - 4.5.3 Revision(s)

1. Updated TUnRar for compatibility with the new v3 rar format.

January 24, 2002 - 4.5.2 Revision(s)

1. Bug found in WinZip with regard to crc calculation of .zip archive
"stored" files. Adjustment made to compensate for this bug so the TZip
component is compatibility with WinZip's stored files.

January 23, 2002 - 4.5.1 Revision(s)

1. Installation of all .zip diskette spanning functions into v4 series
(moved over from v3.x) now complete.

2. Fix with regard to network unc-pathnames.

January 21, 2002 - 4.5.0 Revision(s)

Maintenance release

January 16, 2002 - 4.4.0 Revision(s)

1. New streaming methods installed which improves compression speed even
further. Test results compressing a 2 gigabyte text file using WinZip
= 14 minutes, ZipTV = 7.4 minutes.

2. New .ace format updates. Multi-volume archive updates.

3. Diskette-spanning updates.

4. Addition of huge archive compression / decompression support.

October 15, 2001 - 4.1.9 Revision(s)

1. Removed limitation regarding compatibility with other utilities (such as
WinZip) in the downloadable shareware version. Shareware version now
creates compatible archives.

2. This will be the last update for the downloadable shareware version in
the version 4 series. Updates will continue with the registered version.

October 14, 2001 - 4.1.8 Revision(s)

1. Beta status removed... help file still requires updating.

2. StoredDirNames (sdExplorer set member): updated for better drop / drag
operations.

3. TMakeSfx: updated for compatibility with sfx stubs.