Onrush of the modern software development, and also wide Internet availability, have made a standard practice the frequent release of new versions of software programs. Prompt bugs / mistakes correction and feature adding are those major factors which oblige manufacturers to modify their software products and release updates 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 brought changes from version to version is significantly smaller 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 moreover, the text data can be effectively compressed using well-known algorithms. But if you have to build an update package for executable files (exe, dll) then you'll see that those algorithms are completely useless to make something worthwhile.
Effective comparison of executable files or any other binary files requires absolutely other approaches. We'll use "binary file" to define files which structure is obviously unknown. Such files are considered as an arbitrary octet-byte stream.
Aspects of the software updating problem...
A problem of effective comparing of binary files is not the only one in the view of the software update task. The most important aspects which are really worthy of notice are automation of patch building and delivery of the update module to end-users.
Let's assume, that to some point of time the number of versions of your program has reached 21. It is obvious that a process of patch building for these 20 versions and the following publishing of those patches on the Internet will be quite complicated even if you have a files/catalogues comparing tool like PatchFactory v2.
Let's have a look what an end-user should perform to update a software product:
|·||define the installed version number;|
|·||go to your web-site to make sure that a newer version exists;|
|·||probably he would like to read the changes history for the newer version comparing to the version he already has;|
|·||find in the published list the required version update;|
|·||download and install the update package.|
It is really impressing, isn't it?
And moreover active users of your program would like to receive new versions as soon as possible, having applied from their part to this process a minimum of efforts. And this wish is really reasonable!
PatchFactory v3 as a solution of software updating problem...
Projecting PatchFactory v3, we have set the developing of such product which provides automating of all stages of a software product, or even any other binary data update cycle (as fully as it can be possible) as our primary aim. Hereinafter, let's assume the certain set of operations including preparing of the update data, its publishing on the web-site and/or direct transfer to end-users, and also patch applying as an update cycle. Please refer to Concepts and definitions section of this manual.
Patch applying is a final stage of this update cycle which, actually, provides appearance of the required version of the software program or any other essential data on the end-users side.
There are no doubts that a task set is not so simple, as to find a completely universal decision is hardly possible. However, trying to offer a good enough decision covering the large class of subtasks of updating is quite feasible.