Kein Windows mehr auf ARM

[doc_holleday]

Nein, wirklich exotisch ist „Info“ natürlich nicht und ja, ich hoffe schon auch, dass ein aktuelles Office manches verbessert.

Ich hatte ja bereits zu-/eingestanden, dass mein Setup nicht unbedingt repräsentativ für eine moderne Windows-Umgebung ist [emoji6]

Vermutlich würde auch noch mal einiges besser werden, wenn ich mich genauso intensiv damit befassen würde, wie mit den Apple-Pendants (die ich ja auch nur oberflächlich verstehe im Verhältnis zu manch anderen hier).

Privat ist es eh einfach für mich, da ich da Windows nicht wirklich brauche.

Dennoch fand ich es nett, dass man auf den Macs grundsätzlich jedes der drei großen Betriebssysteme (wenn man Linux als eins zählt) nativ installieren konnte.

In dem bescheidenen Rahmen, mit meinem begrenzten Wissen, haben mich meine eigenen Gehversuche mit Virtualisierung bisher nicht wirklich glücklich gemacht. Aber das wird zum größeren Teil an besagten Wissenslücken liegen. Grundsätzlich weiß ich, dass das gut funktionieren kann. Aber als simple out of the Box -Lösung ist es mir bisher auch noch nicht begegnet.

 

[hosja]

Microsoft drückt momentan sowieso alles in Richtung Azure. Daher ist der Fokus von Windows weg gegangen. Im Moment wird eigentlich alles was neu rauskommt auf Linux, Mac und Windows nutzbar gemacht. Von daher glaube ich auch das sie ihre Kernprodukte auch auf einen ARM Mac zum Laufen bringen. Möglichweise auch Windows selbst.

 

[Scotch]

Möglichweise auch Windows selbst.

Das tut es doch längst. Die Frage ist, ob auch alle ihre SW auf ARM portieren. Apple zwingt die Entwickler dazu, Microsoft tut sowas eher nicht - Apple hat aber auch keine installierte Basis von kundenspezifischer Software, die dann ggf. über Nacht nicht mehr unterstützt wird. Benutzer verzeihen auch nur Apple, dass sie schlicht und einfach alle paar OS Versionen Anwendungen in älteren Versionen für obsolet erklären. Das würde unter Windows oder Linux einfach niemand akzeptieren. Man kann das also u.U. nicht vergleichen.

Wie "einfach" trotz Rosetta so ein HW-Wechsel ist, haben wir ja mit Snow Leopard gesehen. Bei etlicher SW - insb. alles was mit Musik machen zu tun hatte - hat es lange gedauert, bis das zuverlässig im neuen Treibermodell lief. Manche SW und HW ist auf der Strecke geblieben. Man kann jedenfalls sagen, dass der Wechsel auf Intel am Ende Apple mehr Benutzer gebracht hat. Wieviele davon wegen "kann meine Windows-Programme weiterbenutzen" gekommen sind - keine Ahnung. Die Diskussionen hier im Forum zeigen allerdings deutlich, dass Nutzung von Bootcamp oder VMs nicht unbedingt eine Ausnahme ist. Auch ich habe immer 'ne VM produktiv am Start gehabt, weil ich schlicht und einfach drei Programme gebraucht habe, die es einfach für macOS nicht gibt. Bis heute übrigens nicht. Und keins davon läuft auf Windows ARM. Es ist sehr unwahrscheinlich, dass Apple Silicon auf einmal Windows für ARM zum Durchbruch verhelfen wird...

Aber was bei diesen ganzen Diskussionen für mich immer noch im Vordergrund steht - bzw. zunehmend in den Hintegrund gedrängt wird - ist die Frage nache dem "warum". Warum soll ich mir die ganzen Gedanken überhaupt machen? Was interessiert mich die HW-Architektur meiner CPU? Ist das schneller, günstiger, stromsparender...? Die Antwort auf diese Fragen wird bestimmen, ob es überhaupt einen Mehrwert für die Plattform gibt. Gleiche Performance bei längerer Laufzweit? Interessant! Schneller bei geringerem Batterieverbrauch? Will ich haben. Günstiger lassen wir bei Apple mal außen vor... Aber gleiche Performance und Stromverbrauch ohne Windows-Kompatibilität, aber dafür ist "Apple Silicon" 'drin? Hmm... Warum sollte ich das haben wollen?

Ich hab' inzwischen glaube ich alle WWDC-Präsentationen zur HW durch: Wenn ich nichts übersehen habe, bleiben die alle ähnlich vage, wie die Keynote. Und da frage ich mich schon, wieso bei so einem Klopper (Plattformwechsel) und der Bühne (WWDC) da im Prinzip nur Marketing-Gerede kommt. Verstehen tue ich das nicht und der Wechsel auf Intel wurde damals auch ganz anderes zelebriert und motiviert.

Muss alles nix heissen, aber das Gefühl, dass das zumindest aktuell ein "next big thing" ist, habe ich nicht. Ich wäre der letzte, der was gegen gewichtige Gründe hat, macOS einzusetzen. Aber zumindest für mich ist substanzloses "wir nehmen jetzt ARM" und vor allem "wir machen aus macOS iOS für den großen Bildschirm" ganz und gar nicht was ich erwartet hatte und definitiv nicht das, was ich brauche. Da hat es dann schon mehr Wert für mich, dass macOS-Programme auf das iPad wandern. als umgekehrt. Ob mit der aktuellen SW-Qualität und dem Catalyst-Drama Rosetta 2 auch nur annährend so ein Erfolg wie Rosetta wird, muss Apple auch erst beweisen. Wenn nicht, war's das in jedem Fall mit macOS.

 

[hosja]

Naja die Intel Macs sind noch ne Weile da. Und mit der Platformkompatibiltät zwischen iPhone, iPad, AppleTV, Apple Watch und Mac ist die Attraktivität der Platform eigentlich gestiegen. Ich denke das die Software Anbieter sich schon drauf freuen wenn ihre Mitarbeiter mit dem Fähigkeit Swift und Swift UI zu programmieren so viel Geräte beliefern können.

Warum sollten die Firmen da nicht nachziehen. Durch die 64Bit Umstellung sind auch auf Linux und Windows viele alte Programme auf der Strecke geblieben das sollte man nicht vergessen. Aber Apple hat das genutzt um auszumisten.

Und wenn du unter Windows Programme anbietest sterben dir auch die Frameworks weg mit der Zeit. Witzigerweise hat Microsoft mit UWP ja schon das passende Konzept am Start um verschiedene Plattformen mit einer App zu unterstützen. Wenn Windows auf ARM läuft haben Anbieter die auf Windows zeitgemäß unterwegs sind auch gute Chancen das ihre App auf dem ARM Mac unter Windows läuft.

 

[YoshuaThree]

Witzigerweise hat Microsoft mit UWP ja schon das passende Konzept am Start um verschiedene Plattformen mit einer App zu unterstützen.

Ja das ist echt witzig...

Microsoft kündigt Project Reunion an und beendet so UWP-Entwicklung für Windows 10

Auf der Entwicklerkonferenz Build 2020 hat Microsoft das Project Reunion angekündigt und will so Softwareentwicklern möglichst viele Freiheiten geben.

www.pcgameshardware.de

 

[hosja]

Erst mal: Danke. Da war ich nicht auf dem neusten Stand!
Lies den Artikel mal durch. Das Konzept der Platformunabhänigkeit wird gestärkt ohne das Entwickler die Restriktionen der UWP nutzen müssen. Applikation werden sogar direkt in Container gebaut, WebApp Elemente werden nativ unterstüzt. Und es steht im Fließtext das Platformunabhänigkeit das Ziel ist. Also stärkt der Artikel mein These.

 

[Scotch]

Allerdings ist deine These i.W. dass auf einmal alle Welt für Windows ARM zu entwickeln anfängt, weil Apple Intel 'rausschmeisst und daher x86 Windows nicht mehr auf Macs läuft. Find' ich lustig

 

[ottomane]

Occams's Razor sais "won't happen"

 

[hosja]

Ich wollte eigentlich sagen das MS dafür sorgt das alles was mit für und mit MS Frameworks entwickelt wird auf allen Betriebsystemen und Platformen läuft, siehe VS Code, .Net Core u.sw.
Daher gibt es strategisch gesehen kein Hindernis das MS nicht auch die Entwicklung von Apps auf Windows auf ARM supportet.

Die Entwickler müssen nix dafür tun das ihre Zeug auf ARM läuft MS sorgt dafür. Eigentlich genau wie bei Apple.

 

[tjp]

Durch die 64Bit Umstellung sind auch auf Linux und Windows viele alte Programme auf der Strecke geblieben das sollte man nicht vergessen.

Die 64Bit Umstellung auf den wichtigen UNIX Plattformen ist schon Jahrzehnte alt, und man konnte da schon recht früh auf 64Bit Kompatibilität testen. Wer also nicht exklusiv Linux verwendet hat, hat da schon Vorsorge treffen können.

Nachtrag: Die erste 64Bit Linux Version lief wohl auf Alpha AXP, das ist auch gut 25 Jahre her.

 

[Mitglied 87291]

@hosja

Und Windows kann bis heute 32 Bit Anwendungen starten und verwenden. Im Gegensatz zu Apple welche dies einfach grundlos geblockt haben!

 

[Martin Wendel]

Wie kommst du darauf, dass das grundlos passiert ist? Spätestens der Umstieg jetzt auf ARM macht doch klar, dass dahinter ein Plan steckt.

 

[YoshuaThree]

Ich wollte eigentlich sagen das MS dafür sorgt das alles was mit für und mit MS Frameworks entwickelt wird auf allen Betriebsystemen und Platformen läuft, siehe VS Code, .Net Core u.sw.

Also Visual Code ist nur ein plumper Texteditor mit Syntax Higlightning und hat mit Visual Studio und .Net soviel am Hut wie eine Raupe mit einem Delphin verwandt ist.

Das .Net Framework ist unter macOS eine einzige Baustelle und Spielwiese. Mit Windows .Net nicht mal ansatzweise zu vergleichen. Ebenso wie Visual Studio .Net unter macOS. Das ist eine nette Beta - wo sich zudem seit Monaten nicht mehr viel tut. Und jetzt eh nicht mehr...

 

[Mitglied 87291]

@Martin Wendel
Wie kommst du darauf das ARM irgendwas damit zu tun hätte?

32 Bit Software kann natürlich auch auf ARM Basis ausgeführt werden. Man könnte die Befehlssätze integireren. Apple will dies halt nicht. Genauso wie sie es bei x86 nicht wollten. Und genau dies ist nunmal ziemlich willkürlich da es dafür erstmal keinen Grund gibt, außer dass eben eine 32 Bit Umgebung ins OS integriert sein muss. Was bei Windows und Linux kein Problem darstellt.

Gleiches Spiel auch bei OpenGL. Wäre es ein problem gewesen dieses weiterhin in macOS zu integrieren? Nein. Apple wollte es halt nicht und hat auf was eigenes gesetzt was viel weniger genutzt wird.

Gleiches Spiel auch bei NVidia Treibern. Wäre es ein problem gewesen diese weiterhin in macOS zu integrieren (bzw. einfach zu signieren? Nein. Apple wollte es halt nicht.

Sehr viele technische Entscheidungen bei Apple basieren auf "Apple will nicht". Nichts was sie in letzter Zeit so beschlossen haben ist technisch notwendig.

 

[tkreutz]

Hallo, da ja bei den neuen Apple Prozessoren wohl wahrscheinlich kein Windows mehr zu installieren geht, wollte ich euch mal fragen was ihr dann macht?
LG Flashkop.

Na die Frage ist doch immer, wer was mit welchem Rechner macht. Ich glaube, die Leute, die beruflich gesehen viel mit Computern arbeiten, besitzen mehr, als einen Rechner. Das klingt immer so, als ob alle Leute immer nur einen Computer hätten und jetzt wenn irgend ein "Böser" Hardwarehersteller etwas ändert alle in eine Wüste befördert werden - dem ist sicher nicht so. Außerdem muss man so eine Entwicklung auch erst einmal abwarten, bevor man etwas über konkrete mögliche Probleme sagen kann.

Ich muss sagen, dass Leute, die sich mit IT befassen, gerne auch vielfältige Konzepte verfolgen. Was dann daraus wird, sieht man meist eh erst später.

 

[SomeUser]

Moin!

Wie "einfach" trotz Rosetta so ein HW-Wechsel ist, haben wir ja mit Snow Leopard gesehen. Bei etlicher SW - insb. alles was mit Musik machen zu tun hatte - hat es lange gedauert, bis das zuverlässig im neuen Treibermodell lief. Manche SW und HW ist auf der Strecke geblieben. Man kann jedenfalls sagen, dass der Wechsel auf Intel am Ende Apple mehr Benutzer gebracht hat. Wieviele davon wegen "kann meine Windows-Programme weiterbenutzen" gekommen sind - keine Ahnung. Die Diskussionen hier im Forum zeigen allerdings deutlich, dass Nutzung von Bootcamp oder VMs nicht unbedingt eine Ausnahme ist. Auch ich habe immer 'ne VM produktiv am Start gehabt, weil ich schlicht und einfach drei Programme gebraucht habe, die es einfach für macOS nicht gibt. Bis heute übrigens nicht. Und keins davon läuft auf Windows ARM. Es ist sehr unwahrscheinlich, dass Apple Silicon auf einmal Windows für ARM zum Durchbruch verhelfen wird...

Das hängt aber auch stark davon ab, wie sehr sich die Programmierer schon vorher an allgemeine Vorgaben gehalten haben. Gerade im Musikbereich habe ich immer wieder das Gefühl, als würden dort nur Leute eingestellt, die vorsätzlich jede Art der Vorgabe des OS-Herstellers als Teil ihrer Arbeitsvertrages ablehnen müssen und einen möglichst kruden Weg - vorbei an allen Spezifikationen - selbst programmieren wollen, weil das "besser sei".
Steinberg und Co. wunderten sich ja bei quasi jedem neuen Release auf's Neue, das mal wieder eine Methode, die schon seit Ewigkeiten als "nicht mehr unterstützt" bekannt war, irgendwann im Zugriff untersagt, verboten oder sonstwie eingeschränkt wurde.

Wie gesagt: Gerade in dem Bereich fällt das doch immer wieder auf.

 

[Martin Wendel]

Wie kommst du darauf das ARM irgendwas damit zu tun hätte?

Ich habe nicht behauptet, dass ARM keinen 32-Bit Code ausführen kann. Gabs ja jahrelang unter iOS. Aber sich bei der Emulation über Rosetta auf 64-Bit Code fokussieren zu können, macht die Sache wohl um einiges einfacher.

 

[maniacintosh]

@Martin Wendel
Wie kommst du darauf das ARM irgendwas damit zu tun hätte?

32 Bit Software kann natürlich auch auf ARM Basis ausgeführt werden. Man könnte die Befehlssätze integireren. Apple will dies halt nicht. Genauso wie sie es bei x86 nicht wollten. Und genau dies ist nunmal ziemlich willkürlich da es dafür erstmal keinen Grund gibt, außer dass eben eine 32 Bit Umgebung ins OS integriert sein muss. Was bei Windows und Linux kein Problem darstellt.

1.) Man spart sich die Emulation für 32bit-x86-Code.
2.) Man muss den eigenen ARM-Prozessoren den ganzen 32bit-Teil des Befehlssatzes und der Architektur nicht verpassen. Das dürfte die Entwicklung vereinfachen.
3.) Man spart sich die Portierung des ganzen 32bit-Geraffels in macOS auf ARM.
4.) Gerüchteweise hörte ich mal, dass die Lizenz für x86_64 wohl einfacher zu bekommen ist als für den 32bit-Part, finde die Quelle aber nicht wieder. Aber falls da etwas dran ist, ist es einfacher Rosetta 2 eben nur 64bittig zu machen.

Gleiches Spiel auch bei OpenGL. Wäre es ein problem gewesen dieses weiterhin in macOS zu integrieren? Nein. Apple wollte es halt nicht und hat auf was eigenes gesetzt was viel weniger genutzt wird.

OpenGL ist auch in Big Sur für ARM noch enthalten. Sicher nicht die aktuelle Version, aber irgendjemand muss OpenGL für den Mac halt auch anpassen und pflegen, dies ist Aufwand, den Apple nicht mehr treiben will.

Gleiches Spiel auch bei NVidia Treibern. Wäre es ein problem gewesen diese weiterhin in macOS zu integrieren (bzw. einfach zu signieren? Nein. Apple wollte es halt nicht.

Entwickelt NVidia überhaupt noch Mac-Treiber? Und Apple verbaut eben keine NVidia-Grafikkarten, warum sollte man diese Treiber dann mitliefern?

 

[tjp]

Entwickelt NVidia überhaupt noch Mac-Treiber? Und Apple verbaut eben keine NVidia-Grafikkarten, warum sollte man diese Treiber dann mitliefern?

Da verstehst Du etwas fundamental falsch. nVidia wollte aktuelle Treiber liefern, wurde aber durch Apple daran gehindert. D.h. Apple hat aktiv verhindert, dass unter neuen macOS Versionen nVidia Karten benutzt werden können, entweder als eGPUs oder als PCIe Karten im mMP.

 

[Mitglied 87291]

1.) Man spart sich die Emulation für 32bit-x86-Code.
2.) Man muss den eigenen ARM-Prozessoren den ganzen 32bit-Teil des Befehlssatzes und der Architektur nicht verpassen. Das dürfte die Entwicklung vereinfachen.
3.) Man spart sich die Portierung des ganzen 32bit-Geraffels in macOS auf ARM.
4.) Gerüchteweise hörte ich mal, dass die Lizenz für x86_64 wohl einfacher zu bekommen ist als für den 32bit-Part, finde die Quelle aber nicht wieder. Aber falls da etwas dran ist, ist es einfacher Rosetta 2 eben nur 64bittig zu machen.

Genau. Und all diese Punkte macht die Konkurrenz. Mal abgesehen davon dass das mitliefern eines Befehlssatzes auf macOS Ebende nicht schwer ist (einfache Existenz von Librarys). Bei allgemein lauffähigen Prozessoren wie z.B. x86, ist dass dann keinerlei problem.
Bei ARM gebe ich dir insofern recht, dass die grundlegende Architektur 64 Bit ist. Allerdings funktioniert bei x86 auch 32 Bit Software auf 64 Bit Hardware. Inwiefern dies vergleichbar ist weiß ich nicht. Aber eigentlich gehe ich nicht davon aus, dass dies bei ARM anders wäre. Sind beides RISC CPU's, die zugrundeliegende Architektur ist also sehr gleich.

OpenGL ist auch in Big Sur für ARM noch enthalten. Sicher nicht die aktuelle Version, aber irgendjemand muss OpenGL für den Mac halt auch anpassen und pflegen, dies ist Aufwand, den Apple nicht mehr treiben will.

Wurde OpenGL nicht schon vor einigen Jahren komplett rausgeschmissen für Metal? Ist das nicht auch der Grund warum die Adobe Creative Suite wie ein Sack Nüsse läuft? Weil der native GPU-Support über OpenGL fehlt und jetzt auf Metal zurückgegriffen werden muss, was nicht so gut läuft?

Entwickelt NVidia überhaupt noch Mac-Treiber? Und Apple verbaut eben keine NVidia-Grafikkarten, warum sollte man diese Treiber dann mitliefern?

Ja tun sie, hatten Treiber fertig, Apple hat sich geweigert diese zu signieren.
Und das ganze ist Apples entscheidung! Apple entscheidet keine NVidia Chips zu verbauen. Apple entscheidet dass in externe GPU-Cases keine NVidia Grafikkarten eingebaut werden können, indem sie die Treiber nicht mehr bereit stellen.