Windows 10: Build-Nummern und der Fluch der Vergangenheit

Microsoft hat ein 'kleines Problem' mit Windows 10 und den intern verwendeten Build-Nummern. Daher heute in kleiner Exkurs in Sachen Windows 10 und Altlasten im Code, der mir gerade unter die Augen gekommen ist.

Probleme mit Build-Nummern 17000.xxx

Es ist nur ein kurzer Artikel, der mir heute morgen bei den Kollegen von deskmodder.de unter die Augen gekommen ist. Es gibt wohl eine Konversion auf Twitter, die ganz harmlos von Dona Sarkar gestartet wurde.

The #WindowsInsiders team had a bit of fun yesterday escaping an inception situation. We missed you @brandonleblanc! pic.twitter.com/6ocKdeVd9g

— Dona Sarkar (@donasarkar) 25. August 2017

Und dann kommt noch eine faustdicke Überraschung. Brandon Le Blanc hat im Tweet auf eine Benutzerfrage, warum es keine Build 17000 gäbe folgendes geantwortet.

Not necessarily false but perhaps a more complicated "story" that requires more than 140 characters to explain.

— Brandon LeBlanc (@brandonleblanc) 26. August 2017

Und dann hat er folgendes in seinem Twitter-Profil nachgeschoben.

Interesting article! I'm not a "PR person" though. Looking to dive into this topic for Insiders in the next few weeks. https://t.co/7b6Sb71vGr

— Brandon LeBlanc (@brandonleblanc) 28. August 2017

Wäre an mir vorbei gegangen, wenn die Leute bei deskmodder.de es nicht aufgegriffen hätten.

Wenn Marketing und Entwicklung kollidieren

Ich habe es in meinem früheren Leben immer gehasst, wenn da die Leute mit großem Maul herumliefen und von ihren tollen Softwarelösungen schwärmten, die sie gerade mit Tool xyz realisieren. Die Aufmerksamkeit war ihnen sicher, aber ich ahnte häufig nach ein paar Nachfragen schon, dass dieses Projekt früher oder später zur Sanierung bei mir vor den Füßen landen würde. Und wenn Cheffe dann mit betretenem Gesicht und 'Born, wir haben eine Problem …' zur Tür herein kam wusste ich, was kam …

Das fiel mir bei der Geschichte ein und sofort war die Verbindung zu Microsoft da. Dort hören wir vom Marketing 'Windows 10, das beste aller Windows, welches von Microsoft jemals herausgegeben wurde'. Na ja, ich muss fair bleiben, das Marketing kann sich schlecht hinstellen und sagen 'Hey Leute, wir haben ein Windows 10, das ist der letzte Scheiß. Aber wir wollen trotzdem, dass ihr das einsetzt – denn besser können wir es nicht und die Altlasten müssen wir los werden.'

Was man dem Marketing aber ankreiden muss, ist die Schnapsidee mit dem 'Windows as a Service', die den Entwickler eine Altlast weit früher als geplant vor die Füße gespült hat. Ich gesteht, ich habe das mit diebischer Freude vernommen – denn in meinem schon etwas längeren IT-Leben kam man mit Insidern in Kontakt, die die Freude hatten, Altcode in Microsoft-Produkten zu warten. Nicht selten haben die sich dann entschlossen, das Ganze neu zu schreiben.

Der Fluch der 16-Bit im Altcode

Die Geschichte kommt so harmlos daher – bei deskmodder schreibt man, dass man auf Buildfeed die Build 16350.1002 und die Build 17000.1000 sehen konnte – letztere gehört wohl zum Redstone 4-Entwicklungszweig. Und plötzlich switcht man wieder zurück, weil sich die Build-Nummer 17000 als Problem herausgestellt hat – siehe die obigen Tweets.

Da hat sofort etwas in meinem Hinterkopf geklingelt – sind über 25 Jahre her, als ich in Hexzahlen gedacht habe. Die Zahl 17.000 steht für den Hexadezimalwert 0x4268. Da kommt mir sofort der Hexwert 0x3FFF in den Sinn, die größte mit 14 Bit darstellbare Zahl. Der Hexadezimalwert 0x4268 lässt sich mit 14 Bit nicht mehr darstellen (warum man nicht die 16 Bit als unsigned genommen hat, ist an dieser Stelle unklar). Der Wert 0x3FFF entspricht dezimal der Zahl 16383. Oberhalb dieser Build-Nummer gibt es dann Probleme, wenn diese in 16-Bit-Variablen abgebildet und mit 14 Bit gemappt wird. Es kommt zu einem Überlauf des Werts – nicht wirklich gut, wenn man Abfragen auf größer oder kleiner plant (wie das bei Versionen der Fall ist).

Und nun kommen wir zu den Altlasten. In Windows 10 steckt jede Menge Alt-Code, teilweise in Form von DLL-Bibliotheksdateien. Die Build-Nummer wird aber zur Versionierung verwendet. Wenn man nun auf die Build 17000 springt, laufen die 16-Bit-Variablen (in der von mir vermuteten 14-Bit-Maskierung) über und beginnen die Zählung mit dem Hexadezimalwert 0x0268 – eine Build-Nummer die irgendwo bei Windows NT 3.51 verwendet wurde (dieses OS habe ich nie eingesetzt, bin bei NT 4.0 gestartet, und dürfte den meisten Blog-Lesern unbekannt sein).

Lange Rede kurzer Sinn: Microsoft hat jetzt wohl ein Problem, was Brandon Le Blanc nicht mit 140 Zeichen auf Twitter erklären kann. Aber er verweist ja auf diesen Beitrag bei insidewindows.net, wo jemand das Thema auseinander deriviert. Die haben eine Insider Build so gepatcht, dass diese mit der Versionsnummer 17000 im Kernel unterwegs ist und geschaut, was an Kollateralschäden auftritt. Ist natürlich in meinen Augen keine so wirklich gute Idee, weil man den Rattenschwanz an Implikationen so nicht abschätzen kann. Bestenfalls sieht man einige Kollateralschäden, schlechtesten Falls werden die Implikationen erst um drei Ecken sichtbar. Aber immerhin ist man schnell darauf gekommen, dass die Eingabeaufforderung unsinnige Werte für die Build zeigt:

(Quelle: insidewindows.net)

Die Hauptversion 'Windows 10' stimmt zwar und auch die Sub-Build. Aber bei der Buildnummer, wo die 17000 erwartet wird, steht die 0616 – die Folge des 14-Bit-Überlaufs. Das führt natürlich an allen Stellen (z.B. bei Updates) zu Kollisionen, weil es diese Build-Nummer bei Windows 10 offiziell nie gab.

Die Jungs bei insidewindows.net bearbeiten das Thema noch ein wenig in ihrem Artikel. Für mich war das Ganze aber nach den von mir getätigten obigen Überlegungen abgehakt (wenn mir kein Denkfehler unterlaufen ist). Microsoft ist mit Windows 10 und den Build-Nummern möglicherweise in eine Art eigenes 'Year 2K'-Problem gelaufen (für nicht Insider: es gab die Befürchtung, dass beim Wechsel von 1999 auf 2000 viele Software nicht mehr läuft, weil die mit den zwei letzten Ziffer der Jahreszahl operieren. Microsoft hat in Windows trickreiche Konstellationen geschaffen, um den Wechsel von 99 auf 00 zu bewerkstelligen).

Man wäre bei Microsoft zwar irgendwann in dieses Problem gerauscht – aber ohne Windows as a Service hätte es für Windows 11, 12 und was weiß ich gereicht. Für mich wird es jetzt spannend, ob und wie man das gelöst bekommt. Zeit hat man ja noch. Und eure Gedanken so?