Windows 11 ARM64 met Delphi in ondernemingen: opties, risico's en een robuust migratiepad

Windows-apparaten met ARM64-CPU (ARM64 is een 64‑bit processorarchitectuur, bekend uit mobiele SoC’s en steeds vaker ook uit zakelijke notebooks) zijn in veel bedrijven niet langer alleen “exoten”. Ze verschijnen via gestandaardiseerde notebookvloten, langere accuduur, nieuwe beveiligingsfuncties in de hardware en een strategische diversificatie van de toeleveringsketen. Vroeg of laat, zodra businessafdelingen nieuwe apparaten aanschaffen of OEMs bepaalde modellen alleen nog als Windows voor ARM aanbieden, rijst voor IT‑verantwoordelijken de praktische vraag: Hoe gedraagt onze Delphi-gebaseerde businesssoftware zich onder Windows 11 ARM64 – en hoe borgen we exploitatie, support en verdere ontwikkeling?

De kern is: Windows 11 ARM64 met Delphi in bedrijven is minder een zuivere ontwikkelvraag dan een kwestie van afhankelijkheden, deployment‑strategieën, stuurprogramma’s, interfaces en het daadwerkelijke gedrag in de praktijk. In de praktijk zijn er drie routes: voortzetting via emulatie, native ARM64‑builds of een overgangsmodel dat risico’s gecontroleerd verkleint. Dit artikel ordent de typische valkuilen en toont een robuust pad dat werkt in IT‑planning, uitrol en operatie – zonder reflex om “alles opnieuw” te willen.

Waarom Windows 11 ARM64 nu relevant wordt

Windows voor ARM is niet nieuw, maar de randvoorwaarden zijn veranderd: de apparaten zijn beschikbaar in de zakelijke omgeving, Windows 11 brengt een duidelijk meer volwassen x64‑emulatie en softwareleveranciers leveren steeds vaker ARM64‑varianten. Voor bedrijven betekent dit: ARM64 verschijnt niet als een eenmalig pilotproject, maar als een platform dat in inkoop‑ en levenscyclusplanning wordt opgenomen.

Voor procesgerichte softwareoplossingen is minder de CPU zelf het probleem dan de periferie‑ en integratierealiteit: print, signatuurkaarten, scanners, Office‑add‑ins, COM‑componenten (COM is Microsofts componentenmodel voor de integratie van applicaties en bibliotheken), shell‑extensies, VPN‑clients of security‑agenten. Als iets daarvan niet ARM64‑compatibel is, ontstaat er supportwerk – en vaak wordt dan “de applicatie” als verantwoordelijke aangemerkt.

Eenordening: Wat betekent ARM64 technisch voor Delphi-applicaties?

Delphi-applicaties in het zakelijke domein zijn vaak klassieke Windows‑desktopclients (vaak VCL, dus de Visual Component Library voor Windows‑GUIs) met database‑toegang (bijv. via BDE‑vervanging met native aansluiting, de datalaag van Delphi) en een mix van lokale en remote integraties. Onder Windows 11 ARM64 ontstaan daarbij drie uitvoeringsvormen:

1) Native ARM64‑uitvoering

De applicatie en alle native bibliotheken (DLLs) zijn als ARM64 beschikbaar. Dat is op de lange termijn de zuiverste optie omdat het performance en stabiliteit voorspelbaar maakt en randvoorwaarden van emulatie vermijdt. Het is echter alleen realistisch als alle native afhankelijkheden meebewegen: database‑stuurprogramma’s, print/preview, PDF‑engine, cryptobibliotheken, OCR/scan‑SDK’s, hardware‑dongle‑stuurprogramma’s etc.

2) x64‑emulatie onder Windows 11 ARM64

Windows 11 kan x64-applicaties emuleren. Voor veel pure desktopclients werkt dat verrassend goed. In de praktijk is emulatie echter geen ‚vrijbrief‘: zodra drivers, shell-integraties of in-process componenten (DLLs die in het proces geladen worden) betrokken zijn, telt de architectuur. Een x64-proces kan geen ARM64-DLL laden en omgekeerd. Juist die grens beslist vaak over ‚werkt‘ of ‚werkt niet‘.

3) Hybrid: ARM64-client, x64-componenten ontkoppelen

Een overgangspad is kritische x64-componenten uit het proces te halen: bijvoorbeeld als externe service, als REST-backend (REST is een op HTTP gebaseerd interface-model) of als apart hulpprogramma. Dat is minder elegant dan ‚alles native‘, maar vaak de meest economische route om de exploitatie te waarborgen en afhankelijkheden stapsgewijs te moderniseren.

Windows 11 ARM64 met Delphi in ondernemingen: De typische afhankelijkheden die over succes beslissen

In projecten blijkt snel: niet de GUI is de bottleneck, maar het ecosysteem. Een gestructureerde afhankelijkheidsanalyse bespaart hier weken aan trial-and-error.

Native DLLs en SDKs: het onzichtbare risico

Veel Delphi-toepassingen binden DLLs van derden in: PDF-generatie, barcode/QR, beeldverwerking, versleuteling, proprietaire communicatiebibliotheken. Onder ARM64 geldt hard: Een DLL moet bij de procesarchitectuur passen. Emulatie helpt alleen als het hele proces x64 blijft. Zodra men native wil draaien, moeten deze bibliotheken als ARM64 beschikbaar zijn of vervangen worden.

Praktische tip voor IT: Laat de softwareverantwoordelijke u een lijst geven welke DLLs in de installatiemap liggen en welke via systeempaden geladen worden. Dat is de basis om leveranciersondersteuning en alternatieven te beoordelen.

COM, Office-automatisering en shell-extensies

COM wordt in het bedrijfsleven vaak gebruikt zonder zo genoemd te worden: Outlook-integratie, Excel-export via automatisering, DMS-clients, preview-handlers in Verkenner, contextmenu-extensies. Het probleem onder ARM64 is minder COM zelf, maar de bitness-koppeling: in-process COM-servers (DLL-gebaseerde COM-componenten) moeten architectuurgelijk zijn. Out-of-process COM (EXE-gebaseerde servers) is flexibeler, omdat die in een apart proces kunnen draaien.

Als uw Delphi-toepassing bijvoorbeeld een oude 32‑bit of 64‑bit COM-DLL gebruikt, is dat bij native ARM64-uitvoering een blocker. Geëmuleerd als x64 kan het werken – zolang alle COM-afhankelijkheden eveneens x64 zijn en er geen ARM64-only onderdelen tussenkomen.

Afdrukken, PDF en driverlandschap

Afdrukproblemen zijn bij platformwissels klassiekers. Onder Windows 11 ARM64 is bepalend of de printerfabrikant ARM64-drivers levert of dat Universal Print/IPP-class drivers (IPP is een gestandaardiseerd afdrukprotocol) gebruikt kunnen worden. Ook PDF-printers, stapelafdruk, etiketafdruk en speciale apparaten (bijv. thermische printers) kunnen afhankelijk zijn van drivers die alleen voor x64 bestaan.

Voor IT-leiding en administratie is de belangrijke consequentie: ARM64-rollouts moeten op de printstrategie worden afgestemd. ‚De applicatie print niet‘ is vaak ‚de driver bestaat niet‘ of ‚de afdrukpipeline is anders‘.

Toegang tot data: FireDAC, ODBC/OLE DB en database-clients

Op de gegevenslaag is een duidelijke scheiding tussen protocol en clientbibliotheek wenselijk. BDE-Ablosung mit nativer Anbindung kan, afhankelijk van de database, met native clientlibs of met drivers werken. Als bijvoorbeeld een Oracle-client, een oudere PostgreSQL-client of een specifieke ODBC-driver nodig is, moet er een ARM64-versie van beschikbaar zijn – of u kiest voor een architectuur die de gegevenstoegang serverzijdig kapselt (bijv. via REST-services of een Windows-/ Windows- en Linux-Services).

Voor stabiele exploitatie is dit een centraal hefboompunt: hoe minder de desktopclient direct aan databasedrivers en lokale database-„stacks” gebonden is, hoe gemakkelijker ARM64 wordt. Dit geldt ook vanuit security-perspectief: database-inloggegevens, certificaten en netwerkregels zijn serverzijdig consistenter te beheren.

Cryptografie, smartcards, handtekeningen, VPN, EDR

Veel bedrijfsprocessen hangen tegenwoordig aan cryptografische componenten: S/MIME, clientcertificaten, smartcard-middleware, handtekeningkaarten, TLS-inspectie in proxies. Daar komen endpoint-securityoplossingen bij (EDR = Endpoint Detection and Response) en VPN-clients. Deze componenten moeten ARM64-compatibel zijn, anders ontstaat het „apparaat is er, maar mag niet op het netwerk“-probleem.

Voor de Delphi-toepassing betekent dat: als u bijvoorbeeld certificaten uit de Windows-certificaatsstore gebruikt of TLS via systeemcomponenten regelt, is dat doorgaans minder kritisch dan wanneer een specifieke crypto-DLL van een derde partij in het proces hangt.

Beslissingsmatrix: emulatie of native ARM64-portering?

Organisaties hebben een beslissing nodig die de support- en levenscyclusrealiteit weerspiegelt. Een eenvoudige ja/nee-vraag („Porteren we?“) is zelden helpend. Beter is een matrix die afhankelijkheden en risico’s weegt:

• Zuivere client met standaard-Windows-API’s (bestand, netwerk, print via standaarddrivers): emulatie kan op korte termijn volstaan; native ARM64 is op middellange termijn schoner.
• Client met veel native DLLs van derden (PDF, OCR, hardware): eerst beschikbaarheid controleren, dan beslissen. Vaak is een hybride pad zinvol.
• Client met COM-DLLs / shell-extensies: verwacht architectuurconflicten; controleer out-of-process-ontkoppeling.
• Client met een directe DB-driver-zoo: ofwel drivers consolideren, ofwel de gegevenstoegang naar services verplaatsen.
• Hoge regulering/handtekening/smartcard: verifieer vroegtijdig de ARM64-compatibiliteit van de security- en middlewareketen.

Belangrijk: emulatie is geen „tweede klas“, maar het is een bedrijf risico als u op lange termijn ARM64-apparaten in de vloot verwacht. Op het moment van grotere updates, driverwissels of wisselingen van security-agents wilt u niet vastzitten aan een keten van uitzonderingsgevallen.

Een robuust migratiepad: van vandaag naar ARM64 zonder Big Bang

Voor IT en projectverantwoordelijken is een pad goed als het in golven uitrolbaar is, duidelijke acceptatiecriteria heeft en de support niet overbelast. In Delphi-omgevingen heeft een aanpak in vijf stappen zich bewezen.

Stap 1: inventarisatie met „bedrijfsbril“

Leg niet alleen modules vast, maar vooral operationele punten:

• Welke apparaatsklassen: notebooks, rugged devices, terminals?
• Welke randapparatuur: printers, scanners, kaartlezers, labelprinters?
• Welke integraties: Office, DMS, ERP, lokale services, browsercomponenten?
• Welke installatiemethode: MSI, Setup-EXE, ClickOnce, handmatige installatie?
• Welke rechten: beheerdersrechten nodig, lokale services, firewallregels?

Diese Sicht macht schnell sichtbar, ob „nur ein Client“ in Wahrheit fünf Systemabhängigkeiten bedeutet.

Stap 2: compatibiliteitscheck met representatieve ARM64-pilot

De pilot moet niet ‚het mooiste apparaat‘ zijn, maar een typische kandidaat uit de doelvloot. Test daarbij bewust de kritieke paden: afdrukken in alle varianten, export/import, handtekening, offline/online, updates, wisselen tussen tenants, proxy-/VPN-scenario’s. Documenteer afwijkingen als operationele voorvallen, niet als ontwikkelaars-bugs. Zo blijft de prioritering zuiver.

Stap 3: afhankelijkheden verminderen – eerst die met een hoge supporthefboom

Typische maatregelen die in de dagelijkse praktijk veel opleveren:

• PDF-/afdrukpad standaardiseren: weg van proprietaire printer-DLLs, naar stabiele, geteste pipelines.
• Office-integratie ontkoppelen: in plaats van in-process-add-ins liever exportformaten en servergebaseerde documentgeneratie beoordelen.
• DB-toegang consolideren: een gedefinieerde driverroute in plaats van „ODBC per werkplek“.
• Hardware-koppeling kapselen: indien mogelijk via externe processen/services die afzonderlijk bijgewerkt kunnen worden.

Stap 4: deployment en updatebaarheid moderniseren

ARM64 is een goed moment om installatie en updates te saneren. Voor bedrijven tellen hier niet features, maar rollback-mogelijkheid, reproduceerbaarheid en beleidconformiteit. Controleer:

• Pakketering: MSI vs. MSIX (MSIX is Microsofts moderne app-pakketformaat met schone installatie/deïnstallatie en ondertekening).
• Ondertekening: Code Signing (digitale ondertekening van EXE/DLL) vermindert SmartScreen- en EDR-wrijving en is relevant voor gecontroleerde rollouts.
• Configuratiemanagement: scheiding van programbestanden en configuratie, duidelijke paden, geen „verborgen“ Registry-afhankelijkheden.
• Updatekanalen: pilot, ring 1, ring 2 – met telemetrie/logging op applicatie- en operationeel niveau.

Stap 5: native ARM64 waar het echt loont

Native ARM64-builds zijn dan zinvol als u (a) de afhankelijkheden onder controle heeft en (b) de toepassing op lange termijn verderontwikkelt. Typisch is het de moeite waard voor kernclients die veel gebruikers dagelijks gebruiken en die u toch al moderniseert. Voor zelden gebruikte tools kan x64-emulatie een acceptabele overgang zijn, zolang support en security meewerken.

Architectuurimpulsen: ARM64 als aanleiding om interfaces en services te versterken

Veel Delphi-landschappen zijn historisch gegroeid als „dikke client“. Dat werkt, maar het bindt operatie en updates sterker aan individuele werkplekconfiguraties. ARM64 maakt zichtbaar waar deze koppeling duur wordt. Een pragmatische moderniseringsstap is daarom vaak niet „UI neu“, maar interfaces herontwerpen.

Meer stabiliteit door serverzijdige verantwoordelijkheden

Als kritieke logica, datatoegang of documentprocessen naar een centrale dienst verhuizen (Windows- en Linux-services of Windows- und Linux-Services, dus een achtergronddienst zonder interactieve UI), krijgt u:

• uniforme driver- en bibliotheekversies,
• beter controleerbare beveiliging (certificaten, secrets, netwerk),
• lagere complexiteit op de client (ARM64, x64, in de toekomst ook andere platformen),
• duidelijkere monitoring- en loggingpunten.

Voor IT-besluitvormers is dit een reëel operationeel voordeel: problemen zijn aan de serverzijde sneller reproduceerbaar in plaats van vast te hangen op „een speciaal notebook“.

REST-API als ontkoppelingslaag

Een REST-API is niet automatisch „modern“, maar het is een robuuste ontkoppeling tussen clients en backend. Ze definieert duidelijk welke gegevens en acties zijn toegestaan en kan goed worden beveiligd (z. B. via tokens, certificaten of SAML 2.0 als identiteitsstandaard in bedrijfsomgevingen). Voor ARM64 betekent dit: de client hoeft minder „wereldkennis“ over databases, drivers en netwerkdetails te dragen.

Ook als u niet direct alles aanpast: al een kleine, goed afgebakende API-component (z. B. documentgeneratie, licentiecontrole, stamgegevensafstemming) kan afhankelijkheden uit de client verwijderen en daarmee ARM64-risico’s verminderen.

Testen en kwaliteit: wat u onder ARM64 anders moet controleren

Veel teams testen desktopsoftware primair functioneel. Bij ARM64 moet u meer operationeel testen, omdat de foutbeelden anders zijn: niet „onjuiste berekening“, maar „component laadt niet“, „driver ontbreekt“, „update faalt“, „Office-integratie valt uit“.

Checklist voor ARM64-gerelateerde acceptatie

• Installatie/Deïnstallatie: schoon, zonder resten, zonder admin-omwegen.
• Updatepad: upgrade over meerdere versies, rollback-scenario, handtekeningcontrole.
• Logging: centrale logs, duidelijke foutcodes bij DLL-laadproblemen, traceerbare afdrukpaden.
• Performance: opstarttijd, data-operaties, grote lijsten/rapporten – onder emulatie en native apart meten.
• Randapparatuur: printerprofielen, specialistische afdruk, scanner-workflows, smartcard-functies.
• Beveiliging: EDR/AV-interactie, proxy/TLS, certificaatopslag, least-privilege-operatie.

Belangrijk is de documentatie: als een probleem ontstaat door ontbrekende ARM64-drivers, is dat geen „bugfix in Delphi“, maar een inkoop- of standaardiseringsbeslissing.

Beheer en support: hoe u ARM64 in de dagelijkse praktijk integreert

In de dagelijkse praktijk telt hoe snel supportgevallen worden opgelost. Voor ARM64 loont het om de supportbaarheid proactief te verhogen:

Gestandaardiseerde apparaatprofielen en duidelijke goedkeuringen

Definieer ondersteunde ARM64-modellen of op zijn minst minimumniveaus (driverstrategie, afdrukstrategie, Security-Agent-versies). Een „werkt op ARM64“ zonder deze kaders leidt tot heterogene omgevingen en daardoor tot slecht reproduceerbare storingen.

Diagnosecapaciteit in de applicatie

Ook zonder ontwikkelaarsfocus is hier een duidelijke eis aan de software zinvol: een systeeminfo-pagina die de architectuur (x64 geëmuleerd vs. ARM64 native), belangrijke paden, versies van kerncomponenten en afdrukconfiguratie toont, vermindert supporttijden aanzienlijk. Dat is geen „nice to have“, maar operationele hygiëne.

Licentiebeheer en dongles

Als hardware-dongles of oudere licentiedrivers in het spel zijn, wordt ARM64 snel kritisch. In veel omgevingen is het verstandig om licenties over te zetten naar netwerkgebaseerde of serverzijde mechanismen. Daarmee vermindert de afhankelijkheid van drivers op eindapparaten en wordt de devicevloot uitwisselbaarder.

Wat betekent dit voor uw Delphi-strategie?

Delphi is in een bedrijfscontext vaak een stabiele bouwsteen voor desktop-clients en services. Windows 11 ARM64 is geen argument „tegen Delphi“, maar wel een argument voor een zuiverdere kapseling van afhankelijkheden en voor een bedrijfsgerichte modernisering: minder lokale gespecialiseerde drivers, minder in-process-componenten, duidelijkere interfaces, beter deployment.

Als u vandaag al op een moderniseringspad zit (bijv. BDE-Ablösung, overstap naar 64‑bit, intensievere REST-integratie, geconsolideerde data‑toegang met FireDAC), dan is ARM64 vaak „slechts“ een extra doelpunt dat prioriteiten verscherpt. Als uw applicatie daarentegen sterk afhankelijk is van oude drivers, proprietaire DLLs en werkplek-specifieke configuraties, is ARM64 een geschikt moment om die risico’s transparant te maken en planbaar te reduceren.

Conclusie: ARM64 is minder een porteringsproject dan een architectuur- en exploitatieproject

Voor bedrijven is Windows 11 ARM64 vooral een platformvraag binnen inkoop, security en support. Voor met Delphi-gebaseerde businesssoftware wordt succes niet bepaald door een compileroptie, maar door de keten van drivers, DLLs, COM-integraties, data‑toegang en updateprocessen. Een robuuste route is: eerst afhankelijkheden en operationele paden zichtbaar maken, dan met pilotapparaten testen, vervolgens doelgericht ontkoppelen en het deployment professionaliseren – en native ARM64-builds leveren waar ze op lange termijn nut en stabiliteit brengen.

Als u Windows 11 ARM64 in uw apparaatpark wilt invoeren en daarbij Delphi-toepassingen, randapparatuur en interfaces planbaar wilt beveiligen, bespreek met ons een gestructureerde inventarisatie en een realistisch migratiepad:

In de vakinhoudelijke context spelen ook Delphi ARM64 Windows en X64-emulatie Windows 11 een belangrijke rol, wanneer integraties, datastromen en doorontwikkeling netjes moeten samenwerken.

Project of moderniseringsproject met Net-Base bespreken.