Quite. Why hack the binaries when you can have binfmt_elf.c detect affected binaries at runtime and slam in a binary patch? Plus, that works everywhere (FSVO 'everywhere' equal to 'on the machine it was tested on') and makes debugging when you don't know the feature is there so much more exciting!
(I wish I was joking, but Windows does exactly this routinely.)
Posted May 29, 2012 19:21 UTC (Tue) by BenHutchings (subscriber, #37955)
[Link]
So far as I know Windows doesn't patch third-party code in memory, but it does enable compatibility quirks on a per-process basis based on recognition of certain programs. In some cases that approach may be superior to maintaining the old behaviour for all programs - the usual reason for wanting to change the implementation is to improve performance, and Windows can provide that improvement for most programs.
Linux does have per-process compatibility quirks (see setarch(8)) but no provision for enabling them automatically. I'm not sure why, though it may be that such recognition would be better implemented in userland.