• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Endian-ness of "PkgInfo" file
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Endian-ness of "PkgInfo" file


  • Subject: Re: Endian-ness of "PkgInfo" file
  • From: Damien Bobillot <email@hidden>
  • Date: Sun, 15 Jan 2006 22:37:39 +0100


Dirk Stegemann wrote :

Am 13.01.2006 um 23:25 schrieb Douglas Davidson:
The PkgInfo file is independent of processor architecture--for example, a single bundle structure may be used for universal binaries capable of running on either architecture.

Still, I encountered an endian-ness issue, although it seems to be more an AppleEventManager problem than a PkgInfo file problem.
Anyway, the problem *can* be fixed with swapping the PkgInfo file's Creator value, therefore I'll add my observations to this subject:


We have an Faceless Background Application with a registered Creator (TJBR), so the PkgInfo file reads APPLTJBR.
Since a long time, we successfully communicate to this application by sending AppleEvents which were created using the AECreateDesc() API, something like this:


-----snip-----

#define kFBASignature     "TJBR"

AEAddressDesc     gFBAAddress;

OSErr myErr = AECreateDesc (
          typeApplSignature,
          (Ptr)&kFBASignature,
          sizeof(long),
          &gFBAAddress);

-----snip-----

On the Developer Transition System, the FBA doesn't recognise the events until we either change its PkgInfo file to APPLRBJT, or change the kFBASignature macro to "RBJT".

Be careful, you're not using a real four-char-code value, but a C string with four characters. It's a bit different : on both ppc and i386 architectures as C string is an array of 8bits characters, so the byte order is always the same T then J then B then R. A apple's four-char-code are 32bits integers, and the same integer is coded with a different endianness on ppc and i386, so you get different representations.


In this case, you give "TJBR", equivalent to 'TJBR' on a ppc machine. The AE libraries except this, so it works. I remember (but it will be better to check the doc) that on a intel mac, the AE functions do the byte swapping for you. You give "TJBR", equivalent to 'RBJT' : you've done the byte swapping, but the AE library will swap it again...

So, try :
	#define kFBASignature     'TJBR'
or, if the compiler don't like &'TJBR' :
	const uint34_t kFBASignature = 'TJBR';

--
Damien Bobillot

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Endian-ness of "PkgInfo" file (From: Kirk Kerekes <email@hidden>)
 >Re: Endian-ness of "PkgInfo" file (From: Douglas Davidson <email@hidden>)
 >Re: Endian-ness of "PkgInfo" file (From: Dirk Stegemann <email@hidden>)

  • Prev by Date: Button with a "mouseover" alternate image?
  • Next by Date: awakeFromFetch : when it is called ?
  • Previous by thread: Re: Endian-ness of "PkgInfo" file
  • Next by thread: Endian-ness of four-char constants (Was: Endian-ness of "PkgInfo" file)
  • Index(es):
    • Date
    • Thread