Enhanced Power, Speed, and Operability
Under Most Web-Servers.

ZipTV's AES encryption and PPMD compression requires no external dll's!

 

Conditional Defines (requires VCL source version)

• AES_SUPPORT: import AES units for use in your project. No external dll calls required. This conditional has been removed from ZipTV versions for Delphi 2009+.
• TNT_UNICODE: link to 3rd party unicode package (download link below). This conditional has been removed from ZipTV versions for Delphi 2009+.  
• JAPANESE: compatibility with the Japanese language.  Can not use in conjunction with the TNT_UNICODE conditional.
• MSCREG: use to compile the registered version of ZipTV.   
• NO_PROCESS_MESSAGES: there are many instances of Application.ProcessMessages within the components code. When ProcessMessages is used within a treading environment an error can be raised.  Use this conditional to "exclude" all occurrences of Application.ProcessMessages within the code.
  

External dll files (installed in windows\system32 directory)

• ztvUnrar38.dll    (recently changed)
• ztvUnace26.dll
• ztvCabinet.dll
• ztv7z.dll (ZipTV versions for Delphi 2009+)

REMINDER:
Installer Password: The password for the registered version of the installer is the order invoice number obtained from the invoice received at the time of registration.

NOTE: 7-zip support is included in the ZipTV versions for Delphi 2009+.

v2010.04.08

• Component(s) affected: TZipRun
  Source unit: ztvZipRun
  Demo Application: [ziptv install directory]\demos\maindemo\maindemo.dpr
  Delphi palette tab: "ZTV Tools"
  Delphi support: all versions supported by ZipTV
  
  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.

v2010.04.06

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

v2010.04.03

• 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;
  
  

v2010.03.29

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

v2010.03.22

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

v2010.01.12

• PPMD compression/decompression: original release as non-beta.  No known issues remaining.
• Maintenance release.
• 7zip components still considered beta as support has not been added to all ZipTV tool components.

v2009.12.21

• 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.
• TArchiveSplitter and TZipSplit: when splitting .zip archives, ZipTV was returning error 25215 (error opening file).  Corrected.
• TZipRun: unable to run/view a compressed file that was AES password encrypted. Corrected.
• 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.
  

v2009.11.24

• 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/. 

v2009.7.28

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

v2009.6.16  

• TUnSevenZip: added support for the UseStoredDirs and CreateStoredDirs properties.
  • 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.
    
    
  • 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.
    

v2009.6.15  (7-zip support is available in ZipTV for Delphi 2009+)

• Support for 7-zip multi-volume added in all components now supporting the 7-zip format.
• The OnGetPassword event was installed in the TUnSevenZip and TZipCheck components for password protected 7-zip archives.
• 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.
  

v2009.6.11

• Support for 7-zip archives are now supported in the ZipTV version for Delphi 2009+.  The following components also include multi-volume support.
• The following components have been updated and/or added for 7-zip support:
  • TZipTV: (updated) retrieve 7-zip compressed file information.
  • TUnSevenZip: (new) extract compressed 7-zip files.
  • TZipCheck: (updated) perform a validity test on the compressed files.
  • TZipSplitGlue: (updated) join 7-zip multi-volumes into a single archive.
• New dll:
  • ztv7z.dll
• New source files
  • ztvUn7zip.pas
  • ztvJclCompression.pas
  • ztvSevenZip.pas
    

v2009.5.4

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

v2009.4.14

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

v2009.1.1

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

v2009.0.0

• ZipTV for Delphi 2009 is expected to be released sometime around the latter part of December 2008.

v2008.12.13

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 and an extended header created, full 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 the archive signals the filename is UTF8 encoded, 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 the 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. We do not in any way, purport 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. Opposing arguments are always welcome..
   
   
2. TUnGZip: this issue involved a gzip compressed tarball (.tar.gz). 
   
   Archive:  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 incorrectly being extracted as:

• c:\test\data01\eserverdata\contentitems\19\61\ NRC\ NRC Handelsblad - Maandag 8 december.pdf
• 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), 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 correct files should be extracted to:

• c:\test\NRC\ NRC Handelsblad - Maandag 8 december.pdf
• c:\test\System\Inbox\test.001.desktop

v2008.11.30

• Minor bug fixes. Maintenance release.

v2008.9.29

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

v2008.8.04

• Maintenance update
• 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.
• FileInArchive: bug fix.

v2008.4.21

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

v2008.4.20

• Unable to add/delete files from an archive with filenames containing umlaut characters.  Fixed.
• 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.

v2008.2.16

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

v2008.1.21

• New component: TZipEncrypt. Flexability and highly configurable, archive password management system for use with existing archives. This release supports Zip archives.
  
  First and only component of it's kind. TZipEncrypt allows adding new, changing existing, or assigning multiple passwords to individual 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 specific file, file type, directory, range of files. Allow access of specific files contained within an archive to only certain individuals or groups.
  
  Component demo: demos\ZipEncrypt\ZipEncrypt.dpr
  

v2007.9.24

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

v2007.7.29

• New demos:  
  • demos\CustomFileList\CustomFileList.dpr: demonstrates how to bypass ZipTV's internal file scan and use your own list of file names by setting the ScanDiskForFiles property to false.
  • demos\search\FilesByDateOrSize\FilesByDateOrSize.dpr: demonstrates advanced filtering to locate compressed files within archives using the compressed files name, date/time, packedsize, unpackedsize, or within a specified ranges.
    

v2007.6.26

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

v2007.5.29

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

v2007.5.7

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

v2007.3.12

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

v2007.3.8

• 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.  Search for OnCreateDirectory in demo: demos\maindemo\maindemo.dpr (main.pas) for detailed usage notes.
  

v2007.2.26

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

v2007.1.31

• Resolves of all known permissions issues under Windows Vista.

v2006.11.1

• TztvFindFile: wasn't returning file found results when the conditional define TNT_UNICODE wasn't used.  Fixed.
  
• 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.

v2006.10.26

• TZipSplitGlue: wasn't recognizing archives of type atZipMV.
• Attempting to create an archive to a directory where user does not have permission rights now handled correctly.
  
• Compressors: storing empty directory names to an archive were failing when the Windows Indexing Service was turned off. 

v2006.10.1

Note: unicode / dbcs support is available in the components, only in registered source code versions. Due to a requirement to compile the sources locally, dcu versions are not supported. Non-unicode versions like in every other way.

The most comprehensive revision of the ZipTV Components to date!

• Source version only (optional with the use of a conditional define): all directory and filename strings have been converted to WideStrings for support of DBCS and other languages not displayable on varying code pages. With a simple conditional define, these strings can be monitored using unicode compatible functions. Now compatible under Japanese Windows 98 and XP. Languages tested include Russian, Cyrillic, Japanese, Chinese, Arabic, Czech, Danish, French, Korean, and Greek.
  
  Unicode and DBCS support requires Delphi 6+. Win95, 98, and ME all require the Microsoft Layer for Unicode. For further information about the MSLU see: http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx.
  
  
• Tested and verified compatibility under Japanese Win98 OS. We were unable to obtain and test Japanese XP, but it's reasonable to assume compatibility if it works under Win98.
  
  
• 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.
  
  
• Security update. For further information see: http://www.securityfocus.com/bid/19884/references
  

v2006.2.16

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

v2006.1.16

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

v2006.1.16

• TZipRun upgraded. Click here for more details.
• 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.

v2006.1.0

• Included support for Delphi 2006

v2005.6.4

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

v2005.6.3

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

New component demos: 1) demos\streamingdemos\ziptvstream\ziptvstream.dpr

• New components: TztvDbMemo and TztvDbImage. These components haven't yet been added to the setup, but are available to registered developers (at no cost) upon request. Delphi 6+ is required!
  

v2005.6.1

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

v2005.5

• 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.
  
  New component demos: 1) demos\targz\targz.dpr and  2) demos\tarbz\tarbz.dpr. 

v2005.4

• Maintenance release

v2005.3

• TZipTV: OnRead event: Offset parameter changed from type Integer to Int64 in support of files > 4 gig.
• TZipSplitter & TArchiveSplitter: completed support for archives > 4 gig

v2005.2.1

• Maintenance release
• demos\BZipDemo\BZipDemo.dpr added to demos
  

v2005.2.0

• New component (beta): TArchiveStream
  Unit(s): ztvArchiveStream.pas.  
  Demo(s): demos\StreamingDemos\ArchiveStream\ArchiveStream.dpr
  
  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 flexability.
  
  For developer info see the demo's source unit (unit1.pas) header.
  
  

v2005.1.0

• TBZip & TUnBZip components added to component suite.
• TZipSplitter, TZip, TUnZip: files can now be compressed to .zip files using the BZip2 compression algorithm.
  

v2005.0.2

• Added support for Delphi 2005.
• TZipTV & TUnTar: Included support for tar filenames greater than the header limitation of 100 chars.
• ** 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.

v7.4

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.

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

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.

v7.2

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 AES algorithm is vulnerable to the brute force attack).
2. Decompressors -> " OnGetPassword" event change: 
   
   In the demos\maindemo\MainDemo.dpr application, we assign the new seed keys (both header and data keys) within this event.
   
   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;
   
   See the following demonstration app for usage of the new HeaderKeys & DataKeys parameters:
      Demo:  demos\MainDemo.dpr
      Unit:  main.pas
      Procedure: TfrmMain.UnZIP1GetPassword
   
3. New Properties:
   * SeedHeaderKeys (TZip, TJar, TBlakHole, TZipSplitter, TZipTV, TUnZip, TUnJar,   TUnBh TZipSearch TZipCheck, TZipRun components)  
   * 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;
   
   

1. 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 three seedkey values hard coded into
   every zip application whose values are:
   
   Key 0: 305419896
   Key 1: 591751049
   Key 2: 878082192
   
   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:
   
   
   
2. ------ Possible combinations -------
   

   CharSets Propperty	Char set	Number of chars	Combinations 4 character password	Combinations 5 character password
   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 possible 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-key values, using the same csFullSet, 5 char password.  The possible combinations are OFF THE CHART . Before we can begin a brute force search for the chars 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 impossible, but with numbers that large, 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). The AES encryption method was selected as the most secure data encryption method currently in use, but it was just as vulnerable to the TZipKey component's brute force attack as the original zipv2 algorithm was...with the exact findings as the above chart.
   
   My opinion is that the ZipV2 encryption (when the 3 seedkeys are assigned unique values) is the most secure algorithm, which was formed by gathering of fact and charting the numbers. Study the algorithm... it's simply irreversible... can't be done... impossible. There are those that have seen the brute force method and without further research conclude to replace the algorithm, generally with an even more vonerable algorithm.
   
   The use of Seed-Keys and it's security
   The use of unique seed keys does come with a cost.  If the three revised seed-keys used to encrypt the compressed fiiles were lost, there is absolutely no way to decrypt and decompress the archive.  The compressed data is simply lost. Isn't this really the whole object of secure encryption? If an intruder doesn't possess the correct entry information, the data can not not be decrypted? Is this heightened level of security worth the cost? The US Military thinks so.  They have been using seedkeys for encrypting classified, top secret materials and secure communications for decades.  Unique seedkeys in encryption is at the top of the chain for data security.   Even if your company's three 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.
   
3. TArc2Arc:  ztv[..].tmp files containing the read-only file attribute were not being deleted during cleanup.
   
4. Compress disk-spanning: the OnClearDisk event was revised to
   activate every time when FreeSpace < TotalSpace.
   
5. Support for extraction of files from .cab sfx's (self extractable).  ArcType = atCabExe.
   
6. TArc2Arc: 
• temp files, created from compressed files containing the hidden file-attribute were not being cleaned up (deleted) when TArc2Arc finishes it's task.  Corrected.
• added support for ArcType = atCabExe 9 . Revised TFileScan to include support for filenames beginning with the '.' char.  I.e., ".testing".

• v7.1.3

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


• v7.1.2
  • 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. v7.1.1
  • ztvGbls.pas: Added atB64 to TArcType for support of Base64 decoding.
  • ztvConsts.pas: Added the .mim extension to ExtArray for support of Base64 registry association.
  • 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. 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
    
• v7.1.0
  • The ArchiveComment comment was changed to a stream object (ztvStreams.TCommentStream). It is now much easier to view & edit the archive main comment. For demo, see demos\MainDemo\MainDemo.dpr, units: main.pas and unit7.pas. Search for the ArcCmntStrm stream in these two units.
  • SetComment method changed to SetFileComment (differenciate between a file and archive's main comments).
  • GetComment method changed to GetFileComment (differenciate between a file and archive's main comments).
    
• v7.0.8

  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 (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
  ========= end batch file ==========
  
  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
  
  Prior 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 now is:
  Test1.txt
  Test2.txt
  Sub2\Test3.txt
  Sub2\Test4.txt
  
  Note(s)

  • 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\').
• the use of the sdExplorer_UserDefineDefaultDir setting requires assigning the DefaultDir property a valid existing directory name.
  
• v7.0.7

AES (block cipher Rijndael) encryption revisited.


• v7.0.6

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


• v7.0.5

Buf found in the extraction of AES encoded "stored" (no compression) files. Fixed. ZipTV AES downloads for developers of ZipTV 7.0.1+ (source code version):
Our AES support requires no external dll's!


• v7.0.4

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

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

Fix #2.
[Compress Component].ExcludeSpec property: this property no longer requires a fully qualified path.
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.


• v7.0.3

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


• v7.0.2

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


• v7.0.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 implementation of the Rijndael algorithm.
  • 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.    For an example usage,  see the TZipSplitter component's OnRead event in demos\MainDemo\MainDemo.dpr.
  • Linking ZipTV AES into the ZipTV Components: In Delphi 's project options, set the conditional define as MCSREG. In the source version, f ailure 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)
    *  ZipTV AES is not part of the ZipTV Components and therefore not distributed with ZipTV.  It is a free distribution by Microchip Data Systems to current developers of the ZipTV Components Subscription Edition.  To request the ZipTV AES uniits, send  a blank email to us at the contact link on this site, in the subject write "AES package request".   We'll attach the archive in our response to your email. 
    *  The sources for  AES encryption  are not yet available . Our AES implementation require no external dll's!
    
• v6.8.4

  All compress components - OnDeleteFile Event

  .

  • the value of this event's "count" parameter (count of files deleted... including the current file) started at 0 instead of 1.  Fixed.
  • 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.
    
• v6.8.3
  • TUUEncode & TUUDecode
    Updated for compatibility with .zip multi-volume archives.
  • 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

.zip disk-spanning bug fix.


• v6.8.1
  Decompression components - ExtractToFileStream method

• Bug fix.
• New demo: demos\StreamingDemos\ExtractToFileStream\ExtractToFileStream.dpr
  
• v6.8.0
  • This revision changes some event parameters! Please read! When loading projects developed under previous versions, Delphi 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:
    
    * Write down the component and event names so you can re-install the code from the old, to the new event handler.
    * Let Delphi remove the reference. After the project is loaded:
    * Delete the event definition (but not the event handler - containing the event's code).
    *In the object inspector, double click on the event name ( Delphi should have already removed the reference, so it should be blank)
    * Copy your code from the old to the new event handler.
    * Delete the old event handler (including the code you've copied to the new handler)
    * Inspect the new event handler for changes which may affect the code you've copied to the new handler.
  • 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.     See demos\registerarchive\RegisterArchive.dpr for further information.
  • 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)
  • TZipTV, TZipRun, and 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.
  • 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.
  • ztvInflate.pas and ztvDeflate.pas
    ztvInflate.ztvDecompress_StreamToStream revised
    ztvDeflate.ztvCompress_StreamToStream revised
    
    added demo: demos\StreamingDemos\StreamToStream\StreamToStream.dpr   
  • TZipSplitter Component - OnSplitEnd event
    Parameter revision:     
    
    Old declaration:
    TOnSplitEnd = Procedure(Sender: TObject) Of Object;     
    
    New declaration:
    TOnSplitEnd = Procedure(Sender: TObject; VolumesCreated: Cardinal) Of Object;    
    
• v6.7.1  
• 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;
  
• v6.7.0
  • New component: use TZipSplitGlue, combine a multi-volume .zip achive into a single (non-volume) output .zip archive.
    
• v6.5.5
  • TUnZip: disk-spanning bug arose during development of TarchiveSplitter & TZipSplitter components. Fixed.
  • ZipTV Archive Filter: v1.0 original release.

• v6.5.3-4

  Maintenance of demos

• v6.5.2

  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.
  

• v6.5.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 & cmInMemory.
  

• v6.5.0
  1. Prior to installation (running setup.exe):
     a) remove any previous versions of ZipTV from your Delphi IDE.
     b) close Delphi
     c) uninstall any previous version of ZipTV from your computer. The reason
     for this step is simply to remove the current demo's program group from
     the start menu. ZipTV now uses a program group to load and compile
     all demos at the same time. The previous demo definitions in ZipTV’s
     program group will remain, but as dead links. These need to be removed.
     If you don’t want to uninstall the previous version of ZipTV, delete the
     demo definitions from ZipTV’s program group. Start Menu -> Programs ->
     “ZipTV Components for Delphi [Delphi version].
  2. TZipSplitter: this is the first version where this component can actually &
     reliably replace the TZip component. It has the ability to add & delete files
     from multi-volume zip files.
  3. **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. See the workings of this component in demos:
     
     demos\MainDemo\MainDemo.dpr
     demos\SplitVolumes\ZipSplitter\ZipSplitter.dpr
     In the MainDemo, simply create a zip file. The TZipSplitter component will be used (instead of TZip) by default.
     TArchiveSplitter & TZipSplitter do not at this time support files greater than 4 gig. If this feature is required, use the TZip component.
  4. The sfx stub files have been updated to include the Deflate64 method. These
     stubs will be available after Oct. 1, 2003.
     Note:
     ztv_Rar.sfx requires unRar3.dll
     ztv_Ace.sfx requires unAcev2.dll
  5. Messages passed to the OnError event were updated.
  6. Streaming demos (demos\StreamingDemos\*.dpr) were updated.
  7. Search demos (demos\SearchDemos\*.dpr) were updated.
  8. Bug found and fixed in demos\ClipBoard\ClipBoard.dpr.
  9. TArchiveEditor: bug found and fixed when editing .tar file filenames & dates.
     Demo: demos\ArchiveEditor\ArchiveEditor.dpr.
  10. TUUEncode & TUUDecode : bug found and fixed.
      Demo: demos\uucode\uucode.dpr.
  11. TZipKey : bug found and fixed.
      Demo: demos\ZipKey\ZipKey.dpr.
  12. When compiling DemoGroup.bpg (located in the ZipTV program group. Goto Start, Programs, ZipTV Components for Delphi [version]), remember to set debug options in the projects options, so the projects can be traced into the ZipTV code.
      
      To enable debug of ZipTV, change the following line in ziptv.inc unit:{.$define ENABLE_DEBUG} to{$define ENABLE_DEBUG} ß dot before $define removed
  13. Zip volumes created using TArchiveSplitter & TZipSplitter are compatible with volumes
      created under WinZip’s. 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).
  14. **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.
  15. New streaming functions and features:
      One major aspect of v4 is it's new streaming capabilities. Advanced developers will appreciate the new additions of streaming. Documentation is being updated, and new demos are being developed to demonstrate these new lightening speed, advanced capabilities. At this time, no documentation or examples are provided... they will be forthcoming with the removal of the v4 beta status.
  16. Components added:
      TztvFileScan:
      
      Supports multiple FileSpecs as well as multiple FileMasks (a feature not found in this type component). All compressor components now use TztvFileScan to find files for compression with turbo lightening speed! See new demo demos\filescan\fs_demo.dpr for an example of this new component. It's a good demo for testing the new Attributes & AttributesEx properties in the compressor components.
  17. Renamed units (filenames)
      ztvUnAce.pas -> ztvUnAce2.pas: to reflect the supported ace version.
      ztvArcToArc.pas -> ztvArc2Arc.pas: to follow the component name of TArc2Arc.
      ztvZipIT.pas -> ztvZip.pas: to follow the component name of TZip.
      ztvTypes.pas -> ztvHeaders.pas: unit contains archive headers not variable types.
  18. TZipSearch Component
      • Properties
        
        SearchType property added for better automation of searches.
        
        Type
        TztvSearchType = (stDecompress, stNonArchive, stProtected, stMultiVolume);
        
        stDecompress: decompress archives for searching
        stNonArchive: search non-archive files
        stProtected: activate (or bypass) the OnGetPassword event
        stMultiVolume: activate (or bypass) the following events:
        
        OnGetZipFirstDisk
        OnGetZipNextDisk
        OnGetZipLastDisk
        OnNextVolume
        
        See SetSearchType method in this documentation for a description of how to easily set the members of this new property.
      • Methods
        

      TZipSearch.SetSearchType( SearchType: TztvSearchTypes; Value: Boolean ):
      
      This method simplifies the inclusion and exclusion of SearchType values.
      
      Example:
      Place 4 checkboxes on the from:
      ZipSearch.SetSearchType( stDecompress, CheckBox1.Checked );
      ZipSearch.SetSearchType( stNonArchive, CheckBox2.Checked );
      ZipSearch.SetSearchType( stProtected, CheckBox3.Checked );
      ZipSearch.SetSearchType( stMultiVolume, CheckBox4.Checked );
      

  19. Attributes property (all compression components): allows you to include files into an archive containing specific file attributes.
      
      The SetAttribute method simplifies the setting of the values of Attributes.
      <All Compression Components>.SetAttribute( Attr: TztvFileAttr; value: Boolean );

      Example call:
      <CompressComponent>.SetAttribute( fsArchive, <true>/<false> );
      

  20. AttributesEx property (all compression components): allows you to exclude files from beging compressed into an archive that contains specific file attributes..
      
      The SetAttributeEx method simplifies the setting of the values of AttributesEx.
      <All Compression Components>.SetAttributeEx( Attr: TztvFileAttr; value: Boolean ):

      Example call:
      <CompressComponent>.SetAttributeEx( fsReadOnly, true / false);
      

  21. Added TZipKey.WordListFile: dictionary containing words to scan. Dictionary search capabilities.
  22. TZip.EncryptHeaders property: if true, encrypts archive headers so password retrieval programs can't break the archives password.TMakeSfx does not support encrypted headers. When converting an archive into an executable, all encrypted headers are decrypted before writing the compressed files to the executable. If the archive was created using headers encrypted with a key, the value of the key is required to convert a valid archive, else the conversion will fail.
      
      NOTE(s):
      • Even though we wrote the components, we can not retrieve passwords from archives containing the encrypted headers... any such requests will be ignored. Keys values are not stored in the archive, we simply are unable to decrypt encrypted headers without the key.
      • Archives containing encrypted headers are NOT compatible with other commonly distributed archive utilities / components.
  23. Property Changes:

      All Compression Components:

      • FileAttributes property
        Changed from class TPersistance to an object set definition. (Renamed to Attributes)
        
        TztvFileAttr = ( fsZeroAttr, fsReadOnly, fsHidden, fsSysFile, fsVolumeID, fsDirectory, fsArchive );
        
        TztvFileAttr = Set Of TztvFileAttr;
        
        This change makes file attribute specification more accurate and better compatibility with multiple operating systems. See the new SetAttribute method for a description on how to easily set file attributes.
      • StoredDirNames property
        Old definition:
        TStoredDirNames = ( sdNone, sdAbsolute, sdAbsoluteNoDrv, sdRelative,
        sdRelativeStoreStart, sdExplorer );
        
        New definition:
        TStoredDirNames = ( sdNone, sdAbsolute, sdAbsoluteNoDrv, sdAbsoluteNoRoot, sdRelative, sdRelativeStoreStart, sdExplorer );
      • DefaultDir: property
        This property has been removed. All filenames assigned to the FileSpec property now require the full path + filename.

  24. Event additons and changes
      • TZipSearch and TUnGZip components:
        
        New OnChangeArchive event: this event is activated when a nested .tar archive is extracted from a .gz archive
      • TZipTV.OnTotals
        
        Old definition:
        TOnTotals = Procedure( Sender: TObject; UnpackSize, PackSize, Ratio, NumFiles: Integer ) Of Object;
        
        New definition:
        TOnTotals = Procedure( Sender: TObject; UnpackSize, PackSize: Double; Ratio, NumFiles: Integer ) Of Object;
      • TZip.OnClearDisk
        
        TZip.OnClearDisk(Sender: TObject; Drive: String; RequiredSpace, FreeSpace, TotalSpace: Int64; Var Cancel: Boolean);
      • <Compression Components>.OnRenameDupeFile
        • Renamed from OnRenameDupFile
        • Added parameter "Replace: Boolean". Much easier for the developer to
          understand how to skip the replacement of a compressed file.
        • <compression component>.OnRenameFile: temporarily removed for revisions.
  25. New Capablities & features
      • Now compatible for operation under most web-servers. (Delphi vers 5+ and C++ Builder 5+). Prior compilers are not compatible.
      • TZip, TBlakHoke, and TJar components:
        
        Compression speed has been enhanced by 450%. Compression in versions prior v4.0 were 2.5 times slower than WinZip. Speed tests in this release are, on average, 2 times (200%) faster than WinZip v7.
      • The unregistered version of ZipTV can create, edit, and manage archives as valid archives, but these archives are not compatible with other compression utilities. As long as archives are managed with an application developed using the ZipTV Components, there are no noticible incompatibilities.
  26. TUnAce: now supports archives created using the new WinAce version 2.x