Onrush of the modern software development, and also wide Internet availability, have made usual the frequent release of new versions of software programs. Prompt bugs / mistakes correction and feature adding are those major factors which compel manufacturers to modify their software products on a frequent basis. And if the overall size of the distribution package of a software product is quite sizeable, then the necessity to download the full new version distribution package can become an expensive and tiresome procedure for end-users.
Most often, the size of the brought changes from the version to version is significantly less than the size of the full distribution package, so many developers could thought that it would be really a good idea to have an opportunity to implement software updating by delivering to end-users only those, presumably small changes by size which distinguish the new version from the version already installed on the end-user's machine. Well, an attempt to reduce the update data size as much as possible is praiseworthy. However, how to make it really effective? In case of the text data, everything is clear. There are a lot of excellent algorithms for text files comparing. And even more the text data can be compressed effectively. But if you need to build an update package for executable files (exe, dll) then you will find out that these algorithms are completely powerless to make something worthwhile. Effective comparison of executable files or any other binary files requires absolutely other approaches. We'll use "binary file" phrase to define files which structure is obviously unknown. Such files are considered as an arbitrary octet-byte stream.
So, when an update must be provided for the end-users of an application, a developer has several choices:
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 the most common approach used. But for large packages, this can appear to be inappropriate for some customers who need the update immediately, so that you require them to download a large file (or even a collection of files), in spite of the fact that only a relatively small number of changes have been made to specific parts of the application files. You may also send new media to your customers, incurring additional costs related to delivering the updated software.
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 of the application, it can introduce several problems of its own. This method requires that a developer creates a new distribution package which consists of only modified files. If a new version consists of changes made to several large files, or contains a significant number of modified files, then benefits of incremental updating are reduced significantly. And moreover, incremental updating has the potential for introducing problems where critical system libraries or shared components are updated. The developer must make sure that only the appropriate versions of the target files are being overwritten when the update is applied. If the update takes no notice that a file which needs to be overwritten is not of the correct version, it can result in application fail unexpectedly or even general system instability.
Creating a patch is the process of two files comparing, the original and an updated file, and the following returning only of the bytes that have been changed. The resulting patch file consists only of the changes from within each individual file with the help of byte-level differencing technology used by our patching engine, resulting in a significantly smaller update size. 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 end-user's machine and the files are updated to the current version. The patch application process also ensures that the correct files are updated and that the updates are being applied correctly.
Clearly, the most advantageous choice for both the developer and the users is to pack the update as a patch, rather than re-deploying of the entire distribution package or creating an installation package for incremental updating. This approach minimizes the amount of time the developer spends creating and deploying the update, and significantly reduces the size of the update and the amount of downtime that the customer experiences while the application is being updated. And as a result, using patching you can to significantly reduce end-user support costs.
DF SDK is developed to effectively accomplish a "binary files updating/patching" task.
If you are familiar with such standard utilities of the UNIX system as diff and patch then we could say that functionality of DF SDK can accomplish the same task though there is a significant difference: DF SDK effectively operates not only with text but with all binary files.