Classic V2.1
(12. official release for DOS, Win95, NT, OS/2 and Linux on 26.March.98)
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 leave out the redundant data. You may choose to create either executable patches or "plain" patches. The latter are applied using the program DoPatch, whereas executable patches need no external program to be applied. BinPatch easily allows 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 (called 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 compressor or archiver can nearly achieve those fantastic rates that BinPatch does at updating files. With 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, since huge parts of modern programs are made up from static libraries. Especially Windows programs take much of their filesize from these. So try for yourself and see how much BinPatch can save you!
Caveats: The only thing you have to consider is that BinPatch cannot work (good) 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 also receive bad results. (Unfortunately packers / encryptors generate a very broad distribution and resulting diffusion of the processed data, so there is not much similarity after packing.)
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 requires a DPMI-Server (which you already have when running Windows or OS/2. Alternatively use QEMM or free DPMI-Server CWSDPMI.) | None. Developed to run out of the box on any DOS computer. |
| Windows 95/NT | None. | |
| OS/2 | None. | |
| Linux | Kernel 2.0.0 or better | |
The simplest application of BinPatch is to generate a patch from two files
that updates one into the other. 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 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: Executable patches.
Just add the option "-sfx" to the GenPatch command line to create executable patches. Such are, of course larger than "plain" patchfiles, but will not require a DoPatch to be applied anymore. Executable patches 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, Linux) DoPatch version to apply executable patches just the same way you do with "plain" patchfiles. So executing patches is just an option, but not required, if you e.g. run Linux and have a DOS executable patchfile.
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. It begins with the current directory and goes through all of your partitions / harddisk(s). Executable patchfiles do this by default unless you specify the file or directory to be patched on the commandline.
GenPatch offers many options to control its behaviour in most any aspect:
Executable patch files: Use command line option "-s" to have GenPatch creating a executable patch file. That is a patchfile able to apply itself on its execution. Note that these patches may also be applied using a compatible DoPatch, if e.g. you have DOS executable patchfile and want to apply it while using Linux.
Windows interface patch files: The special variant "-s=gui" will not only create an executable patch file, but will instead create one that presents the end-user with an windows interface. Note that the DoPat32.exe that is used to create them can take commandline parameters even though its a Windows 95/NT program. You can use that to avoid the autoscan.
International patch files: With commandline option "-s=loc" you tell GenPatch to create a executable patch file that will detect end users system language and output all texts in that language. Currently international patches support includes English as default, French and German. Other languages will be added and options to control which language texts should be included (e.g. English and Norwegian, but no other) will be implemented with release 2.1.
Allow patial application of patches. Some files are not that important as that failure to update those should cause the complete patching process to fail. Prior versions of the DoPatch engine required all files to be created. With this version of BinPatch you may specify in GenPatch which files DoPatch should tolerate to fail being created due to not finding a matching source version. Using GenPatch option "-t" to do that. With specifying "-t=*.dat" you will tell GenPatch to include information for files matching that pattern to tolerate failure in updating them. Note that "-t=*" will tolerate just any file to fail, but will make the Autofind of DoPatch just useless because such patches may be "applied" to just any directory. DoPatch does not detect that by now, so be aware to not tolerate at least one that serves as an anchor.
Ignore file matching patterns completely: To ignore certain files, file types or subdirectory, just just specify them as patterns with option "-i". Such files will be removed from internal processing of GenPatch completely, ie. this option has highest precedence over all other options. Patterns are filenames, possibly including relative paths, with patterns. With specifying "-i=*.dat", you will e.g. ignore all files that end with ".dat", "-i=data/fra*.dat" will only ignore files in subdirectories "data" start start with "fra" and end with ".dat". The character "*" matches no 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.
Ignore files in some directories only: Ignoring files may be restricted to some of the source or final state directories only. Use "-if=pattern" to ignore final state files only, use "-is=pattern" to ignore files in source state directories only. 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 forth source state with "-i4=pattern". You may also combine those and use "-i2,3,f=pattern" to ignore files in source states 2 and 3 as well as final state in one turn.
Force to create patch information for identical files: Normally GenPatch autodetection skips files of the final state that it finds unchanged compared to all source states. It would be useless to include information about them, unless you want to do one of two things: a) Force existance 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 option "-f" tells GenPatch to create patch information for unchanged files and helps you to apply both of above.
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.
Specify the default packer: By default, InfoZIP is used, if you ask GenPatch to compress the created patchfile into an archive automatically. But you can choose any of the common packer tools as the default. Once you have it installed in your system's path, you can use option "-Z=packername" to select the default packer. It's very much recommended to use this option enviroment variable "BINPATCH_OPTS", as on normal commandline you'll have easier ways to accomplish this task or to override the default setting for packing a specific patch. Packernames supported are InfoZIP, PkZIP, GZIP, RAR, ARJ, JAR and LHA.
Tell GenPatch to pack the created file: Using option "-z" with nothing more, will tell GenPatch to call the default packer (see above) to pack the created patchfile.
Use packer other than 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 precence than option "-Z" and accept the same packernames.
Create selfextracting archives from patches: If you used option "-z" you may add option "-x" to ask the packing tool used to create a selfextracting archive. Note that not all packers support this and not every implementation of this comes with small overhead. Ranges are from 2K (LHA) to 50K (InfoZIP).
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. 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 patchfile is a function of involved filesizes that grows quite fast. BinPatch uses algorithms that don't do that as fast, 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 middle will be reduced to 25% 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 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, it's there likely that you use files with extremly bad matching characteristics.
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 always 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" and "-l".
If you have an executable patchfile, just execute it. It will autoscan your partitions/harddisk(s) 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 patchfiles
If you have a plain patchfile, recognized 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 might not be complete, because then information about all unmodified files is 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), we are 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:
After delivery of a demo we noted that minor changes were necessary. Without those, testing the program would been less telling and we did not want the tester to cope with our fault. But the binary had already been released. Using BinPatch the commandline "GENPATCH UNITED41 UNITED42 UPDATE" created a 5.7kB "UPDATE.UTP", which was packed 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 | 570kB |  |
| Patch | 5.7kB | |
| Packed Patch | 2.7kB | |
Applying the patch was easy. He only needed to type "DoPatch update.utp -auto" and our demo was instantly updated. Cool. If we had sent him an executable patchfile, it would have been only 18kB, still quite tolerable and updating would have been even easier: "Update.exe".
Example B:
We sent some beta-tester an updater 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 | 570kB | |
| Patch | 77kB | |
| Packed Patch | 35kB | |
Unless you add large 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 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 realistic with just 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 versions, react quickly on reports and keep your testers motivated. And you all surely know how essential testers are for quality control and development!
Example C:
For the first BinPatch releases on DOS we did not include GenPatch as an executable but only as a patchfile applicable to and by DoPatch that made GenPatch out of DoPatch! That reduced the filesize of that early release to only 47kB instead of 74kB.
| Smaller releases using BinPatch | ||
|---|---|---|
| Full packed version | 74kB | |
| Full packed version with install using Patch | 47kB | |
We admit that this application is rather untypical, but it shows an additional potential of BinPatch. This patch was reasonable became 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 us a patchfile that corrected the links for us. This was of course also saving in filesize, but even more, it was simply comfortable for us.
Summary: The ideal application for BinPatch is the betatest of complex
software over the internet. Here BinPatch unleashes its power! No
matter if bugfixes oder upgrades, BinPatch proves as an excellent possibilty
to provide better customer support via WorldWideWeb (WWW), FTP or E-mail.
And: Who ever downloaded a 1.4MB archiv from a slow server will know,
how glad he had have been, if there would have been a 100KB update to be
downloaded alternatively (Note how often transmission mysteriously stop after
about 90% ...). It could be a potential customer lost, it could be an important
betatester lost, anyway, it's a loss for all. Not everybody starts downloading
such a big archive twice...
If you have serial numbers in your files, applying BinPatches is a perfectly easy way to overtake those serial numbers with updates. Users need not re-enter the information they've lost and re-contact your support division.
When distributing a program package compiled with the same compiler, you may reduce the compiler overhead by generating other programs from one. This 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 files, 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 redundant may be packed better, when you use GenPatch to make a patch from a 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 an empty file to generate the complete file under your specified filename. Which performance and filesize savings you may expect from this approach 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 Classic" is only allowed according to the following terms. Using "BinPatch Classic" signals agreement to these terms. References to "BinPatch Classic" 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 unregistered
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 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 keyfile, 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 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.
Applying patches will be O.K. as long as the patch doe not violate any licence terms. 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's 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. Also 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, 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 the program errors.
Except as spefifically 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, guarantuee 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, incidential or indirecect damages (including damages for loss of buisness profits, buisness interruptions, loss of buisness 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 incidential 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 (wether in contract, tort (including neglicence), 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 harddisk. 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 Classic and Professional are Copyright © 1996-1998 by Kay Hayen. |
If you like BinPatch, you can - for commercial usage you must - purchase a BinPatch licence. 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 BinPatch licences 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$ | World-Wide | All employees of a company world-wide |
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 urls, info autoresponders, telephone number and a short note. |
|
Registering now includes all further updates of BinPatch Classic. |
|
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 the BinPatch History, we are very dedicated to binary patching technology and respond fast on user-requested additional features. Feel free to suggest any and drop us an e-mail. |
Note: With releases of a newer versions of BinPatch this offer may no longer exists. Look for the newest version of this document at http://www.kayhayen.com/binpatch/readme.htm.
1. WWW (most recent)
If you read this page online, just follow this link to the Download-Area to get to the corresponding 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 (most recent)
The official anon-ftp server for BinPatch is our owners site, ftp://ftp.kayhayen.com. Feel free to visit it. You will find BinPatch in directory /binpatch.
3. Newsgroups
We will post versions of BinPatch to the alt.binary.* newsgroups, but usually wait to see, if there are problems with new releases before doing so.
4. Filenets
Currently all versions go through UtilNet except that for Windows 95/NT which goes through W32_FDN. Feel free to suggest other filenets that might be interested in BinPatch, we are always searching for those.
This chapter lists all current English distributions and their files:
- mkpat21d.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 | 30kB (16kB) | Yes | ||||
| DOPATINT.EXE | 32kB (17kB) |
| File | Description |
|---|---|
| README.TXT | Short summary of BinPatch in ASCII-format |
| README.HTM | The BinPatch Documentation in HTML-format |
| REGISTER.EXE | Windows program to help registering BinPatch offline via Kagi. |
| REGISTER.HTM | Information about registration options for BinPatch. |
| REGISTER.TXT | An ASCII-textfile, that describes registering via Kagi. |
| MINIPNKT.GIF BK101.GIF BAR.GIF LOGO.GIF |
Small images used in HTML-documentation |
- mkpat21n.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 | 36kB (20kB) | |||
| DOPATINT.EXE | 37kB (21kB) |
Other files as in mkpat21d.zip
- mkpat21o.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 | 46kB (27kB) | ||
| DOPATINT.EXE | 47kB (30kB) |
Other files as in mkpat21d.zip
- mkpat21e.tgz: BinPatch Classic for Elf-Linux as tgz-file.
| File | Size(packed) | a-out system | ELF system |
|---|---|---|---|
| genpatch | - | No | Yes |
| dopatch | 30kB (15kB) | No | Yes |
Other files as in mkpat21d.zip
Note: Actual releases may have other implementation or set of features as described below.
V2.2 (Release scheduled for April/May 98)
You miss something, a feature you'd need, an important selection option? Do you think one of this planned features is not an advantage, or you want to provide helpful information? Just email us! It's very often only a question of days or even hours to see your suggestion implemented in a betaversion you receive.
This chapter lists the changes in BinPatch from version to version:
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, and Linux on 17-Feb-97)
V1.01 (2. official release for DOS, Win95, and Linux on 11-Feb-97)
V1.00 (1. official release for DOS, Win95, and Linux on 5-Feb-97)
V0.90 (9. Betaversion for DOS, Win95 and Linux on 31-Jan-97)
V0.89 (9. 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.1.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: Of course the name of a patch should explain somehow, what it does. This will not be the case, if you call it "UPDATE.utp" or similar. Prefer things like "V21_V22.utp".
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 hardly sufficient
in all cases. If this still seems not enough after increasing to maximum,
then you might try the Win95/NT, OS/2 or the Linux version of BinPatch. Alas,
they are compatible but the OSs make 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 (unnecessary) differences, resulting in bigger patchfiles.
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 older versions. The generation of patches is slowed down by this. Possible application is to patch newsbatches (news threads) with this option. Generally newsbatches contain questions and answers quoting it repeatedly. This can be much more space-efficient for big newsbatches compared to packing them only.
Tip: If you want to patch text files, then try the options "-c220" and "-l2000", which modifies the default behaviour of GenPatch. The defaults are optimized to give best result with program files, which are "-c25" und "-l245" at the moment.
Tip: We recommend using LHA for self-extracting 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 a solution.
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.9f coredumped right after generating the patchfiles. The generated files were OK and can be used! This problem should be gone with version 2.0.
You may include hidden files while patching under DOS or Windows95/NT using option "-a". By default hidden files are not included. But you cannnot expect the hidden file attribut to be set after patching. You should instead use a batchfile to set the attributes after patching. Later versions will include ability to set the flags correctly.
Versions 1.9a to 1.9f made rare mistakes in autodetection. It could happen that DoPatch encountered source files already updated when it was tried to use them in overwrite mode. This bug of GenPatch has been fixed with 1.9g and later.
DoPatch for DOS versions prior 2.1 will refuse to run on Pentium II computers.
Embedded files were not moved to backup directory prior release 2.1
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.
Linux: Current implementation does not autofind patch targets. This DoPatch option is ignored completely because of 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 created on another platforms that do not distinguish case.
OS/2: None, but GenPatch for OS/2 does not yet correctly handle CTRL-C. Instead of deleting the incomplete patchfile under OS/2, you will have the patchfile remaining, but it will not be accepted by DoPatch. The so-called "extended attraibutes" (EA) of OS/2 are included for all patched files with GenPatch's option "-A". Applying those 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, you will only loose the EA information of the patchfile.
If you have problems applying patches with DoPatch as a customer, please ask the creator of the patch first! Most problems result from wrong file(s) or wrong parameters 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 already known. Then please look in one of the "Distribution Sources for BinPatch" and see, if the problem has been removed in a newer version.
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.
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.
The try to e-mail us with the following information:
Send that mail to bugreport@kayhayen.com and use subject "Bugreport BinPatch Vx.xx". Please don't include the binaries immediately. If there is reason for this, we will ask you for. Normally there will be no need for it.
Our general thanks go to our founder's brother Andree Hayen, who introduced him to the Internet with his site "Edition". Obviously he was a great consultant and support for him.
In addition we would like to thank Matthias Babisch for giving some ideas at startup-time of the project that made BinPatch fast enough to continue development to a first runable test-version and did not give up before.
Recognition to Matthias Hahn who was helpful at discussing some theoretical problems.
Many thanks go to Oliver Mulatz who constantly helps to revise this documentation. He does a great job in this and contributes in most other fields too.
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
| 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 that are not executable, but plain format, 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 needs and you only need to supply a DPMI-Server on your own, when want you use BinPatch under pure DOS to generate patches. Again: No need for an external DPMI-Sever 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 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 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 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 phenomenons 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 drains of your valuable resources. |
This is page http://www.kayhayen.com/binpatch/readme.htm
Copyright © 1998 Kay Hayen. Last changes 17-April-1998. All mentioned names or trademarks are property of the corresponding companies. Responsible is webmaster@kayhayen.com, Kay Hayen Software, Hamburger Ch.114, 24113 Kiel - Germany.