Also zumindest auf meinem M1-Mac mit der Technical Preview 2 von Parallels laufen auf der neuesten Entwicklervorschau von Windows on ARM jetzt auch Snapshots, Standby, Coherence, Anwendungsfreigabe von Win auf Mac und umgekehrt, sowie geteilte Ordner. Mein Drucker wurde auch korrekt in die VM weitergereicht. Stabiler ist es ebenfalls geworden. Weiß nicht, was bezüglich Funktionsumfang noch fehlen sollte.

Ich bin mir nicht sicher ob ich das verstanden habe, deshalb meine Frage an die Community: Sehe ich das richtig, dass die ganze Sache auf einer Virtualisierung von Windows on ARMS abzielt. Das heißt meine jetziger Parallels Container der ein Windows für Intel enthält wird sich niemals auf einem M1 Mac konvertieren lassen.
Ich hatte gehofft, dass ich nahtlos von einem Intel Mac auf einen Silicon Mac im Bezug auf Parallels migrieren kann.

So ist es … zumindest im Moment.

Ich würde ja gerne ein Mac Mojave System virtualisieren. Das wird aber wohl ein Wunschtraum bleiben, oder?

... oder ein altes Snow Leopard System für Nikon Scan 4 (Software für DiaScanner).
Das wäre cool !

Sag niemals nie, auch wenn ich keine große Hoffnung habe, wäre schon denkbar, dass Parallels einen eigenen Emulator schreibt, um eben z.B. auch alte macOS-Versionen oder auch andere Betriebssysteme auf M1-Macs laufen lassen zu können. Aber im Moment ist das einfach nicht absehbar...

Im Prinzip ist das schon möglich, wenn man einen Intel-Prozessor emuliert. So wurde das früher vor dem Umstieg auf Intel-Prozessoren ja auch gemacht. Würde um einiges langsamer laufen, aber für die Spezialprogramme, die man nicht mehr auf Big Sur bekommt, bestimmt ausreichen.

Da die Mx Prozessoren in den nächsten Jahren deutlich an Performance zulegen werden, kann die x86 die Emulation auf alle Kerne verteilt werden und so nahe native Intel CPUs hervorbringen.

Ich schließe mich dem Wunsch nach 10.6 an. Ggf würde auch ein 10.4 oder 5 reichen damit ich mein geliebtes FreehandMX weiter nutzen kann. Und zwar unter MacOS, nicht unter einem emulierten Windows (for Intel)...

Hab das deshalb auch so! Aber inzwischen bin ich bei Affinity gelandet. Affinity Publisher öffnet sogar FH-Dateien! Zieh dir da mal die Demoversion rein. Öffnet sogar Adobes IDML von Indesign. Oder PDFs um sie zu editieren. Affinity Photo öffnet PSD Dateien mit Ebenen. Werd bald auch meiner Adobe CS6 Good Bye sagen können...

Nimmslocker:
sorry, ich bin Kartograph. Daher habe ich sehr große und recht aufwändige Dateien in FH. Und davon viele. Da streckt Affinity schon beim anschauen alle viere von sich Der Import der FH-Daten ist halt nur sehr rudimentär und bei Text ist ganz schnell Schluß. Landkarten bestehen aber nun mal zu gut 50% aus Text

Verstehe! Illustrator CS4 bis CS5.5 konnten auch, nachdem Adobe Macromedia gekauft hat, FH öffnen. Selbes Problem?

Oder FH kann doch auch zu Illustrator exportieren...

Und ich hab schon gedacht, es geht dir um die FH-Grafiksprühdose. Die gibts sonst nirgends!

Rein aus Interesse, was wäre denn ein Ersatz für so "alte" Dokumente, welche FH4 brauchen?

Kleiner Tipp: Dr. Google könnt‘s wissen!

Schau mal bei VueScan, das unterstützt hunderte alte Scanner...

Das Problem ist nicht die CPU Emulatation. Es ist kein Problem einen Transpiler zu bauen, der x86 Code in ARM Code statisch umwandelt, so dass dieser beim Ausführen nicht durch eine Emulation laufen muss, sondern direkt von der CPU ausgeführt werden kann. Das, was der Transpiler da erzeugt wird auch nur etwa 5-20% langsamer sein als hätte man den Quelltext direkt für ARM gebaut (je nach Art der Anwendung und wie der x86 Code entstanden ist), was angesichts der Performance des M1 dann kaum spürbar wäre im Vergleich zu einem echten Intel Mac, außer bei sehr rechenintensiven Anwendung und Spielen.

Das Problem ist, dass auch Windows mittlerweile Sicherheitssysteme wie Codesigning verwendet, bei Treibern geht z.B. fast nichts mehr ohne und auch fast alle Windows Komponenten, vor allem das Bootsystem, sind so abgesichert. Denen muss man ein System vorgaukeln, in dem wirklich x86 Code ausgeführt wird, denn der transpiled Code ist ja nicht mehr signiert. Und dabei nicht "aufzufliegen" so dass Windows denkt da ist ein Virus am Werk, das ist nicht so einfach, wenn Code z.B. auf anderen Code zugreift, denn das muss man erstmal erkennen und abfangen.

Auch wird ja x86 Code teilweise dynamisch erstellt (Java/C# JIT Compiler, JavaScript JIT Engines in den Browsern) - für die klappt der Trick nicht, da braucht man immer noch einen Emulator oder halt eine JIT Transpiler, der diesen Code dann noch mal JIT umbaut zur Laufzeit und auch das muss man erstmal erkennen und da hat man dann nicht viel Zeit groß zu optimieren, denn sonst dauert es ewig, bis der Code los laufen kann.

Und richtig fies wird es, wenn Code selber durch die Stackframes navigiert, z.B. ein Crash Reporter, ein Debugger, wenn ein Garbage Collector zum Einsatz kommt, wenn so Exceptions implementiert wurden, usw. Und dann gibt es noch sich selbst modifizierenden Code. Es gibt also hunderte Gründe warum einfach mal so eine EXE Datei transpilen gewaltig schief gehen kann zur Laufzeit.

Mit einem echten Emulator für eine x86 CPU hat man diese Probleme natürlich alle nicht, nur ist der halt unheimlich langsam. Ein Nutzer im Macrumors Forum hat es geschafft einen x86 qemu Build mit Rosetta 2 laufen zu lassen und qemu wiederum hat eine x86 CPU emuliert, damit eben auch das ganze JIT Zeugs funktioniert. Geht. Kann x86 Windows booten! Nur dauert schon der Systemboot zwischen 6 und 8 Minuten

Sicherlich wäre ein ARM qemu für Mac etwas schneller, weil dann qemu selber nicht transpiled werden muss, aber selbst wenn er doppelt so schnell wäre (und so schlecht ist Rosettta 2 auch nicht, dass man hier doppelte Geschwindigkeit erhält, wenn man nativ wird), dann wären das immer noch 3-4 Minuten und damit immer noch richtig langsam.

Möglich ist das alles, aber bis Parallels hier was halbwegs brauchbares bieten kann, wird noch einige Zeit vergehen.