Die wissen halt selber nicht, wie sie aus dem Dilemma kommen sollen, dass die alte Edge-Engine für die Einstellungsoberflächen notwendig ist, aber der Browser selber gefloppt ist und auf Chromium umgestellt wurde.
Nun muss man den Unterbau des alten Edge weiter mitschleppen, um die Einstellungsapp darzustellen. Zurückrudern geht jetzt nicht mehr und weiterbasteln ist umfangreicher, als man vermutet hatte.
Selbst die vollständige Umstellung von NT auf den neuen Win95-Desktop hat inklusive aller neuen Elemente(z.B. Gerätemanager)nur 4 Jahre gedauert(bis Windows 2000 erschien).
Die Render-Engine einer Benutzeroberfläche hat doch wenig mit deren Inhalt zu tun. Sowohl Edge als auch die alte IE-Engine als auch Chromium kann alles darstellen, was für eine Systemsteuerung nötig ist. In welchem Format Microsoft diese umsetzt, ist vollkommen egal. Das Problem ist, dass sie sie gar nicht umsetzen respektive nicht wissen, was sie eigentlich darstellen wollen.
Die meisten Informatiker gehen traditionell immer vom Binärsystem aus, wenn da von Bit oder Bytes die Rede ist, auch wenn da nur Prefixe aus dem Dezimalsystem stehen. Einzige wirkliche Ausnahme sind physikalische Aspekte, wie Datenübertragungsraten, wo man aber auch nicht mehr auf der logischen Ebene ist. Genormt wurde das ganze auch erst um den Jahrtausendwechsel, also nachdem es Jahrzehnte Usus war, da normale Dezimalprefixe zu nutzen.
So einfach ist es nicht. Microsoft schreibt ja nicht nur die falsche Einheit hinter Datenspeichergrößen, sondern Microsoft schreibt auch die falsche Zahl vor andere Angaben, die tatsächlich in binärer Stückelung auftreten, beispielsweise beim RAM: Wenn die Zahl "32.768" lautet, dann ist Microsofts "32.000" oder "32 k" die falsche Anzeige. Durch Runden könnte man noch auf "~33 k" kommen, Microsoft macht aber selbst aus 65.536 GiB ein "64 GB". Dabei kennt man Nachkommastellen sehr wohl, so werden 1.440 KiB zu "1,44 MB" – obwohl 1.474.560 Byte entweder "~1,41" MiB" oder "~1,47" MB sind, aber nie "1,44". Und nein, auch in anderen Zahlensystemen ist Microsofts Größenverschleierungssystem nicht naheliegend, sondern komplex: HEX 16.8000 (DEC 1.474.560) ist nicht im geringsten mit HEX 15.F900 (=DEC 1.440.000) verwandt und es gibt keinen einfachen Weg um von HEX 8000 (DEC 32.768) auf HEX 7D00 (DEC 32.000) oder HEX 0020 (DEC 32) zu kommen. Selbst im Binärformat, wo Größenordnungsänderungen eigentliche simple Bitshifts sind, muss man einen solchen nicht nur um eine "krumme" Anzahl von Stellen (BIN 1010) durchführen, sondern dann auch noch das letzte Bit wegwerfen, um von DEX 65.536 auf DEC 64 zu kommen.
Ich kann nur spekulieren, wie sich diese Firmentradition herausbilden konnte. Entweder hat man Ende der 70er Jahre in der Bay Area große Menge Hinterlassenschaften der 69er-Ära verbrauchen müssen oder da hat jemand die Buchhaltung optimiert. Ob es nun ein Angestellter war, der sein "32 k"-Jahresgehalt in 12× 2.730,67 USD hat auszahlen lassen oder ob Bill umgekehrt abgesprochene 32.768 USD als 32-durch-12-pro-Monat hinterlegt hat, bleibt offen. Aber wer auch immer diesen Code geschrieben hat, hatte (temporär) kein Interesse an korrekten Ausgaben und wer auch immer das mitgemacht hat, hatte (temporär) kein Verständnis für Grundrechenarten. Und alle anderen haben bis heute den Salat.