[email protected] writes: >Message: 14 >Subject: Re: Determining whether Mac platform is Intel or PPC? >From: Tom <[EMAIL PROTECTED]> >Date: Wed, 20 Sep 2006 14:40:54 +0200 > >Perhaps I'm late here but why not simple use the following command via >shell class: >> /usr/sbin/system_profiler SPHardwareDataType|grep "CPU Type" >> CPU Type: PowerPC G5 (2.2) > >Not sure what's the reply on an Intel Mac but I don't think it is G5... > >Cheers,
I think it is. I haven't tried this particular thing, but it's a one case of a general class of solutions, which rely on the (apparent fact) that when RB is running under Rosetta, if it shells out to a Unix tool that tool is apparently run native. Therefore, /usr/sbin/system_profiler and /usr/sbin/setctl and probably other programs report the "real" system characteristics. If I end up going this route, I'll probably shell out to "sysctl hw.machine" which seems to report either "i386" or "Power Macintosh" (i.e. general architecture rather than specific processor)... though I can't find THAT documented either. The issue I have with this sort of approach is that these utilities are intended to be human-readable, not machine-readable... and there isn't any documentation that enumerates the set of processor-related strings that can possibly be returned. You say, you're "not sure what's the reply on an Intel Mac." Right... because I don't think there's any documentation for System Profiler that says what it would be. (It happens to be "Intel Core Duo" on my iMac). Sure, you can guess that if the string contains the substring "86" or "Intel" it's probably Intel and if it contains the substrings "power" or "ppc" or "G5" or "G4" it's probably Power Mac. But my feeling is that I don't want to rely on inspection of what system utilities seem to do; that's a kludge. (Do I need look for "Athlon" or "AMD" as substrings, too?) The issue I have with the method described in >http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/ >universal_binary_exec_a/chapter_7_section_7.html is that it relies on calling sysctlbyname with "sysctl.proc_native" as an argument, and for the life of me I can't find any documentation on any sysctl "proc_native" string or value. proc_native seems to be some special magic internal call that does _not_ fall prey to Rosetta's faithful-Penelope simulation of a PPC environment. It happens that it returns 0 when executed within Rosetta, 1 when executed native on an Intel Mac, and fails with an error when executed on Mac OS X 10.4.7 on a Power Mac. The sample code implies that if it fails, you are guaranteed to be running in a true Power Mac environment, but, well, gosh, the sample code happens to have bugs... and it doesn't reference any description of "sysctl.proc_native." (Yesyesyes I know that the next release of RB will solve the problem). _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
