On Aug 13, 2012, at 12:04 AM, Russel Winder <[email protected]> wrote:
> On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote: > […] >> OSX has a lot less backwards compatibility to worry about. > > Not entirely true. > > <semi-rant> > Apple's strategy appears to be that computers are non-upgradable, > non-repairable, disposable items that last until the next release: > everyone is supposed buy the latest version as soon as it comes out and > so be on the latest kit(*). Therefore Apple don't care about backward > compatibility in the way some other manufacturers do, e.g. JDK for the > last 17 years. Of course sometimes this backfires, cf. many white > MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects > this and will not boot 64-bit. This leads to extraordinary problems > trying to compile some codes where the compiler detects 64-bit processor > and assumes a 64-bit kernel API. To build some applications I first have > to build the whole compiler toolchain so as to deal with this mixed > chaos. > > (*) And as we know there are a lot of people who actually do this, which > is why there is a great market in second hand Apple kit, which is fine > for me, since it is reasonable kit at a reasonable price. Unlike new > kit. > </semi-rant> Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler.
