Introducing ExeLock
Program Requirements
What Is ExeLock?
Getting Help
How May I Use It?
What Is Included?
Step By Step
Basic Encapsulation
Apply a Password
Apply a Time Trial
Register a Time Trial User
The GUI in Detail
The ExeLock GUI
Executable Selection
Basic Settings
Compression Settings
Password Protection
Evaluation Settings
Command Line Usage
GenerateKey
Appendices
Common Questions
Password Encryption Details
Error Messages
End User License Agreement

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



Copyright ©2002 StratusBurg LLC.