Laufen Business-Anwendungen unter Windows on Arm? ── Die Realität von x64-Emulation (Prism) und nativen DLLs/COM

„Ab nächstem Monat wechseln wir auf einen neuen PC, einen dieser Copilot+-PCs – läuft unser Geschäftssystem darauf?“ Mit der zunehmenden Verbreitung von Snapdragon-basierten PCs in Unternehmen erreicht diese Frage immer mehr Entwicklungsteams und IT-Abteilungen. Die Marketing-Aussage lautet: „Bestehende Anwendungen laufen ebenfalls, per Emulation.“ Doch die eigene Business-Anwendung ruft hinter ihrer C#-Oberfläche per P/Invoke eine vom Hersteller gelieferte native DLL auf, erzeugt Berichte über eine COM-Komponente und hat obendrein einen Treiber für dedizierte Hardware installiert. Ehrlich gesagt lässt sich „läuft das?“ nicht aus dem Stegreif beantworten.

Die kurze Antwort vorweg: „Die Anwendung selbst läuft in der Regel problemlos. Gefährlich ist alles, was an ihr hängt.“ Die Emulation von Windows 11 verarbeitet x86/x64-Code im Benutzermodus mit ziemlich beeindruckender Genauigkeit, doch es gibt eine klar umrissene Zone „außerhalb der Zuständigkeit der Emulation“, bestehend aus Treibern, Shell-Erweiterungen und der Vermischung von Architekturen innerhalb eines Prozesses – und ausgerechnet diese Zone ist genau der Ort, an dem sich Business-Anwendungen historisch besonders gerne aufgehalten haben.

Dieser Artikel arbeitet auf, wie die Emulation von Windows on Arm funktioniert und wo ihre Grenzen liegen, welche grundlegende Regel besagt, dass sich x64 und Arm64 innerhalb eines Prozesses nicht mischen lassen, welches Kombinationsproblem speziell .NET-Anwendungen betrifft, und welche praktischen Schritte zur Prüfung von „läuft unsere Anwendung auf einer Arm-Maschine“ führen – alles gestützt auf das, was sich in Microsoft Learn nachprüfen lässt.

1. Das Wichtigste zuerst

• Eine rein verwaltete (.NET-)Anwendung oder eine gewöhnliche x86/x64-Desktopanwendung läuft unter der Emulation von Arm Windows 11 fast durchweg problemlos. Die Emulation ist im Betriebssystem eingebaut – es ist weder eine Anpassung der Anwendung noch eine zusätzliche Komponente nötig.¹
• Die Emulation kümmert sich ausschließlich um Code im Benutzermodus. Kernelmodus-Treiber werden nicht emuliert und benötigen unbedingt native Arm64-Builds. UMDF-Treiber und Druckertreiber müssen ebenso zur Architektur des Betriebssystems passen.²³
• Shell-Erweiterungen, IMEs, assistive Technologien – alles, was eine „in einen anderen Prozess geladene DLL“ ist (Explorer und Ähnliches) – muss ebenfalls passend zum System für Arm64 neu kompiliert werden. Die Emulation kann hier nicht helfen.⁴
• x64 und Arm64 können nicht innerhalb eines einzigen Prozesses koexistieren. Ein x64-/Arm64EC-Prozess kann nur x64- und Arm64EC-Binärdateien laden; ein Arm64-Prozess nur Arm64-Binärdateien. Eine x64-EXE kann keine Arm64-DLL aufrufen, und umgekehrt geht es ebenso wenig.⁵
• Die Mechanismen, um diese Beschränkung innerhalb einer einzelnen Datei zu umgehen, sind Arm64EC (nativer Arm64-Code, der im selben Prozess mit x64 koexistieren kann) und Arm64X (eine Binärdatei, in der Arm64- und Arm64EC-Code in einer PE-Datei koexistieren und die in beide Prozesstypen geladen werden kann). Arm64X ist genau der Ort, an dem ein COM-In-Process-Server oder ein Plugin, das von beiden Architekturen aus aufgerufen wird, ins Spiel kommt.⁵⁶
• .NET unterstützt Arm64 offiziell, und Sie können nativ mit der RID win-arm64 veröffentlichen. Andererseits läuft eine AnyCPU-Anwendung auf einer Arm64-.NET-Laufzeit als Arm64-Prozess, sodass das Laden fehlschlägt, wenn Sie per P/Invoke eine native DLL ansprechen, die nur als x64 verfügbar ist – ein Kombinationsproblem, das man kennen sollte.⁷⁸⁵
• Neben physischer Hardware (etwa einem Copilot+-PC) lässt sich eine Testumgebung mit einer Windows-11-Arm64-VM auf Azure oder dem Windows-11-Arm64-ISO einrichten, nutzbar auf Hyper-V auf einer Arm-Maschine oder auf einem Apple-Silicon-Mac. Beachten Sie, dass Sie auf Hyper-V unter einer x64-Maschine keine Arm64-VM erstellen können.⁹¹⁰

2. Was Windows on Arm ist — Snapdragon-PCs und Prism

Windows on Arm ist Windows, das auf einem Arm64-Prozessor läuft. Seit 2024 setzen die meisten „Copilot+-PCs“ – eine neue Kategorie von Windows-11-Geräten mit einer NPU, die mehr als 40 Billionen Operationen pro Sekunde (40+ TOPS) leistet – auf Arm-basierte Chips der Snapdragon-X-Serie, wodurch dieses Thema für Entwicklerinnen und Entwickler nicht mehr zu ignorieren ist.¹¹¹²

Grundlage der Kompatibilität mit bestehenden Anwendungen ist eine im Betriebssystem eingebaute Emulation. Hier eine kurze Erklärung, wie sie funktioniert.¹

• Der Emulator kompiliert Blöcke von x86/x64-Befehlen per JIT in Arm64-Befehle und zwischenspeichert das übersetzte Ergebnis pro Modul, sodass spätere Starts schneller ablaufen.
• Windows 11 kann sowohl x86 als auch x64 emulieren. Windows 10 on Arm kann nur x86 emulieren, sodass jede Diskussion über x64-Business-Anwendungen faktisch Windows 11 voraussetzt.
• Windows 11 24H2 führte einen neuen Emulator namens Prism ein, der gegenüber dem vorherigen die Leistung verbessert und die CPU-Auslastung senkt. Prism ist auf Qualcomm-Snapdragon-Chips optimiert.
• 32-Bit-Anwendungen (x86) laufen über dieselbe WOW64-Schicht wie unter x64-Windows und erhalten eine Umleitung von Dateisystem und Registrierung. x64-Anwendungen hingegen haben keine WOW64-Schicht – da Systembinärdateien im weiter unten beschriebenen Arm64X-Format kompiliert sind, können x64-Anwendungen ohne Umleitung auf das gesamte Betriebssystem zugreifen (sowohl Dateisystem als auch Registrierung).¹

Die von einer unter Emulation laufenden Anwendung sichtbaren CPU-Informationen sind die des „emulierten virtuellen Prozessors“. Aus Kompatibilitätsgründen gibt selbst GetNativeSystemInfo den emulierten Wert zurück; möchten Sie feststellen, ob der Host tatsächlich Arm64 ist, verwenden Sie IsWow64Process2 oder GetMachineTypeAttributes.¹³

Für Anwendungen, die unter der Emulation Probleme bekommen, bietet Windows außerdem die Möglichkeit, Emulationseinstellungen zu ändern (Voreinstellungen Standard/sicher/streng/sehr streng sowie einzelne feingranulare Optionen), indem Sie mit der rechten Maustaste auf die EXE klicken, zu Eigenschaften gehen und den Reiter Kompatibilität öffnen. Das erkauft Kompatibilität mit etwas Leistung, ist aber als Notausgang für den Fall „das lief unter einer älteren Version von Windows on Arm noch“ einen Blick wert.¹⁴

3. Was unter Emulation läuft — und was nicht

Die Antwort auf „läuft das?“ bestimmt nicht die Anwendung selbst, sondern die Art der beteiligten Abhängigkeit. Hier eine Entscheidungstabelle.

Übersetzt in die Begriffswelt von Business-Anwendungen sehen die Warnsignale so aus:

• VPN-Clients, Asset-Management-Agenten, Sicherheitsprodukte – das sind im Wesentlichen Bündel von Kernel-Treibern. Sie müssen beim Hersteller prüfen, ob eine Arm64-unterstützte Version existiert.
• Lizenzdurchsetzung über USB-Dongles, dedizierte Hardware (Messgeräte, Zahlungsterminals usw.) – ob ein Arm64-Gerätetreiber bereitgestellt wird, ist hier der entscheidende Faktor.
• Tools, die „dem Explorer eine Funktion hinzufügen“ – Shell-Erweiterungen werden in den Arm64-Explorer geladen, sodass sie schlicht nicht funktionieren, solange sie x64 bleiben.
• Auch wenn die Anwendung selbst nicht in diese Kategorien fällt, tritt dasselbe Problem auf, wenn der Installer einen Treiber mitbringt (etwa eine über einen virtuellen Druckertreiber realisierte PDF-Ausgabe).

4. Das Mischen von Architekturen innerhalb eines Prozesses ist unmöglich — die Realität von P/Invoke und COM

Seit der 32-Bit-Ära gilt eine eiserne Regel: „Ein 64-Bit-Prozess kann keine 32-Bit-DLL laden.“¹⁶ Windows on Arm besitzt eine äquivalente strukturelle Regel. Die offizielle Dokumentation legt die Ladekompatibilität wie folgt dar.⁵

Hier tauchen zwei Mechanismen auf, die der Schlüssel zum Durchdenken des Arm-Bereitschafts-Designs sind.

• Arm64EC (Emulation Compatible) ist eine native Arm64-Code-ABI, die der Aufrufkonvention, Stack-Nutzung und dem Datenlayout von x64 folgt, sodass sie im selben Prozess mit unter Emulation laufendem x64-Code koexistieren kann. Läuft eine x64-Anwendung unter Windows 11 on Arm, ist der Großteil des in diesen Prozess geladenen Betriebssystemcodes bereits als Arm64EC kompiliert und läuft mit nativer Geschwindigkeit, ohne dass die Anwendung davon etwas mitbekommt. Das ermöglicht einen schrittweisen Migrationspfad – zunächst nur den eigenen Code Stück für Stück in Arm64EC umzuwandeln, um Leistung zu gewinnen, während abhängige DLLs x64 bleiben.⁵
• Arm64X ist ein Binärformat, das klassischen Arm64-Code und Arm64EC-Code in einer einzigen PE-Datei koexistieren lässt. Je nachdem, ob der ladende Prozess x64 oder Arm64 ist, verhält es sich wie eine x64-DLL beziehungsweise eine Arm64-DLL, was es gut geeignet macht für eine DLL, die möglicherweise von Prozessen beider Architekturen aufgerufen wird. Die offizielle Dokumentation nennt „einen 64-Bit-COM-Server, der sowohl von x64- als auch von Arm64-Anwendungen aufgerufen wird“, „ein Plugin, das sowohl in x64- als auch in Arm64-Anwendungen geladen wird“ und „eine einzelne Binärdatei, die in x64-/Arm64-Prozesse injiziert wird“ als Situationen, in denen Arm64X benötigt wird.⁶

Machen wir die realen Auswirkungen auf Business-Anwendungen konkret.

Fall 1: eine x64-EXE plus eine native x64-DLL (P/Invoke). Ist der gesamte Prozess einheitlich x64, läuft er vollständig innerhalb der Emulation. Sie können nicht einfach deshalb eine Arm64-DLL beimischen, weil „nur dieser eine Teil“ schneller sein soll (wie die obige Tabelle zeigt, ist das schlicht nicht ladbar).

Fall 2: ein COM-In-Process-Server. Ein COM-In-Proc-Server ist einfach eine DLL, sodass die obige Tabelle direkt gilt. Ein x64-Client kann nur eine x64- (oder Arm64EC-/Arm64X-)COM-DLL verwenden, und sobald Sie die Anwendung Arm64-nativ machen, wird die x64-COM-DLL nicht mehr ladbar. Benötigen Sie Unterstützung für beides, machen Sie die DLL entweder Arm64X, oder wenden Sie das bewährte Muster aus der 32-Bit-/64-Bit-Ära an: die Trennung in Prozess-externes COM/IPC (Aufteilung in separate, über Interprozesskommunikation verbundene Prozesse). Eine Architekturgrenze an einer Prozessgrenze zu überschreiten, war schon immer der Standardansatz.¹⁶⁶

Fall 3: Sie hosten ein Plugin oder sind selbst ein Plugin. Excel-Add-ins, Plugins für Business-Paketsoftware, Druck-Middleware und jede andere Form, bei der „Ihre DLL in den Prozess einer anderen Anwendung geladen wird“, muss zur Architektur des Gegenübers passen. Umgekehrt müssen Sie, wenn Ihre eigene Anwendung Plugins hostet, den Wirkungsradius durchdenken: Machen Sie Ihre eigene Anwendung Arm64-nativ, fallen sämtliche x64-Plugins Dritter aus.

Übrigens können Sie über eine Developer Command Prompt prüfen, welche Architektur eine bestimmte Binärdatei tatsächlich hat.⁵

link /dump /headers MyLibrary.dll | findstr machine
# 8664 machine (x64)            -> x64
# 8664 machine (x64) (ARM64X)   -> enthält Arm64EC
# AA64 machine (ARM64)          -> Arm64
# AA64 machine (ARM64) (ARM64X) -> Arm64X

5. Der Fall von .NET-Anwendungen — die AnyCPU-Falle und die Architekturerkennung

.NET (die Core-Familie der Laufzeit) unterstützt Windows Arm64 offiziell, und Windows 11/10 Arm64 wird für .NET 8/9/10 ausdrücklich als unterstütztes Betriebssystem aufgeführt. Für die Veröffentlichung genügt es, win-arm64 als RID anzugeben.¹⁷⁷

<!-- csproj: Veröffentlichung für nativ Arm64 -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

Für eine Anwendung, die vollständig aus verwaltetem Code besteht, ist das im Wesentlichen die gesamte Arbeit, um sie Arm64-nativ zu machen. Der JIT erzeugt einfach Arm64-Code, und in der Regel sind keine Quellcodeänderungen nötig. Für .NET-Framework-Anwendungen hat .NET Framework 4.8.1 native Arm64-Unterstützung hinzugefügt (für Arm64-Maschinen unter Windows 11 – die 4.8.1-Laufzeit unterstützt native Arm64-Anwendungen auf Windows-10-Arm-Maschinen nicht). Eine Framework-Anwendung, die weiterhin als x64 gebaut wird, gilt als unter Emulation laufend.¹⁸¹⁹

Das Problem ist die Kombination, die entsteht, wenn Sie per P/Invoke eine native DLL ansprechen. Auf einer Arm-Maschine wird die lang gehegte Annahme „es ist eine .NET-Anwendung, also läuft AnyCPU einfach überall“ enttäuscht.

• Läuft die Anwendung unter einem Arm64-.NET-SDK/einer Arm64-.NET-Laufzeit, läuft sie standardmäßig als Arm64-Prozess.⁸
• Ein Arm64-Prozess kann keine x64-DLL laden (siehe die Tabelle in Kapitel 4). Mit anderen Worten: Ihr eigener AnyCPU-Code bleibt unangetastet, aber das Laden der per DllImport angesprochenen x64-nativen DLL schlägt fehl.⁵
• Umgekehrt läuft eine als win-x64 veröffentlichte Anwendung vollständig als x64-Prozess und funktioniert innerhalb der Emulation (samt nativer DLL). Diese Konfiguration erreicht keine native Arm64-Leistung, bietet aber die höchste Kompatibilität.¹²

Was wie „mal geht’s, mal nicht“ aussieht, ist meistens tatsächlich eine Nichtübereinstimmung zwischen der Architektur des Prozesses und der Architektur seiner nativen Abhängigkeiten. Als erster Schritt zur Eingrenzung hilft es enorm, Code zur Hand zu haben, der meldet, welche Architektur der laufende Prozess tatsächlich verwendet.

using System.Runtime.InteropServices;

// Die eigene Architektur des Prozesses (X64, falls unter x64-Emulation laufend)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// Die tatsächliche zugrunde liegende Architektur des Betriebssystems (Arm64 auf einer Arm-Maschine)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

Ein Punkt, auf den Sie achten sollten: OSArchitecture liefert erst ab .NET 7 die „tatsächliche, um die Emulation bereinigte zugrunde liegende Betriebssystemarchitektur“. Davor gab es auch unter Emulation X64 zurück, sodass Code unter .NET 6 oder früher, der diese API zur Erkennung von „ist dies eine Arm-Maschine?“ verwendet, nicht wie erwartet funktioniert.²⁰²¹

Hier eine Übersicht der .NET-spezifischen Prüfpunkte.

• Native Assets in NuGet-Paketen: Ein Paket, das nur runtimes/win-x64/native mitführt, hat nichts, worauf es beim Veröffentlichen für win-arm64 zurückgreifen kann. Prüfen Sie den Paketinhalt (oder dessen Repository) auf das Vorhandensein von win-arm64-Assets. Der RID-Mechanismus existiert genau für dieses „Routing zu plattformspezifischen Assets“.⁷
• Das SDK-Layout auf der Entwicklungsmaschine: Auf einer Arm-Maschine installiert sich der Arm64-Build von .NET normalerweise unter C:\Program Files\dotnet\, während sich das x64-SDK unter C:\Program Files\dotnet\x64\ installiert; beide können koexistieren. Welches davon dotnet run tatsächlich ausführt, hängt davon ab, wohin PATH oder DOTNET_ROOT zeigen – behalten Sie das beim Testen im Hinterkopf.¹⁷
• Wie Sie die Ausnahme lesen: Eine Architektur-Nichtübereinstimmung in einer verwalteten Assembly zeigt sich als BadImageFormatException (die offizielle Referenz selbst nennt ausdrücklich „das Laden einer Komponente, die auf eine andere Plattform abzielt“ als Auslösebedingung).²²

6. Eine Checkliste zur Arm-Bereitschaft der eigenen Anwendung

In der Praxis ist es effizient, in folgenden drei Stufen zu prüfen.

Für die Stufen 2 und 3 stehen Ihnen folgende Optionen für eine Testumgebung zur Verfügung.

• Physische Hardware: eine Snapdragon-basierte Maschine wie ein Copilot+-PC. Auch nur eine davon zur Hand zu haben, ist die verlässlichste Option, auch für die Fehlersuche.¹²
• Azure-VM: Im Azure-Portal Images nach Arm64 filtern und eine Windows-11-Arm64-VM erstellen (eine empfohlene Größe wie D2ps_v5, basierend auf Ampere Altra). Der Vorteil: Sie können mit dem Testen beginnen, ohne selbst eine einzige Arm-Maschine zu besitzen.⁹
• Lokale VM: Ein Windows-11-Arm64-ISO wird offiziell verteilt, und Sie können eine VM auf Hyper-V auf einer Arm-Maschine oder auf einem Arm-basierten Apple-Silicon-Mac aufbauen. Beachten Sie: Hyper-V auf einer x64-Maschine kann keine Arm64-VM erstellen.¹⁰

Die Kompatibilität von Drittanbieterprodukten können Sie auf der von Microsoft veröffentlichten Statusseite prüfen (Works on Windows on Arm), und bei Kompatibilitätsproblemen von Fachanwendungen (LOB-Apps) bietet das Programm App Assure für qualifizierende Unternehmenspläne kostenlosen zusätzlichen Support. Einen offiziellen Kanal zur Hand zu haben, bevor Sie bei „es funktioniert nicht und wir kommen nicht weiter“ landen, ist auch nützliches Material, um die Lage gegenüber der IT-Abteilung zu erklären.¹²¹⁵

7. Eine pragmatische Antwort für den Moment — die Wahl zwischen drei Optionen

Arm-bereit zu sein bedeutet nicht „vollständig nativ, keine andere Wahl“. Tatsächlich ist für viele Business-Anwendungen ein gestuftes, situationsabhängiges Vorgehen die pragmatische Antwort.

Wenn Sie über eine große C++-Codebasis verfügen, gibt es zwischen (a) und (c) einen Mittelweg: Arm64EC. Es ist der offizielle Weg für den Fall, dass „wir eine riesige x64-Anwendung nicht auf einen Schlag migrieren können“ – Sie lassen abhängige x64-DLLs unverändert, während Sie nur Ihren eigenen Code Stück für Stück nativ portieren.⁵²³

Auf der Werkzeugseite gibt es eine native Arm64-Version von Visual Studio sowie ein auf Arm-Hardware verfügbares Compiler-Toolset, das gleichzeitig Arm64, x64 und x86 als Ziel adressieren kann. CI-Builds lassen sich auch per Cross-Compilation auf einer bestehenden x64-Build-Maschine erzeugen, sodass sich leicht eine Konfiguration einrichten lässt, bei der „nur der Testlauf“ auf echter Arm-Hardware oder einer VM stattfindet.²⁴²³

8. Zusammenfassung

• Arm Windows 11 kann x86/x64-Anwendungen über eine im Betriebssystem eingebaute Emulation ausführen, und die Leistung hat sich mit Prism ab 24H2 weiter verbessert. Die x64-Emulation ist eine Funktion von Windows 11 – Windows 10 on Arm verarbeitet nur x86.
• Die Zuständigkeit der Emulation beschränkt sich auf den Benutzermodus. Kernelmodus-/UMDF-/Druckertreiber sowie „in einen anderen Prozess geladene DLLs“ wie Shell-Erweiterungen, IMEs und assistive Technologien benötigen unbedingt native Arm64-Builds. Ob eine Business-Anwendung funktioniert, bestimmt weniger die Anwendung selbst als diese umgebenden Abhängigkeiten.
• x64 und Arm64 können nicht innerhalb eines Prozesses koexistieren. Ein x64-/Arm64EC-Prozess kann x64 plus Arm64EC laden; ein Arm64-Prozess nur Arm64. Sowohl COM-In-Process-Server als auch Plugins folgen derselben Regel – Arm64X ist die Standardantwort für die Unterstützung beider Architekturen, und Prozess-externes COM/IPC ist die Standardantwort für das Überschreiten einer Prozessgrenze.
• .NET kann nativ mit win-arm64 veröffentlicht werden, doch eine AnyCPU-Anwendung, die auf der Arm64-Laufzeit läuft, läuft als Arm64-Prozess und schlägt daher fehl, wenn sie per P/Invoke eine nur als x64 verfügbare native DLL anspricht. Zur Eingrenzung dienen RuntimeInformation.ProcessArchitecture / OSArchitecture (Letzteres ab .NET 7).
• Das Verifikationsverfahren ist ein dreistufiger Ablauf: „Abhängigkeiten inventarisieren -> unverändert unter Emulation auf echter Hardware testen -> bei Bedarf nativ Arm64 werden.“ Eine Testumgebung lässt sich über eine Azure-Arm64-VM oder das Arm64-ISO einrichten, und Unternehmen können zusätzlich auf den Support von App Assure zurückgreifen.
• Für den Moment lautet die pragmatische Antwort ein situationsabhängiger Mix: „läuft es unter Emulation, unverändert belassen“, „bei Treiber-/DLL-Herstellern den Unterstützungsstatus erfragen“ und „bei entsprechenden Anforderungen nativ Arm64 werden (bei C++ ist auch der gestufte Arm64EC-Migrationspfad möglich)“.

Verwandte Artikel

• Eine native DLL aus C# aufrufen: C++/CLI-Wrapper vs. P/Invoke
• Die Win32-API sicher aus C# aufrufen — ein praktischer P/Invoke-Leitfaden (DllImport / LibraryImport / CsWin32)
• Wie man eine C#-Native-AOT-DLL aus C/C++ aufruft
• Single-File-Distribution für Windows-Anwendungen — Einzelbinärdateien und die Grenzen von OS-Abhängigkeiten
• Ein durchgerechnetes COM-Brücken-Beispiel: eine 64-Bit-DLL aus einer 32-Bit-Anwendung aufrufen

Verwandte Beratungsleistungen

Komura Software LLC übernimmt die Untersuchung, ob eine bestehende Business-Anwendung Arm-bereit ist, den Entwurf von Architekturmigrationen für Anwendungen mit nativen DLLs oder COM-Interop sowie die Ursachenanalyse von Fehlern, die nur auf Arm-Maschinen auftreten.

• Windows-App-Entwicklung
• Technische Beratung und Design-Review
• Fehleranalyse und Ursachenermittlung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Läuft eine gewöhnliche x64-Business-Anwendung unter Windows on Arm?

In den meisten Fällen ja. Windows 11 on Arm verfügt über eine integrierte Emulation, die x86/x64-Anwendungen unverändert ausführt, und seit Windows 11 24H2 verbessert ein neuer Emulator namens Prism zusätzlich die Leistung. Die Emulation kümmert sich jedoch ausschließlich um Code im Benutzermodus – Treiber im Kernelmodus sowie Shell-Erweiterungen, IMEs und Ähnliches, die in andere Prozesse wie den Explorer geladen werden, benötigen unbedingt native Arm64-Builds. Betrachten Sie es weniger als Frage zur Anwendung selbst, sondern eher als Frage zu dem, was an ihr hängt.

Kann eine x64-EXE eine Arm64-DLL aufrufen?

Nein. Innerhalb eines einzelnen Prozesses lassen sich x64- und Arm64-Binärdateien nicht mischen: Ein x64-Prozess (oder Arm64EC-Prozess) kann nur x64- und Arm64EC-Binärdateien laden, ein Arm64-Prozess nur Arm64-Binärdateien. Die umgekehrte Richtung – eine Arm64-EXE ruft eine x64-DLL auf – ist ebenso unmöglich. Benötigen Sie unbedingt eine einzelne DLL, die beides unterstützt, stehen Ihnen Arm64X zur Verfügung, ein Format, in dem Arm64- und Arm64EC-Code in einer Datei koexistieren, oder die Aufteilung in separate Prozesse mit Kommunikation über IPC.

Was ist nötig, um eine .NET-Anwendung Arm64-tauglich zu machen?

.NET 6 und neuer unterstützen Windows Arm64 offiziell, und Sie erzeugen eine native Arm64-ausführbare Datei allein durch Veröffentlichung mit der RID (Runtime Identifier) win-arm64. Für eine Anwendung aus reinem verwaltetem Code ist damit im Wesentlichen die gesamte Arbeit erledigt – nutzen Sie jedoch P/Invoke für eine native DLL oder ein NuGet-Paket mit nativen Assets, müssen Sie für jedes davon prüfen, ob ein Arm64-Build existiert. Für .NET-Framework-Anwendungen unterstützt 4.8.1 die native Ausführung auf Arm64 unter Windows 11.

Welche Art von Software funktioniert nicht unter Windows on Arm?

An erster Stelle steht Software mit Kernelmodus-Treibern. Treiber werden nicht emuliert, sodass VPN-Clients, Sicherheitsprodukte, virtuelle Geräte und die Lizenzdurchsetzung über USB-Dongles ohne einen Arm64-Treiber nicht funktionieren. Danach folgen Dinge wie Shell-Erweiterungen, IMEs und assistive Technologien, die DLLs in Prozesse auf Betriebssystemseite laden, Anwendungen, die dynamische Codeerzeugung untersagen, sowie Spiele, die von älterem OpenGL oder Anti-Cheat-Treibern abhängen. Ob Peripheriegeräte funktionieren, hängt ebenfalls davon ab, ob dafür ein Arm64-Treiber existiert.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.