Windows 10 ARM kommt immer näher, erste Entwickler haben bereits ARM-Geräte, um sich mit ihnen auszutoben und erste Schritte mit der Entwicklung und Performance der Geräte zu tätigen. Der Artikel vom Blog Winplatform gibt dabei schöne Einblicke in die Architektur von Windows 10 ARM.
Technich gesehen ist das Betriebssystem, welches ohne Bloatware installiert wurde komplett für ARM kompiliert. Die Shell, die Systemprogramme, Dienste; schlicht alles zu dem Zeitpunkt der ersten Einrichtung ist für ARM nativ entwickelt. Doch wie läuft nun Software, deren Binärcode nicht für die zugrundeliegende Mikroarchitektur kompiliert wurde? Nun, Microsoft hat bereits Erfahrung damit gemacht:
Als der Sprung von 16-Bit-Software auf 32-Bit-Software gemacht wurde, entwickelte Microsoft das sogenannte Windows-on-Windows (WoW), welches alle 16-Bit Bibliotheken auf einem 32-Bit Betriebssystem zur Verfügung stellte, damit alte, nicht aktualisierte 16-Bit-Software noch ausführbar war. Für die Software selbst änderte sich durch diese Architektur nichts. Später mit Windows 2000 bzw. Windows XP wurde langsam die AMD64 Architektur eingeführt, welche als 64-Bit Erweiterung für die damalige 32-Bit x86-Architektur entwickelt wurde. Um hier etwaige Kompatibilitätsprobleme aus der Welt zu schaffen wurde das Konzept mit WoW64 nochmal aufgewärmt. Hier gab es dann auch die selben Einschränkungen wie beim ursprünglichen WoW bzw. WoW bei Windows 10 ARM: Es können keine Treiber über die Abstraktionsschicht ausgeführt werden.
Auf Windows 10 ARM wird das Problem der Softwarekompatibilität ähnlich gelöst. Zusätzlich zum nativen Windows 10 ARM gibt es einen Windows-on-Windows-Layer für die x86-Software, welche allerdings als 32-Bit Binary vorliegen muss. Windows 10 ARM wird ohnehin lediglich 32-Bit Software ausführen können, da ARM64-Programme genauso wenig unterstützt werden wie AMD64-Software. Auch wird keine Software unterstützt, die per Injecting Code in laufende Prozesse einschleust oder Treiber. Hier müssen die Hersteller Hand anlegen und native ARM-Treiber zur Verfügung stellen.
Apple stellte mit dem Apple A7 in 2013 den ersten 64-Bit Smartphone SoC vor und mit iOS 11 aus 2017 muss jede für iOS entwickelte Software 64-Bit sein. Google führte in 2014 mit Android 5.0 erstmals den Support für ARM64 ein und mittlerweile sind alle aktuellen SoCs für Smartphones und Tablets 64-Bit-fähig. Auch wenn das Betriebssystem selbst – hoffentlich – ARM64 unterstützt, lässt sich keinerlei Software ausführen, welche für 64-Bit kompiliert ist, weder x86 noch ARM.
Die WoW-Abstraktionsebene arbeitet Hand in Hand mit einem selbst entwickelten x86-to-ARM Emulator sowie CHPE DLLs, welches x86-DLLs mit ARM Binärcode sind. Beim erstmaligen Start kann eine x86-App besonders langsam wirken, da das Betriebssystem im Hintergrund den in Echtzeit übersetzten Programmcode auf dem Datenträger abspeichert, sodass das Programm bei späteren Starts bereits fertig kompiliert zur Verfügung steht. Dadurch unterstützt Windows 10 ARM sowohl UWP-Applikationen, welche für x86 (32-Bit) oder ARM32 kompiliert wurden als auch klassische Win32-Programme (ebenfalls 32-Bit). App-Entwickler sollten also darauf achten, wenn sie eine App in den Store bringen, sowohl für ARM, als auch für x86 zu packagen.
Die Zukunft wird zeigen, wie vor allem Hersteller von Software für die Win32-API das neue Windows aufnehmen werden, oder ob es beim selben Schicksal wie für Windows RT bleiben wird. In einer perfekten UWP-Welt wird es irgendwann nicht mehr nötig sein, zu schauen welche Mikroarchitektur ein Gerät nutzt, da man einfach jegliche Software ausführen können wird, die für Windows 10 verfügbar ist. Durch die Einschränkung von 32-Bit Software, sowohl für ARM, als auch x86 werden Spiele erst einmal nicht so schnell auf das neue Konzept wechseln. Das liegt daran, dass vor allem größere Spiele häufig Gebrauch von >4 GB Arbeitsspeicher machen und auch wichtige 64-Bit Erweiterungen benötigen.
Quelle: Winplatform
Am 11. April fanden die British Academy Film Awards oder auch kurz BAFTAs statt. In…
Die App Microsoft Teams hat in den letzten Monaten einigen Auftrieb erhalten, indem sie durch…
Nachrichten aus dem Hause Ubisoft. Dort hat man beschlossen, das Forward-Event auch in diesem Jahr…
Microsoft kann Gaming – der Beweis dafür ist die beliebte Xbox Series S Spielekonsole. Wer…
Der Microsoft Flight Simulator wird optisch weiter aufgewertet. Wir wissen, dass es auch unter unseren…
Die meisten unserer Leser dürften zu Hause über einen Schreibtisch verfügen, an welchem nicht nur…
Diese Webseite benutzt Cookies.
Zeige Kommentare
Windows 10 Mobile ist übrigens ein 32-Bit-Windows. Die Architektur der Lumias ist aber 64 Bit, die im 32-Bit-Modus läuft.
Damit Windows 10 ARM auf einem Lumia lauffähig wäre, müsste also die komplette Treiberschicht bzw. der HAL (Hardware Abstraction Layer) entsprechend angepasst werden. Was A. ein ziemlicher Aufwand ist und B. deswegen auch vermutlich nicht passieren wird.
Da wäre es schon fast einfacher, die x86-Emualtion in Windows 10 Mobile einzubauen. Was sie aber nicht machen werden, da die vorhandenen Handys schlicht zu schwachbrüstig sind...
Die Architektur der Lumias ist sowohl 32 als auch 64 Bit. Oder hast die dies genialen 550/650er schon vergessen, ganz zu schweigen von allen "als für w10m ausreichend" deklarierten WP8.x-ern. Die 950er sind immer noch eher die Ausnahme unter allen W....-Phones, auch wenn diese und ähnliche Communitys was anderes suggerieren.😉
Danke. 👌🏼
Aber warum überhaupt Spiele? Die Geräte konkurrieren mit Chromebooks und ultraleichten Geräten die normalerweise mit Pentium oder Core Y daherkommen. Gerade im Bildungsmarkt sollte MS da ganz stark subventionieren.
Interessant wäre es ja wenn Nvidia mit der nächsten Generation Tegra APUs dabei wäre. Ich bin mir sicher, dass bei passenden Geräten die Emulator Community schnell mit an Bord wäre um Emulatoren für NES, SNES, N64, PS1, PS2, PSP, PS3, und Wii lauffähig zu bekommen. WiiU wäre natürlich zu viel des Guten.
Ansonsten sollte MS auf jeden Fall langen Atem beweisen und die Kooperation mit Chipherstellern intensivieren. Der SD835 war nie für Windows gedacht eine spätere APU vielleicht schon.
Wenn ich mir die Zusammenarbeit mit HP (Mobile) anschaue und dann dieses halbgare Produkt sehe.
Die Entwicklung mit meinen 4 Windows 10 M Geräte mit Windows App für Android vergleiche.
Dann kann ich Windows 10 on ARM keine Gute Zukunft sehen.
Was ist daran halbgar, OK 64Bit Support fehlt noch aber das ist doch erstmal zweitrangig.
Im Absatz über Android haben sich ein paar Fehler eingeschlichen, die erste Version mit ARM64 Unterstützung war 5.0 und auf aktuellen Geräten können auch ARM64 Anwendungen ausgeführt werden.
Hast du ne Quelle, die eindeutig sagt, dass ARM64-Applikationen auf Windows 10 ARM laufen?
Und du hast recht, es kam mit 5.0, 4.5 gabs ja gar nicht :D
Seine Aussage bezüglich ARM64 bezieht sich auf Android.
Ja genau, der Satz "Auch wenn das Betriebssystem selbst – hoffentlich – ARM64 unterstützt, lässt sich keinerlei Software ausführen, welche für 64-Bit kompiliert ist, weder x86 noch ARM." stimmt meinen Informationen nach nicht. Die Google-App liegt zum Beispiel auch als ARM64 vor. https://www.apkmirror.com/apk/google-inc/google-search/variant-%7B"arches_slug"%3A%5B"arm64-v8a"%5D%7D/
Achso, sorry. Das war wohl etwas unverständlich formuliert. Gemeint ist dort Windows 10 ARM :)
Also habe ich das jetzt richtig verstanden - Apps im Store wie Gwent, Fable Fortune , die ganze Telltale Reihe, Fallout Shelter etc laufen auf nen 700€ Notebook nicht weil sie, trotz App, X64 benötigen?
Njein. Spiele brauchen oft mehr als 4 GB RAM, und 32-Bit kann max. 4 GB überhaupt adressieren, meist nur 3 oder 3,ebbes. Wer mehr Speicher nutzen können will, braucht also zwingend 64-Bit-Treiber. Außerdem sind manche Spiele recht hardwarenah geschrieben, um sie schneller zu machen. Hardwarezugriffe funktionieren aber nicht. Auch aus Sicherheitsgründen (Viren, Sandbox) ist hardwarenahe Programmierung problematisch. Gute Programmierer wollen direkt an die Hardware, gute Administratoren unterbinden das am liebsten komplett… 😉 Hardwarenahe Programmierung kann das System zum Absturz bringen, ein Grund mehr, warum Admins sie nicht mögen.
Zurück zu den 4 GB: Windows 10 ARM ist also praktisch nix anderes als Win 10 Mobile plus 64Bit-Unterbau, plus x86-Emulation, PLUS CSHELL (!).
Und: Ein Laptop mit 8 GB Speicher, auf dem ein 32-Bit-Windows installiert wurde, hat 4 GB toten Speicher eingebaut.
Nun, bei x86 gabs sowas wie PAE, welches es ermöglichte, mehr als 4GB Arbeitsspeicher zu adressieren. Und hoffentlich ist ja Windows 10 ARM selbst als ARM64 Code geschrieben.
Njein hilft mir nicht 😉 Würden die Spiele Apps nun laufen oder nicht?
PAE war Mist, asig langsam. Bestimmt ist der Kernel 64 Bit, allein um mehr Speicher adressieren zu können, ist das sinnvoll. Allerdings gibt es schlichtweg (noch) keine Windows-Software für 64-Bit-ARM.
Zudem müssen alle UWPs nochmal kompiliert werden (von 32-Bit-ARM auf 64-Bit-ARM). Apple hatte das gleiche Problem, als sie zu 64 Bit gewechselt sind und da liefen die Apps einfach nicht mehr, die Daten waren weg oder unerreichbar.
Es ist also eine Frage der Zeit, bis alles nativ 64 Bit ist.
Nachtrag: http://www.zdnet.com/article/windows-10-on-arm-s-versus-pro-emulation-and-64-bit-app-support/
Nachtrag 2:
http://www.windows-arm.com/
So langsam, dass das in 32 Bit Servern erfolgreich eingesetzt wurde? Den Speicher gar nicht zu haben und/oder auf HD zu pagen ist deutlich schlechter. Und früher untere DOS ein ähnliches Prinzip EMS/XMS hat es überhaupt erst möglich gemacht mit nen 33MHz/486er statt 640KB sagenhafte 4 MB für AutoCAD nutzbar zu machen. War mein erster Dienstrechner.
Danke. Endlich klar erklärt was es mit dem "Müll der Vergangenheit" auf sich hat. Weiter so....