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.


Anzeige

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.

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.

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

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


Anzeige

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:

Eingabeaufforderung mit falscher Build
(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?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

8 Antworten zu Windows 10: Build-Nummern und der Fluch der Vergangenheit

  1. Nobby1805 sagt:

    Da fehlt wohl etwas in der Erläuterung …

    Die Zahl 17.000 steht für den Hexadezimalwert 0x4268. Da kommt mir sofort der Hexwert 0x3FFF in den Sinn, die größte mit 16 Bit darstellbare Zahl. Der Hexadezimalwert 0x4268 lässt sich mit 16 Bit nicht mehr darstellen.

    Nicht 0X3FFF ist der größte mit 16 Bit (signed) darstellbare Wert sondern 0X7FFF

    • Günter Born sagt:

      Du hast Recht – es scheint, als ob die nur 14 Bit verwenden. Binär wird's klarer (hätte ich tun sollen, dann wäre es mir aufgefallen):

      0011 1111 1111 1111 = 0x3FFF
      0111 1111 1111 1111 = 0x7FFF
      1111 1111 1111 1111 = 0xFFFF

      Ich habe das im Text angepasst – wobei ich mir jetzt die Frage stelle, warum die offenbar auf die 14 Bit maskieren?

  2. Robert Richter sagt:

    Die guten Leute scheinen schon längst Microsoft verlassen zu haben (oder sind im Ruhestand). Bei der Generation, die jetzt Code schreibt, kann man nur noch hoffen, dass man selbst bald in den Ruhestand gehen kann.

    Früher hatten Sie viel weniger Probleme, bzw. viel schneller Lösungen parat. Und bei der Code-Qualität, die heutzutage abgeliefert wird, reden manche über selbstfahrende Autos. Mir wird schlecht…

    • Günter Born sagt:

      Na ja, man muss fairerweise sagen, dass Windows schon ein riesiges Projekt ist. Aber mir ist unverständlich, warum man immer noch auf Uralt-Code und -Konzepte zurückgreift.

      • ich kann es mir nur so vorstellen das der Uralt Code immer noch im System steckt und der wahrscheinlich erst neu geschrieben werden müsste.

        Das ist genauso wie mit den Adobe Flash über Jahrzehnte hinweg weiterentwickelt und nie hat jemand daran gedacht einfach das dumme Ding abzuschaffen mittlerweile sind damit 100 Milliarden verdient worden und steckt halt über all drinnen…

      • Al CiD sagt:

        Da ja wohl alles ineinander verschachtelter Code sein dürfte, weswegen meist auch ein noch so kleiner Patch zig Dateien und eine Menge an Datenverkehr einschließt, lassen die Entwickler es irgend wie laufen… bloß nicht aus dem Gleichgewicht bringen.

        Hätte MS doch schon vor Jahren die alten Zöpfe abgeschnitten und nicht auf Teufel komm raus die Kompatibilität in den Vordergrund gestellt.

        Es gab ja mal so ein Projekt von MS, komm nur nicht mehr auf den Namen…

        • Günter Born sagt:

          "Es gab ja mal so ein Projekt von MS, komm nur nicht mehr auf den Namen…"

          Das Ding hieß Midori, war für Parallelprogrammierung ausgelegt und sollte Windows ablösen. Ist aber 2015 versandet, nachdem Windows 10 heraus kam. Mary Foley hat hier einige Infos zum Projektende von Projektbeteiligten rausgelassen – so sollen einige Erkenntnisse in bestehende Produkte einfließen.

          • Al CiD sagt:

            Yep… danke für den Link und die Auffrischung.

            Besonders der letzte Teil ist (leider) erwähnenswert:
            "My biggest regret is that we didn't OSS (open source) it from the start, where the meritocracy of the Internet could judge its pieces appropriately," Duffy added. "As with all big corporations, decisions around the destiny of Midori's core technology weren't entirely technology-driven, and sadly, not even entirely business-driven. But therein lies some important lessons too."

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.