It basically looks at the machine code of the new and the old executable. Adjusts/aligns the matching parts and then does a diff.(Not 100% correct, but you get the idea)

Simple but really genius .. just like their page rank algorithm... I am still pissed that I didn't come up with something that obvious .. damn .. I could really use all that money.(I would spent most of it on cars, women and drugs. The rest I would squander.)

It basically looks at the machine code of the new and the old executable. Adjusts/aligns the matching parts and then does a diff.(Not 100% correct, but you get the idea)
Simple but really genius .. just like their page rank algorithm... I am still pissed that I didn't come up with something that obvious .. damn .. I could really use all that money.(I would spent most of it on cars, women and drugs. The rest I would squander.)

If it was fast enough, this might be a useful approach to building self-extracting compressed executables for languages that produce large, monolithic, statically linked executables (Delphi comes to mind as a prime example of this)... Probably not worth the trouble for Delphi since it isn't very heavily used anymore, but it might be applicable for the output of some other languages.

It may not be exact same technology but firefox has incremental updates. They are called "mar" files.

I maybe didn't do a good job, but a regular diff has absolutly no understanding what machine code is and how to align machine code. I just left out stuff laymen wouldn't understand and I said it wasn't 100% correct.

So stop telling me what I said, I know.

Read the article again. Rsync does nothing even remotely like this.

How do we use this to generate a better diff? With bsdiff we would compute the new file, 'update' from the 'original' like this:

server:
diff = bsdiff(original, update)
transmit diff

client:
receive diff
update = bspatch(original, diff)

(The server would pre-compute diff so that it could be transmitted immediately)

Courgette transforms the program into the primitive assembly language and does the diffing at the assembly level:

server:
asm_old = disassemble(original)
asm_new = disassemble(update)
asm_new_adjusted = adjust(asm_new, asm_old)
asm_diff = bsdiff(asm_old, asm_new_adjusted)
transmit asm_diff

client:
receive asm_diff
asm_old = disassemble(original)
asm_new_adjusted = bspatch(asm_old, asm_diff)
update = assemble(asm_new_adjusted)

From what I understand, this isn't particularly new - Linux and Windows have delta updates which are binary diffs; I remember Microsoft before Microsoft developed a technology to reduce the size of updates; where a 1MB update might have a 500K file which is only around 30K difference between the old and new file.

The Delta Compression API offers special handling for certain types of executable files (PE files, such as EXE or DLL files.) In particular, executables designed to run on the 32-bit Intel i386 family get special treatment. When the basis and target files are similar executables, this feature can reduce the size of the delta significantlyâ€"typically 50-70% further.

To get the maximum benefit from this feature, symbol files from the LINK process can be supplied during delta creation. This will help the creation process recognize the nature of the changes between the files. Richer symbol info, such as private symbols, will help make smaller deltas. Figure 3 illustrates this process.

Figure 3. Delta compression using symbol files

None of the symbol data is passed in the delta, and the symbol files are not needed during the delta apply process.

See Optional Data for Delta Create for more information on how symbols can be provided.

http://msdn.microsoft.com/en-us/library/ms811406.aspx