[CocoaApp isThisTiger]

  • I'd like to disable some UI if my Cocoa application is running under
    Tiger (as opposed to Leopard). Gestalt would work perfectly well, but
    I wonder what the hard core "no Carbon" Cocoa developers prefer to
    determine this. Or if AppKit version is preferred.

    David Dunham    A Sharp, LLC
    Voice/Fax: 206 783 7404    http://a-sharp.com
    Efficiency is intelligent laziness.
  • On 10/21/07, David Dunham <dunham...> wrote:
    > I'd like to disable some UI if my Cocoa application is running under
    > Tiger (as opposed to Leopard). Gestalt would work perfectly well, but
    > I wonder what the hard core "no Carbon" Cocoa developers prefer to
    > determine this. Or if AppKit version is preferred.

    Check for the existance/lack of a feature that you need at runtime.
    Avoid testing for OS version if possible.

    Need to know more about why you want to disable an aspect of UI on
    Tiger to give specifics...

    -Shawn
  • Hi,

    I'm usign the AppKit Version to get the system version (code was
    written for Tiger):

    LSESystemVersion LSECurrentSystemVersion()
    {
    switch ((int)floor(NSAppKitVersionNumber)) {
      case NSAppKitVersionNumber10_0:
      return LSESystemVersionCheetah;
      break;
      case NSAppKitVersionNumber10_1:
      return LSESystemVersionPuma;
      break;
      case NSAppKitVersionNumber10_2:
      return LSESystemVersionJaguar;
      break;
      case NSAppKitVersionNumber10_3:
      return LSESystemVersionPanther;
      break;
    }
    if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3)
      return LSESystemVersionTiger;
    return LSESystemVersionUnknown;
    }

    Best,
    Fabian

    Fabian Schuiki
    <fabianschuiki...>

    Am 22.10.2007 um 06:31 schrieb David Dunham:

    > I'd like to disable some UI if my Cocoa application is running
    > under Tiger (as opposed to Leopard). Gestalt would work perfectly
    > well, but I wonder what the hard core "no Carbon" Cocoa developers
    > prefer to determine this. Or if AppKit version is preferred.
    >
    > David Dunham    A Sharp, LLC
    > Voice/Fax: 206 783 7404    http://a-sharp.com
    > Efficiency is intelligent laziness.
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • I'd say that can be dangerous.A feature (say method) being available
    does not mean that everything you need is available. What if some
    input manager or framework happens to add a method precisely with
    this name? This only works if you check for *every* method you would
    want to use, which is usually fragile and undoable.

    I would just check for the appkit version. That is a check that
    basically guarantees existence of a whole bunch of methods.

    Christiaan

    On 22 Oct 2007, at 7:55 PM, Shawn Erickson wrote:

    > On 10/21/07, David Dunham <dunham...> wrote:
    >> I'd like to disable some UI if my Cocoa application is running under
    >> Tiger (as opposed to Leopard). Gestalt would work perfectly well, but
    >> I wonder what the hard core "no Carbon" Cocoa developers prefer to
    >> determine this. Or if AppKit version is preferred.
    >
    > Check for the existance/lack of a feature that you need at runtime.
    > Avoid testing for OS version if possible.
    >
    > Need to know more about why you want to disable an aspect of UI on
    > Tiger to give specifics...
    >
    > -Shawn
  • On 22/10/2007, David Dunham <dunham...> wrote:
    > I'd like to disable some UI if my Cocoa application is running under
    > Tiger (as opposed to Leopard). Gestalt would work perfectly well, but
    > I wonder what the hard core "no Carbon" Cocoa developers prefer to
    > determine this. Or if AppKit version is preferred.

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

    -- Finlay
  • On 22 Oct 2007, at 05:31, David Dunham wrote:

    > I'd like to disable some UI if my Cocoa application is running
    > under Tiger (as opposed to Leopard). Gestalt would work perfectly
    > well, but I wonder what the hard core "no Carbon" Cocoa developers
    > prefer to determine this. Or if AppKit version is preferred.

    """
        A better way to get version information on Mac OS X would be to
    read in the
        system version information from the file /System/Library/
    CoreServices/System
    Version.plist.
    """
    from the Gestalt documentation.

    Cheers,
    Graham.
  • On 22/10/2007, Graham J Lee <leeg...> wrote:
    > """
    > A better way to get version information on Mac OS X would be to
    > read in the
    > system version information from the file /System/Library/
    > CoreServices/System
    > Version.plist.
    > """
    > from the Gestalt documentation.

    The documentation is wrong:
    <http://lists.apple.com/archives/carbon-dev/2007/Aug/msg00089.html>

    -- Finlay
  • On 22 Oct 2007, at 10:55, Shawn Erickson wrote:

    > Check for the existance/lack of a feature that you need at runtime.

    As in respondsToSelector?

    Finlay

    > "hard core no Carbon Cocoa
    > developers" need to grow up and stop being babies.

    I agree, but I was curious as to the diametrically opposite approach.

    Fabian

    > if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3)
    > return LSESystemVersionTiger;

    This doesn't actually work:

    NSAppKitVersionNumber10_3_5
    The Application Kit framework included in Mac OS X v10.3.5

    David Dunham
    Voice/Fax: 206 783 7404            http://www.pensee.com/dunham/
    Imagination is more important than knowledge. -- Albert Einstein
  • On 22 Oct 2007, at 16:22, David Dunham wrote:

    > Fabian
    >
    >> if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3)
    >> return LSESystemVersionTiger;
    >
    > This doesn't actually work:

    Whoops, I missed the "floor" there. Probably does work.

    It does seem odd there's no NSAppKitVersionNumber10_4 in the 10.4u SDK.

    David Dunham
    Voice/Fax: 206 783 7404            http://www.pensee.com/dunham/
    Imagination is more important than knowledge. -- Albert Einstein
  • On 10/22/07, David Dunham <dunham...> wrote:
    >
    > On 22 Oct 2007, at 10:55, Shawn Erickson wrote:
    >
    >> Check for the existance/lack of a feature that you need at runtime.
    >
    > As in respondsToSelector?

    ...or checking for nil/NULL function pointers or checking for the
    existence of a class (NSClassFromString(...) != nil), etc. Again hard
    to be specific without knowing what you need to check for which you
    haven't yet talked about.

    If you cannot check for the specific feature then app kit version may
    make sense but IMHO it is best to check for the specific feature if
    you can.

    <http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_de
    velopment/chapter_5_section_1.html
    >

    -Shawn
  • On 22 Oct 2007, at 23:54, Finlay Dobbie wrote:

    > On 22/10/2007, Graham J Lee <leeg...> wrote:
    >> """
    >> A better way to get version information on Mac OS X would be to
    >> read in the
    >> system version information from the file /System/Library/
    >> CoreServices/System
    >> Version.plist.
    >> """
    >> from the Gestalt documentation.
    >
    > The documentation is wrong:
    > <http://lists.apple.com/archives/carbon-dev/2007/Aug/msg00089.html>

    ...but the original poster wanted to find out whether he was on
    Tiger, where the aforementioned approach _is_ documented as better.
  • 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.

    Ack, at 10/23/07, Graham J Lee said:

    > ...but the original poster wanted to find out whether he was on
    > Tiger, where the aforementioned approach _is_ documented as better.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • 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.

    On my system, SystemVersion.plist reports 10.4.10 so I don't see how
    that's distinct from 10.4.10.

    Cheers,
    Graham.
  • That is *exactly* the problem and why you should not parse
    SystemVersion.plist directly. How do you convert the string 10.4.10
    into a numerical value you can compare against? And why are you even
    bothering to do that when Gestalt() gives you the numerical values
    correctly, no need to parse.

    Ack, at 10/23/07, Graham J Lee said:

    > 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.
    >
    > On my system, SystemVersion.plist reports 10.4.10 so I don't see how
    > that's distinct from 10.4.10.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • On 10/22/07, Rosyna <rosyna...> wrote:
    > That is *exactly* the problem and why you should not parse
    > SystemVersion.plist directly. How do you convert the string 10.4.10
    > into a numerical value you can compare against? And why are you even
    > bothering to do that when Gestalt() gives you the numerical values
    > correctly, no need to parse.

    Unless you care about 10.4.10 vs. 10.4.9, in which case Gestalt is
    broken.  At least SystemVersion.plist has the right answer.

    --
    Tom Harrington
    <atomicbird...>
    AIM: atomicbird1
  • Please read the documentation for the Gestalt selectors thoroughly.
    You cannot miss it. It goes into great detail in the header about how
    to handle 10.4.17.

    Ack, at 10/22/07, Tom Harrington said:

    > Unless you care about 10.4.10 vs. 10.4.9, in which case Gestalt is
    > broken.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • On 23/10/2007, at 1:08 PM, Rosyna wrote:

    > Please read the documentation for the Gestalt selectors thoroughly.
    > You cannot miss it. It goes into great detail in the header about
    > how to handle 10.4.17.

    To save everyone the pain, here's one way to do it:

    long majorVersion, minorVersion, bugFixVersion;

    Gestalt(gestaltSystemVersionMajor, &majorVersion);
    Gestalt(gestaltSystemVersionMinor, &minorVersion);
    Gestalt(gestaltSystemVersionBugFix, &bugFixVersion);

    NSLog(@"Running on Mac OS X %d.%d.
    %d",majorVersion,minorVersion,bugFixVersion);

    "Purist" Cocoa programmers should note that this is not a "Carbon"
    routine, you don't need to include Carbon.h. It's just a (very simple)
    C API.

    --
    Rob Keniger
  • On 23/10/2007, Graham J Lee <leeg...> wrote:
    > On 22 Oct 2007, at 23:54, Finlay Dobbie wrote:
    >
    >> On 22/10/2007, Graham J Lee <leeg...> wrote:
    >>> """
    >>> A better way to get version information on Mac OS X would be to
    >>> read in the
    >>> system version information from the file /System/Library/
    >>> CoreServices/System
    >>> Version.plist.
    >>> """
    >>> from the Gestalt documentation.
    >>
    >> The documentation is wrong:
    >> <http://lists.apple.com/archives/carbon-dev/2007/Aug/msg00089.html>
    >
    > ...but the original poster wanted to find out whether he was on
    > Tiger, where the aforementioned approach _is_ documented as better.

    Yes, but the documentation is wrong. The issue is not that something
    has changed on Leopard which means that parsing SystemVersion.plist is
    no longer "a better approach", but rather that the documentation on
    Tiger is incorrect. The documentation has been corrected in Leopard.

    Parsing SystemVersion.plist is probably more lines of code, and
    considered to be relying on an implementation detail. Just use
    Gestalt.

    -- Finlay
  • On 23 Oct 2007, at 2:00 AM, David Dunham wrote:

    > On 22 Oct 2007, at 16:22, David Dunham wrote:
    >
    >> Fabian
    >>
    >>> if ((int)floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_3)
    >>> return LSESystemVersionTiger;
    >>
    >> This doesn't actually work:
    >
    > Whoops, I missed the "floor" there. Probably does work.
    >
    > It does seem odd there's no NSAppKitVersionNumber10_4 in the 10.4u
    > SDK.
    >
    > David Dunham
    > Voice/Fax: 206 783 7404            http://www.pensee.com/dunham/
    > Imagination is more important than knowledge. -- Albert Einstein

    That should be in the main System version of NSApplication.h on
    Leopard. Certainly not in the 10.4u SDK, because that SDK is
    available on Tiger, and Tiger doesn't (officially) know it's last
    AppKit version number yet.

    Christiaan
  • On 23/10/2007, Christiaan Hofman <cmhofman...> wrote:
    > That should be in the main System version of NSApplication.h on
    > Leopard. Certainly not in the 10.4u SDK, because that SDK is
    > available on Tiger, and Tiger doesn't (officially) know it's last
    > AppKit version number yet.

    NSAppKitVersionNumber10_4 would correspond to the AppKit version
    number of 10.4.0, surely?

    -- Finlay
  • On 23/10/2007, Finlay Dobbie <finlay.dobbie...> wrote:
    > On 23/10/2007, Christiaan Hofman <cmhofman...> wrote:
    >> That should be in the main System version of NSApplication.h on
    >> Leopard. Certainly not in the 10.4u SDK, because that SDK is
    >> available on Tiger, and Tiger doesn't (officially) know it's last
    >> AppKit version number yet.
    >
    > NSAppKitVersionNumber10_4 would correspond to the AppKit version
    > number of 10.4.0, surely?

    And just for completeness, that is 824.

    #ifndef NSAppKitVersionNumber10_4
    #define NSAppKitVersionNumber10_4 824
    #endif

    When Leopard comes out, if NSAppKitVersionNumber10_5 is not defined,
    you will obviously be able to use the same trick (just write a one
    line tool to print out the actual value of NSAppKitVersionNumber in
    the GM).

    -- Finlay
  • On 23 Oct 2007, at 1:35 PM, Finlay Dobbie wrote:

    > On 23/10/2007, Finlay Dobbie <finlay.dobbie...> wrote:
    >> On 23/10/2007, Christiaan Hofman <cmhofman...> wrote:
    >>> That should be in the main System version of NSApplication.h on
    >>> Leopard. Certainly not in the 10.4u SDK, because that SDK is
    >>> available on Tiger, and Tiger doesn't (officially) know it's last
    >>> AppKit version number yet.
    >>
    >> NSAppKitVersionNumber10_4 would correspond to the AppKit version
    >> number of 10.4.0, surely?
    >

    Sorry, you're right. But though this might not be the reason then, it
    *is* a fact that NSAppKitVersionNumber10_4 is not defined on Tiger,
    but only in Leopard (and later) Just as NSAppKitVersionNumber10_3 was
    only defined on Tiger. I guess the idea is that an app developed on
    Tiger should not try to use Leopard features, so why should it care
    to check for Leopard?

    Christiaan

    > And just for completeness, that is 824.
    >
    > #ifndef NSAppKitVersionNumber10_4
    > #define NSAppKitVersionNumber10_4 824
    > #endif
    >
    > When Leopard comes out, if NSAppKitVersionNumber10_5 is not defined,
    > you will obviously be able to use the same trick (just write a one
    > line tool to print out the actual value of NSAppKitVersionNumber in
    > the GM).
    >
    > -- Finlay
  • 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
  • On 23/10/2007, Alastair Houghton <alastair...> wrote:
    >> 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.

    The file is an implementation detail. Don't rely on it. The only
    public defined interface to the values defined in the file is through
    Gestalt. There are SPI in CoreFoundation, but they don't really buy
    you anything over using 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.

    Your experience does not mesh with mine.

    > 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.

    So, again, use Gestalt. It's the best tool for the job. Whether it's
    Carbon or Cocoa is irrelevant.

    -- Finlay
  • On 23 Oct 2007, at 14:52, Finlay Dobbie wrote:

    > On 23/10/2007, Alastair Houghton <alastair...> wrote:
    >>> 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.
    >
    > The file is an implementation detail. Don't rely on it.

    My point was that Rosyna was implying that the reason Gestalt() was
    "right" and reading the file was "wrong" was that people messed up
    reading the file.  But that's not true (sure, it's true that people
    stuffed up reading it, but that doesn't make Gestalt() "right" and
    reading the file "wrong").  The reason Gestalt() is the best way is
    that Apple said so.  And in either case, you can still do the
    comparison wrong.  A common mistake is to do this:

      if (majorVersion >= 10 && minorVersion >= 4 && bugFixVersion >= 6) {
        // 10.4.6 and above <---- WRONG!

      }

    because of course the last test will fail for 10.5.0 (and the middle
    one, for 11.0.0).  Gestalt() doesn't save you from that kind of
    stupidity.

    And *even after all that*, there are one or two reasons you might
    want to use the file anyway; for instance, if you need the build
    number, or if you need to identify the version of Mac OS X on a disk
    that you didn't boot from.  And it *isn't* an "implementation
    detail".  It's documented all over the place in Tiger, including in
    the manual page for the "sw_vers" tool, which is yet another way to
    get this information.  As for Leopard, well you can look for yourself
    I suspect.

    >> 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.
    >
    > So, again, use Gestalt. It's the best tool for the job. Whether
    > it's Carbon or Cocoa is irrelevant.

    **I didn't say you shouldn't use Gestalt**, though I will say (now
    that you've said that) that it depends on what you're trying to
    accomplish.  It might be better in some instances to use uname()
    instead of Gestalt().  Or to check the AppKit version number.  Or
    indeed to do something else entirely.  The decision should be made on
    the basis of the information you actually want.

    Checking the system version to see whether you can call a QuickTime
    API, for instance, would be a mistake.  But such things have
    happened, *over and over*, on all the platforms I've worked on.

    The best bet is always to test for features, not versions, because
    it's difficult to screw that up and it allows for the possibility
    that things might be back-ported in future.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 23/10/2007, Alastair Houghton <alastair...> wrote:
    > It's documented all over the place in Tiger, including in
    > the manual page for the "sw_vers" tool, which is yet another way to
    > get this information.

    You shouldn't rely on that either:
    <http://lists.apple.com/archives/darwin-dev/2007/Aug/msg00107.html>

    -- Finlay
  • On 23 Oct 2007, at 16:30, Finlay Dobbie wrote:

    > On 23/10/2007, Alastair Houghton <alastair...> wrote:
    >> It's documented all over the place in Tiger, including in
    >> the manual page for the "sw_vers" tool, which is yet another way to
    >> get this information.
    >
    > You shouldn't rely on that either:
    > <http://lists.apple.com/archives/darwin-dev/2007/Aug/msg00107.html>

    Yes, I remember that thread (or at least something similar that made
    its way to Cocoa-dev).  In a number of important cases, that thread
    is wrong.  Yes, I know, prior to Leopard, some things might not
    conform properly to the POSIX spec., so there may be some changes as
    a result.  But even given that caveat I can think of at least a
    couple of cases where it is *overwhelmingly* preferable to parse
    rather than trying to make the same API calls as the tool in question.

    Not to mention the fact that I didn't suggest parsing the output of
    sw_vers.  I was merely pointing out that the manual page documents
    the presence of the plist file that you claimed is an "implementation
    detail".

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 23/10/2007, Alastair Houghton <alastair...> wrote:
    > Not to mention the fact that I didn't suggest parsing the output of
    > sw_vers.  I was merely pointing out that the manual page documents
    > the presence of the plist file that you claimed is an "implementation
    > detail".

    It's not my claim, I'm just reiterating what I have been told by the
    Apple engineers responsible. The documentation may well be wrong.

    -- Finlay
  • The manual page for sw_vers doesn't document it, it merely lists it.
    And note that it lists two files. Both files may not exist on most
    systems.

    Also, sw_vers has this fun little bug that may cause it to output
    complete garbage on some system configurations.

    Ack, at 10/23/07, Alastair Houghton said:

    > It's documented all over the place in Tiger, including in the
    > manual page for the "sw_vers" tool, which is yet another way to get
    > this information.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • On 23 Oct 2007, at 17:49, Rosyna wrote:

    > The manual page for sw_vers doesn't document it, it merely lists it.

    Which documents its presence.  Maybe not its contents, but certainly
    its presence.

    > And note that it lists two files. Both files may not exist on most
    > systems.

    That's true.  ServerVersion.plist only exists on Mac OS X Server.
    SystemVersion.plist exists on both though.

    > Also, sw_vers has this fun little bug that may cause it to output
    > complete garbage on some system configurations.

    Nice.  My point still stands though.  The presence of this file is
    documented.  In Tiger, the fact that you could use it is documented
    (in the docs for Gestalt(), no less).  It isn't something that Apple
    can freely remove without side effects, because they have made its
    existence public and have, at one point, actively advocated using
    it.  Plus Gestalt() doesn't help you in all cases where this file might.

    So, sure, you should use Gestalt() if that's what you need.  But
    before stating categorically that Gestalt() is the One True Way, it's
    worth realising that not everybody's needs are the same and sometimes
    that means doing something different.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 23/10/2007, Alastair Houghton <alastair...> wrote:
    > Plus Gestalt() doesn't help you in all cases where this file might.

    Would you care to elaborate on that?

    > So, sure, you should use Gestalt() if that's what you need.  But
    > before stating categorically that Gestalt() is the One True Way, it's
    > worth realising that not everybody's needs are the same and sometimes
    > that means doing something different.

    Perhaps where "something different" is not "determining what version
    of Mac OS X we're running on", but then we were never discussing that.

    Gestalt is the best tool for this job.

    -- Finlay
  • Alastair Houghton wrote:

    > The best bet is always to test for features, not versions, because
    > it's difficult to screw that up and it allows for the possibility
    > that things might be back-ported in future.

    Or removed. Or made optional.
  • someone should file a bug.

    On Oct 23, 2007, at 12:39 PM, Finlay Dobbie wrote:

    > It's not my claim, I'm just reiterating what I have been told by the
    > Apple engineers responsible. The documentation may well be wrong.
  • On 23 Oct 2007, at 18:25, Finlay Dobbie wrote:

    > On 23/10/2007, Alastair Houghton <alastair...> wrote:
    >> Plus Gestalt() doesn't help you in all cases where this file might.
    >
    > Would you care to elaborate on that?

    I already did.

    Gestalt() can't tell you the build number (and sometimes there are
    different versions of Mac OS X with the same major/minor/bugfix... it
    commonly happens when new hardware is released, for example).  And it
    only tells you about the *running* system; if, for instance, you need
    to identify a build of Mac OS X that's on some other disk, you can't
    ask Gestalt() for that information.

    >> So, sure, you should use Gestalt() if that's what you need.  But
    >> before stating categorically that Gestalt() is the One True Way, it's
    >> worth realising that not everybody's needs are the same and sometimes
    >> that means doing something different.
    >
    > Perhaps where "something different" is not "determining what version
    > of Mac OS X we're running on", but then we were never discussing that.

    That's not strictly true.  It had entered the discussion on more than
    one occasion, including (I think) in every post I've made on the
    topic, as well as some from some of the other contributors.

    IMO, checking the Mac OS X version is normally the wrong thing to
    do.  It may sometimes be a necessary evil, but usually there are
    better ways to get things done.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • on 2007-10-24 6:07 AM, Alastair Houghton at <alastair...>
    wrote:

    > IMO, checking the Mac OS X version is normally the wrong thing to
    > do.  It may sometimes be a necessary evil, but usually there are
    > better ways to get things done.

    I think that statement is too general. It's true as to specific, individual
    features, but not when the entire product is aimed at technology introduced
    in a particular version of Mac OS X.

    One of my commercial products went through major revisions for Tiger, adding
    many new features based on techniques that were introduced in Tiger. My
    other commercial product was written for Tiger, and some of its core
    features require techniques introduced in Tiger. I didn't have the time
    required to make sure every feature either worked as expected or was blocked
    in Panther and older, and that wouldn't have made any sense for one of them
    anyway because it was designed for Tiger-specific technology. I decided to
    make both products require Tiger or newer. Code testing for Tiger was
    therefore necessary. (I used the Gestalt selectors and some nice code that
    is floating around on the lists to make sure the test works correctly all
    the way pack to Jaguar (or Cheetah?).

    I'll be doing the same thing for Leopard.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • Am 24.10.2007 um 12:39 schrieb Bill Cheeseman:

    > Code testing for Tiger was therefore necessary.

    Why do you require to hack around such tests if one of your users
    wants to test your app in Panther? The user always knows best what (s)
    he wants.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • on 2007-10-24 7:21 AM, Markus Hitter at <mah...> wrote:

    > Am 24.10.2007 um 12:39 schrieb Bill Cheeseman:
    >
    >> Code testing for Tiger was therefore necessary.
    >
    > Why do you require to hack around such tests if one of your users
    > wants to test your app in Panther? The user always knows best what (s)
    > he wants.

    One of my apps functions incompletely under Panther, and the other doesn't
    function at all under Panther. I don't think it would be smart to frustrate
    my customers by forcing them to waste their time finding that out for
    themselves. By testing for Tiger, I am able to tell the user nicely at the
    outset that the product isn't designed for Panther.

    The user may know what he wants, but I know best what my products actually
    do. As the developer of the products, I feel an obligation to inform the
    user what they do and what they don't do.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • > The user may know what he wants, but I know best what my products actually
    > do. As the developer of the products, I feel an obligation to inform the
    > user what they do and what they don't do.

      Perfectly salient point. You can paste this fact (minimum
    requirements) all over the download site, all over the packaging (if
    there is any) and all through the manuals, but many users don't bother
    reading that, they just download and (try to) run it.

      It's quite often that users will download some freeware app I have
    floating around out there, ignoring the system requirements (OS X 10.4
    or above). They then write angry missives about how they can't run the
    (OS X only) app on their Windows PC.

      Of course that's an extreme case (how would you notify them in the
    app if the app won't even launch), but it illustrates an important
    point: sometimes users don't bother reading things. Sometimes that
    sentence is more accurate if you replace 'sometimes' with 'most
    times'. Who the hell cares if the user "knows he wants to run the app
    on 'x' system" ... if he can't, he can't. "Them's the breaks," as the
    horribly broken phrase goes. ;-)

    --
    I.S.
  • You really shouldn't need to know the build number for any purpose,
    except potentially for reporting. Edge cases do not an argument make
    :)

    -- Finlay

    On 24/10/2007, Alastair Houghton <alastair...> wrote:
    > On 23 Oct 2007, at 18:25, Finlay Dobbie wrote:
    >
    >> On 23/10/2007, Alastair Houghton <alastair...> wrote:
    >>> Plus Gestalt() doesn't help you in all cases where this file might.
    >>
    >> Would you care to elaborate on that?
    >
    > I already did.
    >
    > Gestalt() can't tell you the build number (and sometimes there are
    > different versions of Mac OS X with the same major/minor/bugfix... it
    > commonly happens when new hardware is released, for example).  And it
    > only tells you about the *running* system; if, for instance, you need
    > to identify a build of Mac OS X that's on some other disk, you can't
    > ask Gestalt() for that information.
    >
    >>> So, sure, you should use Gestalt() if that's what you need.  But
    >>> before stating categorically that Gestalt() is the One True Way, it's
    >>> worth realising that not everybody's needs are the same and sometimes
    >>> that means doing something different.
    >>
    >> Perhaps where "something different" is not "determining what version
    >> of Mac OS X we're running on", but then we were never discussing that.
    >
    > That's not strictly true.  It had entered the discussion on more than
    > one occasion, including (I think) in every post I've made on the
    > topic, as well as some from some of the other contributors.
    >
    > IMO, checking the Mac OS X version is normally the wrong thing to
    > do.  It may sometimes be a necessary evil, but usually there are
    > better ways to get things done.
    >
    > Kind regards,
    >
    > Alastair.
    >
    > --
    > http://alastairs-place.net
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • On 24 Oct 2007, at 19:08, Finlay Dobbie wrote:

    > You really shouldn't need to know the build number for any purpose,
    > except potentially for reporting. Edge cases do not an argument make
    > :)

    Edge cases may not make an argument, but they do make it less than
    black and white.

    Besides which, at every turn, you seem to be under the impression
    that I'm arguing *against* using Gestalt().  I have not, and I am
    not.  Using Gestalt() *is* the best way to get the system version
    number (assuming that's really what you need).  But that doesn't mean
    that there aren't circumstances where the file is better---or even
    the *only* way to obtain the information.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • Am 24.10.2007 um 13:21 schrieb Markus Hitter:
    > Am 24.10.2007 um 12:39 schrieb Bill Cheeseman:
    >> Code testing for Tiger was therefore necessary.
    >
    > Why do you require to hack around such tests if one of your users
    > wants to test your app in Panther? The user always knows best what
    > (s)he wants.

      Definitely not. Many user do not read manuals and system
    requirements, or don't keep the manual and box around, and then just
    try to run the application to see if it works. If you know your app
    will seem to work fine but crash on the user and take their data with
    them (not arbitrary data, but the current session), it's IMHO the
    right thing to do to tell your users that the app wasn't intended to
    work on this OS.

      Whether you actually let the user proceed after that depends on who
    your users are, why your app may be limited to this particular OS
    version and more. But it is simply a bad user experience to have your
    app crash if you can make it put up a warning instead.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Am 24.10.2007 um 20:08 schrieb Finlay Dobbie:
    > You really shouldn't need to know the build number for any purpose,
    > except potentially for reporting. Edge cases do not an argument make
    > :)

      This sounds like you never ran into the two differing 10.4.10
    builds. Apple shoved out a second release due to that sound issue
    with the former. They also provided an upgrade to turn the broken
    build into the fixed version. But the broken-then-fixed build has a
    different build number (and some different bugs) than the fixed-from-
    the-start second revision.

      The least of our troubles was that, since the build numbers
    differed, Xcode wouldn't let us distribute builds between these two
    versions ...

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Which is actually a good example of why you shouldn't use build
    numbers and the borked behaviours you can get if you do... But Xcode
    has a lot of examples of borked behaviours (see
    MAC_OS_X_VERSION_ACTUAL).

    Ack, at 10/25/07, Uli Kusterer said:

    > The least of our troubles was that, since the build numbers
    > differed, Xcode wouldn't let us distribute builds between these two
    > versions ...

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • On 25/10/2007, Uli Kusterer <kusterer...> wrote:
    > Am 24.10.2007 um 20:08 schrieb Finlay Dobbie:
    >> You really shouldn't need to know the build number for any purpose,
    >> except potentially for reporting. Edge cases do not an argument make
    >> :)
    >
    > This sounds like you never ran into the two differing 10.4.10
    > builds. Apple shoved out a second release due to that sound issue
    > with the former. They also provided an upgrade to turn the broken
    > build into the fixed version. But the broken-then-fixed build has a
    > different build number (and some different bugs) than the fixed-from-
    > the-start second revision.

    Does your app change behaviour based on whether the sound is broken or not?

    -- Finlay
  • Am 25.10.2007 um 10:18 schrieb Finlay Dobbie:
    > On 25/10/2007, Uli Kusterer <kusterer...> wrote:
    >> Am 24.10.2007 um 20:08 schrieb Finlay Dobbie:
    >>> You really shouldn't need to know the build number for any purpose,
    >>> except potentially for reporting. Edge cases do not an argument make
    >>> :)
    >>
    >> This sounds like you never ran into the two differing 10.4.10
    >> builds. Apple shoved out a second release due to that sound issue
    >> with the former. They also provided an upgrade to turn the broken
    >> build into the fixed version. But the broken-then-fixed build has a
    >> different build number (and some different bugs) than the fixed-from-
    >> the-start second revision.
    >
    > Does your app change behaviour based on whether the sound is broken
    > or not?

      No. We expect our users to install the latest system updates, which
    fix this issue. However, the two different fixed versions had other
    bugs around which we had to work. We do change behavior when running
    on a system version that has those bugs, though.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Am 25.10.2007 um 02:50 schrieb Uli Kusterer:

    > Am 24.10.2007 um 13:21 schrieb Markus Hitter:
    >
    >> The user always knows best what (s)he wants.
    >
    > Definitely not.

    With such an attitude, you better stop working for customers.

    My humble opinion.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • On 25.10.2007, at 11:52, Markus Hitter wrote:
    > Am 25.10.2007 um 02:50 schrieb Uli Kusterer:
    >
    >> Am 24.10.2007 um 13:21 schrieb Markus Hitter:
    >>
    >>> The user always knows best what (s)he wants.
    >>
    >> Definitely not.
    >
    > With such an attitude, you better stop working for customers.
    >
    > My humble opinion.

      Well, everyone's entitled to their opinion.

      I have stated in various places that I think that the user doesn't,
    and moreover shouldn't *have to* know what they want. I want to write
    software that stays out of the way, that can be used easily, without
    having to first acquire lots of knowledge about the way the program
    works.

      I've certainly been in the situation myself where I didn't know
    whether an application would run on a particular Mac, and I find it
    much more convenient to just click the thing and have it tell me,
    than having to dig out a paper manual and search it, or having to
    find the correct page on the vendor's huge web site.

      If you still think I should stop working for customers, I guess we
    have to agree to disagree. Or you could read Steve Krug's book "Don't
    make me think!", which explains the school of thought behind this at
    length.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 25 Oct 2007, at 12:08, Uli Kusterer wrote:

    > On 25.10.2007, at 11:52, Markus Hitter wrote:
    >> Am 25.10.2007 um 02:50 schrieb Uli Kusterer:
    >>
    >>> Am 24.10.2007 um 13:21 schrieb Markus Hitter:
    >>>
    >>>> The user always knows best what (s)he wants.
    >>>
    >>> Definitely not.
    >>
    >> With such an attitude, you better stop working for customers.
    >>
    >> My humble opinion.
    >
    > Well, everyone's entitled to their opinion.

    Guys, you already know this, but you're *both* right, it just depends
    on the circumstances.  So there's really no need to argue about it.

    Sometimes it's useful stopping the user from doing something daft.
    Sometimes it isn't necessary, and sometimes it's only necessary to
    warn them and let them proceed at their own risk.  It depends on the
    user, on the piece of software, and on the potential effects of it
    going wrong or not working.  It's a judgement call.

    I think we all know when it would or wouldn't be appropriate, and
    certainly those of us who have commercial or shareware products also
    have some idea of the impact it's going to have on customer support.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today