Anlass für diesen kleinen Lagebericht war ein eigenes „Dauerprojekt“, das ich als alter Retro-Computing-Fan mal zu privaten Zwecken gestartet hatte. Dabei ging es mir ursprünglich nur darum, eine kleine Sammlung exotischer oder ausgestorbener Betriebsysteme startbereit und lauffähig zu erhalten. Über die letzten gut 20 Jahre hinweg war das eine überraschend einfache Aufgabe – zumindest, solange man sich auf Systeme und Software beschränkte, die für Intel- Prozessoren gemacht wurden. Den Auslöser lieferte mir seinerzeit ausgerechnet die Firma Apple, die damals bis dato weder etwas mit Intel-Prozessoren noch mit anderen Betriebssystemen als dem eigenen irgendwas zu tun haben wollte.

Windows und andere Betriebssysteme auf Mac, a long story

Zur Erklärung (für die jüngeren unter uns) sei mir eine kleine Abschweifung in die Computergeschichte entschuldigt:  Als Apple Anfang der Zweitausender mit den PowerPCs in eine Sackgasse kam, weil IBM als Prozessorenlieferant offensichtlich sowohl die Ideen als auch die Lust auf Weiterentwicklung ausgingen, besann man sich des im Unternehmen vorhandenen Know-hows aus der zwischenzeitlich eingekauften NeXT-Vergangenheit und zauberte für die Öffentlichkeit recht überraschend eine x86-Version von OSX 10.4 für den neuen iMac auf Intel-Basis aus dem Hut. Das war damals wohl nur möglich, weil OSX eben im Kern auf das NeXT-Betriebssystem zurückgeht, das es schon einmal für Intel-Prozessoren gegeben hatte. Nun stellte sich heraus: Man hatte den Code nicht etwa weggeworfen, sondern über die Jahre im Stillen weiter gepflegt. Der Schwenk gelang dann auch überraschend reibungslos – nicht zuletzt dank eines ziemlich genialen Software-Frameworks namens „Rosetta“, das nichts weniger machte, als Anwendungen, die für den alten PowerPC gestrickt worden waren, in Echtzeit auf Intel zu übersetzen.

Zwar hatte es auch schon ab den späten Neunzigern eine Software für PowerPC-Macs gegeben, die einen Intel-Windows95-PC emulieren konnte: VirtualPC von Connectix. Aber aufgrund der damals verfügbaren Rechenleistungen war das noch keine wirklich praktikable Alltagslösung. Mit dem Erscheinen der Intel Macs wurde jedoch neu gewürfelt und es entstand bald die etwas bizarre Situation, dass der mit Abstand „universellste“ Standard-PC, auf dem  – zumindest theoretisch – die größte Auswahl an Betriebsystemen lief, ausgerechnet von Apple kam. Es dauerte auch nicht lange und aus der bisher so geschlossenen Apple-Welt wurde plötzlich eine erstaunlich offene. Die für Windows bereits existierenden Lösungen zum Parallelbetrieb virtueller Systeme kamen nun auch auf den Mac. Und damit kriegte man Linux, Windows, NetBSD – fast jedes irgendwann mal für x86-Prozessoren gemachte Betriebssystem – auf dem eigenen (Intel-) Mac irgendwie an den Start, dank Virtualisierung. Apple selbst lieferte nach anfänglicher „starker Zurückhaltung“ einige Zeit später sogar das Werkzeug mit, um Windows auch direkt im Wechsel mit OSX auf der eigenen Hardware installieren zu können: Dank „BootCamp“ lief die Windows-Installation bequemer als auf so mancher originären PC-Hardware. Wenn man also auf einem einzigen Rechner „alles mal ausprobieren wollte“, dann hatte man keine allzu großen Hürden zu nehmen, sofern man sich einen Intel-Mac kaufte. Den umgekehrten Fall bekamen allerdings lange Zeit nur hartgesottene Zeitgenossen auf die Reihe, nämlich OSX auf einem PC „von der Stange“ laufen zu lassen (aber das ist eine andere Geschichte).

Ein Windows 7 (x86) unter vmWare Fusion – aber nur für Intel-Macs

Bald lieferten sich Virtualisierungs-Profis wie Parallels und VMware ein Kopf-an-Kopf-Rennen um die Gunst der Mac-User.  Und durch recht intuitiv gemachte Software wurde die Sache mit der Virtualisierung insgesamt populär. Der zusätzliche Vorteil der Virtualisierung gegenüber dem „BootCamp“-Ansatz war, dass man parallel zu seiner gewohnten Mac-Umgebung seinen „PC“ quasi mitlaufen lassen konnte – und wenn man wollte, sogar soviele davon gleichzeitig, bis CPU und Speicher in die Knie gingen. So manche Windows-Software für Spezialanwendungen wurde dadurch auch für Mac-User alltagstauglich erreichbar.

Dasselbe Windows 7 (x86) mit Parallels – wieder nur für Intel-Macs

Dazu kamen weitere Anbieter auf den Plan, die sich auch schon seit Ende der Neunziger mit Virtualisierung einen Namen gemacht hatten – unter anderem Virtual Box, eine Lösung, die (weitere Abschweifung) ganz früher mal einmal von der deutschen Firma InnoTek zur „Lebenserhaltung“ von OS/2 im deutschen Banken -und Versicherungswesen gestartet war und über Sun letztlich bei Oracle landete. Virtual Box ist heute freie Software und wird noch immer eifrig weiterentwickelt. Allerdings gibt es keine Version für ARM-Prozessoren und damit ist für Nutzer eines aktuellen Mac der Weg hier zu Ende. Weiter im Rennen bleiben Parallels und VMware, die jeweils ihre neuesten Versionen auch für die M-Macs anbieten.

Virtualisierung oder Emulation, der Unterschied

Alle oben genannten Lösungen machten sich jedoch zunutze, dass sich die Hardware eines Intel-Macs nicht mehr wesentlich von der eines Standard-PCs unterschied. Virtualisierung nutzt also lediglich eine in vielen Prozessor-Architekturen bereits seit Langem eingebaute Fähigkeit, mehrere Prozesse quasi gleichzeitig nebeneinander ausführen zu können. Dies beschränkt sich nicht nur auf die Verteilung von Aufgaben über mehrere Kerne, sondern die Funktionen sind trickreich so tief in die CPU-Architektur implementiert, dass sich selbst auf einem einzelnen CPU-Kern völlig unterschiedliche Betriebssysteme gut voneinander abgeschottet und dennoch gleichzeitig abwickeln lassen. Der virtuelle PC im Mac läuft also nahezu ungebremst nebenher, weil nichts in die Sprache einer anderen CPU-Technologie „übersetzt“ werden muss. Die dazu nötigen Steuerungsfunktionen bringt die CPU mit. Moderne Desktop-Betriebssysteme machen inzwischen von diesen Fähigkeiten auch für sich selbst Gebrauch. In einigen Windows-Systemen ist der sogenannte Hypervisor bereits seit Jahren eingebaut. OSX kennt dasselbe in Grundzügen ebenfalls schon seit Version 10.10, hat aber erst ab MacOS 12 (Monterey) angefangen, eine Schnittstelle dafür zu liefern. Von einer einfachen Nutzbarkeit für jedermann ist die jedoch noch weit entfernt.

Und dann gibt es QEMU. Auch dieses Opensource-Projekt ist sozusagen altehrwürdig. Es startete bereits vor über 20 Jahren und verfolgt bis heute einen weit sportlicheren Ansatz: Nicht etwa nur „Virtualisierung“ ist hier das Ziel, sondern bei Bedarf auch „Emulation“! Der ursprüngliche Anspruch war nichts Geringeres, als den Code einer beliebigen CPU-Architektur auf einer (fast) beliebigen anderen Architektur ausführen zu können (für die Nerds unter uns: Auf Basis der genialen Theorie der Turing-Vollständigkeit). Da QEMU viele Standard-Linux-Bibliotheken nutzt, ist es fast überall da lauffähig, wo auch Linux läuft – inzwischen aber natürlich auch unter Windows oder MacOS.

Bei diesem universelleren Ansatz können natürlich die Spezialitäten des darzustellenden Prozessors (z. B. spezielle Befehlssätze) nicht auf Hardwar-Ebenene ausgeführt werden, weil man davon ausgehen muss, dass die ausführende CPU die betreffenden Funktionen gar nicht kennt oder völlig anders macht. Und das geht schon mit so Grundlegendem los wie der Art und Weise, auf die die Prozessoren ihren Speicher zusammenzählen! So wird also die CPU und letztlich sogar die komplette Hardware-Umgebung des Zielsystems vollständig in Software nachgebaut: Was immer dazu nötig ist, das Zielsystem zu starten – jeder einzelne Funktionsaufruf wird abgefangen und nachgebaut. Auf diese Weise gelingt es dann aber, sogar historische Betriebssysteme für PowerPC, Sparc oder gar Motorola 68k- CPUs (oder eben einen Intel x86) mit allem Drum und Dran auf einem Computer mit ARM-CPU an den Start zu bringen. Es ist wohl relativ offensichtlich, dass wegen der dafür nötigen Abstraktionsschichten einiges an „Schwuppdizität“ verloren geht. Aber für die Nachbildung von 20 Jahre alter Hardware spielt das keine Rolle – die Emulation ist immer noch um Größenordnungen schneller. Bei der Emulation aktueller Intel-Prozessoren sieht die Sache schon anders aus, denn die sind ja „in Echt“ erheblich fixer und komplexer als das steinalte CPU-Design eines Sparc- oder PowerPC-Prozessors. Wunder dürfen hier also keine erwartet werden. Die Praxis zeigt aber, dass bereits ein Einstiegs-Mac der M-Klasse durchaus in der Lage ist, einen Windows 10 PC mit halbwegs aktueller Intel-Hardware in immer noch akzeptabler Geschwindigkeit nachzumachen – was eigentlich ein beeindruckender Beleg für die Leistungsfähigkeit dieser M- Prozessoren ist.

M4 Apple Silicon Specs

Was geht nicht auf „Apple-M“?

Wie wir sehen, ist es also recht nützlich, den Unterschied zwischen „Virtualisierung“ und „Emulation“ zu kennen, denn so lässt sich leichter verstehen, was man heutzutage mit einem M-Prozessor Mac erwarten kann – und was eher nicht. Aufgrund der oben beschriebenen Umstände wäre also kein aktueller Mac mehr in der Lage, „einfach so direkt“ Windows zu fahren – denn Windows wurde eben für die Intel-Welt geschaffen.
Würde man meinen.
Aber tatsächlich stimmt das so nicht ganz: Denn einem von Microsoft selbst einmal groß gestarteten, dann aber eher lieblos weiterentwickelten Produkt ist es zu verdanken, dass es schon seit Längerem auch eine Windows-Version für ARM- Prozessoren gibt. Microsoft hatte sie ursprünglich für eine eigene Linie von Surface-Tablets entwickelt und durchaus auch andere Hersteller animiert, auf den ARM-Zug aufzuspringen. Aber da die von Microsoft verwendeten ARM-Prozessoren nie die Leistungsklasse von Apples Varianten hatten und weil obendrein wahrscheinlich auch der Sourcecode von Windows/ARM nicht so punktgenau optimiert werden konnte, war das Ergebnis „eher so mittel“ und „Windows on ARM“ konnte auf diese Weise nie eine größere Verbreitung erreichen. Daher wurde es auch (meines Wissens) bisher nie offiziell als Einzelprodukt an Endkunden verkauft – es gab ja schliesslich auch keine „ARM-PCs zum Selberbauen“. Lediglich „Preview“-Versionen von Windows on ARM gab es bisher von Microsoft offiziell zum Download – eher gedacht für Software-Entwickler. Erst seit Neuestem scheint sich an dieser Situation etwas zu ändern. Microsoft kündigt gerade neue Windows- Versionen für ARM-Prozessoren an und es gibt diesmal im Gegensatz zu früher auch einige andere namhafte Hardware- Hersteller, die Notebooks auf ARM-Basis angekündigt haben, darunter bisher so treue Intel-Gefolgsleute wie Dell oder Lenovo. Hintergrund ist der aktuelle KI-Hype, den Microsoft unbedingt mitmachen will und für den man die in aktuellen ARM-Chipdesigns bereits eingebetteten „KI-Beschleuniger“ braucht, um damit z. B. gegen Apple einen Blumentopf zu gewinnen. Sowohl die CPUs von AMD als auch von Intel haben in dieser Hinsicht nämlich bisher noch nichts Konkurrenzfähiges anzubieten. Ob das Ganze diesmal abhebt, ist aber noch keineswegs sicher. Denn bizarrerweise behindert gerade ein juristischer Streit zwischen ARM (als Lizenzgeber) und der Fa. Qualcomm (einem der wichtigsten Hersteller von ARM- CPUs) die Planungssicherheit: Wegen Lizenzstreitigeiten verlangt ARM gerade nichts weniger als die Einstellung der Produktion von Qualcomms Snapdragon-X Prozessoren – mitsamt der Vernichtung aller bereits damit gebauten Geräte.

Abgesehen davon stand zumindest bisher einer wirklich sinnstiftenden Nutzung von „Windows on ARM“ auch der Mangel an nativen Windows-ARM–Anwendungen entgegen. Selbst Microsoft hielt es offenbar lange Zeit nicht für nötig, für sein Flaggschiff „Office“ eine dedizierte ARM-Version zu entwickeln, sondern vertraute stattdessen praktisch auf das gleiche Verfahren wie seinerzeit Apple mit Rosetta: Die Software läuft dann zwar, wird aber mittels einer im Betriebssystem verankerten Echtzeit-Übersetzung von Intel- auf ARM-Code „umgebogen“. Bei der „Windows on ARM“-VM auf einem aktuellen Mac würde damit also innerhalb der Virtualisierungsumgebung zusätzlich noch emuliert – was dazu führt, dass die betroffene Software im sowieso schon nicht pfeilschnellen „Windows on ARM“-System weiter einbegremst wird.

Warum aber könnte uns Anwender das Ganze interessieren – wenn’s letztlich ja doch „irgendwie läuft“? Nun – weil für die Frage, ob denn ein „M-Mac“ nun Windows „kann“ oder nicht, aufgrund der oben beschriebenen Gemengelage durchaus mehrere Antworten existieren. Und das provoziert natürlich Missverständnisse, um die sich dann die Marketingabteilungen der kommerziellen Software-Anbieter in ihrer Werbung winden wie die Aale. So ist es mit einem aktuellen VMware Fusion für M1-Macs (oder auch mit Parallels) zwar durchaus möglich, ein Windows in der VM zu fahren – nur eben genau nicht das Windows, was wir alle noch „von früher im Schrank haben“ – nämlich das für Intel- Prozessoren. Mit den früheren Intel-Versionen haben das VMware Fusion oder Parallels für aktuelle Macs daher eigentlich nur noch den Namen gemein.

Genausowenig ist es derzeit möglich, seinen „real existierenden“ Intel-PC so wie früher per Konvertierprogramm in eine VM zu überführen und dann im M-Mac weiterleben zu lassen. Denn die genannten Lösungen sind eben „nur“ Virtualisierer und keine Emulatoren – der Umzug in eine fremde Prozessorwelt ist also gar nicht machbar. Als Plattform für den Start z. B. eines „klassischen“ Windows 98 Systems scheiden Lösungen wie das aktuelle Parallels oder Fusion daher leider aus. Noch dazu ist nicht einmal immer sicher, dass wirklich jede für Intel-CPUs programmierte Windows- Anwendung auch auf der ARM-Windows- VM läuft. Zwar tut Microsofts „Rosetta“ innerhalb der VM sein Bestes, um den fremden Code des Programmes zu adaptieren. Das Ganze hat aber seine Grenzen, sobald zum Beispiel eine Applikation auf mehr als die üblichen Feld-Wald-und-Wiesenfunktionen im Betriebssystem angewiesen ist. Der Knackpunkt sind spätestens die Treiber für bestimmte Hardware, die vielleicht weiter benutzt werden wollte. Dann hört der Spaß meist völlig auf, weil Hardware-Treiber in der Regel weiter unten im Betriebssystem ansetzen. Wenn es also keine dedizierten ARM-Treiber für das betroffene Gerät gibt, dann kann es auch mit der VM nicht laufen.

Eine solcherart virtualisierte Windows-Umgebung auf dem M-Mac dürfte daher nur in Spezialfällen die Lösung sein – wenn zum Beispiel auch die Anwendung bereits explizit für „Windows on ARM“ programmiert wurde. Der frühere Weg, Windows einfach mittels „Bootcamp“ direkt zu starten, scheidet übrigens bisher komplett aus: Diese Funktion wurde von Apple gestrichen, obwohl sie für ein ARM-Windows ja durchaus ähnlich hätte funktionieren können.

Welche Windows-Möglichkeiten gibt es für APPLE M-Prozessoren?

Für „Hüter verlorender Schätzchen“ wären das alles schlechte Aussichten – gäbe es da nicht noch eine gute Nachricht und die heisst „UTM“!

UTM in Aktion: Rechts ein Windows7(x86), links startet ein „historisches“ MacOS9 für PowerPC!

UTM ist ein Projekt, das in letzter Zeit zusammen mit den M-Macs enorm Fahrt aufgenommen hat. Es hat sich zur Aufgabe gemacht, eine einfach zu bedienende und zeitgemäße grafische Oberfläche für das oben erwähnte QEMU zu liefern. Denn QEMU selbst kann zwar vieles, aber seine Bedienung ist – vornehm formuliert – spröde, und es erschließt sich nur Kommandozeilen-Akrobaten so ohne weiteres. Genau da setzt UTM ein. Man kann sich UTM auf „mac.getutm.app“ (oder wenn man sich dabei besser fühlt auch im AppStore) herunterladen, installiert ist das Ganze in wenigen Minuten. Zur Illustration der Möglichkeiten wird auf dieser Website auch eine Galerie fertiger Virtueller Systeme angeboten – mit der Möglichkeit zum Download bzw. mit Anleitungen, wie beispielsweise Windows der verschiedensten Versionen zu installieren wäre (fertige Windows-Versionen können ja hier nicht angeboten werden).
UTM stellt sich nun recht geschickt an: All jene Betriebsysteme, die „nativ“ für ARM-Architekturen geschrieben wurden, werden virtualisiert und laufen daher nahezu ungebremst. Sofern eine im Betriebssystem eingebaute Virtualisierungsschnittstelle zur Verfügung steht, wird die angezapft. Alles andere läuft (weitgehend) auch, wird dann aber emuliert. Daher fühlen sich natürlich aktuelle Intel- Windows-Versionen deutlich zäher als gewohnt an – schließlich fehlen zum Beispiel die nötigen Schnittstellen zur Ansteuerung von Grafikbeschleunigern. Für Spiele ist eine emulierte VM also eher nichts, aber das Arbeiten mit Standard-Software gelingt durchaus.

UTM: In drei Schritten zur neuen VM: Hier geht beides – Virtualisieren UND Emulieren!

Die Methoden zum Netzwerk-Sharing oder dem Datenaustausch zwischen VM und Hauptbetriebssystem, wie man sie von den klassischen Virtualisierern gewohnt ist, sind (noch) nicht so ausgefeilt wie die der klassischen Virtualisierer. Auch das „Hereinreichen“ von USB-Geräten steckt wohl noch in den Kinderschuhen (kein Wunder angesichts der schon erwähnten Schwierigkeiten mit systemnahen Treibern).  Aber immerhin – ein Windows (x86) auf Mac (M) funktioniert!

Und zumindest eine Möglichkeit zum Import bereits vorhandener VM existiert auch schon: UTM kann XVHD-Dateien einlesen (das Microsoft-Format für virtuelle Festplatten) – womit man VMs, die vorher auf Microsofts HyperV liefen, vielleicht etwas einfacher übernehmen kann. Als „Zückerli“ aber gehen dann mit UTM sogar Sachen, die kein reiner Virtualisierer schafft –  zum Beispiel ein MacOS 9.2 für PowerPC aus dem Jahre 1998 auf aktueller Hardware laufen lassen oder ein Sun Solaris 9 für SPARC-Prozessoren – da schlägt das Herz des Nerds höher.

Die UTM-Website bietet sogar einige fertige VM zum Download an, für Windows gibt’s Anleitungen

Alles in allem scheint mir UTM trotz aller oben genannter Baustellen der zurzeit vielversprechendste Ansatz zu sein, um „historische“ VM in M-Macs weiter am Leben erhalten zu können. Und ich bin auch zuversichtlich, dass wir von UTM/QEMU in der nächsten Zeit noch einige nette neue Features sehen werden. Von den reinen Virtualisierern ist das (zumindest für die Unterstützung klassischer Intel-Betriebssysteme) eher nicht zu erwarten – prinzipbedingt.

Gibt es Alternativen, die unter Apple M-Prozessoren laufen?

Oh ja, die gibt es. Allerdings hängt das von der eigentlichen Aufgabe ab. Wenn es nur darum geht, eine einzelne Windows-App irgendwie auf dem eigenen Mac zum Fliegen zu bekommen, weil es vielleicht bis heute keine adäquate Mac-Version davon gibt, dann reicht womöglich ein etwas anderer Ansatz: Bereits seit Jahrzehnten gibt es das Opensource- Projekt WINE, das einmal gestartet wurde, um Windows-Anwendungen unter Linux benutzen zu können. Anstatt nun das komplette Betriebssystem nachzumachen, beschränkte man sich bei WINE darauf, „einfach nur“ jeden Funktionsaufruf der Windows-Programme abzufangen und dann sozusagen sinngemäß abzuarbeiten. Es gibt einen kommerziellen Anbieter, der dieses Opensource-Projekt unterstützt und ein eigenes kostenpflichtiges Produkt drumherum gebaut hat: Codeweavers. Mit „Crossover Mac“ macht Codeweavers seit Jahren das Angebot, bestimmte (beileibe nicht alle!) Windows-Programme direkt auf dem Mac auszuführen. Technologisch interessant ist, dass dabei kein Unterschied bei der CPU- Architektur gemacht wird – die Abstrahierung setzt einfach so weit „oben“ an, dass CrossoverMac das Rosetta2-Framework von MacOS für die Übersetzung des Intel-Codes der Windows-Programme nutzen kann.

WinRAR direkt auf MacOS – dank Crossover Mac

Ob das gewünschte Windows-Programm eine Chance hat, kann man womöglich auf der Website des Herstellers herausfinden. Dort wird bereits seit Jahren eine Datenbank mit Testergebnissen gepflegt, die relativ zuverlässig ist. Leider muss man aus Erfahrung auch sagen, dass die meisten dort gelisteten Programme „gut abgehangene Software“ sind und es selten vorkam, dass ein Programm dann in einer späteren Version von CrossoverMac mal lief, wenn es früher nicht lief.

Oder einfach auslagern?

Obwohl es vielleicht auf den ersten Blick am Thema etwas vorbei schießt, sei hier trotzdem darauf eingegangen, was man denn noch tun könnte, um seine Sammlung virtueller Intel-Systeme möglichst ohne großen Aufwand zu retten – obwohl man mit seinem Mac womöglich schon auf M-Technologie gewechselt ist? Das wird schwierig. Leider gibt es bisher wie oben erwähnt zum Beispiel noch keinen bequemen Weg, mit dem man eine vorhandene Intel-VM aus Parallels oder VMware Fusion in UTM importieren könnte. Hier steckt noch vieles in den Kinderschuhen. Ich bin zwar zuversichtlich, dass die Community um UTM sich dieser Sache mal annimmt, weil angesichts hunderttausender installierter „Bestands-Intel-VM“ der Bedarf ja naheliegt. Bis dahin ist aber ein einfacher Weiterbetrieb alter Intel-VM auf einem aktuellen Mac mit ARM-Prozessor – zumindest für „Normalsterbliche“ ohne tiefe Systemkenntnisse – noch praktisch unmöglich.

Unitor8 Control (ein PowerPC- Universal Binary!) auf OSX10.5 für Intel – ferngesteuert über Fusion auf M1-Mac

Bis es einmal soweit ist, könnte aber ein zugegeben etwas bauernschlauer Trick helfen: Man versucht erst gar nicht, die Systeme auf seinem neuen Computer zum Laufen zu kriegen, sondern baut sich stattdessen ein dediziertes Intel-System, das ausschliesslich zum Betrieb von VMs dient und vom Mac aus ferngesteuert werden kann – man nennt sowas auch „Barebone-Virtualisierer“. Dazu organisiert man sich einen halbwegs aktuellen Intel-PC, der ausreichend RAM und Festplattenplatz hat und installiert dort eine Lösung wie Proxmox oder VMware ESXi. Schon mit einem kleinen Intel NUC der Generationen ab ca. 2018 kommt man da erstaunlich weit – und im Falle solcher Mini-PCs verbrät das Ganze auch erstaunlich wenig Platz und Strom. Die Steuerung des Virtualisierers geht dann bequem über einen Webbrowser. Die VMs könnte man ebenfalls über den Browser bedienen, viel eleganter ist allerdings zum Beispiel das Gespann aus ESX(i) und VMWare Fusion – denn in Fusion eingebaut ist seit jeher auch die Fernsteuerung von ESX-Servern. Damit bekommt man sogar die begehrte Durchleitung von USB-Geräten frei Haus: Alles, was direkt am M-Mac steckt, kann dann auch in eine VM weitergereicht werden. Auf diese Weise war es mir sogar möglich, meine 25 Jahre alte Unitor8- Kette via USB an eine OSX10.5 „Leopard“-VM durchzureichen, auf der dann die originale „Unitor8 Control“ Software von ca. 2002 lief und die Geräte programmieren konnte. Dazu wäre zu bemerken, dass Unitor8 Control eigentlich ein PowerPC-Universal Binary ist, das von OSX 10.5 per Rosetta übersetzt wird – absolut verrückt, aber faszinierend … siehe Bild oben!