Seit Windows 10 gibt es für Windows regelmäßige Updates auf neuere Windows-Builds, die im Prinzip eher Upgrades sind.
Es wird im Hintergrund ein neues Windows installiert und dann werden automatisch Programme und Einstellungen in dieses neue System migriert. Das alte System bleibt als „Windows.old“ noch einige Tage zur Vorsicht auf der Disk und wird dann automatisch abgeräumt. Auch Windows 11 fand bei vielen Leuten durch ein Upgrade den Weg auf die Disk und wurde seitdem schon mehrfach aktualisiert.
Aber wie oft wurde das aktuell installierte System eigentlich schon auf diese Weise auf eine neue Version umgestellt?
Windows hält die Historie der Installation in der Registry fest. Startet man regedit, findet man unter HKEY_LOCAL_MACHINE\SYSTEM\Setup für jedes Upgrade einen Schlüssel, der mit „Source OS“ anfängt. Hier hält Windows die Version fest, die vor einem Upgrade auf dem Gerät installiert war.
Das System aus meinem Beispiel wurde also zum ersten Mal am 17.10.2017 von der Windows 10 Version 1703 aus aktualisiert, dann am 4.04.2018 das nächste Mal von der Version 1709 aus und so weiter. Bis zur aktuellen Windows 11 Version, die den Weg am 5.10.2024 aufs Gerät fand.
Die Infos sind nicht wirklich relevant, aber manchmal mag es ja ganz interessant sein, einen Blick in die Historie zu werfen.
Ja, das kleine VarioPro Convertible lebt immer noch, man glaubt es kaum. Beim letzten Mal hatte ich ja beschrieben, wie man Ubuntu installieren kann.
Mittlerweile habe ich festgestellt, dass es noch einen viel einfacheren Weg gibt: Fedora!
Mit Fedora Linux kommt passenderweise gleich der 32-bit EFI Bootloader mit. Man braucht also nichts vorzubereiten, sondern nimmt einfach einen USB-Stick mit dem aktuellen Fedora Image – in meinem Fall den KDE Spin – und installiert los.
Spannenderweise funktioniert damit auch der Sound sauber, der bei Ubuntu so seine Probleme hatte. Und das interne WLAN-Modul ist zwar weiterhin nicht toll, funktioniert aber grundsätzlich.
Die Performance ist natürlich mies, egal ob man nun GNOME oder KDE verwendet. Mit einem etwas leichtgewichtigeren Desktop könnte man evtl. noch ein wenig mehr Geschwindigkeit rausholen.
Zum Ende des Jahres kommen ja überall die Jahresrückblicke. Das hier soll keiner werden, aber das letzte Posting hier ist schon ein gutes Jahr her und somit ist einfach mal wieder ein Lebenszeichen notwendig.
Das Jahr war voll gepackt. Viel Arbeit, ein familiärer Trauerfall, diverse kleine und große Veränderungen. Da fehlte dann irgendwo die Zeit und Lust für Blog-Einträge. Zudem gibt es ja auch diverse andere gute Blogs und Seiten, so dass ich auch nicht all das noch einmal schreiben muss, was anderswo schon steht.
Und viel hat sich in der IT-Welt auch nicht verändert. Es wird weiterhin jedes kleine Windows-Problem zur Katastrophe erklärt, egal wie viele Leute es betrifft. Und es wird weiterhin jedes neue Apple Gadget gehypt, egal wie viele Leute es am Ende kaufen. Und, nicht zu vergessen, nächstes Jahr ist auf jeden Fall das Jahr von Linux auf dem Desktop!
Ich werde von Freunden und Kollegen immer mal wieder drauf angesprochen, dass sie über einen Blog- oder Foren-Beitrag von mir gestolpert sind. Und manchmal ging mir das selbst so. Ja, auf der Suche nach der Lösung eines Problems bin ich immer mal wieder auf eigenen Beiträgen mit den entsprechenden Lösungsansätzen gelandet. Das Blog dient also auch für mich dazu, Dinge festzuhalten, um selbst noch mal wieder drauf zugreifen zu können.
Insofern wird es hier in Zukunft hoffentlich wieder regelmäßiger Beiträge geben. Genug Material ist sicherlich da. Die heimische Server-Welt wurde umgebaut, alte PCs auf neue Betriebssysteme umgestellt. Da wird sicherlich noch der eine oder andere Artikel bei anfallen.
Und keine Angst, einen richtigen Jahresrückblick verkneife ich mir auch dieses Jahr!
Microsoft beglückt die Nutzer seiner Systeme ja immer mal mit mehr oder weniger passenden Neuerungen in Form von zusätzlichen Apps. In den letzten Wochen tauchte auf diversen Systemen die App „Microsoft DevHome“ auf.
DevHome ist somit eine Anwendung für Software-Entwickler. Warum Microsoft die App an normale Nutzer verteilt, wird wohl deren Geheimnis bleiben. Warum sie als Systemkomponente gilt und somit nicht einfach per Rechtsklick deinstalliert werden kann, ist aber schlicht unverständlich.
Als Lösung dient eine Kommandozeile als Administrator gestartet und folgender Befehl:
winget uninstall Microsoft.DevHome
Danach ist das Paket verschwunden und kommt hoffentlich auch nicht wieder.
Vor einigen Jahren hatte ich hier ja mal im Blog über das kleine ODYS Convertible berichtet. Das Gerät lebt immer noch und fristet mangels der minimalen Hardwareausstattung allerdings ein eher klägliches Dasein. Also warum nicht etwas basteln und mal ein Linux drauf ausprobieren? Könnte ja vielleicht besser funktionieren, als das doch etwas sehr zähe Windows 10.
Problem ist halt auch hier das 32-bit EFI. Die CPU selbst ist eine 64-bit fähige CPU, aber zum Booten braucht es einen 32-bit Bootloader. Für Windows bedeutet das, dass nur ein 32-bit Windows 10 verwendet werden kann. Bei Linux geht allerdings auch ein 64-bit System. Man muss es nur zum Booten bringen.
Wir brauchen nur wenige Dinge:
Unser Notebook
Eine Linux Distribution als ISO-Image, im Beispiel ein Ubuntu 22.04 LTS
Einen 32-bit EFI Bootloader
Einen USB-Stick zur Installation
Einen USB-WLAN- oder -LAN-Adapter
Ein wenig Geduld… 😉
Bei meinen Tests wurde der verbaute WLAN-Adapter nicht erkannt oder, wenn er denn mal auftauchte, konnte er keine Verbindung herstellen. Ich habe daher einen USB-WLAN-Adapter im Micro-Format verwendet. Der verwendete Zyxel USB-WLAN-Adapter verwendet einen Realtek Chipsatz und wird vom Linux Kernel direkt unterstützt.
Auf den USB-Stick wird die ganz normale Linux-ISO geschrieben. Das kann unter Linux selbst per dd passieren oder unter Windows per Rufus.
Die Datei bootia32.efi wird nun auf dem USB-Stick in den Ordner \EFI\boot kopiert. Dort liegen schon die bestehenden Bootloader und unser Loader fürs 32-bit EFI kommt einfach dazu. Schon ist der Stick bootfähig und wird ans VarioPro gesteckt.
Ich habe die Erfahrung gemacht, dass dazu am besten die linke USB-Buchse verwendet wird. Diese kennt nur USB 2.0. An der rechten USB 3.0 Buchse wurde mein Stick nicht zum Booten erkannt.
Beim VarioPro kommt man ins Bootmenü, indem man nach dem Anschalten wild die Esc-Taste drückt, bis ein Menü auftaucht. Hier muss nun zuerst SecureBoot deaktiviert werden. Der 32-bit EFI Bootloader ist nicht signiert und damit würde er bei aktivem SecureBoot nicht gestartet werden.
Nachdem SecureBoot aus ist, kann man im Boot-Menü des VarioPro den USB-Stick als Bootmedium auswählen. Und man glaubt es kaum, das System bootet. War noch gar nicht so schwer.
Im grub Bootmenü kann nun die Installation des Linux Betriebssystems ausgewählt werden. Die Installation lässt sich ganz normal durchführen. Ich würde zuerst mal die Minimal-Installation wählen. Fehlende Pakete lassen sich hinterher ja problemlos nachinstallieren. Beim Installationsziel sollte man die gesamte interne Disk angeben und nicht versuchen, Linux neben Windows zu installieren. Das passt nicht wirklich.
Die Installation selbst läuft dann eine gewisse Zeit und nebenbei darf man sein Benutzerkonto einrichten und dem Gerät einen Namen geben. Ist die Installation abgeschlossen, darf man auswählen, das Gerät neu zu starten. Die Meldung, den USB-Stick zu entfernen, sollte man einfach ignorieren. Wir müssen jetzt noch einmal vom Stick booten!
Also beim Neustart wieder wild auf die Escape-Taste hämmern und erneut im Boot-Menü den Stick auswählen. Nun landen wir wieder im grub Menü und drücken hier einmal die Taste „c“, um auf der Kommandozeile von grub zu landen.
Was ist das Problem? Nun, wir haben zwar vom Stick im 32-bit EFI-Modus booten können, aber unser installiertes System weiß davon nichts. Leider ist Ubuntu nicht raffiniert genug, um das festzustellen. Wir müssen also noch ein paar Pakete nachinstallieren. Aber dazu müssen wir zuerst mal unser installiertes System booten.
An der grub Kommandozeile gibt man dazu folgende Kommandos ein:
linux (hd1,gpt2)/boot/vmlinuz-5.19.0-38-generic root=/dev/mmcblk2p2
initrd (hd1,gpt2)/boot/initrd-5.19.0-38-generic
boot
grub beherrscht hier die automatische Vervollständigung der Kommandozeile. Wenn man also nicht genau weiß, welche Kernel-Version installiert ist, gibt man linux (hd1,gpt2)/boot/vm ein und drückt einmal die Tab-Taste, um die Auswahl dazu zu bekommen. Dann ergänzt man die entsprechende Zeile.
Selbiges gilt für die initrd-Zeile. Auch hier kann man die verwendete initrd einfach mit Tab komplettieren. Das Boot-Kommando startet dann das installierte System, wenn man alles richtig getippt hat.
Ist das System gestartet, sollte man den USB-Stick abziehen. Nun können wir die notwenigen Komponenten nachinstallieren. Dazu wird ein Terminal geöffnet und dann werden folgende Befehle eingegeben:
Damit werden die 32-bit EFI Komponenten für grub nachinstalliert, und im System installiert. Nun kann man das System noch einmal neu starten und es sollte ganz normal das installierte Linux booten.
Ich habe ein wenig mit Ubuntu 22.04 auf dem VarioPro herumgespielt und es ist zumindest nutzbar. Natürlich wird aus der Hardware kein Rennpferd, aber alle grundsätzlichen Funktionen scheinen soweit zu funktionieren, mit Ausnahme des erwähnten WLAN-Adapters. Es sind hier etwa 16 GB freier Speicherplatz verfügbar, insofern ist Ubuntu also etwas schmaler auf der Disk, was bei den viel zu kleinen 32 GB eMMC Speicher sicherlich nicht verkehrt ist.
Die Anleitung lässt sich mit leichten Anpassungen bei der Angabe der Partitionsnamen auch für andere CherryTrail Tablets/Convertibles mit 32-bit EFI nutzen.
Viel Erfolg beim Ausprobieren!
Nachtrag vom 15.04.:
Nun fallen mir doch noch ein paar Dinge auf, die ich nachträglich ergänzen möchte.
Einerseits funktioniert die Webcam nicht. Beim Booten wird gemeldet, dass die binäre Firmware dafür fehlen würde. Lädt man diese herunter und kopiert sie in den gewünschten Ordner, funktioniert nach dem Neustart die Kamera weiterhin nicht. Stattdessen crasht im Hintergrund einiges. Also Firmware-Datei schnell wieder gelöscht und auf die Webcam verzichtet.
Und der oben erwähnte USB-WLAN-Adapter funktioniert doch nicht „out of the box“. Warum ich zwischendurch mal Funknetze gesehen habe, kann ich grad nicht nachvollziehen. Vielleicht war da doch irgendwie der integrierte WLAN-Chip aktiv? Keine Idee.
Für meinen oben erwähnten USB-WLAN-Adapter mit Realtek RTL8812BU Chipsatz finden sich die Treiber hier: https://github.com/morrownr/88x2bu-20210702 Die Installation ist dort auch für Laien gut nachvollziehbar beschrieben.
Und gleich noch eine Ergänzung, der Sound macht nämlich auch so ein paar seltsame Mucken. Nach ein bis zwei Minuten hört man statt Musik nur noch ein infernalisches Piepen. Workaround ist der Eintrag folgender Zeile am Ende der Datei /etc/modprobe.d/alsa-base.conf
options snd-intel-dspcfg dsp_driver=2
Auch damit taucht hier noch keine Möglichkeit zur Regelung der Lautstärke auf. Aber ich will ja auch in der Zukunft noch etwas zum Basteln haben…
Die meisten Menschen verbinden Microsoft Windows mit Prozessoren der Firma Intel, manchmal wird sogar von „Wintel“ gesprochen, um die über Jahre enge Verbindung des Betriebssystems zu den Prozessoren darzustellen. Natürlich soll auch AMD nicht vergessen werden. Deren AMD64-Erweiterungen zu den klassischen Intel x86 Befehlen und die damit gebauten Prozessoren sind heute das, was wir allgemein als typische 64-bit Prozessoren im PC-Umfeld ansehen.
Prozessor-Architekturen können nicht einfach Programme ausführen, die für eine fremde Architektur entwickelt wurden. Ein Betriebssystem, welches auf anderen Prozessor-Architekturen funktionieren soll, muss dementsprechend dafür angepasst und der Quellcode neu übersetzt werden. Je systemnäher eine Software arbeitet, desto mehr Anpassungsaufwand ist notwendig.
Mit der Windows 10 Version 1709 von vor fünf Jahren brachte Microsoft ein Windows 10 mit Unterstützung für CPUs mit ARM-Architektur heraus. ARM ist kein Hersteller von Prozessoren, sondern entwickelt Designs von Prozessor- und Grafikkernen. Diese Designs werden an Hersteller lizensiert, die die Prozessoren dann in der von ihnen gewünschten Zusammenstellung selbst fertigen. Die meisten Hersteller von ARM-basierenden Chips arbeiten so, z.B. Qualcomm, Samsung oder Nvidia.
Alternativ kann man bei ARM auch eine komplette Entwickler-Lizenz ordern und dann auf Basis der ARM-Designs die Komponenten selbst weiterentwickeln. Ein aktuelles Beispiel dafür ist Apple. Deren M1 und M2 Chips basieren zwar auf Designs von ARM, nutzen aber nicht die fertigen Rechen- und Grafikkerne von ARM.
Ein wenig Geschichte
Obwohl Windows immer mit der x86-Architektur verbunden wurde, gab es auch schon vor 2017 immer wieder Windows-Versionen, die auf anderen Architekturen liefen. Windows PDAs und Handys liefen mit Windows CE und Windows Phone auf verschiedenen ARM, MIPS und RISC Architekturen. Das „große“ Windows selbst auch auf DEC Alpha und PowerPC, teils nur in Server-Versionen. Auch Intels glücklose IA-64 (Itanium) Plattform hatte ihre eigene Windows-Version. Dabei waren ebenfalls wieder Server das Ziel. Durchgesetzt hat sich beim PC allerdings immer wieder die x86-Architektur.
Im Jahr 2012 gab es dann die erste Annäherung eines für den typischen Normalnutzer gedachten Windows an die ARM-Plattform. Das erste Surface Tablet mit Windows RT wurde präsentiert. Windows RT wurde die für 32-bit ARM CPUs gedachte Windows 8 Version genannt. Die Tablets basierten auf einem ARM32 Design mit Nvidia Tegra Chip und waren, anders als ihre „Surface Pro“ Geschwister, in Sachen Hardwareausstattung eher limitiert.
Eine weitere, große Limitierung gab es allerdings, die das Projekt am Ende scheitern ließ: Windows RT konnte nur Apps aus Microsofts Store installieren. Und das nur, wenn sie dort auch als 32-bit ARM Version vorlagen. Nachdem Microsoft damals im Store keine anderen Browser-Engines zuließ (ähnlich wie Apple es bis heute generell macht), war der Internet Explorer somit der einzig nutzbare Browser. Und nachdem Microsoft damals auch nur als App entwickelte Programme im Store zuließ und keine klassischen Programme, war die Software-Auswahl immer arg begrenzt. Opensource-Entwickler brachten zwar ein paar ARM32 Versionen bekannter Programme heraus, diese mussten aber durch Umgehung von Sicherheitsfunktionen und Store installiert werden. Alles in allem ein ziemlicher Flop.
Upgrades auf neuere Windows-Versionen sind technisch nicht möglich, auch wenn es Bastelprojekte mit Windows 10 Mobile Builds auf Surface RT Geräten gibt. Aber immerhin läuft der Support von Windows RT 8.1 mit Sicherheitsupdates noch bis Januar 2023. Auch wenn die Geräte mittlerweile quasi unbenutzbar sind, sind sie dabei immerhin sicher.
Windows on ARM
2017, beim nächsten Versuch mit „Windows on ARM“, wollte man dann alles besser machen. Und vieles davon wurde auch besser. Windows 10 Version 1709 erschien als Home oder Pro Version für ARM-Systeme. Es gibt keine Beschränkung auf Apps aus dem Store, auch wenn viele Systeme mit Windows im „S-Mode“ mit Store-Beschränkung ausgeliefert werden, welche man allerdings beenden kann.
Qualcomm Snapdragon
Viel wichtiger: Microsoft hat eine Emulation eingebaut, mit der sich Programme laufen lassen können, die an sich für die x86-Architektur erstellt wurden. Damit sollten zumindest viele der gewohnten Programme laufen. Wenn auch in der Performance möglicherweise etwas eingeschränkt, denn eine Emulation kostet halt Leistung. Bei Windows 10 beschränkte sich diese Emulation außerdem nur auf reine x86-Programme, d.h. ausschließlich auf 32-bit Software. 64-bit x86 Software funktioniert nicht. Eine entsprechende Erweiterung, um auch diese emulieren zu können, kam erst 2021 mit Windows 11. Damit laufen viele Programme, aber lange nicht alle.
Die Hardware
Unterstützt wurden und werden bisher ausschließlich Prozessoren des Herstellers Qualcomm. Dieser leitet die Chips bisher von seinen Chips für Smartphones ab. Die Versionen für Windows-Geräte bringen dann etwas höhere Taktraten, da sie sich einfacher als im kleinen Smartphone-Gehäuse kühlen lassen können.
Der erste Chip 2017 war der Qualcomm Snapdragon 835, eine etwas angepasste Version des Snapdragon 830. Der Chip bietet acht Kerne ohne zusätzliche Techniken wie Hyperthreading. Werden all diese Kerne gleichzeitig genutzt, ist die Performance überraschend gut, allerdings ist ein einzelner Kern eher langsam. Software, die nur einen Kern nutzt, wirkt somit auf den Geräten ausgesprochen lahm. 4 bis 8 GB RAM sind möglich. Der Adreno Grafikkern unterstützt DirectX 12 und 4K Videoformate. Ein LTE-Modem ist integriert und ermöglicht damit auch mobilen Zugriff aufs Internet per SIM-Karte. All das ist in den Geräten passiv gekühlt, d.h. kein Lüfter stört.
Asus Novago TP370QL
Interessanterweise war Microsoft nicht zuerst mit einem eigenen Gerät vertreten, sondern überließ dies seinen OEM-Partnern, wie z.B. ASUS. Diese brachten Notebooks und Convertibles mit Snapdragon 835 und seinem Nachfolger 850 auf den Markt. Die erste Generation mit Snapdragon 835 hat dabei einen großen Nachteil: die CPU unterstützt keine Virtualisierungsfunktionen, die Microsoft aber mittlerweile für Windows 11 voraussetzt und ist daher nicht auf der Liste der kompatiblen CPUs fürs Windows-11-Upgrade.
Später kam auch noch Samsung mit eigenen Notebooks dazu, die allerdings keine Samsung-eigene CPU verwendeten (mit den Exynos Chips ist Samsung ja selbst CPU-Entwickler), sondern ebenfalls Qualcomms Chips. Weitere CPU-Hersteller sind bisher nicht von Microsoft genannt worden.
Microsofts eigenes Surface Tablet auf ARM-Basis kam erst relativ spät dazu. Das Surface Pro X verwendet angeblich einen Microsoft-eigenen Chip namens SQ-1, welcher letztlich aber auch nur ein umgelabelter Qualcomm-Chip ist. Der im zweiten Modell verbaute SQ-2 ist zudem eine ziemliche Nullnummer, denn außer der Bezeichnung hat sich am Chip selbst wohl nichts wirklich geändert.
Die aktuellste Ausgabe ist der Qualcomm Snapdragon 8cx Gen 3. Dieser ist im Vergleich zu den alten Snapdragon Chips deutlich schneller, ziemlich effizient, kommt aber in Sachen Performance weiterhin nicht an Intel oder AMD heran. Und auch wenn man mit Apples Chips vergleicht, sieht es da weiterhin etwas dünn aus.
Die Software
Nach dem Erscheinen von Windows 10 für ARM tat sich zuerst einmal wenig in Sachen nativer Software, d.h. Software, die direkt für ARM64 Systeme kompiliert wurde. Auch Microsoft selbst zeigte sich zuerst nicht von seiner besten Seite. Selbst die mit Windows mitgelieferten Programme waren nicht allesamt ARM64-Versionen, sondern manches lief in der Emulation.
Selbst bei Windows 11 hat sich das noch nicht 100%ig geändert. Teils findet man dort in den Release-Notes für neue Preview-Versionen, dass nun auch einzelne weitere Tools nativ als ARM64-Version vorliegen.
Microsofts Entwicklungsumgebung Visual Studio konnte anfangs nicht ohne weiteres Software für ARM64 kompilieren. Und auch Projekte, wie der auf der Chromium Engine basierende Microsoft Edge Browser, kamen erst später für ARM64.
Mittlerweile hat sich die Situation ein wenig verbessert und z.B. Edge und Firefox sind als native ARM64-Versionen verfügbar. Um Google Chrome sollte man somit einen großen Bogen machen, da dieser nur in der Emulation läuft.
Windows 10 ARM Systeminfo
Einige Opensource-Programme wie Notepad++, Handbrake oder Microsofts Visual Studio Code sind nativ verfügbar. Auf andere wie z.B. den VLC Player muss man weiterhin warten. Kommerzielle Anwendungen finden sich bei manchen Entwicklern, z.B. ist mittlerweile Adobe Photoshop als ARM64-Version verfügbar. Das Interesse bei vielen Entwicklern an Windows on ARM ist aber weiterhin eher flau.
Microsofts Office selbst läuft in einer speziellen Hybrid-Version. Die auf Windows 10 ARM installierte Office-Version ist an sich eine x86-Version, verwendet allerdings an einigen Stellen ARM-Befehle. Sie fühlt sich damit fast wie nativ an. Vorteil dieser Konstellation: jegliche Add-Ins für die Office-Programme müssen nicht erst für ARM64 neu kompiliert werden, sondern stehen in der Emulation als x86-Version bereit.
Mit Windows 11 on ARM hat man das Verfahren noch etwas verfeinert. Hier kommt eine Technik namens ARM64EC dazu, die es einfach ermöglichen soll, x64 Anwendungen auch für ARM64 zu optimieren.
Ich bin kein Entwickler und kann daher nicht beurteilen, wie interessant das Thema für Entwickler werden könnte.
In der Praxis
Die bisherigen Windows on ARM Geräte waren immer mit Einschränkungen verbunden. Neben der Emulation vieler Programme finden sich viele der Geräte in recht hohen Preisbereichen trotz eher geringer Leistung.
Das ASUS NovaGo TP370QL, eines der ersten Geräte auf dem deutschen Markt, startete in der Preisklasse von Notebooks mit Intels Core i5, welche in Sachen Performance und Kompatibilität locker Kreise um das ARM-Gerät rannten.
Viele der Geräte wurden 2017 nur mit 4 GB RAM verkauft. Das war damals schon arg knapp und ist es heute natürlich umso mehr. Wer heute eines der Geräte sucht, sollte auf jeden Fall eines mit mehr als 4 GB RAM wählen. Samsung hat es leider geschafft, das 2021 veröffentlichte Galaxy Book Go ausschließlich in einer Version mit 4 GB RAM auf den Markt zu bringen. Unverständlich, auch wenn das Gerät als günstiger Einstieg dienen soll und aktuell eines der preiswertesten Windows on ARM Geräte ist.
Windows 10 ARM Taskmanager
Native Software läuft auch auf den Geräten der ersten Generation performant. Damit kommt dann auch einer der großen Vorteile der Plattform zu Tage: die Akkulaufzeit. Die meisten der Windows on ARM Geräte laufen locker zwei komplette Arbeitstage auf Akku.
Das ASUS Gerät spielt beispielsweise 22 Stunden Video ab. Allerdings kann die erste Generation noch kein HEVC in Hardware dekodieren. Man sollte also bei H.264 Inhalten bleiben, wenn man auf die 22 Stunden kommen möchte.
Treiber
Alle notwendigen Treiber für die Geräte kommen ausschließlich über Windows Update. Auch eventuelle Firmware-Updates werden darüber verteilt.
Leider ist Qualcomm recht faul, was die Pflege der Treiber für existierende Geräte angeht. Für die 2017 erschienenen ersten Geräte gab es 2018 noch mal ein Update des Grafiktreibers und seitdem nichts. Da insbesondere die Grafiktreiber nicht 100%ig stabil sind, ist das unbefriedigend.
Bei den Surface Pro X sieht die Sache besser aus. Hier macht Microsoft wohl entsprechend Druck bei Qualcomm – oder zahlt entsprechend mehr.
Für alle Geräte, die an ein Windows on ARM Gerät angeschlossen werden, braucht man entsprechende ARM64-Treiber, solange die Geräte nicht mit Standardtreibern von Windows funktionieren. Tastaturen, Mäuse oder Webcams sind somit kein Problem, aber bei einem Multifunktionsdrucker muss man vorab schauen, ob der Hersteller des Druckers entsprechende Treiber anbietet.
Im Zweifelsfall muss man die Hardware einfach mal anschließen und schauen, ob Windows Update passende Treiber ausspuckt. Bei vielen Komponenten ist das der Fall. So wurde z.B. hier ein USB-Dock mit DisplayLink Chipsatz ganz von alleine installiert. Auch der vorhandene HP Drucker druckt ohne Schwierigkeiten.
Je ausgefallener die Hardware, desto schwieriger dürfte es werden, ARM64-Treiber für Windows zu bekommen.
Windows-Installation und Recovery
Die Windows on ARM Geräte booten, anders als Android-Geräte, über ein normales UEFI. Es gibt allerdings kein typisches UEFI-Setup. Meist lässt sich durch das Drücken der Laustärke-Tasten beim Anschalten des Gerätes ein Boot von einem USB-Medium starten oder ein einfaches Einstellungsmenü öffnen.
Es gibt keine Windows-Installationsmedien für ARM64 bei Microsoft zum Download. Auch das Media-Creation-Tool oder sonstige Updater-Tools von Microsoft gibt es nicht für ARM64.
Zur Neuinstallation braucht man zwingend ein Wiederherstellungsmedium des Geräte-Herstellers.
Microsoft bietet für seine Surface Pro X Recovery-Medien zum Download an. Die anderen Hersteller machen das nicht unbedingt. Wer z.B. das schon öfter genannte ASUS-Gerät nutzt, hat keine Chance zur Neuinstallation, denn ASUS bietet keine entsprechenden Downloads an.
Man sollte sich also unbedingt vom laufenden Gerät aus ein Wiederherstellungsmedium über die entsprechenden Windows-Funktionen erstellen und weglegen. Ohne ist man im Ernstfall aufgeschmissen.
Die Zukunft
Aktuell erscheinen selten neue Geräte mit ARM CPU für Windows. Das Lenovo X13s wäre das einzige momentane Highlight in dieser Richtung. Lenovo packt Qualcomms neuste Snapdragon 8cx Gen 3 CPU in ein 13″ ThinkPad Gehäuse. Lüfterlos, mit Wifi 6E und 5G sowie den üblichen Business-Funktionen.
Microsoft selbst soll das nächste Surface Pro grundsätzlich mit der Auswahl zwischen Intel und Qualcomm CPU planen. Das ist aber bisher nur Gerüchteküche.
Aktuell sieht es nicht so aus, als würde Windows on ARM schnell wieder verschwinden. Es sieht allerdings auch nicht so aus, als würde es der große Erfolg werden, von dem insbesondere Qualcomm träumt.
Fazit
Windows läuft mittlerweile ganz selbstverständlich auf Geräten mit ARM-Architektur. Allerdings gibt es wenig Gründe, beim Kauf nun unbedingt auf ein solches zu setzen.
Wer ein lüfterloses Gerät mag, mit Microsoft Office, Edge-Browser und den vorhandenen nativen Programmen zurechtkommt sowie ein entsprechendes Gerät günstig bekommt, der kann zugreifen.
Wer mehr Leistung möchte und die komplette Bandbreite der für Windows verfügbaren Anwendungen nutzen will, der kommt an einem Gerät mit Intel- oder aktuell besser AMD-CPU nicht vorbei.
In den letzten Tagen ging mal wieder in teils marktschreierischer Art und Weise eine angebliche Sicherheitslücke in Microsofts Windows Defender Antivirensoftware durch alle möglichen Kanäle. Da titeln Seiten von „peinlichen Sicherheitslücken“ oder verweisen darauf, dass das Problem schon seit acht Jahren bestünde und nun endlich entdeckt worden wäre.
Aber worum geht es überhaupt und was genau ist jetzt die Lücke? Beziehungsweise, gibt es überhaupt eine Lücke?
Ausnahmen
In jeder Antivirensoftware lassen sich Ausnahmen definieren. In den Einstellungen des Windows Defender unter Windows 10 und 11 lassen sich hier folgende Kategorien in der grafischen Oberfläche ausnehmen:
Einzelne Dateien können ausgenommen werden, wenn diese z.B. regelmäßig Fehlalarme produzieren. Ganze Ordner lassen sich ausnehmen, beispielsweise um diverse Programme für Sicherheitstests in einem Ordner nicht einzeln ausklammern zu müssen. Oder ganze Dateitypen wie DWG oder MDB lassen sich ausnehmen, wenn beispielsweise die Dateien eines CAD-Programmes keine aktiven Inhalte enthalten können und es daher nicht lohnt, diese zu scannen.
Diese Ausnahmen gelten für den Echtzeit-Scan, d.h. für die ständig im Hintergrund aktive Überwachungsfunktion, sowie für geplante Scans, die zeitgesteuert die Disk scannen.
Zudem lassen sich Prozesse ausnehmen. Ich kann beispielsweise die Programmdatei eines CAD-Programmes als Prozess ausnehmen. Damit ignoriert der Defender bei der Echtzeit-Überprüfung alle Dateien, die dieses CAD-Programm liest oder schreibt.
Standardmäßig sind auf einem Windows-PC keine Ausnahmen von Haus aus definiert. Die Liste ist also leer.
Auf einem Windows-Server definiert Microsoft verschiedene Standard-Ausnahmen, die in der Liste im Defender allerdings nicht auftauchen. Sie sind allerdings hier auf der Microsoft Webseite dokumentiert.
Gefahren bei Ausnahmen
Wenn ich eine Ausnahme für einen Ordner definiere, auf den ein normaler Benutzer Schreibzugriff hat, kann dieser normale Benutzer Dateien speichern und ausführen, ohne dass der Virenscanner eingreift.
Gebe ich, wie im Screenshot gezeigt, einfach den kompletten Dokumente-Ordner des Benutzers frei, ignoriert der Defender diesen Inhalt ab sofort. Ein normaler Nutzer könnte somit hier problemlos Schadsoftware abspeichern und ausführen.
Solch eine Ausnahme wäre also arg problematisch! Ausnahmen im Antivirenprogramm sollten immer nur für vertrauenswürdige Prozesse eingerichtet werden oder für Ordner, in denen eben nicht jeder einfach mit Benutzerrechten schreiben kann.
Im heimischen Umfeld ist das eher irrelevant, denn in den meisten Fällen ist die Person vor dem PC auch Administrator. Möglicherweise nicht mit dem selben Konto, aber in Person. Heißt, eine heruntergeladene Software wird halt meist eh mit administrativen Rechten installiert. Man muss demnach als Entwickler von Schadsoftware den Benutzer nur von der Installation überzeugen, aber keine Lücken finden.
In Firmen, wo der Defender zentral verwaltet wird, sollten Administratoren aber immer genau drauf achten, was für Ausnahmen definiert werden, um keine „Löcher“ zu schaffen, die ein Benutzer – oder möglicherweise eine Schadsoftware, die im Namen des Benutzers ausgeführt wird – ausnutzen könnte.
Ausnahmen sollten somit immer mit Vorsicht eingesetzt werden, denn sie können gefährliche Löcher schaffen.
Die „Sicherheitslücke“
Windows Defender speichert die Ausnahmen in der Registry.
Unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions finden sich die einzelnen Unterordner mit den jeweils gesetzten Ausnahmen.
Diese Liste in der Registry kann nur mit Administratorrechten bearbeitet werden. Allerdings kann man sie unter Windows 10 mit normalen Benutzerrechten lesen. Dies wird von manchen Sicherheitsforschern als Problem angesehen.
Nehmen wir also mal wieder den ganz normalen PC. Ein normaler Benutzer lädt eine bösartige Software herunter. Der Defender erkennt sie noch nicht, da sie brandneu ist und die entsprechenden Funktionen des Defenders zum Blocken unbekannter Software nicht genutzt werden. Diese Software wird ausgeführt vom Benutzer und läuft damit mit seinen Benutzerrechten. Diese Software könnte nun aus der Registry auslesen, welche Ordner im Defender vom Scan ausgenommen wurden. Und falls dabei ein Ordner ist, der für den Benutzer beschreibbar ist, könnte sie sich dort hin kopieren und würde dort nicht weiter entdeckt werden.
Und da kommen wir zum Punkt: wer nun sagt, dass die öffentlich lesbare Liste der Ausnahmen die Lücke ist, der liegt falsch. Solange keine problematischen Ausnahmen definiert sind, kann die Liste der Ausnahmen problemlos von jedem eingesehen werden und es gibt überhaupt keine Gefahr. Erst wenn darauf eine problematische Ausnahme zu finden sein sollte, wird es gefährlich.
Die Lücke ist also eine möglicherweise vom Nutzer erstellte problematische Ausnahme und nicht, dass man diese auslesen kann!
Wenn ich die Sicherheit eines Systems mit unsicheren Ausnahmen im Virenscanner schwäche, hilft es gar nichts, wenn ich die Liste der Ausnahmen verstecke. Sie ist ja immer noch da.
Dieses Prinzip nennt sich „Security by Obscurity“ und es funktioniert nicht!
Man kann nicht Lücken in einem System schaffen und dann versuchen, diese zu kaschieren, indem man eventuellen Angreifern „ach, schau doch bitte einfach woanders hin“ zuruft.
Warum kocht das grad mal wieder hoch?
Nun, die Meinungen über die Relevanz einer solchen Funktion gehen schlichtweg auseinander. Manch einer mag einwenden, dass der Zugriff auf die Liste nur für Administratoren die Sache dann doch minimal erschwert. Und das ist ja auch nicht falsch. In Windows 11 hat Microsoft die Rechte auch tatsächlich geändert. Hier kommt man an die Liste nicht mehr als normaler Benutzer heran.
Insofern ist die Maßnahme, die Liste nicht öffentlich verfügbar zu machen, schon sinnvoll. Allerdings ist die öffentliche Ausnahmen-Liste selbst eben trotzdem keine Sicherheitslücke.
Trotzdem greifen natürlich grad IT-Journalisten das Thema gerne auf, denn solche Meldungen generieren auf den Webseiten natürlich Klicks und damit Werbeeinnahmen. Und da mittlerweile zum Glück viele Menschen von zusätzlich installierter „Sicherheitssoftware“ abgekommen sind, dürfte der Kreis der interessierten Leser nicht klein sein.
Und falls unter den Werbekunden der Webseiten Hersteller von zusätzlicher „Sicherheitssoftware“ sind, freut diese solch ein Bericht natürlich auch. Denn egal wie irrelevant die Problematik für den Normalnutzer am Ende ist, irgendwas bleibt doch im Hinterkopf hängen. „Windows Defender, da waren doch diese Lücken… ach ich kauf jetzt doch lieber eine andere Software!“
Ach ja…
All das, was oben steht, bezieht sich zwar auf den Defender, gilt aber natürlich genau so auch für jegliche anderen Antivirenprodukte. Auch dort lassen sich Ausnahmen definieren und auch dort sollte man genau aufpassen, was man ausnimmt und welche Lücken man damit möglicherweise aufreißt.
Und wer hat eigentlich schon mal geschaut, bei welchen Produkten die Liste mit den Ausnahmen möglicherweise für einen normalen Benutzer lesbar ist…? 😉
Mit Windows Server 2022 unterstützt Microsoft endlich in den Serversystemen auch TLS 1.3. Wer 2022 einsetzen kann, sollte TLS 1.3 und die zugehörigen Cipher standardmäßig aktivieren, um auf dem aktuellen Stand verschlüsselter Verbindungen zu sein.
Die Aktivierung erfolgt per Registry-Eintrag dort, wo SChannel, die entsprechende Windows-Komponente für diese Funktionalität, auch sonstige Einstellungen erwartet.
Hier werden passend zu den bisher bekannten Einstellungen für TLS 1.0, 1.1 und 1.2 die selben Parameter „Enabled = 1“ gesetzt, nur halt unter einem „TLS 1.3“ genannten Key.
Idealerweise verteilt man solche Einstellungen per Gruppenrichtlinie an alle passenden Systeme. Da nicht klar ist, welche Auswirkungen die Einstellung auf Systeme hat, die noch kein TLS 1.3 unterstützen, sollte man die Verteilung auf Server 2022 Systeme beschränken.
Und macht man genau das, was logisch und sinnvoll erscheint, rennt man mit Anlauf in die erste Falle!
Schaut man nämlich die Liste der möglichen Betriebssysteme an, auf die man hier filtern kann, fällt einem schnell eines auf…
Da fehlt was. Server 2016 und Server 2019 sind gar nicht genannt. Windows 11 nebenbei auch nicht.
Und was passiert, wenn man jetzt „Windows Server 2022 Family“ für den zu verteilenden Registry-Wert auswählt? Das, was zu befürchten war: der Eintrag landet bei allen Windows Server 2016, 2019 und 2022 Systemen.
Hier kommt jetzt der Punkt, wo man sich das Klatschen der Hand gegen die Stirn vorstellen darf.
Nun, damit hat man die erste Falle kennengelernt und, wenn man nicht aufgepasst hat, die TLS 1.3 Registry-Einstellungen an alle der genannten Server-Systeme verteilt.
Der Windows Server 2019 unterstützt zum aktuellen Zeitpunkt kein TLS 1.3. Dummerweise weiß er das nicht. Und fällt böse auf die Nase, wenn man es aktiviert. Das wäre dann Falle zwei, und die ist noch deutlich unangenehmer als die erste Falle.
SChannel wertet nämlich auf Windows Server 2019 die Registry-Keys für TLS 1.3 bereits ganz brav aus! Und stellt fest, dass da jemand ein Protokoll und entsprechende Cipher nutzten möchte. Offenbar „weiß“ SChannel auch schon, dass dieses Protokoll sicherer ist und damit Verbindungen dann möglichst mit TLS 1.3 abgesichert werden sollen.
Was macht ein Server 2019 also in dem Fall? Nun, er versucht Verbindungen von und nach außen mit TLS 1.3 herzustellen, wenn die Gegenstelle es unterstützt. Obwohl er es nicht kann. Was er dann auch schnell feststellt. Das protokolliert SChannel im Eventlog und die Verbindung wird mangels fehlendem Cipher geschlossen.
Damit sendet und empfängt ein Exchange 2019 auf Server 2019 plötzlich keine Mails mehr und die lokale Exchange Control Panel Webseite ist per Edge Browser nicht mehr erreichbar.
Das Klatschen der Hand auf die Stirn wird spätestens jetzt mit einem deutlich hörbaren Stöhnen untermalt…
Die Lösung ist demnach auch wunderbar einfach: man löscht die entsprechenden Einträge via Gruppenrichtlinie wieder. Ein Neustart und schon kommuniziert der Server 2019 wieder ganz brav mit TLS 1.2 gesichert.
Und wie schränkt man nun die TLS 1.3 Einträge sauber auf Windows Server 2022 (und Windows 11) ein? Nun, vielleicht erklärt Microsoft das irgendwann ja mal.
Vermutlich löst sich das Problem irgendwann aber auch auf ganz andere Weise. Der TLS 1.3 Support soll schließlich angeblich auch für Windows Server 2019 zurück portiert werden.
So ganz nebenbei hat Microsoft noch einen kleinen Knaller platzen lassen für Admins, die Windows seit Jahren über WDS installieren: das ist mit Windows 11 nicht mehr unterstützt! Lädt man ein Windows 11 Image, d.h. boot.wim und install.wim in einen WDS, gibts nur eine Meldung, dass das Feature halt nicht mehr funktionieren würde, wenn man davon bootet.
Auf meine Rückfrage wurde das dann noch mal konkretisiert und seit heute gibt es folgenden Artikel:
Man möge doch SCCM (aka MEM) nutzen oder MDT. Also von den drei Möglichkeiten zum Deployment streicht man die, die am einfachsten einzurichten und zu pflegen war und bietet nur noch Lösungen, die entweder ordentlich Lizenzkosten nach sich ziehen oder halt einfach nur massiv umständlicher sind.
Das muss ich jetzt auch erst einmal sacken lassen. Für mich heißt das, dass ich das komplette Windows-Client-Deployment im gesamten Konzern innerhalb der nächsten Monate komplett umstricken muss. Eigentlich noch mal von null anfangen.
Alternativ könnte man stattdessen auch eine boot.wim von Windows 10 nehmen. Dann lässt sich auch Windows 11 weiterhjn problemlos über WDS installieren. Das ist aber dann natürlich auch nicht offiziell unterstützt und wird möglicherweise in Zukunft ebenfalls blockiert. Wie so oft bei Microsoft aktuell grad: es geht also eigentlich problemlos, sie wollen es nur nicht.
Momentan machen die einem das echt nicht leicht. Erst die Geschichten mit den Systemvoraussetzungen, die miese Kommunikation darüber, jetzt noch solche Features, die einfach mal so sinnlos gestrichen werden. Unschön…
Schon von Anfang an war das Thema Systemvoraussetzungen bei Windows 11 ziemlich bestimmend. Nachdem Windows 10 auf allen möglichen alten Geräten lief, egal ob unterstützt oder nicht, hat man bei Windows 11 die Zügel angezogen.
Begründet wird das mit der Stabilität, Features der CPUs oder der Verfügbarkeit von DCH-Treibern für Gerätekomponenten. Ein TPM 2.0 bietet als sicheres Element zusammen mit Features wie SecureBoot sicherlich eine deutliche Verbesserung der Sicherheit des Systems. Nur wird das System des Anwenders zu Hause oder auch in kleinen bis mittleren Unternehmen eben nicht durch aufwändige Firmware-Angriffe in Gefahr gebracht, sondern durch harmlos aussehende E-Mail Anhänge oder katastrophale Sicherheitslücken wie „PrintNightmare“.
Fanden sich zu Anfang nur Intel CPUs ab der 8. Generation auf der Liste der kompatiblen Intel CPUs sowie AMD Ryzen CPUs ab den 2000er Generationen, hat Microsoft mittlerweile die Liste minimal erweitert und einige eher selten verbaute Intel Workstation-CPUs aufgenommen sowie genau eine (!) mobile Intel CPU der 7. Generation. Diese aber auch nur, wenn sie in drei bestimmten Geräten steckt – eines davon ist das Microsoft Surface Studio 2.
Schaut man jetzt die Listen der unterstützten CPUs durch, kommt man aus dem Kopfschütteln nicht mehr heraus.
Ein AMD 3015e Prozessor wird für Windows 11 unterstützt. Das ist eine Dualcore CPU mit zwei Zen Kernen. Die erste Ryzen Generation 1000, die selbige Zen Kerne verwendet, wird hingegen durchweg nicht unterstützt. Ein Ryzen 1800X mit acht Kernen fällt raus, ein lahmer Dualcore SoC bleibt drin? Gibt es hier unterschiedliche CPU-Features? Irgendeine Besonderheit der 3015e CPU, die das rechtfertigt?
Auch beim Support der Intel CPUs sieht es nicht anders aus. Ein Intel Core i7-7820HQ wird unterstützt, so er in einem bestimmten DELL Gerät, in einem Surface Studio 2 oder in einem Lenovo ThinkPad T470p steckt. Letzteres wurde auch z.B. mit einem Intel Core i5-7300HQ verkauft. Oder noch näher dran: mit einem Core i7-7700HQ. Gleiches Gerät. Gleiche Firmware. Gleiche Treiber. Gleiche CPU-Generation und Serie. Nur ein paar Kerne weniger bzw. etwas weniger Takt. Das Modell mit der dicken CPU wird unterstützt, alle anderen nicht.
Blickt man da noch durch?
Nun könnte man ja sagen: „was interessiert mich ein unterstütztes System? Nur laufen muss es!“
Hier läuft ein Windows 10 auf einem Core i7 der 4. Generation. Schaut man in Microsofts Kompatibilitätslisten für Windows 10 findet sich diese Generation dort nirgendwo. Es läuft trotzdem bekommt normal Updates und dass es offiziell gar nicht unterstützt wird, interessiert nicht und man merkt es nicht.
Nun gibt es ja ein paar Leute, die engere Kontakte zu Microsoft haben. So liefern Sprecher von Microsoft der Seite „Windows Central“ die Infos, dass auch auf nicht unterstützter Hardware Windows 11 installiert werden könne. Allerdings halt nur per Installation über das Media Creation Tool bzw. ein ISO-Image. Nicht über ein normales Update. Okay, das wäre zu verschmerzen.
„The Verge“ bekam allerdings gleichzeitig von Microsoft die Informationen, dass diese nicht unterstützten Installationen dann eventuell nicht berechtig seien, Windows Updates zu bekommen. Also vielleicht, möglicherweise, eventuell. Falls es so wäre, wäre das dann schlicht nicht brauchbar. Aber meint man damit nun die normalen monatlichen kumulativen Updates? Oder nur die in Zukunft jährlichen Funktionsupdates auf neue Windows 11 Versionen?
Wer jetzt eine Windows 11 Insider Preview auf nicht von Microsoft unterstützter Hardware installiert hat, soll angeblich vom Developer- in den Beta-Kanal verschoben werden, da im Developer-Kanal demnächst die Testversionen für die 2022er Windows 11 Version erprobt werden. Hier läuft genau solch ein Gerät, aber bleibt weiterhin im Developer-Kanal, obwohl angeblich nicht kompatibel.
All das ist ziemlich unbefriedigend. Katastrophale Kommunikation. Die Leute werden gleich mehrfach im Regen stehen gelassen.
Wer vier Jahre alte Hardware hat, kann oft schon kein Windows 11 mehr einsetzen. Klar, man kann Windows 10 bis zum Supportende 2025 weiter verwenden. Also wird die Hardware nicht gleich wertlos. Das ganze Drumherum ist trotzdem mies.
Jeder kann verstehen, wenn ein neues System bestimmte Anforderungen hat, die alte Hardware und alte Treiber nicht erfüllen. Dann sollte aber auch klar und nachvollziehbar kommuniziert werden, worum genau es da geht. Und nicht auf Systemen, auf denen Windows 11 ganz wunderbar läuft, den Nutzern ein „ihr Gerät ist nicht kompatibel“ gezeigt werden, samt der weiteren Verwirrung, ob es denn nun trotzdem geht oder nicht, Updates bekommt oder nicht und weiterem Unsinn.
Aber Kommunikation war wohl noch nie Microsofts Stärke.
