On 2011-09-07 22:22:25 +0000, Walter Bright <newshou...@digitalmars.com> said:
On 9/7/2011 5:21 AM, Michel Fortin wrote:
On 2011-09-06 18:00:36 +0000, Walter Bright <newshou...@digitalmars.com> said:
The winner with binary compatibility is, far and away, Microsoft.
Indeed, I think you're right that they are better than Apple. But you have to
keep in mind that DMD doesn't depend on Microsoft's linker, and doesn't depend
on Microsoft's C runtime. I bet you'd see more breakages otherwise.
I used to know people who worked in Microsoft's "app compat"
department. The lengths they would go to to maintain support for older
apps was amazing. It wasn't about just supporting documented behavior,
it was supporting undocumented behavior and gross misuse of the APIs.
Well, sometime Apple does support undocumented behaviour of previous
version of their OS too. Take this prototype from time.h for instance:
clock_t clock(void) __DARWIN_ALIAS(clock);
What this __DARWIN_ALIAS macro does is it forces the code to use
"_clock$UNIX2003" as the symbol name for the clock() function instead
of the standard "_clock" symbol name. That's because the older version
of the function had some bug in it (it was not conformant to some UNIX
standard) but they still wanted old binaries to continue using the old
version (so they don't break). Code compiled with the newer header will
link with the fixed "_clock$UNIX2003" function instead of the old buggy
one.
But more generally, there's sometime a long term cost in supporting
undocumented behaviour. If you let developers use undocumented things
without consequence, you send the message that they can depend on them
and they'll just depend on them more, and the more software that
depends on undocumented behaviours the harder it becomes to tweak the
API without breaking everything.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
