Once a software product has been released into the field, it's inevitable that software development companies will want to fix problems, add features, solve unforeseen compatibility issues, and fix security holes. That's why a binary patch maker (http://www.indigorose.com/products/visual-patch/) belongs in the software development tool kit of every programmer.
Benefits of Patching
The role of patches in the software deployment life-cycle is to get already installed software up to date after it becomes outdated. Patching technology offers numerous benefits over simply redistributing new versions of the original software in whole form.
Smaller file size
Because they only contain the data that has changed from one version to another, patches can be much smaller than a full software installer needs to be. Especially in situations where large data files are involved, the savings are often dramatic-patches that are less than 1% of the original file sizes are possible.
Reduced bandwidth
Smaller file sizes translate into reduced bandwidth costs, and reducing the amount of traffic leaves more bandwidth for other services.
Faster transmission speeds
Having less data to transmit means that updates can be sent and received faster, which means less time is spent waiting for updates.
Security
The best way to protect information during transmission is to never transmit it in the first place. By only transmitting the data that has changed, patches reduce the risk of third-party interception. Even if some hypothetical future technology made it possible to "crack" the encryption methods used to package the changes, the unchanged data would remain safe.
Integrity
A patch can't update something that isn't there. If a user doesn't already have your software installed, they won't be able to apply the patch. And if someone is using a modified version of a file, that file won't be updated-unless you expressly permit it when you design your patch.
Patching Methods
There are two basic methods that can be used to update a file: binary patching, and whole-file patching.
Binary Patching
Binary patching or "delta compression" involves analyzing two versions of a file in order to extract only the data that has changed. The same changes can then be applied to any file that matches the old version, in order to "transform" it into the new version.
Creating a binary patch involves performing a byte-by-byte comparison between the original file and the new file, and then encoding the differences into a difference file. Each difference file contains the actual bytes that are different in the new file, along with a number of instructions that describe which bytes need to change, and which bytes are the same. This information is said to be encoded into the difference file.
Tip: The term "difference file" is often shortened to "diff file" or just "diff."
When the patch is applied, the difference file is decoded, and the instructions are used to build the new file by copying the "unchanged" data out of the old file, along with the "changed" data that was encoded into the difference file.
For example, given an old file "A" and a new file "B," a binary patching engine would compare A to B and then produce a difference file; let's call it "AB.diff." Once the difference file is created, you can use it to create the B file from any file that matches the A file. In fact, the binary patching engine could recreate B using A and AB.diff.
Because binary patching only stores the parts that have changed, the difference files can be very small-often less than one percent of the new file's size. The size of the difference file depends entirely on how much data has changed between the two versions.
Each difference file can update a single, specific version of a file to another single, specific version of that file. The encoded instructions in the difference file are only valid for a file that is a perfect match of the original source file. Note that binary patching cannot be used to update a file if it has been modified in any way.
For patches that need to update multiple files, the patch executable will need to contain a separate difference file for each file that needs to be updated. So, for example, to update a single file from version 1.0 or 1.1 to version 1.2, using a single patch executable, it would need to contain one difference file to go from 1.0 to 1.2, and another to go from 1.1 to 1.2.
In most cases, the difference files are so small that you can fit a lot of versions into a single patch executable and still use less space than you would by just including the whole file, as in whole-file patching (see below).
Note: An advanced patch maker like Indigo Rose's Visual Patch will automatically switch from binary to whole-file patching on a file-by-file basis whenever the total size of all the difference files surpasses the size of the whole file.
Whole-File Patching
Whole-file patching operates on a different principle. Instead of only containing the parts that have changed (as binary patches do), whole-file patches just copy the entire file. The "patch" is just a copy of the new version.
Whole-file patches can be faster to apply, because they don't have to search through the original file in order to copy the parts that haven't changed to the new version. They just overwrite the old file with the new one. The downside, of course, is that whole-file patches tend to be much larger than binary patches.
There are, however, two situations where whole-file patches can actually be smaller: when creating a single patch file that is able to update many different versions, and when the files being patched are too dissimilar.
A smart patch maker like Visual Patch http://www.indigorose.com/products/visual-patch/ chooses the patching method that produces the best results. It automatically switches between binary patching and whole-file patching on a file-by-file basis in order to produces the smallest patch possible for your project.
