Q: Why should I use reversible compression or keep backups of the
uncompressed executable file?
A: Even when a program compresses and works perfectly, you should consider
keeping an uncompressed backup of the program on archival storage. Here are some
reasons why:
1) Bug fixes and updates: some vendors supply updates through a patching
mechanism. The upgrades won’t install successfully unless the files are exactly
the same size and have the same contents as when they were installed.
2) Features: though a program may appear to work at first, some features might
not work and it won't be apparent until you use that particular feature.
3) Competitive upgrades: some vendors require you to have the old version of a
program installed (or expect to find a competitor's program installed) before
they will allow you to install an upgrade version. If the size of certain files
don't match what's expected by the upgrade's install program, the installation
could fail.
Q: Why do some programs compress without errors, then fail when they are
run?
A: Typically, this happens when the code in the program examines its own
executable or another executable file, and that file has been compressed. The
code might be looking for special run-time resources, self-extracting data, or
interpreted code. ExeLock has options that allow you to preserve extra data
beyond the end of the executable image, but just preserving that data might not
be enough to allow the program to find it. For example, before the data is
appended, the program could write a pointer to the starting address of the data
somewhere into the data. This pointer would be a fixed value and become
incorrect when the file size decreases. Using DataSim will fix this problem.
ExeLock automatically detects the most obvious case of appended data that
contains a final pointer to the end of the executable image. It automatically
preserves this type of data, appending it beyond the end of the compressed data,
and repairing the final address to point to the data's new starting location. In
other cases, you might want to experiment with the DataSim options. In some
cases programs perform a self-test when they first start. This is to ensure the
program has not been modified, intentionally or otherwise. When the program
finds that its size has changed or that it fails a checksum test it quits with
an error. This is fairly uncommon.
Q: What is a ‘Compatibility error’?
A: When ExeLock was written and tested we examined and tested a wide variety
of executable files produced by many different development environments. However
some of the more obscure features of the executable file format were never
encountered, so it was not possible for us to ensure that our program would work
if these features were used. To be as safe as possible, these cases are flagged
as ‘Compatibility errors’ and given a unique error code. By reporting the code
to StratusBurg, as well as the version of ExeLock that you used, and providing a
copy of the executable that you were compressing (if possible), we can make sure
that we properly handle these uncommon cases.
Q: Why is compression slow?
A: Since you’ll probably only compress a given file once, we opted to
maximize compression at the expense of speed, so that you end up with the
smallest possible files. Decompression speed is not affected. There is an option
for fast compression, which you might find useful when experimenting with
different compression options for compatibility testing. Depending on the speed
of your computer the difference between normal and quick compression will vary.
Q: Do the compressed files use more memory?
A: Once uncompressed and running, compressed executables have the same memory
usage as the original executables, in most cases. In some cases, where critical
portions of the executable were rearranged to improve the amount of compression,
they might use very slightly more memory. Depending on the operating system,
compressed executables might use more swap file space, because the operating
system can no longer retrieve read-only pages (such as the program's code) from
the .exe file which have been paged out, since they would need to be
uncompressed. Instead, it reads and writes them to the swap file.
Q: What is ‘exe relocation information’ and why would I want to preserve it?
A: Relocation information allows the system loader to place an executable
image at different locations in memory. Typically, executables are always loaded
at a standard address, so there is no need for relocation information. Dynamic
Link Libraries, on the other hand, require this information because they might
be loaded anywhere, therefore this option is not available when compressing a
DLL. Some specialized applications might require the preservation of relocation
information, even in an .exe, in order to run properly. Turning on this option
might be useful if you find that a compressed program will not run.
Q: What is the ‘import table’ and why would I want to leave it uncompressed?
A: The import table describes the Dynamic Link Libraries which an executable
needs to have loaded before the program can run and includes the name of the
library and the description of the functions in that library which the program
may call. If you find a program that won’t run when compressed with the default
options, try disabling import table compression to see if that fixes the
problem. Some utility programs dynamically modify other programs to add features
to them. For example, there are utilities that allow programs that directly
access the Internet to instead access it through a "proxy server" even when the
programs themselves don’t have proxy support. Such utilities probably won’t work
on programs whose import tables have been compressed.
Q: After I compress my OCX it doesn't register, how can I get it to work?
A: Windows needs to view information attached to the OCX to be able to
register it correctly. You must set two compression options; compress NO icons,
and do NOT compress ’other resources’.
|