Re: Getting a StringPtr from Gestalt on 64-bit
Re: Getting a StringPtr from Gestalt on 64-bit
- Subject: Re: Getting a StringPtr from Gestalt on 64-bit
- From: Clark Cox <email@hidden>
- Date: Thu, 3 Sep 2009 12:14:15 -0700
On Thu, Sep 3, 2009 at 10:56 AM, Scott Lahteine<email@hidden> wrote:
>> On Sep 2, 2009, at 9:02 PM, Scott Lahteine wrote:
>>>
>>> My preference pane uses Gestalt(gestaltUserVisibleMachineName,
>>> &mySInt32), coercing the SInt32 into a StringPtr to get the Machine
>>> Name. On 64-bit I get a warning because StringPtr is a 64-bit
>>> pointer on that architecture. Does Gestalt() ensure that the
>>> returned pointer is in the low 4 gigs of RAM, or is there a more
>>> appropriate way to get the Machine Name that is 64-bit compatible?
>>
>> On Sep 2, 2009, at 11:13 PM Jim Correia wrote:
>> extern CFStringRef CSCopyMachineName(void)
>> AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;
>> - Jim
>>
>> On Sep 2, 2009, at 11:43 PM, Kyle Sluder wrote:
>> NSHost now does this.
>> --Kyle Sluder
>
>
> Your answers were too quick, Jim and Kyle!
>
> CSCopyMachineName() returns the name of the computer as set by the user in
> the Sharing preference pane, which is not the same thing as the
> gestaltUserVisibleMachineName. The "Machine Name" I want is the
> Apple-defined identifier for the type of computer, which (as of this date)
> begins with one of the following strings:
>
> "AAPL","iMac","PowerBook","PowerMac","RackMac","Macmini","MacPro","MacBookPro","MacBook"
>
> For example, my computer is identified by Gestalt() as a "MacBook2,1"
If you *really* need this information, you can get it from
sysctlbyname(), but I would think long and hard about what you need it
for. If you are basing any decisions on this value you're setting
yourself up for problems with newly released machines (or even old
machines with user-installed upgrades).
> At this point, as far as I can tell Gestalt() is still a viable solution,
> and the returned pointer is just guaranteed to be in the low 4GB of RAM.
Not possible. On 64-bit Intel (at least with the default settings),
there is no such thing as a valid pointer in the low 4GB of RAM. *All*
valid pointers are outside of that first 4GB; in fact, trying to
dereference such a pointer is treated in exactly the same manner as
trying to dereference NULL.
--
Clark S. Cox III
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden