BinPatch is a software package containing two essential items for patching binary files: GenPatch and DoPatch. The program called GenPatch is used to create so-called patchfiles and the program DoPatch for applying them. The patchfiles created with GenPatch carry the differences between a source and a destination and leaves out the redundant data. You may choose either self-executable patches or "plain" patches which are applied using the program DoPatch. Special features of BinPatch are the creation of patches that update a complete directory or even a whole directory structure (including subdirectories) and the update of several *different versions* of a file with *only one* patchfile (Multipatch)! BinPatch has also built-in support for preserving serial number information in files while updating them.
Comparing a compressed patchfile and the corresponding complete release in terms of filesize, you see the main point in using BinPatch. No compressors or archivers can nearly achieve those fantastic rates that BinPatch does at updating files. With binary files (i.e. programs, DLLs,...), text files and databases extremly good rates are typical.
Background: Normally you have only small changes from a version to a newer version of a file. Most parts remain (almost) unchanged, i.e. huge parts of modern programs are made up from static libraries and especially Windows programs take much of their filesize from these. Try for yourself and see how much BinPatch can save you!
Caveats: The only thing you habe to consider is that BinPatch cannot work with compressed or encrypted data ... but this is neither a bug nor a missing feature. No patching program is able to cope with compressed or encrypted data! Use normal software installations instead of packed archives or unpack archives before you create patches. With executables packed internally you will generally receive worse results. (Unfortunately for this case, packers / encryptors generate a very broad distribution and resulting diffusion of the processed data. So a patching program cannot find much similarity in them.)
Packing the generated patchfile is recommended, esp. because GenPatch is optimized to generate patchfiles, which are bigger than neccessary, but will be much smaller when packed! (This is a well-kept secret of BinPatch's power compared to other patching tools.)
Especially for creating and releasing software-updates,
BinPatch
might be very useful to you. It saves the customer a lot of time and money
when receiving bugfixes, updates / newer versions. Why should your customers,
beta-testers and friends receive lots of Megabytes, if you could spare them
the redundant data which is in the newer versions the same and instead send
them only a few Kilobytes?
Requirement Table | GenPatch | DoPatch |
---|---|---|
DOS/Windows3.x | GenPatch for DOS needs a DPMI-Server (which you already have when running Windows or OS/2. Alternatively you may use QEMM or the free DPMI-Server CWSDPMI.) | None needed, developed to run out of the box on any DOS computer. |
Windows 95/NT | None. | |
OS/2 | None. | |
Linux | Needs ELF libraries installed. |
The simplest application of BinPatch is to generate a patch from one file and apply it on another. Given two files OLD.EXE and NEW.EXE and you want to create a patch that will allow to transform OLD.EXE into NEW.EXE. All you need to supply GenPatch with are the both filenames and a name for the patch file to be generated by BinPatch. Say we call the patch "OLD2NEW", all you need to provide is:
GenPatch OLD.EXE NEW.EXE OLD2NEW
and you have your patchfile.
Normally your patchfile will have the suffix ".UTP" to form the file extension of the patch to "OLD2NEW.UTP" which tells others that this is a patchfile. To apply this patch you need to tell DoPatch the filename of the patch and which file to be patched. This needs to be some file exactly matching OLD.EXE in its contents. To update the file OLD.EXE use the command:
DoPatch OLD2NEW.UTP OLD.EXE PATCHED.EXE
This creates the updated version of OLD.EXE as PATCHED.EXE, a filename you may freely choose when applying file patches. If there is no need not keep the original file you may use the following command and overwrite the OLD.EXE file with the newer version:
DoPatch OLD2NEW.UTP OLD.EXE
A typical case for distributing a software package is patching complete directories or even whole directory structures! Internally the processing is entierly different but the user never notices. Just give the path of the two directories and name the patchfile to be generated with this command:
GenPatch OLD_DIR NEW_DIR OLD2NEW
GenPatch scans NEW_DIR and automatically finds those files in OLD_DIR
that can be used as sources and puts all the patching information in one
file. When no matching file in OLD_DIR was found, it will only be stored
in the patchfile and extracted when using DoPatch. All patching information
is kept in one file for simplicity. Files that have not changed will be ignored
(unless you use option "-f" to force patching even those).
By the way: Scanning of directories includes subdirectories as well.
To apply a "directory"-patch use the command:
DoPatch OLD2NEW.UTP OLD_DIR NEW_DIR
A directory NEW_DIR will be created (unless it does already exists) and writes the patched files into it. If you want the changes to be applied directly to the old data, you would use the command:
DoPatch OLD2NEW.UTP OLD_DIR
and all old data will be moved into a new subdirectory "backup" and OLD_DIR will be replaced with the newer one. To patch the current directory, you may use the even shorter command:
DoPatch OLD2NEW.UTP
If you want for your customers the easiest possible application of your patches, you can create patches that need no DoPatch to be applied. Just add the option "-sfx" to the GenPatch command line. If you do, GenPatch will create an executable patchfile. Of course this patchfile is larger than the "plain" patchfile, but will not need DoPatch anymore. It must be run under the same Operating System (OS) of GenPatch which was used to create it, though you still may use any supported OS's (DOS, Win3.x, Win95, NT, OS/2, Unix) DoPatch version to apply this patch.
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 patchfile 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 is the destination and all before are sources. Even in this case GenPatch will autodetect best matches for files in NEW_DIR to patch from.
DoPatch has an option that is very comfortable when applying patches. It finds possible patch targets by scanning your partitions / harddisk(s). Use option "-auto" to activate this scan. Beginning with the current directory and going through all of your partitions / harddisk(s). Executable patches do this by default unless you specify the directory or file to be patched on the commandline.
GenPatch offers some special options:
Use option "-sfx" or "-s" to instruct GenPatch to create a executable patch file. That is DoPatch and a patchfile merged together which will be applied on its execution.
Use option "-f" to tell GenPatch to patch files even if they did not change at all. (Normally GenPatch would ignore these files.) The information for "patching" identical files will be very short, but has two consequences: First, patches will not be applicable unless those files exist. Second, DoPatch will copy them while patching into another destination directory, so this enables the user to create "clean" installations with only necessary files using such a patch.
Use option "-z" to make GenPatch call an external packer after patching. This saves you an extra invokation of the packer program. The packer needs to be installed in your Computer's path and can be selected using "-Z". Using option "-x" you may even generate a selfextracting archive with the patch, given the packer supports this feature.
Use option "-r" to allow patches to refer to parts of the file already created. This may make sense, but it is not the default setting. Try this for your concrete case, and compare packed filesizes. General rules can not be given, both happens dependant on your data: packed patchfiles may get larger and sometimes they get even smaller. Patches with option "-r" will nearly allways be shorter before packing, but that is not that interesting, the packed filesize of a patch is!
Use option "-c" to select the stepsizes of parts not found in the newer version of a file. Higher values produce smaller Patches, which could result in larger packed files. Normally you should find the default of 25 quite perfect for program files. But you might want to experiment with much bigger values for textfiles, because those have much more stable data than program files. Values above 255 will not make too much sense, although.
Use option "-l" to specify the range for optimizing embedded file parts. This value does not influence the size of the patch itself, but in high degree affects packed patchfile size! The default of 245 is quite good, higher values will slow down GenPatch. The ideal value depends on the file itself and on the packer used.
Note: The directory mode currently takes only one set of parameters for all files patched. GenPatch will someday be able to analyse, which parameters "-r", "-c", "-l" are best to choose by itself. For this, it would be of much help, if BinPatch users tell me about their experiments and experience with options -c und -l.
Note: The directory mode currently takes only one set of parameters for all files patched. GenPatch will someday be able to analyse, which parameters "-r", "-c", "-l" are best to choose, itself. For this it would be much help, if BinPatch users tell me about their experiments with options -c und -l.
If you have an executable patchfile, just execute it. It will autoscan your harddisks for possible patch targets. To avoid this scan, you can specify the patch destination on the commandline.
If you supply "-t" when executing the patch, it will not be applied, but only tested, if is applicable and then stopped (where normally patches would be applied after this successful CRC check).
b) Plain patchfiles
If you have a plain patchfile, specified by its extension ".utp", you can apply it with DoPatch only. Anyway, executable patchfiles 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 patchfile DoPatch needs to know which patchfile and what directory / file you want to patch with that file. 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 patchfiles 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, these files would not be complete, because all identical files were not included in the patchfile!
Your advantage using Binpatch compared to sending complete versions all the time can be made clear with some examples:
(Note: Most examples concern: United-Edition, a PBEM (Play By EMail), I'm developing at the moment. It's a typical windows program compiled with Borland Delphi, including help files and other typical stuff. The complete release has about 570kB. Imagine to send this out to somebody via e-mail. Because of current internet standards (and the problem of sending 8-bit data as e-mail) you may have to "encode" the archive, so it may be even 760kB to be transmitted and payed for.
Example A:
I had forgotten to do some minor changes in a demo, which I send to tester. Without them, testing the program would been much harder for him and I did not want him to cope with my fault. But the binary has already been released. The commandline "GENPATCH UNITED41 UNITED42 UPDATE" created a 5.7kB "UPDATE.UTP", which was packable to 2.7kB. In percent that was less than 0.9% and almost next to nothing compared to the full release of 570kB!
Minor bugfix to United-Edition demo | ||
---|---|---|
Full packed version | 570k | ![]() |
Patch | 5.7k | ![]() |
Packed Patch | 2.7k | ![]() |
Applying the patch was very easy. He only needed to type "DoPatch update.utp -auto" and my demo was updated. Easy. If I had sent him an executable patchfile, it would have been only 18k, still quite tolerable and updating would have been even easier: "Update.exe".
Example B:
I sent some beta-tester an update after a longer period (about 2 months) and there were quite a lot changes made meanwhile. But BinPatch is prepared, even optimized for this and yielded smallest filesizes here too:
Major update to United-Edition demo | ||
---|---|---|
Full packed version | 570k | ![]() |
Patch | 77k | ![]() |
Packed Patch | 35k | ![]() |
If you do not add new components, the filesize of the patch starts to remain nearly at that rate from some point. This is because most changes in the executable arise from 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 realistic with allmost any major update.
Consider the savings in Internet bandwidth! And your savings in time and money, of course! And last but not least those of your customers! With these fantastic rates you can release more test version, react quickly on reports and keep your testers motivated. And you all surely know how important testers are during development!
Example C:
For the first BinPatch releases on DOS I did not include GenPatch as an executable but only as a patchfile applicable to and by DoPatch that made GenPatch out of DoPatch!! This reduced the filesize of that early release to only 47k instead of 74k.
Smaller releases using BinPatch | ||
---|---|---|
Full packed version | 74k | ![]() |
Full packed version with install using Patch | 47k | ![]() |
I admit that this application is rather untypical, but it shows an additional potential of BinPatch. Reasonable became this patch due to the Overhead of programs made with the same compiler. If you want to release a bunch of Delphi programs e.g., you may be able to save about 200K with each, using patches to generate others from one complete.
Example D:
A nice betatester found two dead links in the HTML documentation of BinPatch. After correcting them, he sent me a patchfile that corrected the links here for me. This was of course also a big saving in filesize, but even more, it was simply comfortable for me.
Summary: The ideal application for BinPatch is the betatest of complex software over the internet. Here BinPatch shows where its power is. No matter if bugfixes oder upgrades, BinPatch is also a way to provide better customer support via WorldWideWeb (WWW), FTP, E-mail. Who ever downloaded a 1.4M archiv from a slow server will know, how glad he had have been, if there would have been a 100K update to be downloaded alternatively (Note how often transmissions mysteriously stop after about 90% ...).
When distributing a program package compiled with the same compiler, you may reduce the compiler overhead by generating other programs from one. That way, you only transfer common things once. See also Example C above.
If you want to release different (e.g. language) version of your program or a file, then BinPatch offers the option to distribute patches instead of completely "new" versions.
Option "-r" of GenPatch makes it try to take advantage of redundacy in files. This does not always give benefit compared to a patch without, but most of the time it will be a bigger patch after packing. But data that is known to be rather redudant may be packed better, when you use GenPatch to make a patch from an empty file to it. For such files, you may use BinPatch as a pre-packer.
When unpacking, you first unpack the patch and then give DoPatch a empty file to generate the complete file out of this empty file. What you may expect from this procedure differs from file to file, it is worth a try and later versions of BinPatch will allow this without using empty files.
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. Please read this chapter completly!
a) | It is my expressed wish,
that this release shall be spread in the unregistered
Version.
You are allowed to distribute BinPatch in complete and unmodified form only. Please keep the original archive, to give it to others. As an natural exception to this rule, you are allowed to spread DoPatch alone, but not including this file, means you take full responsiblity for it, so you have to disclaim it in the documentation coming along with it. |
b) | Distributing keyfiles for BinPatch is not allowed. Usage of keyfiles, which is not yours also. Only exception is when creating patches for your company, which registered BinPatch. |
c) | It is forbidden to modify BinPatch in any other way than applying patches created for it by Kay Hayen. Nobody else may generate patches for BinPatch. If you want to have BinPatch translated to other languages, please contact me to cooperate in this job. |
d) | If you want to translate BinPatch into another language, please email me. Only official translations shall be released. |
e) | The non-commercial usage of BinPatch is allowed without registration. Users are welcome to register BinPatch if they like it. Only authors themselves are allowed to create patches for their programs, this is especially essential for commercial programs. |
f) | The commercial usage
of GenPatch is not allowed without prior
registration. Usage is commercial, if the patched data is of
commercial kind or when shareware is being patched. It's never allowed to
generated and distribute patches for commercial data or shareware of other
authors or companies. This may only be done by the
authors himself and of course only using
his/their registered version of BinPatch. Applying patches will be Ok as long as the patch doesn't violate any licence term. Licence for commercial usage has to be bought and comes into effect with the installation of the keyfile only. The single user licence covers commercial usage of a single person or a one-man company. Site licence is for all company or organisation's employees in a radius of 100miles and word-wide licence is the same for this whole planet. |
g) | A keyfile of a company may not be used by employees for their own projects. Other way round, companies may not use employees keyfiles for their projects. They both have to register in order to use BinPatch for their commercial applications. |
h) | It is forbidden to reverse-engineer, discompile or disassemble BinPatch or parts of it. Also it's forbidden to produce products that base on BinPatch without the explicit permission of Kay Hayen (email: kay@kayhayen.com). |
i) | The author is optimistic that BinPatch will fullfill some use, but the only thing guaranteed, is that it will consume space on hard disks. The software package may be used within the terms of this license, but only as-is! No special function 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 is Copyright © 1997 by Kay Hayen. |
If you like BinPatch, you can - for commercial usage you must - register BinPatch. You have several options to do so. They are listed in BinPatch registration and include use of the Register.EXE that comes with BinPatch and online registration via credit card at Kagi.
The prices for registration are:
Price | Licence type | Licence description |
---|---|---|
25 US$ |
single user | One single person or one-man company |
500 US$ |
site licence | All employees at a company-site in a 100 miles radius |
5000 US$ | word-wide | All employees of a company world-wide |
As stated above BinPatch is free for non-commercial usage,
but I've spent a lot of effort, to make BinPatch as efficient and comfortable
as possible and that I'll continue this in the future too. This is what you
get:
![]() |
Your personal BinPatch registration key. Users see, that you created the patch and find your name and email address in each patch you release. At your option are address, WWW- / FTP-URL, Telephone number, and a short note. |
![]() |
Registering now includes all further updates. |
![]() |
For all platforms you specify you receive bugfixes and new releases per email. |
![]() |
A really good product and constant development. Have a look at the reviews and comments on BinPatch ! As you can get from my BinPatch-History I am very dedicated to BinPatch and respond quite fast on user-requested additional features. Feel free to suggest and drop me an e-mail. |
Note: With the release of a newer versions of BinPatch this offer no longer exists. Look for the newest version of this document in one of the BinPatch sources.
1. WWW (most recent)
If you read this page online, just follow this link to the Download-Area to get to the correspondig WWW page, else you may enter or copy&paste
http://kayhayen.com/binpatch/download.htm
to your browser's URL box. Select your platform there.
2. FTP
The official anonymous FTP server for BinPatch is my own site,
ftp://ftp.kayhayen.com.
Feel free to visit it. You will find BinPatch there in directory
/binpatch.
3. Newsgroups
I will post versions of BinPatch to the alt.binary.* newsgroups, but usually I wait to see, if there are problems with new releases before doing so.
4. Filenets
Currently all versions go through UtilNet except for Windows 95/NT which goes through W32_FDN. Feel free to suggest other filenets that might be interested in BinPatch, I'm allways searching for those.
This chapter lists all current English distributions and
their files:
- mkpat19d.zip: BinPatch for
DOS/Windows3.1 as zip-file.
File | Size(packed) | DOS | Windows 3.x | Windows 95 | Windows NT | OS/2 |
---|---|---|---|---|---|---|
GENPATCH.EXE | - | Yes, with a DPMI-Server | In DOS-Boxes | In DOS-Boxes | In DOS-Boxes | In DOS-Boxes |
DOPATCH.EXE | 30k (16k) | Yes | ||||
DOPATINT.EXE | 36k (18k) |
File | Description |
---|---|
README.TXT | Short summary of BinPatch in ASCII-format |
README.HTM | The BinPatch documentation in HTML-format (this HTML-page!) |
REGISTER.EXE | Windows program to register BinPatch offline via Kagi. |
REGISTER.HTM | Informations about registration options for BinPatch. |
REGISTER.TXT | An ASCII-textfile, that describes registering via Kagi. |
MINIPNKT.GIF BK101.GIF BAR.GIF BINPATCH.GIF |
Small images used in my HTML-documentation |
- mkpat19n.zip: BinPatch for Windows 95/NT as zip-file.
File | Size(packed) | Windows 3.x | Windows 95 | Windows NT |
---|---|---|---|---|
GENPATCH.EXE | - | No | In DOS-Boxes | NT command prompt |
DOPATCH.EXE | 51k (28k) | |||
DOPATINT.EXE | 57k (32k) |
Other files as in mkpat19d.zip
- mkpat19o.zip: BinPatch for OS/2 V2, Warp3&4 as zip-file.
File | Size(packed) | DOS | OS/2 |
---|---|---|---|
GENPATCH.EXE | - | No | In OS/2-Boxes |
DOPATCH.EXE | 46k (27k) | ||
DOPATINT.EXE | 51k (30k) |
Other files as in mkpat19d.zip
- mkpat19e.tgz: BinPatch for Elf-Linux as tgz-file.
File | Size(packed) | a-out system | ELF system |
---|---|---|---|
genpatch | - | No | Yes |
dopatch | 30k (15k) | No | Yes |
Other files as in mkpat19d.zip
Note: Actual releases may have other implementation or set of features as described below.
V2.0 (Release scheduled for 11.97)
Somethings missing? A feature you need, an important option? You think one of this planned features is not an advantage? You can offer helpful information? Just email me! :-)
This chapter lists the changes in BinPatch from version to version:
V1.9 (10. offical release for DOS, Win95, NT, OS/2 and Linux on 3.9.97)
V1.8 (9. offical release for DOS, Win95, NT, OS/2 and Linux on 11.7.97)
V1.7 (8. offical release for DOS, Win95, NT, OS/2 and Linux on 19.6.97)
V1.06 (7. offical release for DOS, Win95, NT, OS/2 and Linux on 17.6.97)
V1.05 (6. offical release for DOS, Win95, NT, OS/2 and Linux on 9.6.97)
V1.04 (5. offical release for DOS, Win95, NT, OS/2 and Linux on 21.5.97)
V1.03 (4. official release for DOS, Win95, NT, OS/2 and Linux on 3.4.97)
V1.02 (3. official release for DOS, Win95, and Linux on 17.2.97)
V1.01 (2. official release for DOS, Win95, and Linux on 11.2.97)
V1.00 (1. official release for DOS, Win95, and Linux on 5.2.97)
V0.90 (9. Betaversion for DOS, Win95 and Linux on 31.1.97)
V0.89 (9. Betaversion for DOS, Win95 and Linux on 22.1.97)
V0.88 (7. Betaversion for DOS, Win95 and Linux on 20.1.97)
V0.87 (6. Betaversion for DOS, Win95 and Linux on 16.1.97)
V0.86 (5. Betaversion for DOS, Win95 and Linux on 14.1.97)
V0.85 (4. Betaversion for DOS and Linux on 23.12.96)
V0.84 (3. Betaversion for DOS and Linux on 19.12.96)
V0.83 (2. Betaversion for DOS on 16.12.96)
V0.82 (1. Betaversion for DOS 11.12.96)
Earlier versions were internal alpha versions and have not been released.
Tip: Of course the name of a patch should explain somehow, what a patch does, which will not be the case, if you call it "UPDATE" or similar. Prefer things like "V21_V22".
Tip: If you are patching big files with the DOS/Windows Version of GenPatch, it may occur that the "automatic" DPMI-Service of Windows fails. In this case create a special DOS-Box, edit its memory settings for DPMI from "automatic" to 32000 or even 65000. Background: Windows will not give DPMI as needed in "automatic" mode, but rather calculate the size from your physical RAM. This is even with 32MB installed not much and too less for GenPatch when creating patches for very big files. If this still seems not enough, then you might try the Win95/NT, OS/2 or the Linux version of BinPatch. Alas, they are compatible but the OS makes it easier to acquire as much memory as needed.
Tip: The enviroment variable "BINPATCH_OPTS" is read and parsed by GenPatch every time you run it. Place there frequently used parameters.
Tip: Try to have the same compiler options when compiling programs which will be patched later. Otherwise you produce more differences that make the patchfile bigger.
Tip: Option "-r" may give better results for files with redundancy (parts of the file occur several times in a similar way) that were not there in the older versions. The generation of patches is slowed down by this. Possible application is to patch newsbatches (Threads) with this option. Very many newsbatches contain questions and answers in it. This can be much more space-efficient for big newsbatches compared to only packing them. (Remember to unpack them before patching them.)
Tip: If you want to patch text files, then try the options -c200 and -l2000, which modify the default behaviour of GenPatch. The defaults are optimized to give best result with program file, which is about -c25 und -l245 at the moment.
Tip: I recommend using LHA for selfextracting archives. It has only 2KB overhead which is *much less* compared to other packers.
Using the DOS/Windows version of GenPatch, you may see GenPatch terminating with a complaint about not enough memory. See Tips section above for solutions.
The size of patchable files is limited to 2 Gigabytes, but this has not been verified, yet. ;-)
Using OS/2 version of GenPatch and pressing CTRL-C while creating a patchfile, the "begun" patchfile is not deleted and DoPatch will not accept those incomplete files. Other platforms automatically delete the patchfile on CTRL-C.
It has been reported that GenPatch for Linux 1.05-1.8 coredumped right after generating the patchfiles. The generated files were OK and can be used! This problem should be gone with version 1.9.
DOS/Windows 3.x: None.
Windows 95/NT: None. DoPatch will not work in MS-DOS mode, use DoPatch for DOS.
Linux: Current implementation doesn't yet autofind patch targets, but ignores this DoPatch option completely. This is due to possible endless loops caused by links in current implementation. Also Linux is the only supported platform that has case-sensitivity on filenames. This can be problematic when applying patches generated on other platforms that do not distinguish case. So this is not recommended unless you use filesystems compatible with (V)FAT.
OS/2: None, just note that GenPatch does not yet correctly handle CTRL-C with deleting the incomplete patchfile.
If you are only applying patches with DoPatch, please ask the creator of the patch first! Most problems result from wrong file used to generate or apply patches. No responsible author will distribute patches of which he is unsure if they really work.
If you find something in BinPatch that is supposed to be a bug, please read the chapters "Platform specifics" and "Possible Problems" to see, if this problem is allready known. Then please look in one of the Distribution Sources for BinPatch and see, if the problem allready has been removed in a newer version.
Try to reproduce the problem under given circumstances. If 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 same problem.
If possible for you, try out other platforms of BinPatch with the same situation, to see if the problem is related to one special platform. And it would be fantastic, if you tried out older versions of BinPatch in order to see, if the problem is new.
The try to email me with the following informations:
Send that mail to bugreport@kayhayen.com and use subject "Bugreport BinPatch Vx.xx" in order to give me a chance to presort messages. Please don't include the binaries immediately. If there is reason for this, I'll ask you for. Normally there will be no need for it.
Registered users may decide themselves to prepend "REG:" to the subject and will be treated with priority.
My general thanks go to my brother Andree, who introduced me to the Internet with his site "Edition". Consulting him was often a big help / support for me and kept me away from many foolish things.
In addition I would like to thank Matthias Babisch for giving some ideas at startup-time of the project that made BinPatch fast enough to continue my development to a first runable test-version and did not give up before.
Recognition to Matthias Hahn who was helpfull at discussing some theoretical problems.
Many thanks go to Oliver Mulatz who helped me to revise this documentation. He has done a great job in this!
Thanks to DJ Delorie and Eli Zaretski. They have given me a lot support for "DJGPP" a GNU-Port of gcc for DOS, which was surely a good tool for developing BinPatch.
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 helpfull in alpabetical order:
Enjoy trying it out!
Regards, Kay Hayen
PS: I shall be very thankfull for proposals on content, layout or HTML code of this documentation. Please help to make it as understandable as possible. Feel free to enhance / correct it and sent it as email to suggestion@kayhayen.com
BinPatch | The program package to generate and apply patches. Sometimes you will also find patches made with BinPatch aka UTP-files addressed as a "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, part of BinPatch. |
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 does need, but you only need to supply a DPMI-Server on your own, when want you use BinPatch under pure DOS to generate patches. |
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 needn't 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 dots. Only DoPatch for Windows 95/NT can work with these filenames, but not DoPatch for DOS/Windows3.x. |
There are situations when you may have to update several similar files or directories. You could supply two different patchfiles to update version 2.0a and 2.0b to 2.1. Using Multipatch you can generate a patchfile containing info on how to update both with only one patchfile with normally only minimal increased size of the patchfile, saving you 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 carrys 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 one patchfile. |
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 a quote (with '>' or similar) of the article in it. 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 "issi" two times. BinPatch can take advantage of such phenomens to shorten file information by referering 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 drains of your valuable resources. |
This is page http://www.kayhayen.com/binpatch/readme.htm
Copyright © 1997 Kay Hayen. Last changes 3.11.1997. All mentioned names or trademarks are property of the corresponding companys. Responsible is webmaster@kayhayen.com, Kay Hayen Software, Hamburger Ch.114, 24113 Kiel - Germany.