About Self-Extracting EXE’s

A few issues relating to self-extracting EXE’s are explained here:

The Purpose of a Self-Extracting EXE
The purpose of a self-extracting EXE is to provide something that will extract/unpackage files such that no other software is required to be installed on the computer where it is run. Common archive file formats, such as .zip, .tar, etc., all require some sort of utility program to be installed/available on the computer where the archive is to be extracted. Furthermore, the person extracting files from the archive must have knowledge of the utility program (such as WinZip) and must choose where to extract the files. A self-extracting EXE eliminates the need for a pre-installed extractor utility program. It may also help with deciding where the files are to be extracted.

No Standard Format
A self-extracting EXE has no implied file format. Self-extracting EXE’s created by different tools/API’s will (and do) embed file data within the EXE in different ways. It’s technically not important to the end-user how the files are embedded, or the format of the embedded data. The important thing is that when run, the EXE extracts the files. (Sometimes though, developers want to know details about how Chilkat embeds file data within a self-extracting EXE. This will be discussed further below..)

Common Technique: Append a Zip Archive to the .exe
One common technique for creating a self-extracting EXE is to append a Zip archive to the end of an extractor EXE. (This technique is used by tools such as WinZip. It is not the technique used by Chilkat, for reasons discussed further below.) Windows EXE’s will still run even if extra data is appended to the end. The extractor EXE opens the zip located at the end of it’s EXE and unzips, possibly displaying a dialog to prompt for the extract path.

Self-extracting EXE’s created using this technique can be opened by Chilkat Zip via the OpenZip method. The reason is that if OpenZip does not find the 4-byte “Zip signature” at the very start of the file, it will scan the file until it finds the Zip start, and then open it.

Embedding a Zip Archive as a Windows Resource
Another technique is to embed a Zip archive as a Resource within an exe. One issue is that it may introduce size limitations, but this would only come into play if the .zip were very large, perhaps more than a gigabyte.

The OpenZip method should be able to open Zip archives embedded as a resource in the same way as describe above (by scanning for the Zip signature marker).

Chilkat Zip provides methods for adding/replacing/removing a .zip resource in an EXE: AddEmbedded, ReplaceEmbedded, RemoveEmbedded. It also provides methods for opening .zip’s stored in an EXE: OpenEmbedded, OpenMyEmbedded. The OpenMyEmbedded method can open a .zip stored in the caller’s own EXE. It provides a way for one to create a custom self-extract application that will open the .zip stored within itself by calling OpenMyEmbedded. The custom self-extract application is compiled and linked. The post-link step is to “inject” the self-extract application with a .zip using another simple application (written by you) that calls AddEmbedded.

Chilkat’s Self-Extracting EXE Format

The internal format of the self-extracting EXE’s produced by Chilkat Zip’s WriteExe method, or by the Zip-2-Secure-EXE utility program is (at this point) proprietary and undocumented. Chilkat decided against using a .zip file format internal to the EXE for two reasons: complexities due to 64-bit size issues, and complexities/limitations involving Unicode filenames. The undocumented Chilkat format is a very simple compressed streaming file format (more similar to TAR, but with compression and far simpler) with no limitations on file sizes, number of files, Unicode filenames, etc. It also self-optimizes by compressing files in chunks. If a file does not compress well after the first few chunks (such as with already-compressed format such as JPG, PDF, etc.) then it will suppress compression for a time and re-sample periodically to see if compression should resume or not. The intent is to get the best trade-off automatically between compression and performance.

A self-extracting EXE created by Chilkat Zip, or by Chilkat’s Zip-2-Secure-EXE utility program cannot be opened by WinZip, 7-Zip, or any other “zip” tool, including Chilkat Zip. (Chilkat may in the future add functionality to “open-and-extract” a Chilkat-created self-extracting EXE.)

Adding a Manifest to the EXE

In a few cases, Chilkat customers have needed to add a manifest to the self-extracting EXE produced by Chilkat. Adding a manifest is a post-link build step, and unfortunately the manifest must come before the self-extract file data, and the “mt.exe” program has the side-effect of eliminating the file data. I will describe a technique for adding a manifest. Unfortunately, at the time of this writing, it requires a bit of extra work on your part:

When the self-extracting EXE runs, it scans itself looking for a marker — a sequence of bytes – that marks the beginning of the compressed data. (If it’s not found, you get the “failed to find marker” error.)
You’ll need to write a program that scans for the marker, chops the EXE in to two parts (the EXE and the data), you could then run mt.exe on the EXE part, then re-join the two.

The marker is 8 bytes:
07D26CBF 2159ABAA

Scan for this marker, chop the EXE into two files — the first is everything up to but not including the marker, the 2nd is the marker and everything after. Run mt.exe on the 1st file. Then re-join the two.

False-positives as Trojans/Viruses

One unfortunate problem with using self-extracting EXE’s is that there is always a small risk that your self-extracting EXE will be flagged as a Trojan/virus by various Anti-virus vendors. It’s a very small risk, but it does happen from time to time, and it applies to EXE’s created by any tool (Chilkat or non-Chilkat). The best solution is to immediately report these problems to the anti-virus vendor. Most are very responsive and fix false-positives quickly.

Not Intended as a Full-Blown Setup/Install Solution

A self-extracting EXE is a reasonable solution for distributing software with relatively simple “install” needs. The Chilkat self-extracting EXE API and tool provides some install/setup related features, but it is not intended to be a full-blown setup/install solution.

Using DOS Environment Variables in Self-Extracting EXE’s

This post pertains to using the Chilkat Self-Extracting EXE utility.

The goal is to create a self-extracting EXE such that the files are unzipped into the directory where the EXE is located.  To do this, the %CD% environment variable is used in a DOS command line.

The intent is to use the -d option with “%CD%” so that the environment variable is run when the self-extracting EXE runs — but NOT when creating the self-extracting EXE.  The trick is to use a double-percent sign:

In batch files, the percent sign may be "escaped" by using a double percent sign ( %% ).
That way, a single percent sign will be used within the command line.

The DOS command to create the self-extracting EXE might look like this:

CHILKATZIPSE.EXE -u myUnlockCode -autoexit -d %%CD%% -sm -sp -RUN doSomething.bat myApp.zip

Debugging Self-Extracting Executables at Runtime


Some of our users are reporting that the self-extracting file reports
“Failed to extract file”. The user has admin access to the file system and
the file is not corrupted.


When running the self-extracting EXE, use the “-log” command line option to generate a log file with error information. If the reason for failure is not clear, send it to support@chilkatsoft.com.

Example of a .bat file using -log:

mySelfExtractor -log errorLog.txt

UI-less Self-Extracting EXE

The most common question regarding Chilkat self-extracting EXE’s is: How do I create a silent extractor that runs a “setup” program after extracting?

Here is a sample command line that creates a silent self-extracting EXE:

ChilkatZipSE -u unlockCode -a -sm -sp -nowait -r setup.exe -exe a.exe a.zip
  1. The “-r” option is used to specify the name of a setup program found within the .zip that is being converted to a self-extracting EXE.
  2. The “-a” option is for creating a self-extracting EXE that will automatically extract to an automatically-chosen temp directory. If “-a” is used but “-r” is NOT USED, then the resulting EXE *will* display a dialog. The reason is that it makes no sense to extract to some unknown temp directory unless there is a setup program that can do something with the extracted files.
  3. The “-sm” option is for creating a self-extracting EXE that suppresses the main dialog.
  4. The “-sp” option is for creating a self-extracting EXE that suppresses the progress dialog.
  5. The “-nowait” option allows the self-extracting process to exit before the setup.exe program completes.
  6. The “-exe” option specifies the name of the self-extracting EXE to be created. If omitted, the EXE produced has the same name as the .zip but with a .exe extension.

Some Important Notes: If the embedded setup EXE does not run, try running the self-extracting EXE with a “-log” runtime option to see what happened. For example:

a.exe -log whatHappened.log