RTPatch Technology Overview


RTPatch is a commercial, binary diff (delta) software product, first released in 1991. Today, it is the gold-standard in its class, and is used worldwide for millions of updates applied daily.

RTPatch consists of two main components: the portion that Builds the patch file on the developer's machine, and the portion that Applies (merges) the patch file on the target device:




Patch Build Features

State of the art binary diff patching (90+ percent reduction of update size)
  • Experience: Pocket Soft has been in the binary diff file compression business commercially since 1991. We’ve actually been in the business for longer than that: we originally wrote the tools for our own internal use, then built a commercial system from those tools. Tens of billions of patches have been applied worldwide using our tools (over a million applied daily), and our reliability is unparalleled. This level of experience has also led us to have industry-leading rich feature set and performance levels. Whether you need to build patches on small files in a resource-limited environment or multi-gigabyte files on multicore machines, whether your primary need is for small patches, rapid build times, or custom end-user file-handling, our solutions have the flexibility and performance you need.
Cross platform (build on one OS, apply on another)
  • Not simply a port from one OS to several others, we have cross-platform features designed in from the ground up. OS-specific filesystem features are handled gracefully. For example, a patch built on Windows but applied on Linux will have file permissions set so as to mimic as closely as possible the effect of the file security present under Windows.
Platforms: build on Windows (with multicore support - Windows 2000 or later), OS X (Leopard or later), Linux (many versions), or BSD (many variants/versions)
  • This list represents the platforms on which we routinely test  new versions. Custom support for older or specific platforms is also available.
Extensive metadata support - extended attributes, alternate data streams
  • Available for all supported platforms/filesystems (extended attributes: Windows, OS X, some *nix; alternate data streams: Windows)
  • In Windows, OS X and *nix, hard and soft links can be handled in a variety of ways at both build and apply time.
Compressed archive support (currently ZIP, APK, JAR - others coming) - compare the files within archives rather than the compressed archives themselves
  • The problem: compressed archives (in fact, compressed files in general) are a real problem for differential file compression because a small change in the underlying uncompressed file can lead to a massive set of changes in the compressed file.
  • Our solution: our patch build engine now has the ability to recognize compressed archives, uncompress them, and build (special) patches on the uncompressed files. Similarly, the patch apply engine has the ability to recognize compressed archives, uncompress them, apply the (special) patches and recompress the files into a compressed archive. Both of these work recursively with nested archives as well.
Other common features available on most platforms
  • 90-99% update size reduction
  • Robust Apply API for custom front-ends to the RTPatch Apply engine
  • Utilize multiple cores during the Build process for faster patch creation and efficient use of available resources
  • Specify amount of RAM used during patch creation, which is especially useful in OEM applications, where your end-users are creating patch files on their computers
  • Customize the Apply interface and messages
  • Create patch files from the command line and automate the Build process
  • Update multiple old versions of a system with a single patch
  • Set options on a per-file basis
  • Smart file location
  • Support files whose names have changed
  • Password protect the patch file
  • Backup the old system of files
  • Ensure that no system is ever partially updated (patch rollback functionality)
  • Run an external command or executable before, during, or after the patch process, and, optionally, abort the patch process depending on the return code of the external command
  • Adjust the amount of user interaction required (if any)
  • Ignore missing files when applying the patch
  • Log errors at apply time
  • Add new files, or overwrite existing files