Windows 11 ARM64 con Delphi nelle imprese: opzioni, rischi e un percorso di migrazione solido

Windows-Geräte mit ARM64-CPU (ARM64 ist eine 64‑Bit-Prozessorarchitektur, bekannt aus mobilen SoCs und zunehmend auch aus Business-Notebooks) sind in vielen Unternehmen nicht mehr nur „Exoten“. Sie kommen über standardisierte Notebook-Flotten, längere Akkulaufzeiten, neue Sicherheitsfunktionen in der Hardware und eine strategische Diversifizierung der Lieferkette. Spätestens wenn Fachbereiche neue Geräte beschaffen oder OEMs bestimmte Modelle nur noch als Windows su ARM anbieten, stellt sich für IT-Verantwortliche die praktische Frage: Wie verhält sich unsere Delphi-basierte Business-Software unter Windows 11 ARM64 – und wie sichern wir Betrieb, Support und Weiterentwicklung?

Der Kernpunkt ist: Windows 11 ARM64 mit Delphi in Unternehmen ist weniger eine reine Entwicklungsfrage als eine Frage von Abhängigkeiten, Deployment-Strategien, Treibern, Schnittstellen und dem realen Verhalten im Feld. In der Praxis gibt es drei Wege: Weiterbetrieb über Emulation, native ARM64-Builds oder ein Übergangsmodell, das Risiken kontrolliert reduziert. Dieser Beitrag ordnet die typischen Stolpersteine ein und zeigt einen belastbaren Pfad, der in IT-Planung, Rollout und Betrieb funktioniert – ohne „Alles neu“-Reflex.

Warum Windows 11 ARM64 jetzt relevant wird

Windows su ARM ist nicht neu, aber die Rahmenbedingungen haben sich geändert: Die Geräte sind im Business-Umfeld verfügbar, Windows 11 bringt eine deutlich ausgereiftere x64-Emulation, und Softwarehersteller liefern immer häufiger ARM64-Varianten. Für Unternehmen heißt das: ARM64 taucht nicht als einmaliges Pilotprojekt auf, sondern als Plattform, die in Beschaffungs- und Lebenszyklusplanungen eingeht.

Für prozessnahe Softwarelösungen ist dabei weniger die CPU selbst das Problem, sondern die Peripherie- und Integrationsrealität: Druck, Signaturkarten, Scanner, Office-Add-ins, COM-Komponenten (COM ist Microsofts Komponentenmodell zur Integration von Anwendungen und Bibliotheken), Shell-Erweiterungen, VPN-Clients oder Security-Agenten. Wenn davon etwas nicht ARM64-tauglich ist, entsteht Supportaufwand – und häufig wird dann „die Anwendung“ verantwortlich gemacht.

Einordnung: Was bedeutet ARM64 technisch für Delphi-Anwendungen?

Delphi-Anwendungen im Unternehmensumfeld sind oft klassische Windows-Desktop-Clients (häufig VCL, also die Visual Component Library für Windows-GUIs) mit Datenbankzugriff (z. B. über BDE-Ablosung mit nativer Anbindung, Delphis Datenzugriffsschicht) und einer Mischung aus lokalen und entfernten Integrationen. Unter Windows 11 ARM64 ergeben sich dabei drei Ausführungsarten:

1) Native ARM64-Ausführung

Die Anwendung und alle nativen Bibliotheken (DLLs) liegen als ARM64 vor. Das ist langfristig die sauberste Option, weil sie Performance und Stabilität planbar macht und Emulationsrandbedingungen vermeidet. Sie ist aber nur dann realistisch, wenn alle nativen Abhängigkeiten mitziehen: Datenbanktreiber, Druck/Preview, PDF-Engine, Kryptobibliotheken, OCR/Scan-SDKs, Hardware-Dongle-Treiber etc.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 può emulare applicazioni x64. Per molti client desktop puri questo funziona sorprendentemente bene. In pratica però l’emulazione non è una “carta libera”: non appena entrano in gioco driver, integrazioni della shell o componenti in-process (DLL caricate nel processo), conta l’architettura. Un processo x64 non può caricare una DLL ARM64 e viceversa. Proprio questo confine decide spesso tra “funziona” o “non funziona”.

3) Ibrido: client ARM64, disaccoppiare i componenti x64

Un percorso di transizione è estrarre le componenti x64 critiche dal processo: p. es. come servizio esterno, come backend REST (REST è un modello di interfaccia basato su HTTP) o come utility separata. Non è elegante come “tutto nativo”, ma spesso è la via economicamente più sensata per garantire il funzionamento e modernizzare le dipendenze gradualmente.

Windows 11 ARM64 con Delphi in azienda: le dipendenze tipiche che determinano il successo

Nei progetti si vede rapidamente: il collo di bottiglia non è la GUI, ma l’ecosistema. Un’analisi strutturata delle dipendenze risparmia settimane di tentativi ed errori.

DLL native e SDK: il rischio invisibile

Molte applicazioni Delphi integrano DLL di terze parti: generazione PDF, barcode/QR, elaborazione immagini, crittografia, librerie di comunicazione proprietarie. Su ARM64 vale in modo rigido: una DLL deve corrispondere all’architettura del processo. L’emulazione aiuta solo se l’intero processo rimane x64. Non appena si vuole eseguire nativamente, queste librerie devono essere disponibili come ARM64 o essere sostituite.

Suggerimento pratico per l’IT: fatevi fornire dal responsabile del software un elenco delle DLL presenti nella cartella di installazione e di quelle caricate tramite percorsi di sistema. È la base per valutare la disponibilità del produttore e le alternative.

COM, automazione Office e estensioni della shell

COM è spesso utilizzato nella quotidianità aziendale senza che venga chiamato così: integrazione con Outlook, esportazione in Excel tramite Automation, client DMS, handler di anteprima in Explorer, estensioni del menu contestuale. Il problema su ARM64 non è tanto COM in sé, quanto il accoppiamento della bitness: i server COM in-process (componenti COM basate su DLL) devono avere la stessa architettura. L’Out-of-Process-COM (server basati su EXE) è più flessibile perché può girare in un processo separato.

Se la vostra applicazione Delphi usa, p. es., una vecchia COM-DLL a 32 bit o 64 bit, con esecuzione nativa ARM64 questo diventa un blocco. Emulata come x64 può funzionare — purché tutte le dipendenze COM siano anch’esse x64 e non intervengano componenti esclusivamente ARM64.

Stampa, PDF e paesaggio driver

I problemi di stampa sono il classico caso nei cambi di piattaforma. Con Windows 11 ARM64 è cruciale se il produttore della stampante fornisce driver ARM64 o se è possibile usare driver di classe Universal Print/IPP (IPP è un protocollo di stampa standardizzato). Anche stampanti PDF, stampa in batch, stampa di etichette e dispositivi speciali (p. es. stampanti termiche) possono dipendere da driver disponibili solo per x64.

Per la direzione IT e l’amministrazione la conseguenza importante è: i roll-out ARM64 devono essere allineati con la strategia di stampa. “L’applicazione non stampa” spesso significa “il driver non esiste” o “la pipeline di stampa è diversa”.

Accesso ai dati: FireDAC, ODBC/OLE DB e client database

A livello dati conviene una chiara separazione tra protocollo e libreria client. BDE-Ablosung mit nativer Anbindung può lavorare con client nativi della banca dati o con driver. Se, ad esempio, è necessario un client Oracle, un client PostgreSQL datato o un driver ODBC specifico, quel componente deve essere disponibile per ARM64 — oppure si adotta un’architettura che incapsula l’accesso ai dati lato server (p. es. tramite servizi REST o un Windows- e Linux-Services).

Per un esercizio stabile questo è un leva centrale: meno il client desktop dipende direttamente da driver di database e da stack locali del database, più semplice diventa il passaggio ad ARM64. Vale anche in termini di security: credenziali d’accesso al database, certificati e regole di rete si gestiscono in modo più consistente lato server.

Crittografia, smart card, firme, VPN, EDR

Molti processi aziendali oggi dipendono da componenti crittografici: S/MIME, certificati client, middleware per smart card, smart card per firma, TLS-Inspection nei proxy. A questo si aggiungono soluzioni di endpoint security (EDR è Endpoint Detection and Response) e client VPN. Questi componenti devono essere compatibili ARM64, altrimenti si crea il problema del «dispositivo presente ma non autorizzato in rete».

Per l’applicazione Delphi ciò significa: se, ad esempio, si usano certificati dal keystore di Windows o si delega TLS a componenti di sistema, spesso la questione è meno critica rispetto al caso in cui una specifica DLL crittografica di terze parti resti caricata nel processo.

Matrice decisionale: emulazione o porting nativo ARM64?

Le aziende devono prendere una decisione che rifletta la realtà del supporto e del ciclo di vita. Una semplice domanda sì/no („Portiamo il software?“) raramente è utile. Più efficace è una matrice che pesi dipendenze e rischi:

• Client puro con API standard Windows (file, rete, stampa tramite driver standard): l’emulazione può bastare nel breve termine; il porting nativo ARM64 è la soluzione pulita a medio termine.
• Client con molte DLL native di terze parti (PDF, OCR, hardware): prima verificare la disponibilità, poi decidere. Spesso ha senso un percorso ibrido.
• Client con COM-DLL o estensioni della shell: aspettarsi conflitti architetturali; valutare l’isolamento Out-of-Process.
• Client con zoo di driver DB diretti: o si consolida la famiglia di driver o si sposta l’accesso ai dati verso servizi.
• Elevata regolamentazione/firme/smart card: verificare precocemente la compatibilità ARM64 della catena di security e middleware.

Importante: l’emulazione non è una „seconda classe“, ma rappresenta un rischio operativo se si prevede una flotta prevalente ARM64 a lungo termine. Al più tardi in occasione di aggiornamenti importanti, cambi driver o sostituzioni di agent di sicurezza, non si vuole ritrovarsi con una serie di eccezioni da gestire.

Un percorso di migrazione solido: da oggi ad ARM64 senza Big Bang

Per IT e responsabili di progetto un percorso è valido quando può essere distribuito a onde, ha criteri di accettazione chiari e non sovraccarica il supporto. Nei contesti Delphi si è dimostrato efficace un approccio in cinque fasi.

Fase 1: inventario con la «prospettiva operativa»

Rilevate non solo i moduli, ma soprattutto i punti operativi:

• Quali classi di dispositivi: notebook, rugged device, terminali?
• Quale periferia: stampanti, scanner, lettori di carte, etichettatrici?
• Quali integrazioni: Office, DMS, ERP, servizi locali, componenti del browser?
• Quale forma di installazione: MSI, Setup-EXE, ClickOnce, installazione manuale?
• Quali permessi: amministratore necessario, servizi locali, regole del firewall?

Questa vista rende rapidamente evidente se ’solo un client‘ in realtà significa cinque dipendenze di sistema.

Passo 2: Verifica di compatibilità con un pilota ARM64 rappresentativo

Il pilota non dovrebbe essere „il dispositivo più bello“, ma un candidato tipico della flotta target. Testate intenzionalmente i percorsi critici: stampa in tutte le varianti, esportazione/importazione, firma, offline/online, aggiornamenti, cambio di tenant, scenari Proxy/VPN. Documentate le deviazioni come incidenti operativi, non come bug degli sviluppatori. Così la prioritizzazione resta chiara.

Passo 3: Ridurre le dipendenze – partire da quelle con il maggior effetto sul supporto

Misure tipiche che nella pratica risultano efficaci:

• Standardizzare il percorso PDF/stampa: allontanarsi da DLL proprietarie per stampanti, verso pipeline stabili e testate.
• Disaccoppiare l’integrazione Office: invece di In-Process-Add-ins preferire formati di esportazione e generazione documenti lato server.
• Consolidare l’accesso al DB: una via definita per il driver invece di „ODBC a seconda della postazione“.
• Incapsulare il collegamento hardware: quando possibile tramite processi/servizi esterni che possono essere aggiornati separatamente.

Passo 4: Modernizzare il deployment e la capacità di aggiornamento

ARM64 è un’occasione utile per ripulire installazione e aggiornamenti. Per le aziende non contano le feature, ma capacità di rollback, riproducibilità e conformità alle policy. Verificate:

• Paketizzazione: MSI vs. MSIX (MSIX è il moderno formato di pacchetto app di Microsoft con installazione/disinstallazione pulita e firma).
• Firma: Code Signing (firma digitale di EXE/DLL) riduce attriti con SmartScreen ed EDR ed è rilevante per rollout controllati.
• Gestione della configurazione: separazione tra file dell’applicazione e configurazione, percorsi chiari, nessuna dipendenza „nascosta“ nel registro di sistema.
• Canali di aggiornamento: Pilot, Ring 1, Ring 2 – con telemetria/logging a livello applicativo e operativo.

Passo 5: ARM64 nativo dove conviene davvero

I build nativi ARM64 hanno senso quando (a) avete sotto controllo le dipendenze e (b) l’applicazione verrà sviluppata a lungo termine. Tipicamente conviene per client core utilizzati da molti utenti quotidianamente e che comunque intendete modernizzare. Per strumenti usati raramente l’emulazione x64 può essere una transizione accettabile, purché support e sicurezza siano gestiti.

Spunti architetturali: ARM64 come occasione per rafforzare interfacce e servizi

Molti Delphi-landscapes sono cresciuti storicamente come ‚client pesante‘. Funziona, ma vincola gestione e aggiornamenti alle singole configurazioni di postazione. ARM64 mette in luce dove questo accoppiamento diventa costoso. Un passo pragmatico di modernizzazione non è quindi spesso „interfaccia utente nuova“, ma interfacce rinnovate.

Più stabilità attraverso responsabilità lato server

Se la logica critica, l’accesso ai dati o i processi documentali vengono spostati in un servizio centrale (Windows- und Linux-Services o Windows- und Linux-Services, cioè un servizio in background senza UI interattiva), otterrete:

• versioni uniformi di driver e librerie,
• sicurezza più controllabile (certificati, segreti, rete),
• minore complessità sul client (ARM64, x64, in futuro anche altre piattaforme),
• punti di monitoraggio e logging più chiari.

Per i decisori IT questo è un reale vantaggio operativo: i problemi risultano riproducibili più rapidamente lato server, invece di restare bloccati su „un notebook specifico“.

REST-API come strato di disaccoppiamento

Una REST-API non è automaticamente „moderna“, ma è un disaccoppiamento robusto tra client e backend. Definisce in modo chiaro quali dati e azioni sono consentiti e può essere protetta in modo ordinato (ad es. tramite token, certificati o SAML 2.0 come standard di identità negli ambienti aziendali). Per ARM64 questo significa: il client deve portare meno „conoscenza del mondo“ su database, driver e dettagli di rete.

Anche se non si decide di migrare tutto immediatamente: già un piccolo componente API ben delimitato (ad es. generazione documenti, verifica licenze, riconciliazione anagrafiche) può rimuovere dipendenze dal client e ridurre così i rischi legati ad ARM64.

Test e qualità: cosa dovete verificare diversamente sotto ARM64

Molti team testano il software desktop principalmente dal punto di vista funzionale. Con ARM64 dovreste testare maggiormente a livello operativo, perché i profili di errore sono diversi: non „calcolo sbagliato“, ma „componente non si carica“, „driver mancante“, „aggiornamento fallito“, „integrazione con Office che si interrompe“.

Checklist per l’accettazione orientata ad ARM64

• Installazione/Disinstallazione: pulita, senza residui, senza workaround da amministratore.
• Percorso di aggiornamento: upgrade su più versioni, scenario di rollback, verifica della firma.
• Logging: log centralizzati, codici di errore chiari per problemi di caricamento DLL, percorsi di stampa tracciabili.
• Prestazioni: tempi di avvio, operazioni sui dati, liste/report di grandi dimensioni – misurati separatamente in emulazione e nativo.
• Periferiche: profili stampante, stampa speciale, flussi di lavoro scanner, funzionalità smartcard.
• Sicurezza: interazione EDR/AV, proxy/TLS, archivio certificati, funzionamento con privilegi minimi.

Importante è la documentazione: se un problema è dovuto a driver ARM64 mancanti, non si tratta di una „correzione in Delphi“, ma di una decisione di approvvigionamento o di standardizzazione.

Esercizio e supporto: come integrare ARM64 nella gestione quotidiana

Nel quotidiano conta la rapidità con cui vengono risolti i casi di supporto. Per ARM64 conviene aumentare proattivamente la capacità di supporto:

Profili dei dispositivi standardizzati e approvazioni chiare

Definite modelli ARM64 supportati o almeno profili minimi (strategia driver, strategia di stampa, versioni degli agent di sicurezza). Un „funziona su ARM64“ senza questi vincoli porta a ambienti disomogenei e quindi a guasti difficili da riprodurre.

Capacità di diagnostica nell’applicazione

Anche senza orientamento agli sviluppatori conviene che il software fornisca informazioni chiare: una pagina di system info che indichi l’architettura (x64 emulato vs. ARM64 nativo), i percorsi importanti, le versioni dei componenti core e la configurazione di stampa riduce significativamente i tempi di supporto. Non è un „nice to have“, ma igiene operativa.

Licenze e dongle

Se entrano in gioco dongle hardware o driver di licenza legacy, ARM64 diventa rapidamente critico. In molti ambienti è sensato spostare la gestione delle licenze su meccanismi di rete o server-side. Questo riduce la dipendenza dai driver sui dispositivi finali e rende la flotta più facilmente ricambiabile.

Cosa significa questo per la vostra strategia Delphi?

Delphi è nel contesto aziendale spesso un componente stabile per client desktop e servizi. Windows 11 ARM64 non è un argomento „contro Delphi“, ma un argomento a favore di una incapsulazione più pulita delle dipendenze e di una modernizzazione orientata all’esercizio: meno driver specialistici locali, meno componenti in-process, interfacce più chiare, deployment migliore.

Se siete già su un percorso di modernizzazione (ad es. BDE-sostituzione, migrazione a 64 bit, integrazione più stretta di REST, accesso ai dati consolidato con FireDAC), allora ARM64 è spesso „solo“ un ulteriore punto obiettivo che chiarisce le priorità. Se invece la vostra applicazione dipende fortemente da driver legacy, DLL proprietarie e configurazioni speciali delle postazioni, ARM64 è un valido motivo per rendere questi rischi trasparenti e ridurli in modo pianificabile.

Conclusione: ARM64 è meno un progetto di porting e più un progetto di architettura e di esercizio

Per le aziende Windows 11 ARM64 è soprattutto una questione di piattaforma per acquisti, sicurezza e supporto. Per software business basato su Delphi il successo non si decide su un’opzione del compilatore, ma sulla catena di driver, DLL, integrazioni COM, accesso ai dati e processi di aggiornamento. Un percorso solido è: prima rendere visibili dipendenze e percorsi operativi, poi testare con dispositivi pilota, quindi disaccoppiare in modo mirato e professionalizzare il deployment – e fornire build native ARM64 dove portano beneficio e stabilità a lungo termine.

Se volete introdurre Windows 11 ARM64 nel vostro parco e al contempo mettere in sicurezza in modo pianificabile applicazioni, periferiche e interfacce basate su Delphi, parlate con noi per un inventario strutturato e un percorso di migrazione realistico:

Nel contesto tecnico giocano inoltre un ruolo importante anche Delphi ARM64 Windows e X64-Emulation Windows 11, quando integrazioni, flussi di dati e evoluzione devono funzionare coerentemente insieme.

Discutere il progetto o l’intervento di modernizzazione con Net-Base.