Windows for ARM - auf Mac Mx sehr erstaunlich!

[Frank E. (Firma: Q3) (qualidat)]

Bisher hatte ich immer Macbooks mit Intel-Prozessor (i7, 32GB), da war 
das Aufsetzen einer Windows-Umgebung für Tests oder den Unterricht mit 
Virtualbox keine große Sache. Meine VMs booteten teilweise schneller als 
die vom Bildungsträger an die Kursteilnehmer übergebenen HP-Laptops ...

Irgenwann muss man aber mit der Zeit gehen, also beschaffte ich mir ein 
gebrauchtes M2 14 Zoll Macbook. Sehr schön, leicht, flach, sehr schnell 
und auf MacOS-Seite keinerlei nachteilige Effekte hinsichtlich 
Anwendungen und des OS.

Aber, o-weh, nicht bedacht, mit VirtualBox war es erstmal aus, die läuft 
nicht auf Apple-Silicon. Schnell fand ich jedoch die alternative 
Software "UTM". Allerdings war die Freude nur von kurzer Dauer, denn das 
zugrunde liegende QEMU kann in dieser Umgebung Intel-Prozessoren 
anscheinend nur sehr, sehr langsam emulieren. Ein installiertes Windows 
11 war praktisch unbrauchbar, auch bei sehr viel gutem Willen und 
Geduld.

Dann hab ich doch tatsächlich "Windows for ARM" entdeckt, es 
heruntergeladen und in die UTM installiert. Und was soll ich sagen? Es 
ist gefühlt genau so schnell wie auf einem echten Intel-PC. Auch optisch 
keinerlei Unterschied. Selbst die Software für Intel-Windows läuft ohne 
spürbaren (nicht gemessenen!) Geschwindigkeitsverlust. Anscheinend hat 
Microsoft den ARM-Intel-Emulator wirklich gut gemacht, man kann es 
tatsächlich benutzen!

Ich bin ja richtig hin und weg ... :-)

[Hmmm (hmmm)]

Frank E. schrieb:
> Dann hab ich doch tatsächlich "Windows for ARM" entdeckt, es
> heruntergeladen und in die UTM installiert. Und was soll ich sagen? Es
> ist gefühlt genau so schnell wie auf einem echten Intel-PC.

Das Windows selbst ist auch nativer ARM-Code, da wird nichts emuliert.

Frank E. schrieb:
> Selbst die Software für Intel-Windows läuft ohne
> spürbaren (nicht gemessenen!) Geschwindigkeitsverlust.

Für x86- und x64-Code steckt ein JIT-Compiler drin, der beim Start 
ARM-Code daraus macht. Der erste Start dürfte deshalb etwas länger 
dauern, danach liegt der Code im Cache.

[Ob S. (Firma: 1984now) (observer)]

Hmmm schrieb:

> Für x86- und x64-Code steckt ein JIT-Compiler drin, der beim Start
> ARM-Code daraus macht.

Damit dürfte alle Windows-Software mit HW-Kopierschutz schon mal aus dem 
Rennen sein, oder?

[Harald K. (kirnbichler)]

Ob S. schrieb:
> Software mit HW-Kopierschutz

Welche Wirkmechanismen meinst Du? USB-Dongles?

Warum sollten die nicht funktionieren?

[Hmmm (hmmm)]

Ob S. schrieb:
> Damit dürfte alle Windows-Software mit HW-Kopierschutz schon mal aus dem
> Rennen sein, oder?

Es wird bei allem schwierig, was spezielle Hardware braucht, denn die 
Emulation gibt es nur im Userland, Treiber müssen für ARM vorhanden 
sein.

[Ob S. (Firma: 1984now) (observer)]

Harald K. schrieb:

> Welche Wirkmechanismen meinst Du? USB-Dongles?

Ja.

> Warum sollten die nicht funktionieren?

Weil da Codeteile erst zur Laufzeit entschlüsselt werden, d.h., dass 
diese zur Laufzeit des JIT-Compilers noch garnicht in ausführbarer Form 
vorhanden sind und dementsprechend nicht von ihm "übersetzt" werden 
können.

[Ob S. (Firma: 1984now) (observer)]

Hmmm schrieb:

> Es wird bei allem schwierig, was spezielle Hardware braucht, denn die
> Emulation gibt es nur im Userland

OK, daran hatte ich bei meiner Frage noch nichtmal gedacht. Diese 
Dongles erfordern ja i.d.R. auch noch Kernel-Treiber. Da nutzt ein 
"Durchreichen" des USB-Gerätes á la VirtualBox alleine noch garnix.