[CocoaApp isThisTiger]

[Alastair Houghton]

On 23 Oct 2007, at 03:00, Rosyna wrote:

> And the documentation on Tiger for reading that file is wrong. Very  
> wrong. And you can see how wrong it is by every application that  
> broke horribly in 10.4.10 because they didn't use Gestalt() like  
> you're supposed to.
>
> Use Gestalt() and be done with it. It is the correct and most  
> robust way to get the system version.

Though whichever way you do it, it's possible to screw up if you get  
your comparisons wrong.  It slightly easier to mess up if you're  
trying to scan a version string from a file, of course, but that  
doesn't mean you can't do it properly.  I do note though that one of  
Apple's guys said that reading that file was wrong and that we should  
use Gestalt.

On 22 Oct 2007, at 19:26, Finlay Dobbie wrote:

> You can use NSAppKitVersionNumber, but "hard core no Carbon Cocoa
> developers" need to grow up and stop being babies.

Speaking as someone who would rather avoid Carbon where possible  
(which is not quite the same thing, I must emphasise), I find that  
the You-Should-Use-Carbon-Because-Its-Better camp are much more  
vociferous than the Hard-Core-No-Carbon camp (which is not surprising  
because I'm not actually convinced that the latter exists).  And  
given that the "debate" is between people who do exist and people who  
do not, it's frankly rather boring and not a little preachy.

Any sensible/pragmatic developer---and I think that's most of us--- 
will use a Carbon API *if* they know about it and if it makes their  
life easier or provides a better user experience.  Developers who  
have a background in Mac OS development prior to OS X may be more  
inclined to use Carbon APIs where they exist; developers with other  
backgrounds (UNIX, for instance) may be less inclined to use them.   
And people writing cross-platform code may want to avoid them  
completely (just as they may wish to avoid Win32 APIs on Windows  
wherever possible).  All for valid reasons.

As for the specific case of wanting to enable/disable things on a per- 
system basis, it's much better to check for features rather than  
versions.  That way you won't annoy users if (for instance) Apple  
back-ports something from 10.5 to 10.4.11, and you don't have any  
opportunity to stuff up when doing version number checks.  Yes, there  
is a small risk that something not written by you or Apple might add  
its own methods/classes/functions with the same names, but if they're  
doing that, then their code will break on the new system anyway  
(unless the methods/classes happen to be equivalent, in which case  
who cares anyway?)

Kind regards,

Alastair.

--
http://alastairs-place.net