Apfelinsel
Apple => Thema gestartet von: Patrick am Mai 24, 2007, 13:33:57
-
Auch wenn es schon ein paar Tage her ist: laut Think Secret (http://www.thinksecret.com/news/0705macosx10410.html) und anderen ist scheinbar das nächste Tiger-Update in der Mache. Somit gibt es zum ersten mal ein Update mit 2 Stellen in der Versionsnummer.
Nachdem das letzte Update scheinbar nicht für alle sehr erfreulich war, war dieser Schritt unabhängig vom Entwicklungsstand des Leoparden unumgänglich.
Natürlich werden jetzt auch Spekulationen laut, daß jetzt auch ein MacOS X 10.10 oder sogar höher möglich wäre...
-
Natürlich werden jetzt auch Spekulationen laut, daß jetzt auch ein MacOS X 10.10 oder sogar höher möglich wäre...
Das nötige Updates ausbleiben, nur weil uns in unserer Fantasie keine mögliche Update-Nummer eingefallen ist, habe ich auch nie geglaubt.
(es jibbet ja auch noch über 20 Buchstaben....)
;D
-
Phonetisch ist es natürlich großartig: "Meck O Es Zehn Punkt 4 Teiger Zehn Punkt Zehn".
Gut das es Alternativen gibt: "Tischä, neuester". :)
-
Das nötige Updates ausbleiben, nur weil uns in unserer Fantasie keine mögliche Update-Nummer eingefallen ist, habe ich auch nie geglaubt.
Naja, höher als .9 ging's halt in den letzten 20 Jahren noch nie und selbst 10.3.9 wurde eisern beibehalten.
-
Man kann es auch 10.4.9.1 nennen. :P Da hat man bis Leopard dann ja noch 9 Versionssprünge, ich denke, das müsste reichen. 8)
-
Oder Tiger mit Punkten! :)
-
Man sagt natürlich "Mäk Oh Es Zehn Taiger Zehn Vier Zehn". ;D
Für die Technik-Freaks unter Euch: ;)
Es gibt einen technischen Grund, weshalb die Nummerung tatsächlich bestimmten Grenzen unterliegen sollte: Es gibt in Mac OS X einen alten Carbon-Funktionsaufruf, der aus Mac OS übernommen wurde. Diese Funktion liefert einem Programm die Versionsnummer des gerade laufenden Betriebssystems in einem speziellen Code zurück, nämlich als 16-Bit-Zahl, gedeutet als vierstellige Hexadezimalzahl, wobei die ersten beiden Ziffern die Hauptversionsnummer, die dritte Ziffer die Unterversionsnummer und die vierte Ziffer die Unterunterversionsnummer darstellen.
Beispiel: Die Version Mac OS X 10.4.9 wird in Carbon durch die Zahl 4169 codiert, weil diese Zahl im Sechzehnersystem als "1049" dargestellt wird. (C-Programmierer markieren Hexadezimalzahlen mit "0x", also 0x1049.) Mac OS X 10.2.5 hatte den Code 4133, weil dies der Zahl 0x1025 entspricht.
Bei 10.4.10 scheitert das: Das lässt sich in 4 Ziffern nicht mehr unterbringen, es sei denn, man würde die Hexadezimalziffern A bis F zulassen. Das wiederum gibt Probleme, denn viele Programme sind darauf nicht vorbereitet. Auch ist es inkonsistent, denn 0x104A müsste dann besser als 0x0A4A codiert werden, was aber die ganze Sortierung und Vergleichsmöglichkeiten durcheinanderbringt.
Apple wird hier wahrscheinlich die bisherigen Vorschriften aufgeben und kann diese Codierung nicht mehr fortschreiben bis 10.5 (= 4176) herauskommt. Das heißt, Carbon-Programme, die nur diese veraltete Methode der Versionsprüfung verwenden, werden 10.4.9 nicht von 10.4.10 unterscheiden können, da der Code bei 4169 festhängt. Viele Programme verwenden solche Prüfungen, um zu wissen, auf welche Bugs im System sie sich vorbereiten müssen.
-
Beeindruckend!
-
Könnte man aber durch Streichen der 0 bei der 10 vorne doch übergangsweise beheben, dann wäre es 0x1410, somit 5136 dezimal. Wäre dann zwar streng genommen Mac OS 14.1.0, aber was solls ;)
-
Wäre dann zwar streng genommen Mac OS 14.1.0, aber was solls ;)
Dann gibts Probleme bei OS 14 ;).
-
Apple wird hier wahrscheinlich die bisherigen Vorschriften aufgeben und kann diese Codierung nicht mehr fortschreiben bis 10.5 (= 4176) herauskommt. Das heißt, Carbon-Programme, die nur diese veraltete Methode der Versionsprüfung verwenden, werden 10.4.9 nicht von 10.4.10 unterscheiden können, da der Code bei 4169 festhängt. Viele Programme verwenden solche Prüfungen, um zu wissen, auf welche Bugs im System sie sich vorbereiten müssen.
Hätte diese Vorgehensweise irgendwelche negativen Auswirkungen auf Programme? Das wäre dann nämlich eher schlecht...
-
Hätte diese Vorgehensweise irgendwelche negativen Auswirkungen auf Programme? Das wäre dann nämlich eher schlecht...
Nunja, wenn es Bugs gibt, die in .9 und .10 unterschiedlich behandelt werden müssen, dann ja.
-
Nunja, wenn es Bugs gibt, die in .9 und .10 unterschiedlich behandelt werden müssen, dann ja.
Dann gibt es ja vielleicht eine andere Möglichkeit festzustellen ob nun .10 oder .9 eingesetzt wird.
-
Hätte diese Vorgehensweise irgendwelche negativen Auswirkungen auf Programme?
Nicht wirklich, denn Programme, die den Unterschied zwischen 10.4.9 und 10.4.10 erkennen wollen, "wissen" ja bereits, dass es ein 10.4.10 gibt und können dann eine bessere Prüfung auf die Versionsnummer vornehmen.
Negative Auswirkungen gäbe es nur, wenn Apple wirklich dieses Codierungsschema ändern würde, um die 10.4.10 abzubilden. Dann würden alle Programme, die diese Codes nutzen, nicht mehr richtig laufen. Deshalb ja meine Vorhersage, dass Apple das ganz bestimmt nicht ändern wird. Der Vorschlag "Mac OS X 10.4.10 = 0x1410 = 5136 =? Mac OS X 14.1" kann deshalb auch nicht funktionieren.
Dann gibt es ja vielleicht eine andere Möglichkeit festzustellen ob nun .10 oder .9 eingesetzt wird.
Ja, die gibt es natürlich. Wie gesagt ist die beschriebene Technik ziemlich alt, wird aber wohl noch gerne verwendet, da man über einen einzigen 16-Bit-Vergleich mit dem Versionscode arbeiten kann.
Die bessere Technik basiert auf Textvergleichen mit dem Inhalt der XML-Datei /System/Library/CoreServices/SystemVersion.plist. Da weiß man dann auch, welche Build-Version man hat und ob eine Server- oder Preview-Version vorliegt.
-
Der Vorschlag "Mac OS X 10.4.10 = 0x1410 = 5136 =? Mac OS X 14.1" kann deshalb auch nicht funktionieren.
War auch nicht wirklich ernst gemeint ;)
-
War auch nicht wirklich ernst gemeint
Ja, ich weiß. ;)
-
Aha. Danke für die Erklärung. Dann muss ich mir ja keine Sorgen machen. Vor allem, weil ich noch ein halbes Jahr Classic brauche. Und diese Programme hätten bestimmt ein Problem damit.
-
Nö, die laufen ja eben in Classic. Denen ist reichlich egal, was für ein OS X da auch noch irgendwo läuft. ;)
-
Genau, die Classic-Programme laufen auf einem virtuellen Mac und kriegen von Mac OS X nichts mit.
Der virtuelle Mac läuft z.B. mit Mac OS 9.2.2 und liefert dann einen Versionscode von 0x0922 = 2338.
-
Die ersten Probleme mit der Versionsnummer tauchen auf... 8)
Programme, die den "alten" Weg zur Bestimmung der Versionsnummer verwenden, verhalten sich gutmütig, da 10.4.10 hier tatsächlich die falsche Antwort 10.4.9 als Versionsnummer zurückliefert.
Aber Programmierer, die den "neuen" Weg verwenden, das aber unter der Vermutung programmiert haben, dass Apple solche merkwürdigen Nummern nicht verwendet, haben jetzt Probleme: So lässt sich der Oberflächen-Patcher UNO 1.5.1 (http://gui.interacto.net/) unter 10.4.10 nicht mehr installlieren, da er denkt, es handle sich um 10.4.1.
-
Heisst das nun, dass gewisse Programme wegen der 10 in der Versionsnummer troubles machen? Oder geht es hier nur um die Anzeige der Version?
Wenn keinerlei Veränderungen/Verbesserungen vorgenommen worden sind, was ist der Grund für Apple dieses Update rauszubringen und was ist der Grund für die User es zu installieren?
-
Heisst das nun, dass gewisse Programme wegen der 10 in der Versionsnummer troubles machen?
Ja. Wie gesagt ließ sich das genannte Programm nicht mehr starten. Der Entwickler wird das natürlich (wahrscheinlich heute noch) korrigieren.
Wenn keinerlei Veränderungen/Verbesserungen vorgenommen worden sind,
Es sind schon einige Änderungen und Verbesserungen (http://docs.info.apple.com/article.html?artnum=305533) vorgenommen worden. Das Combo-Update für die Universal-Server-Version ist beispielsweise 399 MByte groß.
Falls Du Dich auf den anderen Thread hier beziehst: Ich habe mich nur beklagt, dass viele Verbesserungen, auf die ich persönlich schon Monate bis mehrere Jahre warte, immer noch nicht vorgenommen wurden. So wird es hoffentlich wohl noch ein 10.4.11 geben.
-
Die Diskussion zur Softwareaktualisierung mit Mac OS X Server / im Netzwerk findet man nun hier (http://www.apfelinsel.de/forum/index.php?topic=2306.0).
Getrennt nicht wegen Ordnungswahn sondern weil sehr interessant und so später leichter auffindbar.