Imagine a modern PC game for example. I'm using this example because typically the executable file is fairly large, and especially in modern games the resource files are also pretty big.

Patching a resource file is fairly simple because depending on the file format it could just be a case of replacing one contiguously stored resource with another. But what about if you wanted to change one line of code in a bulky executable?

When the code is compiled, it's optimised and rearranged to allow for structures not present in lower level languages, and so generally the resulting code file is very rarely a line-by-line translation of the high level code. So with this in mind if you wanted to change one particular line to fix a bug, would the update then contain a new version of the entire executable, or can it work like some sort of difference-spotting technique like a source control system?

  • 3
    It's possible to delta-compress executables. Chrome's update uses pretty fancy delta compression optimized for executable files. – CodesInChaos Oct 12 '15 at 9:27
  • 1
    Despite having an undergraduate degree in computer games technology, I had never even heard of delta compression :/ – leylandski Oct 12 '15 at 9:35
  • There are mechanisms to apply a security check to a binary. .NET for example allows you to sign your binaries with a key, in order to make sure binaries are not tempered with. There are also third party tools to do this at a more advanced level. I guess that would break a mechanism where you would only update the file? – Jonathan van de Veen Oct 12 '15 at 9:49
  • 1
    1) Note that even when you use delta compression, you generally create a temporary file for the new version and only move it in place in the end. While this needs some temporary disk space, it simplifies the algorithms and doesn't corrupt the original file if something goes wrong. 2) You might be interested in this article about Chrome's auto-update: Software Updates: Courgette – CodesInChaos Oct 12 '15 at 9:53

Yes and no, both mechanisms work.

The easiest way to patch a product is by replacing a component (eg a dll) with a new version of it. This usually requires the program to be stopped, so it's useful for a game or other program that is run occasionally but not so good for OS components.

So various techniques have been developed to directly patch a running executable (or dll). Microsoft does this by creating all dlls with a space before each function so it can be overwritten by a "jump to a new location" patch, the new function can be shipped and the location changed so all running programs will start to use the new code once patched. (Technical details here) This occurs at runtime, so stopping the patched program will require the patch to be re-applied (this either occurs automatically or the component is upgraded once the program is stopped - i.e. on a reboot, the new dll replaces the old one so the runtime patching is no longer required).


When the executable is changed, it's often easier to replace the entire executable, rather than modify it. This makes it possible to patch the executable no matter which version it's at (unlike binary difference patchers). The vast majority of modern games do it like this.

In modern games, the size of the executable pales in comparison to the resource files, so there is little to gain by modifying the executable.


When you modify an executable, you must always anticipate failure. User stumbles over the power cable, that kind of thing. If you modify the existing file, you now have a broken file. Applications usually consist of multiple files. Even if you replace files cleanly, you might end up with a folder with mismatching pieces.

The safe way is to create a folder with the new version of the application, exchanging both directories, and deleting the new one. Worst case if things go wrong you end up with an incomplete directory that can be removed.

Not the answer you're looking for? Browse other questions tagged or ask your own question.