.NETZ Compression Providers

.NETZ supports different compression libraries (providers). A compression provider is implemented as a .NET DLL file. Users can also define their own custom compression providers. By default the defcomp.dll compression provider is used. To specify a different compression provider use the -r option, or rename the provider's DLL to defcomp.dll.

Some providers may need that you distribute an additional DLL file with the packed application (e.g., the defcomp.dll uses zip.dll). Check out the help for the -z and -l options, to respectively pack or rename the provider's redistributable DLL (if any).

The default compression provider defcomp.dll, that comes with .NETZ, relies on the open source #ZipLib compression library for .NET to compress the executable data.

The #ZipLib (Default) compression provider uses ZIP compression for EXE files and achieves about 60% size reduction. The provider needs to distribute a reduced version of #ZipLib (zip.dll) with the packed applications. The #ZipLib license allows you to distribute zip.dll with closed-source commercial applications packed with .NETZ. The source code of the reduced #ZipLib version for zip.dll can be downloaded from ziplib-src.zip (~200KB). This source code comes under GPL.

The size of zip.dll is about 65KB. This means that it makes no sense to try to pack with the default compression provider applications smaller than 150KB. Use the default compression provider of .NETZ only for applications bigger than 150KB.

You have to distribute the zip.dll file that comes with .NETZ with the packed version of the application that uses the default provider. You cannot compress the zip.dll file, but you can pack it with the -z option.

The (default) #ZipLib compression provider works with any .NET version.

The .NET 2.0 compression provider (net20comp.dll) that comes with .NETZ, uses the .NET 2.0 System.IO.Compression.DeflateStream class. It cannot be used for .NET applications compiled with older versions of .NET.

This provider does not require that you redistribute any DLL file with the packed applications, so you do not need to use the .NETZ -z and -l options for it.

The .NET 2.0 compression has a worse compression level (3), than the default #ZipLib compression provider (9).

Use the .NETZ -! option to find out the .NET runtime version under which .NETZ is being run.

You may need to create a custom compression provider when:

• You have a compression library, that does better than the compression providers that come with .NETZ.
• You want to do some custom processing of the data apart of compression. For example, you may encrypt the data when you compress them and decrypt them at run time. .NETZ offers no default schema for the protection of data. You can implement your own schema by implementing a custom compression provider.

Compression Provider Implementation Details

For a complete example, on how to implement a compression provider, see the source code for the defcomp.dll and net20comp.dll in the .NETZ source distribution.

A .NETZ compression provider is a .NET DLL that contains a class type that implements the netz.compress.ICompress interface, shown below. Being .NET DLLs, the compression providers can be implemented in any .NET language (apart of MC++). The templates discussed below, however, must be in C#.

namespace netz.compress
{
	public interface ICompress
	{
		long Compress(string src, string dst);
		string GetRedistributableDLLPath();
		string GetHeadTemplate();
		string GetBodyTemplate();
	}//EOI
}

The netz.compress.ICompress interface definition is found inside the netz.exe file, so if you plan to create your own provider, link the compression provider DLL with netz.exe. The methods of this interface are called by the .NETZ tool. The compression provider class should have also a default constructor with no parameters.

A short description of the ICompress interface follows:

• The Compress() method compresses the source (src) file to a destination (dst) file. This method will be used by .NETZ to compress an EXE or DLL to a temporary file. The length of the compressed file (dest) in bytes must be returned.
• The GetRedistributableDLLPath() method returns the name of the decompression DLL file that .NETZ may need to redistribute with the packed application. For #ZipLib, this file is named zip.dll. Not every provider may have a redistributable DLL. In this case this method should return null. The .NETZ -l option overwrites the strings returned by this method. The .NETZ -z option, embeds the redistributable DLL (if any) as resource in the packed application. The redistributable DLL should be as small as possible. It should contain only the functionality required by the decompression code (see GetBodyTemplate()).
• The .NETZ starter code for the packed application decompresses the data. The starter code is actually a C# source code template, re-compiled by .NETZ for every packed application. The decompression code must be specified, thus, as C# code by the GetBodyTemplate() method. The code must be the implementation of this method:
  

  	private static MemoryStream UnZip(byte[] data)
  	{
  //#ZIPBODY
  	}
  

  
  That is, a compressed byte[] vector data, should be decompressed into a System.IO.MemoryStream object and this object should be returned.
• If additional namespaces, apart of the following:
  

  using System;
  using System.IO;
  using System.Resources;
  using System.Reflection;
  using System.Collections.Specialized;
  

  
  are needed by the code inside the body template returned by the GetBodyTemplate() method, then these namespace usage sentences, must be specified in C# syntax (similar to the example above), by the GetHeadTemplate() method.

The C# templates returned by the GetBodyTemplate() and the GetHeadTemplate() methods, can be packed as string resources in the compression provider DLL. See the implementation of defcomp.dll for an example.

Please check out: Encryption and Assembly Protection.

.NETZ does not-in-place decompression of the compressed data. This means that the applications packed with .NETZ require slightly more virtual memory than the original unpacked versions. This is usually not a problem, because .NET frees the memory lazily as needed.