ActivePatch Developer's Guide - Introduction

Software development has grown increasingly complex, resulting in larger applications and increasing dependency on components and shared libraries. This problem is particularly acute on the Windows family of platforms, which have a large number of interdependencies between system components, shared application components and the application programs themselves. This results in a large installation package that contains all of the required components, which is then copied to the target system if the installer determines that those files need to be created or updated. The size of the initial package may not be a concern to the developer, particularly if the product itself is distributed on media such as CD-ROMs. However, there will come a point when that product needs to be updated to include fixed defects, additional features or changes to data files used by the application. For many applications, it may also be necessary to distribute interim updates to correct unexpected failures, and those updates must be made immediately available to users, without waiting for the release of the next version of the product.

At this point, when an update must be made available to the users of an application, the developer has several choices:

Re-Packaging

Create a complete installation package for the application and make it available for download, or issue new media that contains the updated software. This is the simplest, and unfortunately the most common, approach used by application developers. For large packages, this puts an unnecessary burden on the customer who needs the update immediately, requiring them to download a large file (or collection of files) when only a relatively small number of changes have been made to specific parts of the software. Alternatively, the developer may send new media to their customer, incurring additional costs related to delivering the updated software.

Incremental Updates

Although many companies refer to this method as a "patch", an incremental update of the package involves redistributing only those files which have changed since the previous release. While this approach is an improvement over re-packaging the application, it can introduce several problems of its own. This method requires that the developer create a new distribution package (or "setup") which consists of the modified files. If the new version consists of changes to several large files, or contains a significant number of modified files, then the benefits of incremental updating are significantly reduced. And, incremental updating has the potential for introducing problems where critical system libraries or shared components are updated. The developer must make certain that only the appropriate versions of the target files are being overwritten when the update is applied. If the update inadvertently overwrites a file that is not the correct version, it can result in the application failing unexpectedly or general system instability.

Patching

Creating a patch is the process of comparing two files, the original and an updated file, and returning only the bytes that have changed. A patch file consists of a sequence of instructions and data which is used to convert the contents of the original file into the updated file using the fewest number of bytes possible. When multiple files need to be updated, the collection of individual patches are then collected in a single file called a patch package. This patch package is then applied on the user's system and the files are updated to the current version. The patch application process also ensures that the correct files are being updated and that the updates are being applied correctly.

Clearly, the most advantageous choice for both the developer and the users is to package the update as a patch, rather than re-deploying the entire package or creating a new installation package as an incremental update. This approach minimizes the amount of time the developer must spend creating and deploying the update, and it significantly reduces both the size of the update and the amount of downtime that the customer experiences while the application is being updated. In turn, the customer is more inclined to install the update, which reduces support costs for the developer.