BinPatch Classic V3.0
(14. release for DOS, Win3.1, Win95, Win/NT, OS/2 and Linux on 23-January-99, last minor
update April 99)
Table of contents for this document:
BinPatch is a software package containing two essential items for updating binary files by only transmitting the differences in the form of a patch file: extract the differences with one program, GenPatch, and apply the difference file with another, DoPatch. GenPatch generates so-called patch files from sources and DoPatch applies them into targets. The patch files carry the differences between selected sources and leave out the previous data. You can choose creating either executable or "plain" patch files. Executable patch files provide updaters that are applied by starting them like you would with any program. Plain patch files are applied with DoPatch. You can create patch files to update complete directory structures with just one updater. Or, create updaters for several different versions of a software with only one patch file, too. If needed, you can use the built-in support for preserving serial number information in files while updating them.
Compare the full version size and the BinPatch-created patch file and you will see why using BinPatch is compelling. The rates you can achieve are so immense that you can even update multi-megabyte software releases with just a few kilobytes - and, to boot, immediately available per email or the Internet. Extremely good rates are typical with program files, DLLs, text files and databases.
Even though your program might have undergone a lot of changes, actual alteration is minimal. The changes occurring from an older version to a newer version of any file usually are small. Most parts remain (almost) unchanged, even with software that looks very different, since huge parts of modern programs are derived from compiler libraries. Windows programs, especially, associate much of their file size from libraries. So why not try for yourself and see how much BinPatch can manage your software!
One thing that you have to consider though, is that BinPatch cannot work (efficiently) with compressed or encrypted data. This is not a bug nor a missing feature, because the purpose of BinPatch is precisely that - to do the same process in a different manner. Encrypted or compressed files change their contents almost completely, if you change even a single byte. Unpack archives before you create patches. A remarkable philosophy behind BinPatch is its ability to work on "living" software installations. In fact, this is what makes using BinPatch so appealing. You need not reinstall software.
Especially for creating and releasing software-updates, BinPatch might be very useful to you. It saves your customers a lot of time and money when receiving bug fixes, updates / newer versions. Why should your customers or Beta-testers receive lots of megabytes, if you could spare them the redundant data and instead send them only a few kilobytes - of patches.
Please be sure to read the Patching Feature Highlight section so that you don't miss the many sophisticated features of BinPatch. This section covers only the very basic usage of BinPatch. Nevertheless, you will be astonished as to what can already achieve at this level.
BinPatch can work with complete directories or simple files. However, the most common application of GenPatch is to create a patch file that updates one file into another version. Say you have two similar files "OLD.EXE" and "NEW.EXE" and the patch should transform "OLD.EXE" into "NEW.EXE". All you needed to supply GenPatch are both filenames and a name for the patch file to be generated. Let's choose "OLD2NEW" for this purpose, then all you need to provide on the commandline (assuming that GenPatch is in your system path) is:
> GenPatch OLD.EXE NEW.EXE OLD2NEW
and you have your patch file.
Normally the patch file will have the suffix ".utp" that indicates it is a plain patch file. Creating executable patch files requires you to add an option to the GenPatch commandline. Choose "-s" for a commandline interface and "-s=gui" for a windows interface for your patch file.
> GenPatch OLD.EXE NEW.EXE OLD2NEW -s=gui
and you have your executable patch file with windows interface. This assumes, of course, that you are using the DOS/Windows3.1 or Windows95/NT version of BinPatch. This time the patch file will have the ".exe" suffix and you may execute it by double-clicking or starting it from the commandline.
To apply your patch file you have several options. If it's executable, simply start it and that's it. If it's a plain patch file you may choose from one of these example commandlines, each achieving different results:
> DoPatch OLD2NEW.UTP OLD.EXE PATCHED.EXE > DoPatch OLD2NEW.UTP OLD.EXE > DoPatch OLD2NEW.UTP -auto
The first one creates a new file, "PATCHED.EXE," by applying the patch file to "OLD.EXE" which remains unchanged. The second applies the patch to "OLD.EXE" and replaces it in the process. "OLD.EXE" will now be identical to "NEW.EXE".
The last one is somewhat special, in that it enables the "Autofind" feature of DoPatch to scan your files for the target file. It will present all files that are identical to "NEW.EXE" or files where the patch file could be applied. Executable patch files, on the other hand, will always make an autofind for the comfort of customers.
A typical case for distributing a software package is patching complete directories or even whole directory structures. Internally, the processing of BinPatch is done differently, but this is transparent to the user. Just give the path of the two directories and name the patch file to be generated to GenPatch like you learned above with single file patches. You might want to learn about the "Autodetection of best matching source files" that GenPatch performs with directories. Relax - there are many options for you to be able to control the operation. Be sure to read the sections on these topics found in the table of contents.
When applying the patch file (exactly as with files, you'd only supply directories) and all old data will be moved into a new subdirectory "backup" (which you may choose yourself) and the files in OLD_DIR will be updated as needed.
To patch several different files or directories, you just need to supply more than one source for GenPatch. So the simple command:
> GenPatch OLD_DIR1 OLD_DIR2 OLD_DIR3 OLD_DIR4 NEW_DIR OLD2NEW
will create a patch file to update any or mixtures of all those OLD_DIRs to NEW_DIR. The logic behind this is simple. The last parameter is the filename for the patch, the one before it is the destination and all those before are sources. Even in this case, GenPatch will autodetect best matches for files in NEW_DIR to patch from.
GenPatch allows you to create two different types of patches. The so-called "File Patch" will change a single file on the enduser's computer and not much more. Oftentimes, however, you will want to change more than a single file. You can do this by creating a "Directory Patch". Although this sounds complicated, creating them is actually very simple. Select directories as source and target if you want to update a directory just as you would file(s) as source and target if you want to update a file. GenPatch checks if all files are of the same type (mixing directories and files will lead to an error report) and creates the appropriate type of patch file.
When GenPatch handles directories it scans through the target directory and handles all files found. Due to a special feature called "Autodetection" it is able to find the ideal sources itself and not based on matching filenames. You may want to disable this feature in case you are not satisfied with its choices. Also you may not want to process all files or ignore some file types. If so please read these chapters too: Autodetection of best matching source for a target file, ignore files by pattern, specify files that should be tolerated to fail, forcing identical files to be patched.
GenPatch allows you to create patch files to update a single acceptable source, but you may also create patch files to update several different versions at once. You simply do this be specifying more than one source. So instead of "genpatch source target patchname" you would use "genpatch source1 source2 source3 target patchname" to update e.g. 3 different sources to a target. This is the so-called "Multiversion patch".
Creating a Multiversion patch file will work not only for single files but also for directories. Please read the chapter "Single files or complete directories at once." above, if you have not done so before. GenPatch selects "paths" to create a file from available files and ensures that the patch file can be applied to all versions on the enduser's machine.
As a special feature, patch files will update even mixed versions (such as in the case where some are 1.01 and others are versions 1.02) as every file is handled individually and version checks are done for each file, separately.
Normally you need to have a DoPatch program to apply patch files and is required for applying patch files, but you can choose to include it into the patch file and have an executable created that is a DoPatch and a patch file merged into a single file. Such patch files are normal programs that can be executed under the OS that you specified on patch creation. Executable patch files apply themselves upon execution.
Of course, including the DoPatch into a patch file, every time you release a patch file, makes it larger. So by default, GenPatch creates the so-called "plain" patch files which do not have a DoPatch included. For your Beta testing we recommend that you send the DoPatch to your users once and thereafter, only patch files that can be applied using it. For updates we recommend choosing executable patch files, since the stubs are only 16k to 20k when compressed and this is not too much of an overhead. You will avoid many problems for your customers this way.
To create executable patch files use the command line option "-s" of GenPatch creating a executable patch file. You may choose a windows interface for your patch file instead of the commandline interface. Using the windows interface will result into 34k more compressed filesize added to your patch file. This is a downside, but since most users are not familiar with the commandline, we recommend that you create patches with the windows interface.
When you choose to create a executable patch files using option "-s", GenPatch creates a patch file that applies itself using a commandline interface. But when you are using the Windows platforms of BinPatch, you may choose option "-s=gui" instead and create a patch file with windows interface. This interface will be more natural and familiar to the majority of endusers.
The windows interface is available for both Windows 3.1 and Windows 95/NT. The GenPatch option "-s=gui" will use the "native" DoPatch of the platform. So using "-s=gui" with the DOS/Win3.1 version of GenPatch, you will create a patch file for Windows3.1 and using the Win95/NT version, you will create a patch file that requires Windows95/NT to be run. You may choose option "-s=gui16" to tell the Win95/NT version of GenPatch to create a patch file to be run on both Windows3.1 and Windows95/NT.
When patching complete directories at once GenPatch determines and chooses automatically the most suitable source file to create a target file from all. Unique algorithms allow this to take place without a noticeable amount of time used. Instead of only patching identical filenames and you can explicitly tell it every file that was renamed, GenPatch finds the best suited file even among several very similar files.
Of course the Autodetection may not be desirable in every instance. Say, for example, that you have some data files that might exist in every concrete installation of your software. Then it might be very unwise to create new files from others that possibly do not exist. In such cases, you have the option "-e" of GenPatch to disable the autodetection for patterns of files. A file that matches a "-e=pattern" will only be created from source files that have identical filenames and if no such file is present, it will embedded into the patch file completely. In case you prefer disabling the Autodetection for all files, simply specify the option "-e=*" and GenPatch will work as you wanted it to, because the pattern "*" will match all files.
When patching complete directories at once GenPatch may encounter files in new subdirectories. These files will be handled too, unless you explicitly ignore all files in subdirectories. Please read how to ignore files by pattern, if you want to use this option. When applying the patch file, the directories containing new files are created, accordingly. Please note: There is currently no way to create empty directories and such are ignored by GenPatch.
New files, i.e. target files not found in the sources for the patch file, are first subject to "Autodetection of best matching source for a target file" and if this does not yield a source file that would be worth using it, GenPatch embeds the complete file into the patch file. It will be written into the directory while applying the patch file. Note that, very often, the Autodetection will choose a file seemingly rather unrelated to serve as a source for creating a file. But only a single reference to a part can decrease the size of the information to be stored for that file. See the above topic on how to disable Autodetection or how to ignore certain files in case you wanted that. Both methods could be used to change the source files used.
While patching complete directories at once GenPatch will handle files that have been renamed and modified for you. It does so using the "Autodetection of best matching source for a target file" which will tell GenPatch to use the correct source file for the renamed file. With BinPatch you need not care about this at all and if you enable the automatic cleanup, the patch will also delete the old version (actually move it to the backup folder) so that it no longer exists.
DoPatch normally requires all files to be updated and will not change a single file unless all files can be updated when patching complete directories at once. But you may tell GenPatch to include information into the patch file to tolerate failure when generating a file. This has been considered in order to allow you, as the software vendor, to keep control over what installations might exist. Problems arising when only partial updating occurs and the installation freezes or does not work properly, can be prevented this way. Either all important files are updated or none at all.
By default, all files are considered important, but some files like e.g. "FILE_ID.DIZ" are not really that important. But, unless you tell GenPatch that it is not, it will cause the complete update process to fail because the user might have deleted the old "FILE_ID.DIZ," not expecting that it would be required for a later update. You may specify files that will only yield a warning, in case there was no appropriate source file found when the patch tries to update them. Use GenPatch option "-u=pattern" in order to do that. By specifying "-u=*.dat" you tell GenPatch to allow failure in updating all files matching the pattern. Note that "-u=*" will tolerate just any file to fail, but usage is not recommended because the Autofind will think that such patches may be "applied" to just any directory. DoPatch does not detect this, so be aware not to tolerate failure of patching with at least one file (typically the main executable) that serves as a kind of anchor for your patch file.
You may want to ignore some files in the directories while GenPatch processes them. These files may be ini-files, data files or just anything that might have changed and cannot be used as a source for patching.
To ignore certain files, file types or subdirectories: Just specify the files as patterns with option "-i". Such files will be removed completely from all internal processing of GenPatch (this option has the highest precedence over all others). Patterns are filenames, possibly including relative paths, with patterns. By specifying "-i=*.dat", the process will ignore all files that end with ".dat", "-i=data/fra*.dat" will only ignore files in subdirectories "data" start with "fra" and end with ".dat". The character "*" matches none or any number of characters in a filename, but will not include the slash that separates one directories in a relative path. Another special character is "?" which will match an arbitrary single character that is not a slash or a backslash.
To Ignore files only in some directories: Ignoring files may be restricted to some of the source or final state directories only. Use "-if=pattern" to ignore files in the target only, use "-is=pattern" to ignore files in source directories only. (Note that there might be more than one source directory.) If you create a patch for several source states, you'll be able to ignore files in the first source state directory with "-i1=pattern" and in the fourth source state with "-i4=pattern". You may also combine these and use "-i2,3,f=pattern," to ignore files in sources 2 and 3, as well as in target, in one turn.
Include hidden and system files: Use option "-a" to tell GenPatch for DOS/Win3.1 or Win95/NT to process hidden or system files in directory mode. Otherwise they would be ignored.
When applying a patch file to a directory this will normally replace some files in that directory. In order to allow endusers to restore old versions of the software, those files are preserved by moving them to a backup directory. This backup directory defaults to a subdirectory named "Backup" but this can be changed using the GenPatch option "-b=AnotherDir" which tell DoPatch to use this as the backup directory.
Note that you should specify this differently for each version, since any file already present in the backup directory will be overwritten when applying the patch. Applying the same patch several times will be no problem since that will not change any file and therefore won't impose the need to replace anything. Please also note that embedded files may also replace existing ones and these will be moved to the backup directory, too.
The so-called "deleted" files are actually only moved to the backup directory and not really physically deleted. To clean up and prevent waste of disk space you might tell you users or create a batch file to delete the backup directory after applying patches.
Another important feature of BinPatch is the ability to cleanup directories when applying a patch file to a directory. You may specify files to be "deleted" using the option "-d" and "-D".
With option "-d" you specify that all files found in source directories, but not found in the target directory shall be deleted/removed (actually they are only moved to the backup directory) when applying the patch file. You may restrict this by using a pattern like "-d=*.exe" which will work nearly the same way, but only remove obsolete program files and no other files.
With option "-D" you can specify files to be deleted even though they are not present in the target directory. You would typically use this with files that you know existed, but were ignored. Ignoring files by pattern has higher precedence than "-d" and would therefore cause ignored files not be removed. You should normally not need to use this option variant, but it's available for the few rare cases that might require it.
Normally GenPatch will skip files that are found identically in all source directories. It would be useless to include information about them, unless you want to do one of two things: a) Force existence check of these files. b) Have complete versions created, if DoPatch is given an alternate directory to write patched files into; end users might want to create "clean installations" doing so. Using GenPatch's option "-f" helps you to address both needs.
There might be cases where you want to ensure that these files exist when applying a patch file. You can do so by using the GenPatch option "-f" that forces GenPatch to include patch information even for totally unchanged files. This patch information would simply copy the old file and call it new. Now if you do not tolerate to fail updating these files the patch cannot be applied without those files existing.
You may note that with release 2.2 option "-f" allows you to use file patterns in order to choose the files you want to check for more without checking for others files that you did not want to.
When you create a filepatch of identical files using the option "-f" you get a small patch file that can be used to check the version of a file. If the patch file can be applied it's matching the version and if not, it's another version.
Patch files for the Windows95/NT platform can autofind the installed target software by looking at the registry. This is done by embedding the name of a registry key that will contain the path to the software if installed on the computer. This is done with option "-k" of GenPatch. When applying a patch file with embedded registry lookup information, it is scanned for with highest precedence, if you are using the DoPatch for Win95/NT or an executable patch file for Win95/NT. Other platforms will ignore the registry information because they could not access the registry.
Note: The path found in the registry (if the key is present) has even higher precedence than checking the current directory. It actually disables checking the current directory which is normally the default.
We recommend to use this option if your software is for Windows 95/NT since it will allow your users to start the patch file from any place and they would not even need to enter a path manually.
To make patch files for Win95/NT that autofind the software using registry lookup, just specify the HKEY_LOCAL_MACHINE registry key to the option "-k" of GenPatch. The option "-k=SOFTWARE\YourSoftware\InstallPath" will tell the patch file to check the path found in the key "HKEY_LOCAL_MACHINE\SOFTWARE\YourSoftware" and its value of "InstallPath". If you wanted to use the default value of a key make sure that the value ends with a "\" like in "-k=SOFTWARE\YourSoftware\". GenPatch takes all before the last slash as the key part and all after is regarded as the value part.
If you cannot use the "Autofind by registry lookup" method you still may use the traditional Autofind method of BinPatch. This method is first scanning the current directory and then all the users' harddisks in order to find the matching software. Currently you will find that the windows interface versions do not scan the users' harddisks, but instead allow you to browse the directories to check. The commandline versions of patch files will use this method unless you use an external DoPatch for patch application. That would require the option "-auto" in order to enable the autofind.
Please note that with a directory patch the autofind procedure is much faster than with a file patch. Where a directory patch will normally only need to check for a filename existence to see that a patch cannot be applied it's much harder to check all files in a directory if they make a potential target of the patch.
If you have serial numbers in your files, applying BinPatches is a perfectly easy way to protect those serial numbers in your updates. Users do not need to re-enter the information they've lost and re-contact your support division. Please note that information on how-to use this feature is only published to our customers. Please contact us if you need to know details in order to evaluate BinPatch.
By default created patch files are internally compressed. The efficiency of this internal compression is better than with standard zip-tools, but might result into a larger archive if you need to deliver zip-files because compressing the internally compressed patch file will result into bigger archives. This is a typical problem with doing several compressions on a file and not specific to BinPatch.
But you may want to disable the internal compression when you have to use a zip file anyway. To deactivate internal compression specify option "-j" on the GenPatch commandline. The resulting plain patch file will be larger, but the externally compressed patch file will be smaller.
Very often you will want to compress or at least "shell" the created patch files for smooth download or email receipt. Still, files ending in ".utp" won't be handled correctly by all web-servers and most email programs will not handle unknown file types correctly, too.
So as this is a rather typical action with BinPatch we have built support for automatic usage of compression into BinPatch. And this is how you handle it:
Specify the default packer: The internal ZIP method is the standard compression method. It does not require any special installation and is 100% compatible with WinZIP, PkZIP and InfoZIP. We recommend using it. But you may choose any of the common commandline packer tools as the default. Once you have installed them in your system's path, use option "-Z=packername" to select it as your default packer. Packernames supported are InfoZIP, PkZIP, GZIP, RAR, ARJ, JAR and LHA.
Tell GenPatch to pack the created file: Use option "-z" to tell GenPatch to call the default packer after the patch file has been created.
Temporarily override the default packer: If you want to use a packer other than your default packer, you can easily override the default setting, by using "-z=packername" on the commandline. It will have higher precedence than option "-Z" and accepts the same packernames.
Reduce memory usage: Even though GenPatch uses not much memory compared to the difficult task to created efficient patches in fastest speed, it might allocate a lot memory with larger files though. Using option "-m=value" you might reduce the memory usage drastically. The default and minimum value is "-m=5" which will produce best results at patching and consuming the normal amount. Using "-m=6" will reduce memory usage by 16% and won't hurt (packed) patch file sizes very much. With "-m=10" you reduce memory usage to 50% and with "-m=100" you'll reduce memory usage to 5%, but might increase the patch file size very much. But with rather constant files of many MB size, it might be a good choice to do so, if you run out of memory. We recommend not to use this option unless you really run into problems, normally you won't at all.
Increase patch generation speed: The problem to create an optimum patch file is a function of involved filesizes that grows quite fast. BinPatch uses sophisticated algorithms that don't do that as soon. But in case you have large files with many changes, you will find that option "-m=value" from above does not only reduce memory usage, but also results in those patch files created much faster. The number of checks to be done in average will be reduced by 75% when using "-m=10", so this option might be the right tool for you. Using "-m=6" will increase speed by 50% will almost no loss at all. It's not the default, since best patch files is what BinPatch is about and creation times of usually seconds need not be reduced trading patch file size. We recommend using this option only if you encounter time problems with patch creation and if you do encounter them, it's likely that you use files with extremely bad matching characteristics that will not be worth patching anyway.
If you have an executable patch file, just execute it. It will autoscan your partitions/hard disks for possible patch targets. To avoid this scan, you can specify the patch destination on the commandline.
Supply option "-t" when executing the patch and it will not change any file, but only test if it is applicable.
b) Plain patch files
If you have a plain patch file, recognized by its extension ".utp", you need a DoPatch to apply them. Anyway, executable patch files are in fact compatible to plain patches and can be applied using DoPatch the same way as plain patches rather than executing them directly, if you wish to.
To apply a patch file, DoPatch needs to know which patch file to use and which directory / file you want to patch with it. If you do not know where that directory / file is, you may easily locate it, using option "-auto" which will make DoPatch behave like executable patch files and autofind the patch target for you on your partitions / harddisk(s)!
You may supply option "-t" to see, if a patch is applicable without actually applying the patch and giving one more filename/path, you may choose to create files in another place. But beware that if the creator did not use option "-f" to ensure that the patch includes infromation about files not changes, these files will not be copied along while patchand and the directory might not be complete then.
Your advantage using Binpatch Technology compared to distributing complete versions all the time can be made clear with some examples:
Example A: The Minor Bugfix.
Say you noticed that software you released had a bug. Only minor changes were necessary to remove the problem, but once you did them, you needed to re-send your customers the complete version. This might be expensive for you, if you have to do it by postal mail. And it would possibly be a problem to the customer it you sent it by email. Anyway, sending the patch file instead of the full version would do one of these:
Figure A: Minor bugfix to a Windows Software | ||
---|---|---|
Full Installation Version | 1570kB | ![]() |
Executable Patch File | 40kB |
![]() |
Plain Patch File | 1.7kB |
![]() |
Example B: The Minor Update
Say you want to make an update to your software as a regular update or as part of beta-testing your software publicly.
Figure B: Major update to Windows Software | ||
---|---|---|
Full Installation Version | 1570kB | ![]() |
Executable Patch File | 134kB |
![]() |
Plain Patch File | 99kB |
![]() |
Unless you add large new components, the filesize of the patch starts to remain at a constant rate from some point. This is because most changes in the executable arise from typical linker optimizations and moved global variable references, that need to be changed in update process. But rewriting complete routines is only a few bytes compared to that. So this result is very typical with just any major update.
Consider the savings in time and money and the convenience for your customers. You could offer them to subscribe to a special email update mailing lists or offer them small patch updates that upgrade their software without requiring re-installation.
With such small updates, you may release more test versions during your product beta test, react much quicker on their bug reports and keep your testers motivated this way. And you all surely know how essential testers are for quality control and development! Using BinPatch will shorten your betatesting as well as improving its results.
Usage of the computer software package "BinPatch" is only allowed according to the following terms. Using "BinPatch" signals agreement to these terms. References to "BinPatch" here mean the software package including documentation in all formats and on all platforms including Click'n Patch. Please read this chapter completely!
a) | It is our expressed wish, that this release shall
be spread in the distribution version. You are allowed to distribute BinPatch in complete and unmodified form only. Please keep the original archive for others. As a natural exception to this rule, you are allowed to spread DoPatch alone. Not including this file, means you take full responsibility for it, so you have to disclaim it in the documentation coming along with it. |
b) | Distributing license files for BinPatch is not allowed. Usage of a license file, which is not yours also. The only exception of this rule is creating patches for your company, which licensed BinPatch and that you are an employee of. |
c) | It is forbidden to modify BinPatch in any other way than applying patches created for it by Kay Hayen Software. Nobody else may generate patches for BinPatch. |
d) | If you want to translate BinPatch into another language, please email us. Only official translations shall be released. |
e) | The non-commercial usage of BinPatch is allowed without extra-licensing. Users are welcome to purchase license BinPatch if they like it. Only authors themselves are allowed to create patches for their programs, this is especially true for commercial programs. Please note that shareware, light and trial versions of commercial software are all considered commercial. |
f) | The commercial usage of GenPatch and Click'n Patch
requires purchasing commercial usage license. Usage is
commercial, if the patched data is of commercial kind or when shareware is being patched.
It is never allowed to generate and distribute patches for commercial data or shareware of
other authors or companies. This may only be done by the
author himself/herself and of course only using
his/their registered version of BinPatch. Free-lancers should contact us for
special licenses. Applying patches will be O.K. as long as the patch doe not violate any license terms. License for commercial usage has to be purchased from Kay Hayen Software and comes into effect with the installation of the license file only. Please see commercial licensing types to see what license type applies to you. |
g) | A company license may not be used by employees for their own projects. Also companies may not use employees' license files for their projects. They both have to purchase a commercial license in order to use BinPatch for their commercial applications. |
h) | It is forbidden to reverse-engineer, decompile or disassemble BinPatch or parts of it. Also it is forbidden to produce products that are based on BinPatch without the explicit permission of Kay Hayen (email: kay@kayhayen.com). |
i) | Kay Hayen does not warrant that the BinPatch is free from all bugs, errors, and
omissions. Kay Hayen may, at his discretion, choose to make a reasonable effort to correct
possible program errors. Except as specifically set forth above, Kay Hayen makes no, expressed or implied, including without limitation the implied warranties of merchantability and fitness for a particular purpose, regarding the BinPatch product. Kay Hayen does not warrant, guarantee or make any representations regarding the use or the results of the use of BinPatch in terms of its correctness, accuracy, reliability, currentness or otherwise. The entire risk as to the results and performance of BinPatch is assumed by customer. The exclusion of implied warranties in not permitted by some jurisdictions. The above exclusions may not apply to the customer. Except as specifically set forth above, Kay Hayen will in no event be liable to customer for any consequential, incidental or indirect damages (including but not limited to damages for loss of business profits, business interruptions, loss of business information, and the like) arising out of the use or inability to use BinPatch even if Kay Hayen has been advised of the possibility of such damages. Because some jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above exclusion may not apply to customer. Kay Hayen's liability to customer for actual damages for any cause whatsoever, and regardless of the form of the action (whether in contract, tort (including negligence), product liability or otherwise), will be limited to the purchase price customer paid for the product. The author is optimistic that BinPatch will fulfil some use, but the only thing guaranteed is that it will consume space on your hard disk. The software package may be used within the terms of this license, but only as-is! No special functionality is guaranteed! The author cannot be held responsible for any damage resulting from the usage of BinPatch! Also the author does not claim any rights on files generated using BinPatch, and can't be held responsible for their contents too. |
j) | BinPatch Classic and Professional are Copyright © 1996-1999 by Kay Hayen. |
For commercial usage of BinPatch Classic or Professional you must purchase a BinPatch license.
All BinPatch licenses include this unless stated contrary below.
The prices for BinPatch licenses are:
Price | License Type | Products Included | License Description |
---|---|---|---|
49 USD |
One-man company license | BinPatch Classic for PC. |
This kind of license may only be used by companies that are property of the a single person and do not have employees. Please read about the free-lancer comment to see that special case. |
100 USD |
One-man professional license | BinPatch Classic for PC BinPatch Professional for PC(*) |
This license type is exactly the same as the "one-man company license", but includes allowance to use and distribute the DoPatch software components of the Professional package too. |
500 USD |
Single product license | BinPatch Classic for PC BinPatch Professional for PC |
This license will allow companies to use BinPatch with a single product family, but not with any other product. |
500 USD |
Mid-range company license | BinPatch Classic for PC BinPatch Professional for PC |
This kind of license should be purchase by companies that have a single location and are not internationally present. Contact us if your company would not fit these terms but wanted to restrict usage to a certain point of presence. This would be acceptable and subject to negotiation. |
5000 USD |
World-wide company license | BinPatch Classic for PC BinPatch Professional for PC |
This kind of license must be purchased by companies that are present all over the world and want to use BinPatch to create patch files in more than one place or for more than one product. |
>5000 USD | BinPatch OEM license | BinPatch Classic for PC BinPatch Professional for PC GenPatch DLL package |
This kind of license is required to use the GenPatch software components in your application. The license terms are subject to negotiations and may include a higher price, restrict usage to a number of computers, royalties on the number of installations or other things. If the number of installations is very small a lower price might also be negotiated. |
You have several options to purchase BinPatch which are listed in this file. They include online purchase via credit card and sending checks to our postal address.
Note: This license agreement may change with newer releases of a newer versions of BinPatch. Purchased licenses are not affected. Look for the newest version of this document at http://www.kayhayen.com/binpatch/readme.htm.
(*) The one-man company professional license does not allow completely hidden usage of the DoPatch DLLs, but will show a license information once for a certain license - no matter how many patch files are applied.
The current BinPatch Classic distributions are:
File | DOS/Windows3.1 mkpat30d.zip 250K |
Windows95/NT mkpat30n.zip 250K |
Windows95/NT-GUI mkpat21g.zip 1.1M |
OS/2 mkpat30o.zip 250K |
SCO-Unix mkpat30s.tgz 250K |
Elf-Linux mkpat30e.tgz 250K |
---|---|---|---|---|---|---|
GenPatch (Commandline patch creator) |
Yes. | Yes. | No. | Yes. | Yes. | Yes. |
BinPatch32 (Windows95/NT interface patch applier) |
No. | No. | Yes. | No. | No. | No. |
DoPatch (Commandline patch applier) |
Yes. 41k (17k) (DOS version.) |
Yes. 28k (25k) (Win32 version.) |
Yes. 38k (21k) (Win32 version) |
Yes. 61k (32k) (OS/2 version) |
Yes. |
Yes. (Elf-Linux version) |
DoPat32 (Windows95/NT interface patch applier) |
No. | Yes. 32k (28k) | Yes. 59k (34k) | No. | No. | No. |
DoPat16 (Windows3.1 interface patch applier) |
Yes. 59k (34k) | Yes. 59k (34k) | Yes. 59k (34k) | No. | No. | No. |
Note: Actual releases may differ from what is described below.
V3.1 (Release scheduled for May 1999)
Are you still missing a feature needed for your BinPatch usage or do you have a suggestion? Do you think that one of these planned features is not an advantage, or you want to provide helpful information? Just email us! Normally it's very often only a question of days or even hours to see your suggestion implemented in a prerelease version you receive.
This chapter lists the changes in BinPatch from version to version:
V3.0 (14. official release for DOS, Win95, WinNT, OS/2 and Linux on 23-January-99)
V2.2 (13. official release for DOS, Win95, WinNT, OS/2 and Linux on 9-August-98)
V2.1 (12. official release for DOS, Win95, NT, OS/2 and Linux on 26-Mar-98)
V2.0 (11. official release for DOS, Win95, NT, OS/2 and Linux on 5-Feb-98)
V1.9 (10. official release for DOS, Win95, NT, OS/2 and Linux on 3-Sep-97)
V1.8 (9. official release for DOS, Win95, NT, OS/2 and Linux on 11-Jul-97)
V1.7 (8. official release for DOS, Win95, NT, OS/2 and Linux on 19-Jun-97)
V1.06 (7. official release for DOS, Win95, NT, OS/2 and Linux on 17-Jun-97)
V1.05 (6. official release for DOS, Win95, NT, OS/2 and Linux on 9-Jun-97)
V1.04 (5. official release for DOS, Win95, NT, OS/2 and Linux on 21-May-97)
V1.03 (4. official release for DOS, Win95, NT, OS/2 and Linux on 3-Apr-97)
V1.02 (3. official release for DOS, Win95, NT and Linux on 17-Feb-97)
V1.01 (2. official release for DOS, Win95, NT and Linux on 11-Feb-97)
V1.00 (1. official release for DOS, Win95, NT and Linux on 5-Feb-97)
V0.90 (9. Betaversion for DOS, Win95 and Linux on 31-Jan-97)
V0.89 (8. Betaversion for DOS, Win95 and Linux on 22-Jan-97)
V0.88 (7. Betaversion for DOS, Win95 and Linux on 20-Jan-97)
V0.87 (6. Betaversion for DOS, Win95 and Linux on 16-Jan-97)
V0.86 (5. Betaversion for DOS, Win95 and Linux on 14-Jan-97)
V0.85 (4. Betaversion for DOS and Linux on 23-Dez-96)
V0.84 (3. Betaversion for DOS and Linux on 19-Dez-96)
V0.83 (2. Betaversion for DOS on 16-Dez-96)
V0.82 (1. Betaversion for DOS 11-Dez-96)
Earlier versions were internal alpha versions and have not been released.
Tip: Try to name your patch files with informative filenames. It should explain somehow what it does. A patch file called "update.exe" does tell the user nothing about the purpose of the patch. Prefer instead things like "v21_V22.utp" if you are bound to the DOS filename conventions or if not use "Update MySoftware 1.0x to MySoftware 1.1 patch.utp". This will allow to easily decide what a patch file does just from its filename. The example would tell the user that it's an update, that it's for MySoftware and can be applied to version 1.05 but not to version 1.2.
Tip: For minimum patch file sizes try to have the same compiler options when compiling programs which will be patched later. Otherwise you produce more (unnecessary) differences, resulting in bigger patch files. Incremental linkage should be disabled and a complete rebuild be done to guarantuee that no changes must be made due to this.
Tip: The environment variable "BINPATCH_OPTS" is parsed by GenPatch every time you run it. Place there frequently used parameters like your "-Z" packer method choice.
Tip: (DOS only, not applicable to Win32 platform: The DOS/Windows version of GenPatch uses DPMI services to overcome the DOS limitations. But the Windows "automatic" DPMI-Service fails although you have enough memory. In this case create a special DOS-box link, edit its memory settings for DPMI from "automatic" to 32000 or even 65000 and retry. Background: Windows gives in "automatic" DPMI mode only a fraction of your physical RAM to DOS software, but this is hardly sufficient in all cases. We stronlgy suggest to use the native GenPatch for Win32 if you are using Windows 95, it will not have any problems with DPMI service limitations at all, but still is capable of creating patch files for DOS or Windows 3.1.
Requirement Table | GenPatch | DoPatch |
---|---|---|
Win32 | None. | |
OS/2 | None. | |
SCO Unix | None. | |
Linux | None, kernel must be 2.0 or better | |
DOS/Win3.x | DPMI-Server like the ones of Windows or OS/2. | None. |
DOS/Windows 3.x: None.
Windows 95/NT: None. You need to use DoPatch for DOS for pure MS-DOS mode, but DoPatch for Windows 95/NT in Windows DOS-boxes.
SCO Unix and Linux: Current implementations do not autofind patch file targets. Also Unix does have case-sensitive filenames. This can be problematic when applying patches files created on another platforms that do not distinguish case.
OS/2: GenPatch for OS/2 does not handle CTRL-C with deleting the patch file. The so-called "extended attributes" (EA) of OS/2 are included with GenPatch's option "-A". Applying EAs to patched or embedded files will only work with DoPatch for OS/2, while other platforms DoPatches will apply such patches with no problem, the EAs will simply not set then.
If you find something in BinPatch that is supposed to be a bug, please check the "Distribution Sources for BinPatch" and see, if the problem has been removed in a newer version.
Please try to reproduce the problem under given circumstances. If the error occurs when patching directories, remove all files that are not necessary to reproduce the problem. If the error comes along with a special file, try if a patch of that single file also shows the problem.
The try to e-mail us with the following information:
Send that mail to bugreport@kayhayen.com and use subject "Bugreport BinPatch Vx.xx" where x.xx is the version of BinPatch that you use. Please don't include the binaries immediately. If there is reason for this, we will ask you for. Normally, there will be no need.
Our general thanks go to our owner's brother Andree Hayen. Obviously he is a great consultant and support for him.
In addition we would like to thank Matthias Babisch for giving ideas at startup-time of the BinPatch project.
Recognition to Matthias Hahn who was helpful at discussing some theoretical problems.
Many thanks go to Oliver Mulatz who constantly helped to revise this documentation and constantly beta tests the product. He does a great job in this and contributes in most other important fields, too.
Thanks to DJ Delorie and Eli Zaretski. The compiler product "DJGPP" which is Unix "gcc" for DOS made GenPatch for DOS possible.
And last but not least my thanks to all beta-testers and customers of BinPatch. Most of all the good ideas in BinPatch come from their critics, here are the most helpful in alpabetical order:
BinPatch | The program package to generate and apply patch files. Sometimes you will also find patch files made with BinPatch addressed as "a "binpatch" or "binpatches". |
---|---|
Compiler | A program being used by developers to generate programs. Normally they include some standard functionality along with every program, which is common for all programs made with the same compiler. |
DoPatch | Name of the program to apply patches that are not executable, so-called plain patch files. This program is part of BinPatch and available in versions with commandline interfaces for various platforms as well as with windows interfaces. |
DPMI | Technique for DOS-programs to access more memory than DOS normally can. Every DOS-box of Windows or OS/2 has a DPMI-server built-in which programs can access. This is exactly what GenPatch for DOS needs and you only need to supply a DPMI-Server on your own, when want you use GenPatch under pure DOS. Again: No need for an external DPMI-Server when you use the DOS-Version under Win95, OS/2, ... only under 'plain' DOS. |
GenPatch | Name of the program to generate patches, part of BinPatch. |
Long Filenames (LFN) | This is how the new filenames introduced with Windows 95 are called. They need not conform to the old DOS-conventions. You can have filenames with more than 8 characters, more than one dot within them and any number of characters after a dot. (Only the DoPatches for Windows 95/NT can work with these filenames, but not DoPatch for DOS or Windows3.1. If you need to update software that runs on both platforms be sure to choose a DoPatch for the later, since it's the lowest common denominator.) |
There are situations when you may have to update several similar files or directories. You could supply two different patch files to update version 2.0a and 2.0b to 2.1. Using Multipatch you can generate a patch file containing info on how to update both with only one patch file with normally only minimal increased size of the patch file, saving you and your customers a lot of hassle when dealing with release control. | |
Patch file | A special file (BinPatch normally uses the suffix ".utp" for them, therefore also called utp-file) that carries information needed by DoPatch to create a newer version of a file from a older version the patch is related to. As a special feature of BinPatch you may supply a complete directory structure to be patched with only a single patch file. |
Redundancy | This is how repeated occurrence of chunks of data is called. BinPatch recognizes redundancy very good, e.g. when you have an article and another articales that quotes it (with '>' or similar) in the same file. Such redundancy is not well recognized by other patchers, but it is dealt superb with if you enable the GenPatch option "-r". For Example: In the word "Mississippi" you can find "iss" two times. BinPatch can take advantage of such phenomenon to shorten file information by referring to already written parts! |
This term refers to file archives in form of executable files that unpack their contents when executed. You need no unpacker for those, they unpack themselves. | |
Overhead | Part of a program that has no special function, but exists nevertheless and increases the filesize of your software. |
This chapter lists a summary of all options available for GenPatch. You may refer to the section explaining GenPatch features if you are looking for a special funtion, but you will find what you desire here.
@file | Read this file and handle each line as one
parameter. Parameters are not split by spaces, but by newlines instead. Lines that start
with a "#" are ignored and may serve you to be comments. Leading and trailing
white-spaces are ignored and it's allowed to use this recursively, i.e. you can
"include" other parameter files from a parameter file. Note that BINPATCH_OPTS
allows you use this option too, but will make sure you don't specify file names here.
|
-all -a |
Handle all files, normally hidden files are not included in the patch creation process. If you use -all, they are handled also. |
-backup="Backup Directory with Space" -backup=backupdirwithnospace -b=backupdir |
Specify the backup directory used when applying the patch file. It defaults to "Backup". |
-comment="Up to 76 characters of comment you
give\nwithin 10 lines" -comment=@comment.txt -c="Comment short form" |
Specify a comment that needs to be acknoledged by the end use before applying the patch file. You may either specify a short comment on the commandline with the first form, or refer to a file that is required to fit into a 76x10 display. |
-cache | Preserve patch information for later reuse. May speed up your testing of BinPatch options to just enter and be done once you have created the patch information for files. When you change a single file not all other information needs to be renewed. While BinPatch is so really fast that you may not need it in most cases, this option is a big helper if you got some hard nuts for BinPatch in your software. |
-delete="filename with spaces" -delete=pattern -d=pattern |
Obsolete files can be removed when applying patch files. Normally they will be kept, but those matching a filename or file pattern given to this option will be moved into the backup directory when applying the patchfile. Note that the matching will be done when creating the patch file. |
-exact="filename with spaces" -exact=pattern -e=pattern |
Require matching files to be generated from files with exactly the same filename and no other. This can avoid to create files from other filenames in the start states where it's not wise to do so from your point of understanding. There files might not necessarily exist all at the same time e.g. |
-force="filename with spaces" -force=pattern -force -f |
The first two forms are for use in directory mode. They will force files matching the filename or pattern specified to be "patched" even if they are identical in all source states and final state. Normally, they would be skiped, but using this option, you require the file to be present and the patch either does nothing to it or if you apply a patch into an alternate position, this will copy the file along. |
-g=info | Protect parts of the source files to kept intact during the patching process. This option will only be documented to commercial users, because it's only useful for commercial software and abuse shall be avoided. |
-help -h |
Output usage information of GenPatch. |
-ignore="filename with spaces" -ignore=pattern -i=pattern |
Ignore files matching given file names or patterns. These files will be excluded from all further processing, because this option has the higher precence than all other options. |
-j | Disable internal compression. Do this to achieve better compression ratios if you plan to send the patch file as zip file anyway. |
-key="\HKEY_LOCAL_MACHINE\Software\YourApp\YourValue" -key=HKEY_LOCAL_MACHINE/Software/YourApp/YourValue -k=HKLM\Software\YourApp\ThisKeysDefaultValueToTake\ |
Specify the registry key where the patch software will be located. You can choose the backslash as well as the forward slash. Signal the default value by giving "" as the value part like \Software\Key\ and use "@" if you need to quote and you shell would take "\Software\Key with space\" as an escaped quoting character. |
-K=@RegManip.reg,HKLM/Software/YX/Install,yourmain.exe,r (not implemented yet) |
Specify a registry manipulation to be done after successfully applying the patch file. The file given is expected to be in REGEDIT4 file format as output by the registry editor on Win32 platforms. A single exception: You specify a single replacement character that is being replaced with the contents of the specified key's content at runtime. Ie. all occurances of %r in the values will be replaced with what is found on the client machine at the time the patch is appied. You are free to choose any numeric or alpha character and the replace marking is case sensitive. The manipulation requires full access to manipulated keys and read access to the lookup key. To maximize use of this, you can specify a base value which is known to be always present and that e.g. parts a path part that you want to replace elsewhere from the not needed filename. |
-logfile=type -log=type -l=type -l |
Enable log file function. The log file gets the base name of the patch file with the log file type's extension. Allowed types are txt (alias ascii) and htm (alias html) with "txt" being the default of this option when no type is given. |
-m=number | Reduce the amount of memory being used. Accepts numerical parameters from 5 to 100 with 5 as the default. Higher values use less memory. Usage is only recommended if you run into memory shortages. |
-pgp -p (not implemented yet) |
Call externally installed pgp to sign the created patch file. Not inplemented yet. |
-quiet -q |
Make GenPatch more quiet. Normally it informs you about all the processing it does. Using this option you reduce the amount of information displayed. It will e.g. no longer inform you about skiped files, etc. |
-unimportant="Filename with spaces" -unimportant=pattern -u=pattern |
Specify those files that need not be sucessfully created when applying a patch file. These will be the unimportant files who do not require existent source files for applying the whole patch file. |
-s=gui32 -s=gui16 -s=gui -s |
Select to create an executable patch file with this option.
The first variant chooses a Win32 only graphical windows interface, the second goes for a
Win3.1 platform interface. The third is somewhat a shortcut. It will choose a
"native" graphical interface depending on what GenPatch you use. The GenPatch
for Win32 e.g. will create a Win32 interface. The last variant will create a executable patch file commandline interface that is "native" to the GenPatch creating the patch file. |
-time=now -time=latest -time=apply -t=n -t=l |
Select the time stamp handling for the patch file. Normally GenPatch will put the actual time stamp of each end state file into the patch to be set when applying the patch file. But you can choose to use the current time stamp when creating the patch file instead with "-time=now". With "-time=latest" you select all handled files to receive the time stamp of the oldest file handled. With "time=apply" you choose to have the patched file to have the date of the actual patch applying and not a fixed one. |
-version -v |
Display the GenPatch version information. |
-z=Packername -zip -z |
Tell BinPatch to apply a externally compression to the created patch file. The ZIP mechanism is built-in and requires no external installation. All other possible choices require a working installation found in the system path. Please note that you should disabled the internal compression if you use an external to avoid losses due to repeated compression. |
This is the BinPatch documentation, find the latest version of this page at http://www.kayhayen.com/binpatch/readme.htm
Copyright © 1996-1999 Kay Hayen. All mentioned names or trademarks are property of their respective owners. Responsible is Kay Hayen Software, docmaster@kayhayen.com, Washingtonallee 22, 22111 Hamburg, Germany.