How can users check if their mac is 64-bit-capable?
-
Is there an official Apple-supplied list of which Macs (PPC and Intel) are capable of running 64-bit applications? I need something to refer customers to so they can verify whether their machine is 64-bit capable or not. Obviously I could supply a tiny app to tell them, but it's a bit pointless and politically incorrect to have to have a download for this.
So even better, is there a convenient GUI-based way for a user to check this? I don't see anything in "About this Mac". Since there are no running 64-bit processes by default, I can't tell them to check Activity Monitor. A standard app that will always start in 64-bit mode so it can be checked from Application Monitor? (These are ordinary users, no Developer Tools or command-line methods).
It's important for this information to be readily available --- it's hard to push 64-bit apps if no one can tell if their machine can really run one or not.
Also: how can a customer easily choose to run the 32-bit version of a 32/64 universal app? This may prove occasionally necessary to accommodate missing QTKit functionality.
Thanks. -
Le 11 déc. 08 à 18:07, Russ a écrit :
>
> Is there an official Apple-supplied list of which Macs (PPC and
> Intel) are capable of running 64-bit applications? I need something
> to refer customers to so they can verify whether their machine is 64-
> bit capable or not. Obviously I could supply a tiny app to tell
> them, but it's a bit pointless and politically incorrect to have to
> have a download for this.
>
> So even better, is there a convenient GUI-based way for a user to
> check this? I don't see anything in "About this Mac". Since there
> are no running 64-bit processes by default, I can't tell them to
> check Activity Monitor. A standard app that will always start in 64-
> bit mode so it can be checked from Application Monitor? (These are
> ordinary users, no Developer Tools or command-line methods).
>
IIRC, Chess.app launch as 64bits app in Leopard on 64 bits compatible
computers.
You can then check in the Activity Monitor to see if this is a 64 bit
process.
> It's important for this information to be readily available --- it's
> hard to push 64-bit apps if no one can tell if their machine can
> really run one or not.
>
> Also: how can a customer easily choose to run the 32-bit version of
> a 32/64 universal app? This may prove occasionally necessary to
> accommodate missing QTKit functionality.
>
> Thanks.
-
On Dec 11, 2008, at 10:07 AM, Russ wrote:
> Is there an official Apple-supplied list of which Macs (PPC and
> Intel) are capable of running 64-bit applications?
No, but I wrote one in a message to this group a while ago. The 64-bit
capable Macintoshes are:
1. All Xserves, except for the very first model
2. All Power Mac G5s
3. All Mac Pros
4. All MacBooks, except for the first edition
5. All MacBook Pros, except for the first edition
6. All MacBook Airs
7. All iMacs, except for the CRT-based models, "iLamps", and the first
two Intel-based models
8. All Mac minis starting with the fifth model (mid-2007)
9. All VMware virtual machines running OS X Server in X86-64 mode
10. All unauthorized Hackintoshes with an X86-64 CPU (Core 2 Duo,
Xeon, Athalon 64, etc.)
Basically, every non-laptop and non-mini released between 2003 and
2005 is 64-bit, and all Macs made since mid-2007 are 64-bit.
> So even better, is there a convenient GUI-based way for a user to
> check this?
Yes; have them get info on /Applications/Chess.app. If a check box
appears saying "open in 32-bit mode", then they are using a 64-bit Mac.
> I don't see anything in "About this Mac".
Well, it does list the CPU type. If the CPU type is Core 2 Duo, Xeon,
or PowerPC G5, then it's 64-bit.
> Since there are no running 64-bit processes by default, I can't tell
> them to check Activity Monitor.
There are four apps that come with Leopard that are 64-bit that I know
of: Chess, Xcode (which, by default, runs as a 32-bit app), Apache,
and MySQL (Server only).
> Also: how can a customer easily choose to run the 32-bit version of
> a 32/64 universal app? This may prove occasionally necessary to
> accommodate missing QTKit functionality.
Get Info on the app in the Finder. From there, it becomes obvious. :)
Nick Zitzmann
<http://www.chronosnet.com/> -
On Dec 11, 2008, at 12:07 PM, Russ wrote:
> So even better, is there a convenient GUI-based way for a user to
> check this? I don't see anything in "About this Mac".
Actually - yes. "About this Mac" *will* tell you. If it says "G5" or
"Core 2", and 10.5.*, it's a 64-bit capable Mac. If it's running any
earlier OS release, a G3 or G4, or first-generation Core, it's 32-bit
only.
sherm-- -
Well not that you mentioned, I was reading about the 64bit changes
that OS X and Cocoa api has, and how to convert my current 32 bit app
to 64 bit app.
In an apple doc I read that mos of leopard app doesn't need to convert
to 64 bit architecture, but later on the document its says something
like, that in the future the apps should take advantage of the new 64
bit api and frameworks, or that what I understood, so, I was
wondering, if Im starting a new app (small one), should I build it for
a 64 bit architecture or no?, if so what should I take care of?,
instead of using int use NSInteger or NSUInteger, alos instead of
float use CGFloat, take care of the way I encode and decode ? I guess
im missing lots, and what else should I change the build target to be
64 bit architecture?
any guidance? or should I just "let it be, let it be"
Gus
On 11.12.2008, at 19:08, Sherm Pendley wrote:
> On Dec 11, 2008, at 12:07 PM, Russ wrote:
>
>> So even better, is there a convenient GUI-based way for a user to
>> check this? I don't see anything in "About this Mac".
>
> Actually - yes. "About this Mac" *will* tell you. If it says "G5" or
> "Core 2", and 10.5.*, it's a 64-bit capable Mac. If it's running any
> earlier OS release, a G3 or G4, or first-generation Core, it's 32-
> bit only.
>
> sherm--
-
On Dec 11, 2008, at 2:16 PM, Gustavo Pizano wrote:
> In an apple doc I read that mos of leopard app doesn't need to
> convert to 64 bit architecture, but later on the document its says
> something like, that in the future the apps should take advantage
> of the new 64 bit api and frameworks, or that what I understood, so,
> I was wondering, if Im starting a new app (small one), should I
> build it for a 64 bit architecture or no?
I wouldn't want to build *exclusively* for 64-bit at this point -
there's still a lot of 1st-generation Core Macs out there, and even
some G4s, as well as some machines running Tiger. So IMHO it seems a
little premature to go 32-bit only.
That said, it's not an all-or-nothing proposal. Universal binaries can
include both 32- and 64-bit binaries. For a smooth transition, you
could start supporting 64-bit right now, without necessarily having to
require it. Eventually, the time will come when it's appropriate to
drop support for 32-bit machines and OS versions.
> , if so what should I take care of?, instead of using int use
> NSInteger or NSUInteger, alos instead of float use CGFloat, take
> care of the way I encode and decode ? I guess im missing lots, and
> what else should I change the build target to be 64 bit architecture?
>
> any guidance?
As usual, Apple's own docs are a good place to start:
<http://developer.apple.com/DOCUMENTATION/Darwin/Conceptual/64bitPorting/int
ro/chapter_1_section_1.html>
> or should I just "let it be, let it be"
Great song. :-)
sherm-- -
On Dec 11, 2008, at 12:16 PM, Gustavo Pizano wrote:
> if Im starting a new app (small one), should I build it for a 64 bit
> architecture or no?, if so what should I take care of?,
It's a mixed bag. We've released one 64-bit app (iClipboard), so I can
speak from some experience here.
The benefit of using 64-bit now is it will greatly increase the
scalability of your app. If your app has the potential to manipulate
and store very large files (hundreds of megabytes or larger), and
streaming is not an option, then your app will greatly benefit from
being 64-bit. It will also make it slightly faster on X86-64 due to
improvements in the CPU architecture (e.g. arguments will no longer be
placed on the stack 99% of the time).
But there are a few drawbacks:
1. The 32-bit frameworks have been around for more than a decade and
are quite stable. The 64-bit frameworks have been around for only a
year and a half, and have had interesting bugs. Some of them have been
fixed in point releases, but every now and then, someone comes here
talking about something odd happening in their 64-bit app that doesn't
happen in their 32-bit app.
2. Because there are very, very few shipping 64-bit apps for Mac OS X
right now, some users who watch Activity Monitor like a hawk see that
the app uses 1.7 GB of VRAM on launch (33-34 GB if GC is on) and freak
out, thinking there's a big memory leak and the app is wasting their
hard disk space. This is because some people don't understand that VM !
= swap, but they used to be the same thing in Mac OS 7-9, so it's
confusing. Anyway, there does seem to be public reluctance to adopt 64-
bit apps.
3. It's been more than a year since Leopard has been released, and
there still are a lot of frameworks out there that are closed-source
and 32-bit only.
4. Not everything is available to 64-bit frameworks, but the majority
of that stuff is stuff that is deprecated and shouldn't be used
anymore (ATSUI, QuickDraw, FSSpec, HIToolbox, etc.). Still, this makes
porting old code rather painful. Microsoft and Adobe in particular got
screwed over the removal of HIToolbox.
Issues #1 and #2 will go away in the coming months, but they're
something to keep in mind.
And I wouldn't build for 64-bit exclusively, unless you are developing
an in-house app only, or you are doing something that absolutely
cannot be done in a 32-bit space. There are still many first edition
MacBook users out there who would not appreciate you doing that.
> instead of using int use NSInteger or NSUInteger, alos instead of
> float use CGFloat, take care of the way I encode and decode ? I
> guess im missing lots, and what else should I change the build
> target to be 64 bit architecture?
Yes. Even if you're not going to go 64-bit now, I would strongly
recommend you at least get your code ready for it, because there will
be a day when the i386 architecture gets deprecated. That means
switching ints to NSIntegers, getting rid of FSSpec, etc.
Nick Zitzmann
<http://www.chronosnet.com/> -
On Dec 11, 2008, at 1:15 PM, Nick Zitzmann wrote:
> But there are a few drawbacks:
I missed a spot:
5. Good luck trying to debug 64-bit apps. As of Xcode 3.1.2, the
debugger often fails to respond to commands correctly when a 64-bit
app is loaded, Shark doesn't work correctly with them, and MallocDebug
doesn't work with them at all (though Instruments works fine).
Nick Zitzmann
<http://www.chronosnet.com/> -
> Yes. Even if you're not going to go 64-bit now, I would strongly
> recommend you at least get your code ready for it, because there will
> be a day when the i386 architecture gets deprecated. That means
> switching ints to NSIntegers, getting rid of FSSpec, etc.
Minor point to be aware of when you go to 64 bit.
Apple uses LP64 - meaning that long and pointers are 64 bit, but int's
are 32 bit (see http://en.wikipedia.org/wiki/LP64).
A potential source of confusing is that NSInteger in 64 bit is not an
int, but a long. This means that NSInteger is 64 bit on 64 bit systems.
A general switch from int to NSInteger is therefore probably not
appropriate, but a switch to NSInteger is needed when you want to
store the result of any API that returns an NSInteger.
Jesper Storm Bache -
On Dec 11, 2008, at 2:50 PM, Jesper Storm Bache wrote:
> A potential source of confusing is that NSInteger in 64 bit is not
> an int, but a long. This means that NSInteger is 64 bit on 64 bit
> systems.
> A general switch from int to NSInteger is therefore probably not
> appropriate, but a switch to NSInteger is needed when you want to
> store the result of any API that returns an NSInteger.
You're correct when it comes to handling formats of fixed size, but if
you need a primitive's size to be the same no matter what, then you
should probably be using int8_t, int32_t, int64_t, etc. instead of
either int or NSInteger...
Nick Zitzmann
<http://www.chronosnet.com/> -
On Thu, Dec 11, 2008 at 1:50 PM, Jesper Storm Bache <jsbache...> wrote:
>> Yes. Even if you're not going to go 64-bit now, I would strongly
>> recommend you at least get your code ready for it, because there will
>> be a day when the i386 architecture gets deprecated. That means
>> switching ints to NSIntegers, getting rid of FSSpec, etc.
>
> Minor point to be aware of when you go to 64 bit.
> Apple uses LP64 - meaning that long and pointers are 64 bit, but int's are
> 32 bit (see http://en.wikipedia.org/wiki/LP64).
>
> A potential source of confusing is that NSInteger in 64 bit is not an int,
> but a long. This means that NSInteger is 64 bit on 64 bit systems.
> A general switch from int to NSInteger is therefore probably not
> appropriate,
For function/method parameters and return types, an unconditional
switch to NSInteger/NSUInteger is fine (the registers are all 64-bit,
so you lose nothing by doing so; a 32-bit type would still take up the
entire 64-bit register)
> but a switch to NSInteger is needed when you want to store the
> result of any API that returns an NSInteger.
Indeed. For structures and arrays especially, you should consider
carefully whether or not you *need* a 64-bit type, as the doubling in
size can become significant there.
--
Clark S. Cox III
<clarkcox3...>
