home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / misc / 4269 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  1.5 KB
  1. Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  2. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  3. Newsgroups: comp.unix.misc
  4. Subject: Re: Programs to create and apply binary patches?
  5. Message-ID: <1992Nov20.092309.19734@thunder.mcrcim.mcgill.edu>
  6. Date: 20 Nov 92 09:23:09 GMT
  7. References: <1992Nov17.194826.26531@spillman.uucp>
  8. Organization: McGill Research Centre for Intelligent Machines
  9. Lines: 29
  10.  
  11. In article <1992Nov17.194826.26531@spillman.uucp>, tye@spillman.uucp (E. Tye McQueen) writes:
  12.  
  13. > [Follow-ups to comp.unix.misc]
  14.  
  15. That's odd, something's wrong then.  My software ignored your
  16. Followup-To:...I'll have to check it out.
  17.  
  18. > Any great ideas on how to create a "patch" file of differences
  19. > between two versions of a very large *binary* file (executable) so
  20. > the patch file could be distributed (via modem) and applied to the
  21. > many copies of the old version of the file?
  22.  
  23. You could always convert both files to text via something like
  24.  
  25.     while ((c=getchar()) != EOF) printf("%d\n",c);
  26.  
  27. and run a regular diff on those.  Applying the resulting patch should
  28. be a straightforward (though more complex than the above :) program,
  29. and can be done without needing the textified versions of the binary
  30. files.
  31.  
  32. But wouldn't it be better to ship over the patches to the source
  33. instead?  Probably not a whole lot larger, much more useful, and you
  34. need to ship 'em anyway to keep the source and binary in sync.
  35.  
  36.                     der Mouse
  37.  
  38.                 mouse@larry.mcrcim.mcgill.edu
  39.