With Mac OS X 10.4 Tiger, Apple introduced three new Gestalt selectors for
determining the version of the running operating system:
gestaltSystemVersionMajor, gestaltSystemVersionMinor and
gestaltSystemVersionBugFix. The Gestalt documentation indicates that this
was done to permit system versioning in which the minor and bugfix version
numbers can go as high as 15, as in Mac OS X 10.4.15.
For compatibility, the existing gestaltSystemVersion selector will return
0x1049 for all versions from 10.4.9 through 10.4.15.
This means that all existing software that uses gestaltSystemVersion to do
things like identifying a system in which a bug was fixed must be revised if
you need to distinguish between versions 10.4.9 and 10.4.10, for example.
Comparisons of the form (0x1041 > 0x1040) won't work, of course, when the
minor or bugfix version number is greater than 9.
For my own software, I've devised this solution. It generates version
numbers as a 6-character string of the form "MMmmbb", where MM is the major
version, mm is the minor version, and bb is the bugfix version. Leading
zeroes pad each field out to two characters as needed to maintain the string
length. The benefit of this technique is that I can compare version numbers
from 10.0.0 through 10.4.15 (and even 10.15.15, someday) simply by using
-[NSString compare:], because alphabetical ordering is equivalent to version
ordering. Also, I can embed test version strings into my code like this:
static const NSString *versionBugFixed = @"100410";
just as I used to do it like this:
static const unsigned long versionBugFixed = 0x1049;
+ (NSString *)QSWStandardizedOperatingSystemVersionString {
long systemVersion, systemVersionMajor, systemVersionMinor,
systemVersionBugFix;
if ((Gestalt(gestaltSystemVersion, &systemVersion) == noErr) &&
(systemVersion <= 0x1039)) { // Mac OS X 10.3.9 Panther and older
return [NSString stringWithFormat:@"%i%i0%i0%i", ((systemVersion >>
12) & 0xF), ((systemVersion >> 8) & 0xF), ((systemVersion >> 4) & 0xF),
(systemVersion & 0xF)];
} else if ((Gestalt(gestaltSystemVersionMajor, &systemVersionMajor) ==
noErr) && (Gestalt(gestaltSystemVersionMinor, &systemVersionMinor) == noErr)
&& (Gestalt(gestaltSystemVersionBugFix, &systemVersionBugFix) == noErr)) {
// Mac OS X 10.4.0 Tiger and newer
return [NSString stringWithFormat:@"%i%2.2i%2.2i",
systemVersionMajor, systemVersionMinor, systemVersionBugFix];
}
return @"999999"; // signifies error
}
Usage:
[[myClass QSWStandardizedOperatingSystemVersionString] compare:@"100410"]
== NSOrderedAscending;
Or, if I declared a static variable as shown above:
[[myClass QSWStandardizedOperatingSystemVersionString] compare:(NSString
*)versionBugFixed] == NSOrderedAscending;
As written, this method is not valid for Mac OS 9 and older, but I don't
anticipate that Apple will port Cocoa to the classic Mac OS.
I BELIEVE this code will work correctly on Intel machines, but I would
appreciate confirmation because I'm only just getting into the universal
conversion literature. I'm doing some bit-shifting here, but for fewer bits
than the long data type returned by the Gestalt function, which I understand
is safe on Intel.
This solution was inspired by the ISO 8601 date standard
<http://en.wikipedia.org/wiki/ISO_8601>, which also uses fixed-length
strings with leading zeroes and most-significant-value-first field ordering
to ensure that alphabetical ordering of dates is equivalent to chronological
ordering.
Shouldn't Apple add something like this to NSProcessInfo? The existing
-[NSProcessInfo operatingSystemVersionString] method is not useful for
comparisons. My use of "Standardized" in the method name is analogous to
-[NSURL standardizedURL], for those who care about such things.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden