<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jun 10, 2005, at Fri, Jun 10, 8:25 24 PM, David Steuber wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Lucida Grande" size="3" style="font: 12.0px Lucida Grande">Now you are talking about endian issues?<SPAN class="Apple-converted-space"> </SPAN></FONT></P></BLOCKQUOTE><BR></DIV><DIV>If you read Apple's doc on Universal Binaries at:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><<A href="http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf">http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf</A>></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>you'll see that endian issues are one of the largest that Carbon developers will encounter. There is a whole chapter in a 5 chapter PDF entitled "Swapping Bytes" so yes, it is a significant porting issue.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Perhaps you've had vastly more programming experience than I have in C and it's children than I have. In my experience, endian issues are irrelevant accept when exchanging data between two architectures with different byte ordering schemes.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>That's what this transition means - exchanging data (saved documents, custom resources, etc.) between two architectures (ppc, intel) with different byte ordering schemes (ppc=big-endian, intel=little-endian).<BR><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If a Mac developer's ppc app writes certain multi-byte struct fields out to disk in byte-address order and reads them back in on an intel Mac using his own app simply recompiled for intel these multi-byte data will be read back in reversed. If this same application simply recompiled for intel writes this same multi-byte data out to disk in byte-address order, it will be read back in reversed using the same app running on a ppc Mac.</DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> That is why network byte ordering is a standard, so that it doesn't matter if you are big or little endian.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The real problem is that many developers have implicitly assumed that byte-address ordering would always be big-endian. This has worked for them until now because their apps were always compiled for and run on ppc. Now some versions of their apps will be compiled for and run on intel, so byte-address ordering is no longer guaranteed to be big-endian for all versions of their apps.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">In spite of that, the programmer from Wolfram didn't seem to have too much trouble porting Mathematica which is not written all in Objective-C, if there is any there at all.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Mathematica is a multi-platform app so they've been doing the right thing all along - they've had to deal with endian issues for years. The endian issues will tend to "bite" <groan> Mac-only Carbon developers who have never dealt with using a little-endian system to read their big-endian data.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>These issues will also affect all Carbon developers - even those whose applications are cross platform - if their applications write and read mac specific data such as old style Mac OS Classic resources. If a developer defined custom resource types, these will not be automatically byte-swapped by the OS. These developers will have to write byte swapping callbacks known as "flippers." The problem of course is that they will now be reading mac specific big-endian data - custom resources - on a little endian intel system running Mac OS X.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>These issues are largely taken care of for Cocoa developers because the Cocoa frameworks have dealt with different architectures since before Apple bought Next. As long as a Cocoa developer uses Cocoa framework calls to write data and read it back in it will be read back in properly regardless of what cpu architecture the app is compiled for and running on.</DIV><DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>One byte ordering issue that affects both Cocoa and Carbon is custom Apple Event data types.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>regards,</DIV><DIV>Ralph<BR><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV> <DIV>Raffael Cavallaro, Ph.D.</DIV> <DIV><A href="mailto:raffaelcavallaro@mac.com">raffaelcavallaro@mac.com</A></DIV> </DIV><BR></DIV></DIV></DIV></BODY></HTML>