• 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: Determining how the app is run (intel/ppc/rosetta/os version)?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Determining how the app is run (intel/ppc/rosetta/os version)?


  • Subject: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • From: Greg Hurrell <email@hidden>
  • Date: Sun, 21 May 2006 14:12:38 +0200

El 21/05/2006, a las 11:51, Gerben Wierda escribió:

On 21 maj 2006, at 10.38, Gerben Wierda wrote:

I would like to determine very specificly how my app is being run. E.g.
- On 10.4.4 on intel using rosetta
- On 10.4.6 ppc
- On 10.3.9 ppc

There was a lengthy thread about this only a few days ago:

http://lists.apple.com/archives/Cocoa-dev/2006/May/msg01141.html

Because my app ran fine as UB in 10.4.3 on a DTK even though there was an unexplained problem. This problem I could not solve (deep inside Apple's Frameworks somehow an NSData object was produced with a negative length, to put it shortly) but luckily it only gave a warning in console.app when the NSData was changed in an NSString (this was subprocess output data) and the NSString (nil) was used in an NSView. That way, my app ran for years.

With 10.4.4 this produced an exception and I had therefore revert to a ppc-only app that is compiled against 10.3.9 and that thus again only gave the warning.

No chance of catching the exception with @try/@catch/@finally or NS_DURING/NS_HANDLER?


With 10.4.6, my app has become one of a set that triggers the partial freeze (like MatLab), see http://www.macfixit.com.

In my own code that processes the output from AutorizationExecuteWithPrivileges() I've avoided the use of NSData and other high-level stuff entirely, depending on low-level funcitons like getc(), ferror() and feof() and finally I use CoreFoundation to pack it all into an NSString:


NSString* bufferLine = [(NSString *)CFStringCreateWithCString(NULL, inBuffer, kCFStringEncodingMacRoman) autorelease];

You may also need CFStringGetSystemEncoding() and GetApplicationTextEncoding() but kCFStringEncodingMacRoman has always worked for me with the output from commandline tools (I guess kCFStringEncodingUTF8 is another good candidate). Is there anyway you could avoid the freezes by taking an alternative route?

So, I now have to put out an app that does not run on 10.4.4 and up on intel. And if I fix it such that it works via rosetta, I would like to be able to let it run as a rosetta app but not native. I want this check in my code so that it does not depend on my compile.

Good luck with your problem. I've benefited from your i-Installer many times!


Cheers,
Greg

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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

  • Follow-Ups:
    • Re: Determining how the app is run (intel/ppc/rosetta/os version)?
      • From: Gerben Wierda <email@hidden>
References: 
 >Re: Determining how the app is run (intel/ppc/rosetta/os version)? (From: Gerben Wierda <email@hidden>)

  • Prev by Date: Re: textDidChange not firing
  • Next by Date: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Previous by thread: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Next by thread: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
  • Index(es):
    • Date
    • Thread