Windows 11 ARM64 ist im B2B-Alltag nicht mehr nur ein Sonderfall für Technik-Enthusiasten. Neue Notebook-Generationen, längere Akkulaufzeiten, „Always-on“-Szenarien und der zunehmende Wunsch nach leichten, mobilen Arbeitsplätzen führen dazu, dass Unternehmen ARM64-Clients einkaufen – manchmal bewusst, manchmal nebenbei über Standard-Modelle im Rahmenvertrag. Für Teams mit gewachsener Individualsoftware ist das eine klare Ansage: ARM64 muss früh in die technische Planung, sonst wird es später ein teures Nachrüstprojekt.
Bei Delphi-Anwendungen ist die zentrale Frage dabei selten „kann Delphi das kompilieren?“. In der Praxis scheitern ARM64-Rollouts fast immer an der Peripherie: an nativen DLLs, Druck-/Scan-Komponenten, Datenbanktreibern, Report-Engines, COM-Integrationen, Setup-Routinen, Code-Signing oder an Build-Pipelines, die stillschweigend nur x64 kennen. Genau deshalb lohnt es sich, Windows 11 ARM64 als Architektur- und Betriebsanforderung zu behandeln – nicht als reines Plattform-Feature.
Dieser Beitrag zeigt, welche technischen Stolpersteine bei Delphi typischerweise auftreten, wie Sie die Risiken systematisch identifizieren und welche pragmatischen Migrationspfade sich bewährt haben – vom schrittweisen Fit-Machen einzelner Module bis zur klaren Zielarchitektur mit Services und REST-Servern.
Warum Windows 11 ARM64 jetzt ein Architekturthema ist
In vielen Unternehmen war „Windows“ lange gleichbedeutend mit x86/x64. Diese Annahme steckt in Scripten, Installern, Third-Party-Komponenten und manchmal sogar im Datenmodell (z.B. Pfade, Registry-Keys, Treiber-Interfaces). Sobald ARM64-Clients auftreten, wird sichtbar, wie viel implizites Wissen im System steckt. Und genau das ist der wirtschaftliche Kern: Späte Anpassungen sind nicht nur „ein paar Compiler-Flags“, sondern ein Aufräumen von Annahmen, die sich über Jahre verfestigt haben.
Praktisch relevant wird ARM64 insbesondere in drei Situationen:
- Client-Software mit langer Lebensdauer: Fachanwendungen, die 8–15 Jahre genutzt und iterativ erweitert werden. Eine neue Client-Plattform mitten im Lebenszyklus ist wahrscheinlicher als ein kompletter Neubau.
- Gemischte Flotten: Außendienst/Service, Management-Notebooks, BYOD-nahe Szenarien oder Tochtergesellschaften, die andere Hardware beschaffen.
- Sicherheits- und Compliance-Druck: Modernes Code-Signing, Härtung, „least privilege“, kontrollierte Updater – dabei werden Installations- und Updateprozesse ohnehin angefasst. Genau dann ist ARM64 als Nebenanforderung günstig zu integrieren.
Die gute Nachricht: Wer ohnehin an Delphi Modernisierung, 64-Bit-Umstieg, Entkopplung der Datenzugriffe oder an einer serviceorientierten Zielarchitektur arbeitet, kann Windows 11 ARM64 oft „mitziehen“ – sofern es früh im Backlog steht und nicht erst bei der ersten ARM-Maschine im Support landet.
Delphi auf ARM64: Was ist „easy“, was ist „hard“?
Delphi-Projekte unterscheiden sich stark: von reinen VCL-Desktop-Clients bis zu mehrschichtigen Systemen mit REST-Server, Windows Services, Report-Worker, Integrations-Komponenten und Hintergrundjobs. Für Windows 11 ARM64 ist entscheidend, welche Teile wirklich nativ auf dem Client laufen müssen und welche Teile ohnehin sinnvoll in Services ausgelagert werden können.
Der Compiler ist selten das Hauptproblem
Wenn der eigene Code sauber ist (keine Inline-Assembler, keine alten 32-Bit-Annahmen, keine fragilen Pointer-Casts, keine veralteten API-Aufrufe), ist die Kompilierung für eine neue Zielplattform häufig machbar. Probleme entstehen durch:
- Third-Party-Komponenten mit nativen Anteilen (DLLs, BPLs, C/C++-Brücken)
- Treiber und Geräteanbindung (Druck, Scan, Signaturpads, Dongles)
- Datenbankzugriff über ODBC/OLE DB/Client-Libraries, die nicht ARM64-fähig sind
- Reporting und Office-Integration (COM-Automation, alte Exportfilter)
- Installer/Updater, die nur x64 testen oder hart verdrahtete Pfade verwenden
Damit ist Windows 11 ARM64 vor allem ein „Ökosystem-Test“: Wie gut ist Ihr Softwarepaket von alten Plattformannahmen entkoppelt?
VCL, FMX und UI-Abhängigkeiten
Viele B2B-Fachanwendungen sind VCL-basiert und nutzen über Jahre gewachsene UI-Komponenten. Das ist nicht per se ein Problem – aber UI ist oft der Ort, an dem sich Abhängigkeiten bündeln: PDF-Drucker, Barcode-Generatoren, Bildbibliotheken, Browser-Controls, COM-Objekte. Für ARM64 gilt: Je mehr UI-nahe Spezialkomponenten Sie einsetzen, desto wichtiger wird eine frühe Kompatibilitätsliste.
Bei Multiplattform-Strategien (z.B. Windows + macOS) kommt häufig FMX ins Spiel. Unabhängig vom Framework ist eine robuste Strategie, die Fachlogik und Integrationen vom UI zu trennen. Das zahlt sowohl auf Delphi Multiplattform als auch auf Windows 11 ARM64 ein.
Typische technische Stolpersteine (und wie man sie früh erkennt)
In der Praxis lassen sich die meisten ARM64-Probleme frühzeitig erkennen, wenn Sie strukturiert inventarisieren und einen „ARM64 Readiness“-Check durchführen. Entscheidend ist, nicht nur den Delphi-Code anzusehen, sondern alles, was zum Produkt gehört: Installer, Treiber, Konfiguration, Plugins, Dritttools, Update-Kette, Support-Scripts.
1) Native DLLs, BPLs und gemischte Prozesslandschaften
Viele Delphi-Anwendungen laden zusätzliche DLLs: Kryptografie, CAD-Viewer, OCR, Signatur, Hardware-SDKs, Spezial-Parser. Auf x64 wird häufig stillschweigend angenommen, dass „es schon eine 64-Bit-DLL gibt“. Für ARM64 ist das anders: Sie brauchen explizit ARM64-Binaries oder eine Architektur, die diese Abhängigkeit aus dem Client herausnimmt.
Praxisansatz:
- Erstellen Sie eine Liste aller geladenen nativen Module (auch indirekt über Komponenten).
- Klassifizieren Sie: „ARM64 verfügbar“, „x64-only“, „32-bit-only“, „unklar“.
- Bewerten Sie, ob das Modul wirklich lokal sein muss oder als Service ausgelagert werden kann.
Ein häufiger Befund: Ein einzelnes x64-only-Modul blockiert den kompletten ARM64-Client. Das ist der Moment, in dem eine saubere Schichten- bzw. Layer-3 Architektur wirtschaftlich wird: UI/Client bleibt leicht, Integrationen wandern in kontrollierte Server-/Service-Schichten.
2) COM, Office-Automation und Shell-Integrationen
In vielen Unternehmen sind Word/Excel-Export, Outlook-Anbindung, Explorer-Kontextmenüs oder DMS-Integrationen über COM historisch gewachsen. COM ist nicht automatisch „ARM64-ready“, insbesondere wenn Drittanbieter-COM-Server oder Add-ins nur x64 ausliefern. Auch der Betrieb von 32-Bit/64-Bit-Mischungen (Out-of-Proc vs. In-Proc) wird schnell komplex.
Frühe Klärung:
- Welche COM-Objekte werden genutzt (ProgIDs/CLSID-Liste)?
- In-Proc oder Out-of-Proc? Gibt es ARM64-Registrierungen?
- Lässt sich Export über serverseitige Bibliotheken (z.B. dokumentenbasierte Formate) statt Office-Automation lösen?
Oft ist das ein Modernisierungshebel: Weg von UI-gekoppelter Automation hin zu reproduzierbaren Export-Services (z.B. PDF/Excel via Bibliothek), die sowohl für Windows x64 als auch für ARM64 oder sogar Linux-Server einsetzbar sind.
3) Datenbankzugriff: ODBC, Client-Libraries, Legacy-BDE
Der Datenzugriff ist eine häufige ARM64-Schnittstelle, weil hier Treiberlandschaften und Client-Libraries eine Rolle spielen. Besonders kritisch sind alte ODBC-Setups, proprietäre Datenbank-Clients oder lokale Datenbanken mit historischen Zugriffsschichten.
Für Delphi-Stacks ist das ein Klassiker: Wenn noch Borland BDE, alte Paradox-Strukturen oder schwer wartbare Treiberketten im Spiel sind, wird ARM64 zum Katalysator. Eine BDE-Ablösung und die Umstellung auf BDE-Ablosung mit nativer Anbindung mit klarer DB-Treiberstrategie reduziert Plattformrisiken deutlich.
Konkrete Prüfpunkte:
- Welche DBs sind im Einsatz (SQL Server, PostgreSQL, MariaDB, Firebird, lokale Engines)?
- Welche Treiber werden genutzt (ODBC, native Client, BDE-Ablosung mit nativer Anbindung-Treiber, OLE DB)?
- Wo liegen Connection-Strings und DSNs (pro User, pro Maschine, im Installer)?
- Gibt es Abhängigkeiten an 32-Bit-ODBC-Treiber oder alte Provider?
Gerade bei SQL Server/ODBC kann ein ARM64-Client funktionieren – aber nur, wenn die Treiberkette und die Installationsroutine sauber sind. Das ist kein Thema, das man „im Feld“ debuggen möchte.
4) Reporting, Druck, Scan, PDF und Output-Workflows
Output ist in Fachanwendungen oft geschäftskritisch: Lieferscheine, Etiketten, Rechnungen, Protokolle, Zählerstände, Zertifikate, Versandlabels. Viele dieser Workflows hängen an Reporting-Komponenten oder an spezifischen Drucker-/Scanner-Treibern.
Auf Windows 11 ARM64 sind die Stolpersteine typischerweise:
- Etikettendrucker-/Spezialtreiber nur als x64 verfügbar
- Scanner-Software/SDKs ohne ARM64-Support
- Alte Report-Engines mit nativen Preview-/Export-Modulen
- PDF-Erzeugung über „virtuelle Drucker“ statt Library
Ein robuster Weg ist, Output-Workflows zu standardisieren: PDF/Office-Formate über Bibliotheken erzeugen, Druck über standardisierte Schnittstellen, spezielle Hardwarezugriffe möglichst kapseln. Wo das nicht geht, braucht es früh eine Geräte-/Treiber-Matrix für ARM64.
5) Installer, Updater, Code-Signing und Betrieb
Viele ARM64-Projekte scheitern nicht am Programm, sondern an der Lieferung: Setup erkennt die Architektur falsch, installiert Treiber nicht, registriert COM nicht, setzt falsche Pfade oder scheitert an Code-Signing-Richtlinien. Auch automatische Updates (Delta-Updates, Self-Updater) sind häufig stark architekturabhängig.
Wichtige Fragen für den Betrieb:
- Wie wird installiert (MSI, Inno Setup, eigener Updater)?
- Wie werden Abhängigkeiten installiert (VC++ Runtimes, Treiber, Zertifikate)?
- Wie wird signiert (EXE, DLL, Installer, Treiberpakete)?
- Wie wird getestet: echte ARM64-Hardware oder nur Annahmen?
Für Unternehmen ist das ein Governance-Thema: Wenn Windows 11 ARM64 in der Client-Flotte auftaucht, muss das Deployment reproduzierbar sein – inklusive Rollback, Supportfähigkeit und klarer Versionierung.
Strategie: Windows 11 ARM64 als „frühe Nicht-Funktionale Anforderung“
Die wirtschaftlich sinnvolle Herangehensweise ist, ARM64 wie eine nicht-funktionale Anforderung (NFA) zu behandeln – ähnlich wie Performance, Security oder Offline-Fähigkeit. Das bedeutet: nicht erst im Sprint „wenn es brennt“, sondern als definierte Leitplanke für Architektur und Lieferkette.
ARM64-Readiness-Check: Inventar statt Bauchgefühl
Ein belastbarer Check umfasst typischerweise:
- Abhängigkeitsinventar: alle Third-Party-Komponenten, DLLs, Treiber, SDKs, Browser-Controls, Kryptomodule, Reporting.
- Build-/Pipeline-Analyse: Build-Targets, Paketierung, Signierung, Artefaktablage, Versionsnummern, Reproduzierbarkeit.
- Installer-/Update-Kette: Setup-Logik, Prerequisites, Registry/Dateisystem-Pfade, Policies, Rechte.
- Betriebsmodell: Support, Logging, Crash-Dumps, Telemetrie (falls vorhanden), Rollout-Plan.
Das Ergebnis sollte nicht „ARM64: ja/nein“ sein, sondern eine priorisierte Liste: welche Blocker existieren, welche Module betroffen sind, welche Alternativen es gibt und welche Investition realistisch ist.
Entscheidungsmatrix: Nativ auf ARM64 oder entkoppeln?
Bei jeder problematischen Abhängigkeit lohnt eine klare Entscheidung:
- ARM64-nativer Ersatz möglich: Upgrade, Herstellerwechsel, Umstieg auf andere Bibliothek.
- Abhängigkeit kann ausgelagert werden: z.B. in einen Windows Service, einen Hintergrundworker oder einen zentralen REST-Server.
- Abhängigkeit muss lokal bleiben: z.B. weil Hardware direkt am Client hängt. Dann braucht es verbindliche ARM64-Hardware-/Treiberfreigaben.
Gerade für Integrationen ist Auslagerung oft der sauberste Weg: Der Client bleibt UI + Fachdialoge, während komplexe Integrationslogik in kontrollierten Services läuft. Das unterstützt neben ARM64 auch Themen wie zentrale Updates, Rechtekonzepte und bessere Testbarkeit.
Architektur-Pattern, die ARM64-Projekte stabil machen
Wenn Windows 11 ARM64 früh eingeplant wird, lassen sich mehrere Architekturentscheidungen so treffen, dass sie später nicht teuer revidiert werden müssen.
1) Klare Schichten: UI, Fachlogik, Integration, Datenzugriff
Gewachsene Delphi-Clients haben häufig „alles in einem Prozess“: UI, Business-Regeln, Datenzugriff, DMS-Anbindung, Druck und Export. Das ist wartbar, solange die Plattform stabil bleibt. Sobald aber Plattformvarianten (ARM64, ggf. macOS, ggf. Terminalserver) relevant werden, steigt der Wert einer klaren Schichtung.
Pragmatisches Zielbild:
- UI-Schicht: minimal, testbar, keine direkten Treiber-/SDK-Abhängigkeiten.
- Fachlogik: möglichst plattformneutral, sauber modelliert.
- Integrationsschicht: kapselt COM, Dateiformate, DMS/ERP-Connectoren, Geräte-SDKs.
- Datenzugriff: konsolidiert (z.B. FireDAC), klare Transaktionsgrenzen, keine verstreuten SQL-Fragmente.
Das ist nicht „Akademie“, sondern spart später reale Kosten: Wenn nur die Integrationsschicht ARM64-problematisch ist, muss nicht der gesamte Client neu gebaut werden.
2) Services und REST-Server als Stabilitätsanker
Viele B2B-Systeme profitieren davon, zentrale Funktionen als REST-Server oder als Windows-/Linux-Services zu betreiben: Rechteprüfung, Dokumenten-Workflows, Datenvalidierung, Export, Import, Schnittstellen zu ERP/DMS/CRM. Wenn diese Funktionen serverseitig laufen, reduziert sich die Komplexität am Client erheblich – und damit auch die ARM64-Angriffsfläche.
Typische Aufteilungen, die sich bewährt haben:
- Client: Dialoge, Anzeige, Offline-Logik (falls nötig), minimale lokale Integrationen.
- REST-Server: fachliche Operationen, Validierung, Mandantenfähigkeit, zentrale Protokollierung.
- Worker/Service: zeitgesteuerte Jobs, Schnittstellenpolling, Report-Generierung, Batch-Exporte.
Das passt auch zu modernen Betriebsmodellen: Eine Funktion, die serverseitig läuft, wird einmal aktualisiert – statt auf jedem ARM64-Client einzeln.
3) Ein Build-System, mehrere Targets (x64 + ARM64) von Anfang an
Wenn ARM64 ein Ziel ist, sollte die Build-Pipeline das widerspiegeln. Nicht als „wir machen später einen Sonderbuild“, sondern als Standard: Jede Release-Kandidaten-Version baut reproduzierbar für x64 (und, wenn vorgesehen, ARM64), inklusive Signierung und Installer-Paketierung.
Wichtig ist dabei weniger das Tooling als die Konsequenz:
- Artefakte klar benennen (Architektur im Paketnamen/Ordnerstruktur).
- Konfigurationswerte je Target trennen (Pfade, Prerequisites, Treiberpakete).
- Smoke-Tests je Architektur definieren (Start, Login, DB-Verbindung, Druck/PDF).
Damit wird ARM64 nicht zum „Big Bang“, sondern zu einem kontrollierten zusätzlichen Target.
Delphi-Modernisierung: ARM64 als Gelegenheit, technische Schulden gezielt abzubauen
Viele Unternehmen nutzen neue Plattformanforderungen als Anlass für „alles neu“. Das ist riskant und oft unnötig. Deutlich wirtschaftlicher ist es, Windows 11 ARM64 als Leitplanke für eine schrittweise Modernisierung zu nutzen: technische Schulden dort abbauen, wo sie ARM64 blockieren oder die Lieferfähigkeit gefährden.
64-Bit und Unicode: alte Baustellen nicht verschleppen
Wenn in der Codebasis noch 32-Bit-Annahmen oder Altlasten aus frühen Delphi-Versionen stecken, treten sie bei Plattformwechseln wieder zutage. Auch wenn ARM64 nicht automatisch „Unicode“ bedeutet: Viele Projekte, die ARM64 ernsthaft angehen, stellen im gleichen Zug sicher, dass Unicode sauber ist, dass 64-Bit-Pfade etabliert sind und dass Speicher-/Pointer-Themen bereinigt wurden.
Das Ziel ist nicht Perfektion, sondern ein verlässlicher Standard: ein Code, der für neue Targets gebaut werden kann, ohne jedes Mal die gleichen Klassen von Fehlern zu reproduzieren.
BDE-Ablösung und konsolidierter Datenzugriff als ARM64-Enabler
Wo noch historische Zugriffsschichten existieren (BDE, lokale Paradox-Daten, gemischte Datenzugriffe), ist eine Konsolidierung ein Hebel mit mehrfacher Wirkung: wartbarer Code, stabilere Deployments, klarere Treiberstrategie. Mit FireDAC lässt sich der Zugriff in vielen Szenarien vereinheitlichen, inklusive zentraler Parameterverwaltung, Pooling-Strategien und sauberer Fehlerbehandlung.
Wichtig: Eine BDE-Ablösung ist nicht nur „Komponenten austauschen“. Sie betrifft Transaktionslogik, Datentypen, Sortierungen, Filtersemantik und teilweise auch das Datenmodell. Genau deshalb sollte sie geplant werden – und nicht als Notfallmaßnahme, wenn ARM64-Clients plötzlich im Feld auftauchen.
Test und Qualitätssicherung: ARM64 ist nur dann planbar, wenn es messbar wird
ARM64 früh einzuplanen bedeutet auch: Es muss getestet werden – nicht als Volltest jedes Features, sondern als gezieltes Risikotesten der kritischen Kette. Der wichtigste Schritt ist, eine reale ARM64-Testumgebung zu haben. Emulation kann in Einzelfällen helfen, ersetzt aber nicht die Praxis mit echter Hardware, echten Treibern und echten Sicherheitsrichtlinien.
Minimaler ARM64-Smoke-Test: was wirklich früh abgedeckt sein sollte
Ein pragmatisches, aber wirkungsvolles Smoke-Test-Set für jede Release-Kandidaten-Version:
- Programmstart, Login, grundlegende UI-Funktionen
- DB-Verbindung (inkl. Authentifizierung, Zertifikate, DNS/Proxy, falls relevant)
- Ein Kernprozess „End-to-End“ (z.B. Auftrag anlegen, speichern, drucken/exportieren)
- Updater/Installer: Neuinstallation und Update über eine Version hinweg
- Logging/Fehlerdialoge: sind Diagnosen auch auf ARM64 verwertbar?
Damit werden die typischen ARM64-Blocker früh sichtbar: fehlende DLLs, falsche Treiber, Setup-Probleme, unerwartete Rechteanforderungen.
Diagnosefähigkeit: Crash-Dumps, Logs, Versionstransparenz
Wenn ARM64 in der Flotte ist, werden Supportfälle kommen – allein schon wegen neuer Treiberkonstellationen. Deshalb lohnt es sich, Diagnosen zu standardisieren: klare Build-IDs, aussagekräftige Logs, reproduzierbare Installations- und Updatepfade. Das ist nicht spezifisch für ARM64, aber ARM64 macht Defizite hier besonders schnell teuer.
Rollout und Betrieb: gemischte Flotten ohne Chaos
Die meisten Unternehmen werden mittelfristig gemischte Client-Flotten betreiben: ein Teil x64, ein Teil ARM64. Der Schlüssel ist, diesen Zustand bewusst zu gestalten.
Paketierung: getrennte Installer, klare Erkennung, eindeutige Downloadwege
In der Praxis funktioniert es am besten, wenn Installer/Pakete eindeutig sind: x64-Paket ist x64, ARM64-Paket ist ARM64. „Ein Installer für alles“ klingt bequem, wird aber schnell komplex (Prüflogik, Prerequisites, Treiberpfade, Signierung, Reparaturinstallation). Für kontrollierte Unternehmensrollouts ist Eindeutigkeit häufig der robustere Weg.
Update-Strategie: keine Sonderpfade für ARM64
ARM64 sollte im Updateprozess kein Sonderfall sein. Ziel ist: gleiche Releasefrequenz, gleiche Fachversionsnummer, aber getrennte Artefakte. Wenn ARM64 nur „manuell“ aktualisiert wird, entstehen Abweichungen in der Flotte, die später die Supportkosten hochtreiben.
Integrationen sauber dokumentieren
Viele ARM64-Probleme liegen nicht im eigenen Code, sondern in Integrationen: ERP-Connector, DMS-Client, Signaturdienst, Scanner-Software, Etikettendrucker. Eine gepflegte Integrationsliste mit Versionsständen und Architekturhinweisen ist für B2B-Systeme ohnehin sinnvoll – und macht ARM64-Entscheidungen transparent.
Was Unternehmen jetzt konkret tun sollten (ohne Aktionismus)
Windows 11 ARM64 früh einzuplanen heißt nicht, sofort alles umzubauen. Es heißt, die richtigen Fragen früh zu beantworten und Blocker zu eliminieren, solange der Aufwand planbar ist. Ein bewährtes Vorgehen ist:
- 1) Bestandsaufnahme (2–10 Tage je nach Systemgröße): Abhängigkeiten, Installer, Treiber, Datenzugriff, COM, Reporting.
- 2) Zielbild und Pfad: Was muss nativ auf den Client? Was wird Service/REST? Welche Komponenten werden ersetzt?
- 3) Proof of Feasibility: ein lauffähiger ARM64-Build mit Installer und einem End-to-End-Use-Case.
- 4) Schrittweise Härtung: restliche Funktionen, Tests, Updatekette, Diagnosefähigkeit.
So entsteht kein „ARM64-Projekt“, das monatelang isoliert läuft, sondern eine kontrollierte Erweiterung der Lieferfähigkeit.
Fazit: Windows 11 ARM64 ist kein Hype, sondern ein Frühindikator für technische Reife
Windows 11 ARM64 wird für viele Unternehmen schlicht Realität – durch Hardwarebeschaffung, Mobilitätsanforderungen oder Standardisierung. Für Delphi-Anwendungen ist die eigentliche Herausforderung nicht der Quellcode allein, sondern das Gesamtsystem aus Abhängigkeiten, Installations- und Updateprozessen, Integrationen und Treibern. Wer ARM64 früh einplant, kann diese Punkte strukturiert klären, statt sie später unter Zeitdruck zu „patchen“.
Am Ende ist ARM64 ein nützlicher Prüfstein: Wie gut ist Ihre Anwendung entkoppelt, testbar und lieferfähig? Wenn Sie diese Frage jetzt beantworten, gewinnen Sie nicht nur Plattformoptionen, sondern auch eine stabilere Basis für Modernisierung, Services, REST-Architekturen und langfristige Wartbarkeit.
Kontaktieren Sie Net-Base Software GmbH, wenn Sie Windows 11 ARM64 in Ihrer Delphi-Roadmap belastbar bewerten und mit einem klaren technischen Pfad umsetzen möchten.