3 ms·

"A company like Microsoft [...] would never deem manually binary editing as acceptable." is complete bullshit speculation. The guy who has analysed the bug repo

"A company like Microsoft [...] would never deem manually binary editing as acceptable." is complete bullshit speculation. The guy who has analysed the bug report must be good at assembly language. Maybe he has developed the binary patch very quickly as a proof of his analyse. When this analyse was hand over to development team, they had two options: spending time to setup the development environment with the correct version of sources and tools (error prone), performs again the development using c++, launching all the non regression tests. The other option is to do nothing and bet this binary will never need again to evolve. This is cheaper and the risks seem smaller. IMHO, this beautiful patch shows that Microsoft is open minded and choose smart options instead of bureaucratic ones. I applaud.

stinos 9y ago
Came here to write the exact same thing. "The only way this happened is if Microsoft somehow lost the source code of a long forgotten Office component." is completely false speculation/generalization. It is not the only way.
- DaiPlusPlus 9y ago
  More than likely it was a project that only builds in a long-discontinued non-conforming C/C++ compiler that only runs on Windows 95. When I was working at MS very recently I was surprised to learn that all software affected by the Sun lawsuit, way back in 2001, was still strictly verboten, even internally. All builds of Windows 95 through XP SP1 were absent from the internal builds and products shares just as they are from MSDN. I don't believe Microsoft would have somehow lost this source code as the article speculates - more likely they reasoned that the effort needed to get a build environment set-up and working would take more time than finding someone on the team who really knows x86 assembly well enough to manually fix the bug - and there are plenty of people like that on campus.
reacweb 9y ago
A comment below says that Microsoft didn't write it (but Design Science). Maybe the C++ patch was rejected because the source code did not follow Microsoft coding rules mandating a complete rewrite of the code. To avoid a huge development cost, one rule has to be violated: either the binary patch or bad code. We can speculate many reasonable scenarios to explain what happened. I do not see any shame on Microsoft.
- eesmith 9y ago
  In your scenario, Microsoft is making a probabilistic statement ("a bet") that there will not be many future changes to the code. That is, the binary patch path is more expensive than code patches, because it requires more specialized skills. At some point, with enough patches, it would have been worthwhile to update the source and rebuild than to modify the binary.
deleted 9y ago
[deleted]

stinos 9y ago

Came here to write the exact same thing. "The only way this happened is if Microsoft somehow lost the source code of a long forgotten Office component." is completely false speculation/generalization. It is not the only way.

DaiPlusPlus 9y ago
More than likely it was a project that only builds in a long-discontinued non-conforming C/C++ compiler that only runs on Windows 95. When I was working at MS very recently I was surprised to learn that all software affected by the Sun lawsuit, way back in 2001, was still strictly verboten, even internally. All builds of Windows 95 through XP SP1 were absent from the internal builds and products shares just as they are from MSDN. I don't believe Microsoft would have somehow lost this source code as the article speculates - more likely they reasoned that the effort needed to get a build environment set-up and working would take more time than finding someone on the team who really knows x86 assembly well enough to manually fix the bug - and there are plenty of people like that on campus.

reacweb 9y ago

A comment below says that Microsoft didn't write it (but Design Science). Maybe the C++ patch was rejected because the source code did not follow Microsoft coding rules mandating a complete rewrite of the code. To avoid a huge development cost, one rule has to be violated: either the binary patch or bad code. We can speculate many reasonable scenarios to explain what happened. I do not see any shame on Microsoft.

eesmith 9y ago
In your scenario, Microsoft is making a probabilistic statement ("a bet") that there will not be many future changes to the code. That is, the binary patch path is more expensive than code patches, because it requires more specialized skills. At some point, with enough patches, it would have been worthwhile to update the source and rebuild than to modify the binary.

deleted 9y ago

[deleted]