Windows und der Fluch der Versionsnummer

Microsoft hat es schon nicht leicht. Kaum ändert man in Redmond die Versionsnummer von Windows, schon hagelt es Probleme. Berühmt war der Fall von Windows Vista: Damals setzte Microsoft die interne Versionsummer von 5.2 (Windows XP) auf 6.0 (Vista) hoch. Rumms, sagte es, und viele Applikationen versagten den Dienst. Der Grund war eigentlich lächerlich: In diesen Applikationen gab es allzu simple Versionsprüfungen, die beispielsweise auf Version 5.x prüften, weil die Anwendungen nicht mit Windows NT oder noch älteren Fassungen kompatibel waren. Auf eine Version 6.0 war der Code aber nicht gefasst, also glaubte er, ein zu altes Windows vor sich zu haben und verweigerte die Mitarbeit.

Also zog Microsoft ab Windows 7 zahlreiche Register. Nicht nur vermied man in Redmond den (naheliegenden) Sprung auf Version 7.0, weswegen sich Windows 7 souverän als Version 6.1 meldete. Noch dazu gibt es seither unter der Haube einige Tricks und Kniffe, mit denen Windows einfach gestrickten Applikationen die Versionsnummer vorgaukelt, die diese wahrscheinlich sehen wollen. Ein lesenswerter Artikel auf Ars Technica beschreibt einiges dazu:

[Why Windows 10 isn’t version 6 any more and why it will probably work | Ars Technica]
http://arstechnica.com/information-technology/2014/11/why-windows-10-isnt-version-6-any-more-and-why-it-will-probably-work/

In diesem Artikel steht auch, warum Windows 10 dieses Versteckspiel beenden und sich intern als Version 10.0 ausgeben kann.

Eine Variante, auf das “richtige” Windows zu prüfen, besteht darin, die Build-Nummer des Betriebssystems abzufragen. Die lautete bei Windows XP 2600, bei Vista 6000, und Windows 8 (und Server 2012) melden sich als Build 9200. Nicht zuletzt sind es aber die Preview-Versionen von Windows 10 (und Windows Server 2016, bisher auch als “Windows Server Technical Preview” bekannt), die das Build-Nummernspiel zu neuer Blüte treiben. Die erste Preview kam als Nummer 9860, kurz darauf erschien Build 9879. Seit Anfang dieses Jahres liegen die Buildnummern höher als 10.000 (aktuell 10074 für Windows 10 und den Server, 10080 für Windows Phone) – und ein altes Problem ist wieder da: Urplötzlich verweigern Programme und Skripts den Dienst, die noch vor Kurzem in der Preview anstandslos liefen, und behaupten, die Windows-Version sei zu alt. Was ist denn nun los?

Der Grund ist wieder einmal trivial, allerdings teilen sich diesmal Microsoft und die Applikations- bzw. Skriptentwickler die Schuld. Fragt man nämlich die Buildnummer über eine der üblichen Schnittstellen ab, so liefert Windows diese zurück. Buildnummern sind Nummern, also kann man sie vergleichen. Verlangt ein Programm mindestens Windows 8, so könnte es prüfen (in Pseudocode):

WENN Buildnummer < 9200 DANN “Wir brauchen mindestens Windows 8”

Die aktuellen Previews von Windows 10 erzeugen mit einer Prüfung nach diesem Muster genau diesen Abbruch: Sie vermuten ein Windows älter als Windows 8. Kann Windows plötzlich nicht mehr rechnen?

Doch, kann es. Man muss ihm dann aber auch das Richtige zu rechnen geben. Das Problem: Die Buildnummer ist für Windows überhaupt keine Zahl, sondern ein String. Und ein Vergleich von Stringwerten geschieht alphabetisch, nicht numerisch: 9200 beginnt mit einer 9, 10074 hingegen mit einer 1. Also ist 10074 (als String) tatsächlich kleiner als 9200 (als String).

Eigentlich sind die Entwickler hier wieder mal in dieselbe Falle getappt. Sie haben ein Verfahren gewählt, das sie nicht näher geprüft haben, und weil es bislang funktionierte, setzen sie es weiter ein. Das ging solange gut, wie die Buildnummern vierstellig waren, sodass neuere Builds sowohl numerisch als auch “alphabetisch” höhere Nummern haben. Mit dem Sprung auf die fünfte Stelle (also 10000) ist es mit dem simplen Prüfen aber vorbei. Spätestens jetzt müssen Entwickler die Buildnummer ausdrücklich in einen numerischen Wert konvertieren, um sie zu vergleichen …

(Und bevor jemand meint, mich erwischt zu haben: Ja, ich habe genau denselben Fehler auch gemacht, in einem Skript, das öffentlich bereitsteht. Damit bin ich aber nicht allein: Auch ein Skript, das Microsoft selbst zum Einsatz unter Build 10074 empfiehlt, stolpert an dieser Stelle.)