News Windows 10 on ARM: Keine Emulation von x86-64-Bit-Anwendungen

[xexex]

Zurück zum Laptop: Das Laptop wird öfter mal zum Briefeschreiben, PDFs ansehen und zum Surfen verwendet.
Und zum Kopieren von wichtigen Dokumenten wie z.B. Rechnungen, Schreiben von der Krankenkasse, Mahnungen, usw.

Hier treffen halt ganz verschiedene Generationen aufeinander! "Heutzutage" würde man sich einfach mal eine Barmer App installieren und darüber die Kommunikation abwickeln.
https://www.barmer.de/gesundheitscampus/apps/service-app-9080

Es bringt aber glaube ich wenig in einem Computerforum darüber zu diskutieren wie sinnlos heutzutage ein PC geworden ist, in der "freien Wildbahn" ist es aber genau der Fall. Ich buche meine Flüge, Hotels, oder Fahrkarten auch gerne noch einfach über den Browser. Viele die ich kenne nutzen dafür jedoch nur noch die entsprechenden Apps der jeweiligen Anbieter und fummeln nicht mit irgendwelchen PDF Dokumenten herum.

Officeanwendungen kann man mit einem Tablet genauso gut bearbeiten wie mit einem PC, einzig eine entsprechende Tastatur wird benötigt. Die meisten Daten speichert man in der Cloud, dann hat man auch über den Smartphone jederzeit Zugriff darauf und um etwas auszudrucken kann man einfach Google Cloud Print oder Apple AirPrint verwenden.

 

[joshy337]

Hier treffen halt ganz verschiedene Generationen aufeinander! "Heutzutage" würde man sich einfach mal eine Barmer App installieren und darüber die Kommunikation abwickeln.
https://www.barmer.de/gesundheitscampus/apps/service-app-9080

Ich schätze, dann bin ich, sowie meine Schwester als Twen wohl geistig überaltert.
Wir bekommen noch Post in Briefform und versenden Bewerbungen per Post.
Wenigstens haben wir so noch Kopien unserer Schreiben.

Es bringt aber glaube ich wenig in einem Computerforum darüber zu diskutieren wie sinnlos heutzutage ein PC geworden ist, in der "freien Wildbahn" ist es aber genau der Fall. Ich buche meine Flüge, Hotels, oder Fahrkarten auch gerne noch einfach über den Browser. Viele die ich kenne nutzen dafür jedoch nur noch die entsprechenden Apps der jeweiligen Anbieter und fummeln nicht mit irgendwelchen PDF Dokumenten herum.

Da ist was wahres dran. Dennoch ist das Diskutieren eine schöne Sache.
Man lernt so die Sichtweise ander Leutchen kennen und findet Pro/Contra einer Sache heraus.
Dafür ist ein Forum ja auch da, finde ich.

Officeanwendungen kann man mit einem Tablet genauso gut bearbeiten wie mit einem PC, einzig eine entsprechende Tastatur wird benötigt. Die meisten Daten speichert man in der Cloud, dann hat man auch über den Smartphone jederzeit Zugriff darauf und um etwas auszudrucken kann man einfach Google Cloud Print oder Apple AirPrint verwenden.

Klar. Aber man kann statt einem Tablet auch ein Laptop besitzen.
Ich selbst habe z.B. beides. Mein Tablet mit Android 4 bekam ich mal geschenkt,
liegt aber seit einer Weile in der Ecke, so wie mein alter Pocket PC mit Win Mobile 2003.
Ein einfacher Schwarz/Weiss eBook Reader mit e-ink Display wäre mir deutlich lieber gewesen.
Immerhin habe ich dank einer Trainings-App auf dem Tablet später eine Prüfung bei der Bnetza geschafft.

 

[FoooBar]

eindeutig nicht!
ghecko hat völlig recht mit seinem Zitat.

Nö hat er nicht.

 

[joshy337]

Nachdem selbst beim x86_64 Windows der 16-Bit Support schon vor über 10 Jahren gestrichen wurde, kennst du sicher die Antwort. Lustigerweise gibt es aber eine Lösung, auf der 64-Bit, 32-Bit und 16-Bit Windows Applikationen nebeneinander her sauber ausgeführt werden können, inklusive der alten Installer: Linux mit Wine

Manch einer mag das auch traurig finden, aber dort läuft alte Windows Software in der Regel unproblematischer als auf einem aktuellen "echten" Windows.

Da stimme ich zu. Wine ist ganz gut, auch wenn es mit Win16 Real-Mode Anwendungen noch ein paar Problemchen gibt.
Wie es der Zufall so will, gab es vor kurzer Zeit eine News, in der berichtet wurde, dass Linux bald OS/2-Programme ausführen kann:
https://www.pro-linux.de/news/1/25639/2ine-os2-anwendungen-unter-linux-ausgeführt.html

Finde ich gut. Windows NT verlor diese Fähigkeit mit Win XP. Windows NT4 und 2000 konnten auch noch HPFS lesen und OS/2-Textmode-Anwendungen ausführen. Mit einem Add-on auch GUI-Programme für den OS/2-Presentation Manager. Das Add-on hies "Microsoft OS2 Presentation Manager For NT" und konnte 16-Bit OS/2-Programme bis zu Version 1.3 ausführen. Klingt jetzt nach wenig, war aber im Prinzip das Gegenstück zu Win-OS/2 (immernoch bei BlueLION OS dabei!).

Wenn wir Glück haben, schafft es das Linux-Subsystem, die Unzulänglichkeiten von Windows10 auszubügeln.
Für XP gab es z.B. AndLinux, mit dem man Linux-Programme unter Windows laufen lassen konnte.
Das war so gut, dass man WINE darin instalilieren konnte. Seit Windows x64 geht das aber nicht mehr,
da man den Linux-Kernel nicht mehr booten kann. Zu viele Beschränkungen bezüglich Treiber-Sperre, die keine unsigniertee Treiber mehr erlaubt. Als unabhängiger Hobby-Programmierer ist man ohne eine
MS-Mitgliedschaft unter Win x64 scheinbar eher weniger willkommen.

 

[Thala]

Hier ist jede Menge gefährliches Halbwissen im Umlauf.

Erstmal laufen unter Windows für ARM native 64 bit ARM Anwendungen - inclusive Win32 Desktop Anwendungen. Wer also 64 bit Addressraum braucht kann einfach für ARM64 übersetzen.
x86 Anwendungen sind nur eine Übergangslösung - Kann ja nicht das Ziel sein, auf einer ARM CPU ausschliesslich x86 zu emulieren.

Was die x86 Emulation angeht werden folgende Instruction Set Features unterstützt:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1

 

[I'm unknown]

Wer also 64 bit Addressraum braucht kann einfach für ARM64 übersetzen.

Das mache ich mit einem gewünschten Closed-Source-Programm wie genau?

Was die x86 Emulation angeht werden folgende Instruction Set Features unterstützt:
AES, CX8, FXSR, MMX, POPCNT, SSE, SSE2, SSE3, SSE4.1

Dafür hast du doch bestimmt eine Quelle ?

 

[Thala]

Das mache ich mit einem gewünschten Closed-Source-Programm wie genau?

Du machst das überhaupt nicht. Es geht um Entwickler, die einschätzen, dass 32 bit Unterstützung für ihre App nicht mehr ausreichend ist, oder eben kein 32 bit mehr unterstützen wollen oder können.

Dafür hast du doch bestimmt eine Quelle ?

Ja, die Quelle bin ich. Habe Windows für ARM unter QEMU installiert, danach ein x86 Programm geschrieben, was die CPUID auswertet und alle Features listet. Das habe ich dann unter Windows für ARM ausgeführt.

 

[I'm unknown]

Ja, die Quelle bin ich. Habe Windows für ARM unter QEMU installiert, danach ein x86 Programm geschrieben, was die CPUID auswertet und alle Features listet. Das habe ich dann unter Windows für ARM ausgeführt.

Und hast du auch getestet ob das nur als vorhanden angezeigt wird oder auch mit echten Beispielen funktioniert?

 

[Thala]

Ich habe nur die CPUID ausgewertet. Microsoft wäre aber schön dämlich, wenn sie hier hochstapeln würden, da manche Programme einen alternativen Code-Pfad bereitstellen, falls features fehlen. Solche Programme würde dann trefflich crashen obwohl sie eigentlich laufen könnten.

Was würde dich denn interessieren? Ich kann ja auch mal nen "echtes" Beispiel übersetzen

Hatte aber interessehalber mal nen altes Windows Programm, was MMX braucht laufen gelassen. Es handelt sich um das Spiel Unreal aus dem Jahr 1998. Das lief mit dem MMX software renderer.

 

[joshy337]

Kann ja nicht das Ziel sein, auf einer ARM CPU ausschliesslich x86 zu emulieren.

Aus Anwendersicht wäre aber genau das ideal. Emulation ist nicht mehr das selbe, wie vor 30 jahren.
Heute gibt es dynamische Recompiler, JITs, etc. Sofern genug RAM vorhanden, kann der Code-Cache vernünftig groß sein.
Die Perfomance wäre dann vergleichbar mit Java bzw. Java Mobile.

Bei Windows bzw. Win32 ist es sogar noch einfacher, da viele API-Funktionen 1:1 übersetzt werden können.
D.h. Funktionen wie "CreateWindow" sind beim x86 Windows die gleichen wie beim ARM Windows,
nur die Maschinensprache ist anders.

Wenn man es richtig anstellt, liegt die Performance bei geschätzt 80%-90% eines echten x86 Windows.
Wohlgemerkt, wenn moderene Emulation zum Einsatz kommt, mit "Abkürzungen" sozusagen.
Man darf so eine Emulation nicht mit derer von Spielekonsolen vergleichen.

Klar, wenn das Programm intern komplizierte Berechnungen mit SSE und MMX durchführt, wird die Sache langsam.
Aber solche Dinge würden eine echte Win32 ARM-Anwendung auch verlangsamen, da die Aufgabe an sich
sehr heraufordernd ist. Wenn man die Kreiszahl Pi berechnen will, ist so ziemlich jede Architekur ausgelastet.

Bei einfachen Business-Anwendung ist dies aber meist nicht der Fall.
Da werden Fenster gezeichnet, Rechtecke gefüllt, Datensätze geladen,Truetype-Schriften aufgerufen, etc.
Diese Aufgaben werden aber alle von der nativen Seite des Win10 ARM ausgeführt.
Die Emulation hat damit nichts zutun. Die Performance wäre exakt die gleiche, wie bei einer nativen Win32 ARM-Version.

Das ist ja genau der Punkt, warum die Emulation einer Win64-Anwendung technisch kein Problem wäre.
Bis auf ein paar 64-Bit Pointer und "RAX" statt "EAX" ist alles gleich.
Zumindest beim grundlegenden, "reinen" X86-64 ohne das SSE.

 

[Thala]

Aus Anwendersicht wäre aber genau das ideal. Emulation ist nicht mehr das selbe, wie vor 30 jahren.
Heute gibt es dynamische Recompiler, JITs, etc. Sofern genug RAM vorhanden, kann der Code-Cache vernünftig groß sein.
Die Perfomance wäre dann vergleichbar mit Java bzw. Java Mobile.

Bei Windows bzw. Win32 ist es sogar noch einfacher, da viele API-Funktionen 1:1 übersetzt werden können.
D.h. Funktionen wie "CreateWindow" sind beim x86 Windows die gleichen wie beim ARM Windows,
nur die Maschinensprache ist anders.

Wenn man es richtig anstellt, liegt die Performance bei geschätzt 80%-90% eines echten x86 Windows.
Wohlgemerkt, wenn moderene Emulation zum Einsatz kommt, mit "Abkürzungen" sozusagen.
Man darf so eine Emulation nicht mit derer von Spielekonsolen vergleichen.

Klar, wenn das Programm intern komplizierte Berechnungen mit SSE und MMX durchführt, wird die Sache langsam.
Aber solche Dinge würden eine echte Win32 ARM-Anwendung auch verlangsamen, da die Aufgabe an sich
sehr heraufordernd ist. Wenn man die Kreiszahl Pi berechnen will, ist so ziemlich jede Architekur ausgelastet.

Bei einfachen Business-Anwendung ist dies aber meist nicht der Fall.
Da werden Fenster gezeichnet, Rechtecke gefüllt, Datensätze geladen,Truetype-Schriften aufgerufen, etc.
Diese Aufgaben werden aber alle von der nativen Seite des Win10 ARM ausgeführt.
Die Emulation hat damit nichts zutun. Die Performance wäre exakt die gleiche, wie bei einer nativen Win32 ARM-Version.

Das ist ja genau der Punkt, warum die Emulation einer Win64-Anwendung technisch kein Problem wäre.
Bis auf ein paar 64-Bit Pointer und "RAX" statt "EAX" ist alles gleich.
Zumindest beim grundlegenden, "reinen" X86-64 ohne das SSE.

Ich finde es grundsätzlich erstmal erfreulich, dass du etwas detaillierter auf die Performance trade-off bei Emulation eingehst. Ich lese zu oft in der Foren, dass die Windows on ARM Geräte aufgrund von irgendwelchen low-level Benchmarks extrem langsam sein werden. In der Tat ist es aber eher so, dass man selten einen Unterschied merken wird, da bei typischen Anwendungen, wie du richtig herausstellst, größere Teile des Codes native ausgeführt werden, speziell alle OS calls und Grafik Bibliotheken - auch wenn die Anwendung selbst nur als x86 native Code vorliegt.
Dennoch kann Emulation nur eine stop-gap Lösung sein, da die Vorteile die ARM in Bezug auf Effizienz hat so teilweise aufgebraucht werden und zum Anderen, weil nicht alle Apps oben beschriebenes Verhalten aufweisen. Wenn man in einem Video Editor einen neuen Effekt berechnet ist das 100% Anwendungs code und kaum OS code. Ich würde sogar davon ausgehen, dass viele Anwendungen, die den Schritt zu 64 bit nötig gemacht haben ein solches Verhalten an den Tag legen. Insofern würde ich es als absolut kontra-produktiv betrachen, wenn hier noch eine x64 emulation nachgeschoben wird anstelle den Entwicklern nahezulegen für ARM64 zu übersetzen.

 

[Limit]

Artikel-Update: Microsoft hat gegenüber Engadget bestätigt, dass Windows 10 on ARM in Zukunft auch mit 64-Bit-Apps umgehen können wird. Allerdings nicht per Emulation. Stattdessen wird der Konzern zur Entwicklerkonferenz Build Anfang Mai ein SDK bereitstellen, mit dem Softwareanbieter ihre 64-Bit-Programme neu kompilieren müssen, damit sie in 64 Bit unter Windows 10 on ARM laufen. Der Kompiler soll sowohl mit klassischen Programmen als auch mit UWP-Anwendungen aus dem Windows Store zusammenarbeiten. Inwiefern Microsoft auch Windows 10 on ARM in Zukunft weiter ausbaut, bleibt abzuwarten.

 

[Steini1990]

Klingt gut. Je flexibler Windows 10 on ARM ist desto besser für alle.
Auch wenn der Zusatzaufwand die vorhandene Software einschränken wird.

 

[nille02]

Inwiefern Microsoft auch Windows 10 on ARM in Zukunft weiter ausbaut, bleibt abzuwarten.

Wenn es ein Erfolg werden soll, sollten sie es tun. Aber ich bin gespannt was es so alles an Hardware geben wird. Ich für meinen Teil finde den SD835 viel zu teuer um wirklich eine Alternative zu sein.

Ich hoffe aber auch, dass MS ihre Secure Boot Politik auf nicht X86 Hardware überarbeitet. Bisher ist auf ARM ja Secure Boot erzwungen und nicht abschaltbar.

 

[Herdware]

Klingt gut. ...

Besser als nichts, aber so richtig hilfreich ist das doch auch nicht. Der Emulator ist ja gerade für Software nützlich, wo sich niemand (mehr) die Mühe macht, sie als native ARM-Version zu bringen.

Es wird dann wohl auch nicht so oft der Fall sein, dass exstierende oder neue x64-Software extra nochmal neu compiliert wird, um im Emulator zu funktionieren. Den meisten Entwicklern wird es auch diese (angeblich) kleine Mühe nicht wert sein, um die neuen Windows-ARM-Geräte zu erreichen. Jedenfalls so lange nicht, bis die einen nennenswerten Marktanteil haben, und dann wäre auch der Emulator nicht mehr so wichtig. Der ist ja gerade dafür da, den neuen Geräten den Start zu erleichtern, bis es genug native Software gibt.

 

[He4db4nger]

irgendwie versteh ich den einen satz im update nicht.. wenn man es neukompiliert für arm64 sind die apps doch nativ?

und wie sie das system ausbauen.. ist wirklich fraglich. meiner meinung nach wirds an den gleichen problemen scheitern wie windows RT, auch wenn es jetzt etwas "offener" ist. das ganze hätte nur eine chance, wenn die pwa (progressive web apps) schon eine breite verfügbarkeit hätten, aber dafür kommt es einfach 1-2 jahre zu früh. schau ich mir die preise an, die derzeit für so geräte aufgerufen werden würde ich das überhaupt nicht in erwägung ziehen, obwohl ich windows10 allgemein sehr gut und die arm-technologie hochinteressant finde und viele meiner sachen auch als apps im windows store verfügbar sind.

unter dem strich dürfte das am ende nicht mehr sein, als ein testballon für das sagenumwobene surface phone - in welcher form es auch (falls überhaupt) kommt..

 

[DJMadMax]

Stattdessen wird der Konzern zur Entwicklerkonferenz Build Anfang Mai ein SDK bereitstellen, mit dem Softwareanbieter ihre 64-Bit-Programme neu kompilieren müssen, damit sie in 64 Bit unter Windows 10 on ARM laufen.

Natürlich! Denn wir alle, die wir programmieren, wissen genau, dass der eigene Quellcode sofort und ohne jegliche Anpassungen laufen wird, wenn man ihn mit einem neuen Compiler für eine neue Plattform kompilieren darf.

Dass hier wieder nur ein Bruchteil der Softwareentwickler die Ressourcen aufbringen wird, um die eigene Anwendung auf Windows 10 on ARM zum Laufen zu bringen, ist selbstredend.

Somit ist das System jetzt schon eine Todgeburt und dem gleichen Schicksal wie bereits sämtliche Windows Mobile-Versionen zuvor geweiht.

Danke, Microsoft... vielen Dank!

Cya, Mäxl

 

[simons700]

Dennoch kann Emulation nur eine stop-gap Lösung sein, da die Vorteile die ARM in Bezug auf Effizienz hat so teilweise aufgebraucht werden und zum Anderen, weil nicht alle Apps oben beschriebenes Verhalten aufweisen. Wenn man in einem Video Editor einen neuen Effekt berechnet ist das 100% Anwendungs code und kaum OS code. Ich würde sogar davon ausgehen, dass viele Anwendungen, die den Schritt zu 64 bit nötig gemacht haben ein solches Verhalten an den Tag legen. Insofern würde ich es als absolut kontra-produktiv betrachen, wenn hier noch eine x64 emulation nachgeschoben wird anstelle den Entwicklern nahezulegen für ARM64 zu übersetzen.

Aber das wird halt nicht passieren! In Wirklichkeit ist ARM auf Microsofts UWP doch im Rückwärtsgang.
Xbox: X86, Tablets: X86, PCs und Server: X86, Smartphones: tot.
Der MS Store war ja ursprünglich mal als Plattform übergreifende Softwarequelle gedacht, um die ARM app´s zu pushen.
Ja jetzt läuft er aber eigentlich nur noch auf X86 Geräten.
Hier ist es doch schon wieder das gleiche, diese ganzen Always Connected Geräte kommen jetzt mit dem SD835 aber demnächst auch mit CPU von Intel mit integriertem LTE Modem. Dazu ist Qualcomm auch noch eine Partnerschaft mit AMD eingegangen und es wird die Geräte mit AMD APU+ Qualcomm Modem geben.
Soll heißen sogar Qualcomm weiß dass sie ohne X86 kerne gegen Intel abstinken und bekommen so wenigstens noch ihre Modems in die Geräte!

 

[borizb]

Klingt gut. Je flexibler Windows 10 on ARM ist desto besser für alle.

Jup. Endlich wird auch auf ARM Chips Linux verdrängt
Für EIN einheitliches Ökosystem unter amerikanischer Führung!

 

[Steini1990]

@borizb
Mir wäre neu das unter ARM ein freies Linux der Markführer wäre. Android oder Chrome OS kann man nicht als Linux bezeichnen.
Da kann ich auch nicht auf beliebigen Geräten das Betriebssystem meiner Wahl installieren sofern man kein ROM Entwickler ist. Selbst dann scheitert es manchmal an den Treibern.
Software installiert man auch von einer einzigen zentralen Quelle. (Ja auch Sideload ist möglich, das wird bei Windows auf ARM auch nicht ausgeschlossen)
iOS ist so abgeschlossen wie sonst kein zweites OS.

Kannst du also etwas spezifischer werden welches Linux verdrängt werden soll?
Außerdem steht so gut wie jedes Ökosystem steht unter Amerikanischer Führung. Egal welches.