macOS The joys ahead...

[Palad1]

Have a look at the universal binary dev pdf, it's highly instructive for what's ahead of us...

Three things that will come and haunt us for the years to come:

• Endianness => big endian vs little endian, watch out when serializing data...
• Division by zero: => 0 on a ppc, divide by zero error
• Objective-C message sent to nil behavioral change on x86 arch

Too bad, big endianness had its charms (especially when reading memory dumps)...
And rosetta only works with G3 applications... do'h!

Well, that'll be... interesting

 

[robbieduncan]

For 99% of (Cocoa) apps out there none of these things matter! If you have been saving your data using NSArchivers it's not a problem endianness is not an issue. You should not have been deviding by zero anyway! Sending messages to nil objects is not good practice either (although I will have to check that I am not doing this).

With regards to Rosetta it will run most code fine. Only code that depends on G4 or G5 specific features (or uses Altivec) will not run.

Personally I think that this is a fine and brave move. As long as we don't get anything with a Netburst architecture (PIV) then we are fine.

 

[Nutter]

I thought sending messages to null objects was perfectly ok?

What's going to change?

 

[robbieduncan]

I thought sending messages to null objects was perfectly ok?

What's going to change?

The return values for floats and doubles is sort of undefined, whereas on PPC it was 0.0 for floats (floats on intel will return the contents of the float register). Messages that return objects (or ints) are fine.

See page 46 of the PDF.

 

[robbieduncan]

Well that was easy. First app recompiled as a Universal Binary. The big difficulty was that the 10.4 Universal SDK did not install as standard. Steve was correct. With that installed it was a simple as telling XCode to generate i386 code and compiling.

Now where can I get an Intel box to play with?

 

[Nutter]

Ok. Boolean return values would still be 0, then?

I quite often use object pointers that could be nil, but I don't think I would ever use the return value in such a case. Perhaps as part of a logical expession, but I doubt this would have a floating point return!

Why would it take longer to modify a carbon project for universal binary compilation? Is it just because the cocoa APIs are more abstracted?

Thanks.

 

[robbieduncan]

Ok. Boolean return values would still be 0, then?

I quite often use object pointers that could be nil, but I don't think I would ever use the return value in such a case. Perhaps as part of a logical expession, but I doubt this would have a floating point return!

Why would it take longer to modify a carbon project for universal binary compilation? Is it just because the cocoa APIs are more abstracted?

Thanks.

I think booleans would still be 0. Without an Intel machine to play with I can't test for you.

Cocoa is easier to port as, at it's heart, it's almost all NeXTStep which was available on multiple CPUs before Apple bought NeXT. Carbon apps are much more likely to be effected by endian issues and are more likely to call lower level CPU specific functions (and make assumptions about bit orders and the like). I suppose that, yes, it all comes down to level (and quality) of abstractions.

 

[Applespider]

Well that was easy. First app recompiled as a Universal Binary.

Now where can I get an Intel box to play with?

Congrats.... did you beat the 2-hour Mathematica record?

 

[robbieduncan]

Congrats.... did you beat the 2-hour Mathematica record?

Yes, but Car-100 Control really is tiny! It only takes a minute or two to compile from scratch. Still, for pure Cocoa apps it really is as simple as tick a couple of boxes and compile.