OSX and 64-bit [Re: First working Win64 program!]

Sean Kelly sean at invisibleduck.org
Mon Aug 13 12:41:57 PDT 2012


On Aug 13, 2012, at 12:04 AM, Russel Winder <russel at winder.org.uk> 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. 


More information about the Digitalmars-d-announce mailing list