V1.9
V1.9
The name BinPatch describes my software-package to generate and apply patches on binary files of any kind. One program named GenPatch can be used to generate a so-called patchfile from two (or more) different version of a file (or from two or more complete directory structures). That patchfile serves another program called DoPatch to transform a given version of a file or whole program directory into another one. This usually makes sense when doing software-updates.
If you compare a compressed patchfile with the complete new versions in terms of filesize, you see the point of using BinPatch. No compressor can nearly achieve those fantastic rates that can be achived using BinPatch for updating files. Esp. program files, texts and databases show up with extremly good rates when patched (see also "Praxis examples of BinPatch usage".)
Background: Normally there is only little change in programs for newer versions. Only few parts are revised and most parts remain (allmost) unchanged. Also huge parts of modern programs are made up from libraries, that rarely change and especially windows-programs have a huge nearly constant part. Try and see how much BinPatch can save with these.
Caveats: Only thing you habe to worry about, is that BinPatch can not work with compressed or crypted data. Always use normal software installations instead of archives of packers. Unpack those before. Executables packed internally also give worse results. (Unfortunately packers generate completely different archives even with similare data, so BinPatch can't do its' job with them.)
Hints: Packing the generated patchfile is completely Ok, esp. because GenPatch is optimized to generate patchfiles, which are bigger than neccessary, but will be much smaller when packed! (This is much of the secret of BinPatch's power compared with other patching tools.)
Especially if you do software-updates,
BinPatch might be very useful for you.
It saves a lot of time and money for the customers receiving Bugfixes or
newer versions. Why should your customers, beta-testers or friends receive
lots of Megabytes, if you could send them only a few Kilobytes?
| Requirement table | GenPatch | DoPatch |
|---|---|---|
| DOS/Windows3.1 | GenPatch for DOS needs a 386 processor and a DPMI-Server, which you implicitely have using any DOS-Box of Windows or OS/2. Alternatively you may use QEMM or the free DPMI-Server CWSDPMI. | DoPatch for DOS needs only DOS and a 286 or higher. Almost no memory and no DPMI needed. It has been developed to run out of the box on any DOS computer. |
| Windows 95/NT | None. | |
| OS/2 | None. | |
| Linux | Both need ELF-libraries installed. Support for aout-Linux is no more planned. | |
Differences between GenPatch and DoPatch for DOS have design reasons. GenPatch has a very complex job to do and needs to be reasonable fast. DoPatch has to be useable for everyone while GenPatch is more targeted to developers and experienced users, where these requirements are comparatively low.
Usage of the computer software package "BinPatch" is only allowed if you respect the following terms. Using "BinPatch" signals agreement to these terms. Refering to "BinPatch" here means sll programs of the softeare package as well as the 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 only allowed to distribute BinPatch in complete form and unmodified. Please keep the original archive file to give it to others. As an natural exception to this rule, it is allowed to put a DoPatch together with a patchfile, but not including this file within it means taking full response 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 patch 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 does not 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 registration 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 (mail: 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 won't take responsibility for their contents too. |
| j) | BinPatch is Copyright © 1997 by Kay Hayen. |
The advantage of Binpatch compared to sending complete versions all the time can be made clear with some examples:
(Note: Most examples concern: United-Edition, a PBEM, I'm developing at the moment. It is a Windows program compiled with Delphi including help files and other typical stuff for that platform. A complete release has about 570k. Quite a few bytes.... Now image to send this out to somebody via mail to somebody in the internet. Because of current internet standards, you may have to 'encode' the archive, so it may be even 760k to be transmitted and payed, by both!)
Example A:
I had not localized some german texts in a demo, which I send a English friend. Now I didn't want him to cope with the German texts and changed them later. But the demo was out, so what did I? Yes, I typed: "GENPATCH UNITED41 UNITED42 UPDATE" and created a 5.7k filesize "UPDATE.UTP", which was packable to 2.7k. In percent that was less than 0.9% and next to nothing:
| Minor bugfix to United-Edition demo | ||
|---|---|---|
| Full packed version | 570k |  |
| Patch | 5.7k | |
| Packed Patch | 2.7k | |
My friend only needed to type "DoPatch update.utp -auto" and rightaway the program found the old version itself and offered him to update it. Easy.
Example B:
I wanted to send somebody a update after a longer time (about 2 months) and there were quite a lot changes made in this time, but BinPatch is optimzed to this matter and yields smallest filesizes here too:
| Major update to United-Edition demo | ||
|---|---|---|
| Full packed version | 570k | |
| Patch | 77k | |
| Packed Patch | 35k | |
If you don't add new components the size of the patch starts to grow slowly from some point. This is because most changes in the executable arise from linker optimizations and moved global variables, whose references need to be patched. But rewriting complete routines is only a few bytes compared to that. So this result is very realistic with allmost any major update.
Example C:
For the first releases on DOS I did not include GenPatch.EXE as a binary but as a patch of DoPatch.EXE that made GenPatch out of DoPatch. This reduced the filesize of that early release fto 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 internet. Here BinPatch shows what it's power is. No matter if bugfixes oder real upgrades, BinPatch is also a way to provide better custom support via WWW. Who ever downloaded a 1.4M archiv from a slow server will know, how glad he'd have been, if there would have been a 100K update to be downloaded alternativly. (Note how often the transmission stops after about 1.3M....)
Through a special option you can instruct GenPatch to try to take advantage of redundacy in the newer version of a file. 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 prepacker.
When unpacking, you first unpack the patch and then give DoPatch a empty file to regenerate the complete file. What you may espect from this procedure differs from file to file, a try is it worth and later versions of BinPatch will allow this without using empty files.
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.
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 WWW and email address easily. |
|
Registering now includes all later updates. |
|
You receive bugfixes and new releases for one selected platform per email. |
|
A really good product and constant development. |
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.
Note: A site or word-wide licence only to applies to products of the registered company. No employee may use that licence for his own projects.
1. WWW (most recent)
If you read this page online, just follow the 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 anon-FTP server for BinPatch is mine: ftp.kayhayen.com. Feel free to visit it. You will find here newest on older versions of BinPatch.
3. Newsgroups
I 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.
This chapter lists all current English distributions and
their files:
- mkpat19d.zip: BinPatch for
DOS/Windows3.1 as InfoZip-file.
| Datei | Size(packed) | DOS | Windows 3.1 | 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 docomentation in HTML-format |
| REGISTER.EXE | Windows program to register BinPatch via Kagi. |
| REGISTER.HTM | Informations about registration options for BinPatch. |
| REGISTER.TXT | A 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 InfoZip-file.
| Datei | Size(packed) | Windows 3.1 | Windows 95 | Windows NT |
|---|---|---|---|---|
| GENPATCH.EXE | - | No | In DOS-Boxes | NT command prompt |
| DOPATCH.EXE | 51k (28k) | |||
| DOPATINT.EXE | 57k (32k) |
Other files as they are in mkpat19d.zip
- mkpat19o.zip: BinPatch for OS/2 V2, Warp3&4 as InfoZip-file.
| Datei | Size(packed) | DOS | OS/2 |
|---|---|---|---|
| GENPATCH.EXE | - | No | In OS/2-Boxes |
| DOPATCH.EXE | 46k (27k) | ||
| DOPATINT.EXE | 51k (30k) |
Other files as they are in mkpat19d.zip
- mkpat19e.tgz: BinPatch for Elf-Linux as tgz-file.
| Datei | Size(packed) | a-out only | ELF system |
|---|---|---|---|
| genpatch | - | No | Yes |
| dopatch | 30k (15k) | No | Yes |
Other files as they are in mkpat19d.zip
Note: Actual releases may have other implementation or set of features as described below.
V2.0 (Release scheduled for 9/10.97)
Somethings missing? A feature you need, an important option? You think one of this is a mistake? You can offer helpfull 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.
The most simple application of BinPatch is to generate a patch from one file to another. Suppose we have 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 for this job are the both filenames and last one, which will be the name of the patch generated by BinPatch. Say we call the patch "OLD2NEW", all you need to provide
GenPatch OLD.EXE NEW.EXE OLD2NEW
and you have your patchfile.
Normally your patchfile will have the suffix ".UTP" to form the filename 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 what file shall 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 you need not keep the original file you may use the command:
DoPatch OLD2NEW.UTP OLD.EXE
A typical case for distributing a software package is patching complete directories or directory structures. This does not require something very different. Just give the path of the two directories and name the patchfile to be generated with this command:
GenPatch OLD_DIR NEW_DIR OLD2NEW
and you have your directory patch. GenPatch scans NEW_DIR and automatically finds those files in OLD_DIR that can be used as sources and puts all these 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 haven't changed will be ignored (unless you use option "-f" to force patching even for these). BTW: Scanning of directories includes subdirectories as well.
To apply a "directory"-patch use the command:
DoPatch OLD2NEW.UTP OLD_DIR NEW_DIR
It would create the directory NEW_DIR (unless already existing) 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 old data will be moved into a new subdirectory "backup" and replaced with newer one. To patch the current directory, you would use the even shorter command:
DoPatch OLD2NEW.UTP
If you want application of your patches as simple as possible, 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 which will be able to apply itself. Of course this patchfile is larger than the "plain" patchfile, but will not need any DoPatch. It must be run under the OS of the GenPatch with which it was created, though you still may use DoPatch 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 in 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's very comfortable when applying patches. It can find possible patch targets by scanning your harddisk for such. Use option "-auto" to activate this scan, that begins with the current directory and goes through all of your harddisks.
GenPatch offers some special options:
Use "-sfx" or "-s" to instruct GenPatch to create a selfexecuting patchfile. That will be a DoPatch and a patchfile merged and apply the Patch when it's executed.
Use "-f" to tell GenPatch to patch files even if they didn't change at all. The information for this will be very short, but has two consequences: First DoPatch will not work without that files. Second DoPatch will copy these files when patching into another directory, so this enables the user to create "clean" installations with only necessary files using such a patch.
Use "-z" to make GenPatch call an external packer after patching. This saves you the call of that program. The packer needs to be installed and can be selected using "-Z". Using "-x" you may even generate a selfextracting archive of the patch and DoPatch, but keep in mind, that not all packers can generate self extracting archives on every platform.
Use "-r" to allow patches to refer to parts of the file allready created. This may make sense, but isn't the default. Try it in your concret case, and compare packed filesizes. A generell rule can't be given, as both happens, sometimes the packed patchfile gets larger and sometimes it's smaller. Watchout as the packed filesize of the patch is normally more interesting. Though patches made with "-r" are normally smaller, this says nothing about packing.
Use "-c" to select the stepsize 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 and might want to experiment with much bigger values for textfiles, because those have much more stable data than program-files. Values above 10000 won't make to much sense.
Use "-l" to specify to range of the local peephole for optimizing embedded parts of newer versions. This value does not influence the size of the patch itself, but in high degree this changes the size of the patch after packing! For programs the default of 245 is quite good, higher or lower value will quickly result in bigger packed patches. The ideal value depends from the file itself and from the packer used. Normally, you shouldn't change it, only exception are textfiles, where -l2000 will give you better result. Even higher values will give not much better values and make "Warp 3:" of GenPatch very slow.
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.
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 something like that. Prefer things like "V21_V22".
Tip: If you're 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 it's memory settings for DPMI from "automatic" to 32000 or even 65000. Reason: Windows won't give DPMI as need in "automatic" mode, but instead calculate somehow a size from your physical RAM. This may be to less, when patching very big files. (Supplying such high values seems harmless in all aspects, but no guarantue..) If this still seems not enough, then you might try the OS/2 version or the Linux version of BinPatch. They are compatible, but the OS makes it easy to get as much memory as you need.
Tip: The Enviroment-Var "BINPATCH_OPTS" is scaned by GenPatch and concated to any command line given to it. Use this to enter parameters like "-f" that you want enabled by default for every patch you do.
Tip: Try to have the same compiler options when compiling programs to be patched. Otherwise you produce unneccessary differences that only make the patchfile bigger, just because of debugging code or so.
Tip: The option "-r" will give much better results, for files with redudancy (parts of the file occur several times in a similar way) that weren't there in the older versions. The generation of patches is slowed down by this. Possible application is to patch newsbatches with this option. Very many newsbatches contain questions and answers in it. This can be save much for big newsbatches compare with 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.
Using the DOS/Windows version of GenPatch, you may see GenPatch terminating with a complaint, that there was not enough memory. See Tips section above for soultions.
The size of patchable files is liimited to 2 gigabytes, but this has not yet been verified. ;-)
When pressing CTRL-C while GenPatch creates a patchfile, the "begun" patchfile is not deleted and DoPatch will not accept those incomplete files. Since V1.05 this problem has been solved for GenPatch for DOS/Windows3.1 and Linux. Since 1.9 it has also been solved for Windows 95/NT, OS/2 still has that problem.
All versions of DoPatch can be used several times in paralell except for DoPatch for DOS, which may only run once at a time. But this has not been tested much, so please be carefull.
It has been reported that GenPatch for Linux 1.05/6 coredumps after generating the patchfiles. The generated files are OK and can be used! (Strange, I admit) Since I can't test it here myself and 1.7 had to be out quickly, I decided to release it, before I had reports, wether the problem still exists with the new version. This problems seems to be in GenPatch for Linux even with 1.9 on some machines.
DOS/Windows 3.1: None.
Windows 95/NT: None, but DoPatch for Windows95/NT requires GUI mode under Win95. Use DoPatch for DOS, if you want to apply patches in MS-DOS mode.
Linux: Currently Linux is the only supported platform that distinguishes case of filenames. This can be problematic when applying patches generated on other platforms that do not distinguish. Generate directory patches with GenPatch for Linux until this is solved.
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 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 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 it. Normally there will be no need for it. (Registered users may decide themselves and prepend "REG:" to the subject.)
My general thanks go to my brother Andree, who opened internet for me with his site "Edition". Consulting him was often a big support for me and kept me away from many foolish things.
In addition I'd 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 didn't give up before.
Recognition to Matthias Hahn who was helpfull at discussing some theoretical problems.
Thanks to DJ Delorie and Eli Zaretski. They've given a lot support for 'djgpp' a GNU-Port of gcc for DOS, which was surely a good tool to develop 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 needs, you only need to supply a DPMI-Server your own, when want you use pure DOS to generate patches. |
| GenPatch | Name of the program to generate patches, part of BinPatch. |
| Long filenames | 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.1. |
| 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, saving you a lot hassle and normally only minimum increase of patchfile size. | |
| 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 it's called, when information is being repeated in a similar way. For BinPatch there's redundancy when you have a article and a quote of (with '>' or similar) in it, because BinPatch compensates minor changes very good. Such redundancy is not well recognized by other patchers, but it is, if you enable the option "-r" with BinPatch. |
| Normally this term refers to file archives in form of executeable files that unpack their contents when executed. You need no unpacker for those, they unpack themselves. With BinPatch you have something similar, so called selfextracting patchfiles. Those are simply an executable that - when executed - searches for possible targets and applys the patch information it carries. Using selfextracting (short SFX) patchfiles you need not bother if or what kind of DoPatch the other one has. Selfextracting patches are not bigger that normal patchfiles with size of DoPatch for that platform added. | |
| Overhead | Part of a program that has no function, but is there for technical reasons. |
This is page http://www.kayhayen.com/binpatch/readme.htm
Copyright © 1997 Kay Hayen. Last changes 10.9.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.