Comment by dtech
9 years ago
That is both pretty impressive and horrific.
I wonder if they patched this way because they wanted to maintain as much binary compatibility as possible, or if they don't have the original source/couldn't reproduce the build process.
Horrific? This is what you do when you want to make sure you don't introduce any unintentional changes. Computers aren't magic, and there is nothing wrong about patching a binary.
Compiling the software with a modern compiler or linking to a modern runtime is very likely to bring obscure bugs in the codebase to the surface. It's pretty hard to replicate the entire build process that produced the original binary, even if they have the source code and everything else on hand.
> Horrific? This is what you do when you want to make sure you don't introduce any unintentional changes.
Horrific, because the average programmer would consider patching the binary a worst-case scenario.
> there is nothing wrong about patching a binary
I would only trust a skilled assembly programmer to do this task without creating other problems, and most businesses don't have those on retainer.
> Horrific, because the average programmer would consider patching the binary a worst-case scenario.
That says more about the average programmer than it does about the reasonableness of binary patches.
I used to table in MASM on the 8088 and have dabbled a little on microcontrollers (6800) as well. But the last time I looked at modern x86, I was pretty lost.
1 reply →
...and sometimes, compiling and linking takes even longer than just opening the binary with a hex editor and changing the right bytes. I've done this a few times with things like string constants that were slightly off, although after testing the binary, I change the source too.
>> It's pretty hard to replicate the entire build process that produced the original binary, even if they have the source code and everything else on hand.
I seem to recall Microsoft rebuilds everything from source daily (or weekly?). This is a common practice in companies with a large code base. "Nightly Builds" even come from Mozilla. The reason is simple - if you wait until it's time to release, you're gonna have problems. Even if a developer tests his changes locally, they need to be integrated in with everything else and retested.
If you're really serious about things you will have your tool chain under revision control. As a result you can reproduce binaries to the byte from source code, with the possible exception of embedded dates pulled in at compile time. This is actually a good fallback when someone finds a critical problem in old code - you start by finding the code and then verify by reproducing the affected binary from source. This is not technically hard, it requires discipline and best practices.
Patching the binary manually means that now the source code and the binary are out of sync, and the changes will be lost if it is ever compiled from the source code again.
Its funny how very few people do fully self contained and reproducible builds. At least nixos tries hard.
Your QA process, including automates tests should ensure there were no unacceptable changes introduced. Otherwise you ability to create and ship fixes in timely manner will be severely harmed by the fear of breaking things.
how many decades of software is your QA process, with its automated tests, covering?
1 reply →
Building a new binary means running a full QA against it, which is probably not cost-effective for such an old component. In contrast, this patch has exactly known impact. I know it seems like magic to you lot, but it's a day's work if you've the right skills.
They probably don't have the Office 97 or 2000 build pipeline around anymore. And back then for Office XP or 2003 copied the equation editor in binary form to the new repository.