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 komen via gestandaardiseerde notebookvloten, langere accuduur, nieuwe beveiligingsfuncties in de hardware en een strategische diversificatie van de toeleveringsketen. Zodra afdelingen nieuwe apparaten aanschaffen of OEMs bepaalde modellen alleen nog als Windows on 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 ontwikkelingsvraag dan een kwestie van afhankelijkheden, deploymentstrategieën, stuurprogramma’s, interfaces en het werkelijke gedrag in het veld. In de praktijk zijn er drie routes: voortzetting via emulatie, native ARM64-builds of een overgangsmodel dat risico’s gecontroleerd vermindert. Dit artikel plaatst de typische valkuilen en toont een betrouwbare route die werkt in IT‑planning, rollout en exploitatie — zonder de reflex „alles opnieuw“.

Waarom Windows 11 ARM64 nu relevant wordt

Windows on ARM is niet nieuw, maar de randvoorwaarden zijn veranderd: de apparaten zijn beschikbaar in zakelijke omgevingen, Windows 11 brengt een duidelijk rijpere x64-emulatie, en softwareleveranciers bieden steeds vaker ARM64-varianten. Voor bedrijven betekent dit: ARM64 verschijnt niet als een eenmalig pilotproject, maar als een platform dat onderdeel wordt van inkoop- en levenscyclusplanning.

Voor procesnabije softwareoplossingen is de CPU zelf vaak minder het probleem dan de periferie- en integratierealiteit: printers, handtekeningkaarten, scanners, Office-add-ins, COM-componenten (COM is het componentenmodel van Microsoft voor de integratie van applicaties en bibliotheken), shell-extensies, VPN-clients of security‑agenten. Als iets daarvan niet ARM64‑geschikt is, ontstaat extra supportwerk — en vaak wordt dan „de applicatie“ verantwoordelijk gehouden.

Plaatsing: wat betekent ARM64 technisch voor Delphi-applicaties?

Delphi-applicaties in bedrijfsomgevingen zijn vaak klassieke Windows-desktopclients (vaak VCL, dat wil zeggen de Visual Component Library voor Windows-GUI’s) met database‑toegang (bijv. via BDE-Ablösung mit nativer Anbindung, Delphis data‑accesslaag) en een mix van lokale en externe integraties. Onder Windows 11 ARM64 ontstaan daarbij drie uitvoeringsvormen:

1) Native ARM64-Ausführung

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

2) x64-Emulation unter Windows 11 ARM64

Windows 11 kan x64-toepassingen emuleren. Voor veel zuivere 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, doet de architectuur ertoe. Een x64-proces kan geen ARM64-DLL laden en andersom ook niet. Juist die grens bepaalt vaak of iets ‚loopt‘ of ’niet loopt‘.

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

Een overgangspad is om kritische x64-componenten uit het proces te trekken: bijv. als externe service, als REST-backend (REST is een HTTP-gebaseerd interfacemodel) of als apart hulpprogramma. Dat is minder elegant dan ‚alles native‘, maar vaak de economischste route om de operatie te waarborgen en afhankelijkheden stapsgewijs te moderniseren.

Windows 11 ARM64 met Delphi in bedrijven: De typische afhankelijkheden die het succes bepalen

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

Native DLLs und SDKs: Het onzichtbare risico

Veel Delphi-toepassingen binden third-party DLLs in: PDF-generatie, Barcode/QR, beeldverwerking, encryptie, proprietaire communicatiebibliotheken. Onder ARM64 geldt strikt: 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 u door de softwareverantwoordelijke een lijst geven welke DLLs in de installatiemap liggen en welke via systeempaden worden geladen. Dat is de basis om te beoordelen of leveranciers ondersteuning bieden en welke alternatieven er zijn.

COM, Office-automatisering en shell-extensies

COM wordt in het bedrijfsleven vaak gebruikt zonder dat het zo genoemd wordt: Outlook-integratie, Excel-export via Automation, DMS-clients, preview-handlers in de Explorer, contextmenu-extensies. Het probleem onder ARM64 is minder COM zelf, maar de bitness-koppeling: in-process-COM-servers (DLL-gebaseerde COM-componenten) moeten dezelfde architectuur hebben. Out-of-process-COM (EXE-gebaseerde servers) is flexibeler omdat die in een apart proces kan draaien.

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

Afdruk, PDF en driverlandschap

Afdrukproblemen zijn bij platformwissels een klassieker. Onder Windows 11 ARM64 is beslissend of de printerfabrikant ARM64-drivers levert of dat Universal Print/IPP-klassenstuurprogramma’s (IPP is een gestandaardiseerd afdrukprotocol) kunnen worden gebruikt. Ook PDF-printers, batchafdruk, etikettenafdruk en speciale apparaten (bijv. thermische printers) kunnen afhangen van drivers die alleen voor x64 beschikbaar zijn.

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

Toegang tot gegevens: FireDAC, ODBC/OLE DB en databaseclients

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

Voor stabiele exploitatie is dit een centrale hefboom: hoe minder de desktopclient direct gebonden is aan databasetreivers en lokale database-„stacks“, hoe eenvoudiger ARM64 wordt. Dit geldt ook vanuit beveiligingsoogpunt: database-inloggegevens, certificaten en netwerkregels zijn serverzijdig consistenter te beheren.

Crypto, smartcards, handtekeningen, VPN, EDR

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

Voor de Delphi-toepassing betekent dit: als u bijvoorbeeld certificaten uit de Windows-certificaatafhandeling gebruikt of TLS via systeemcomponenten regelt, is dat meestal minder kritisch dan wanneer een specifieke externe crypto-DLL in het proces hangt.

Besluitvormingsmatrix: emulatie of native ARM64-portering?

Organisaties hebben een beslissing nodig die de realiteit van support en levenscyclus weerspiegelt. Een simpele ja/nee-vraag („porteren we?“) is zelden toereikend. Beter is een matrix die afhankelijkheden en risico’s weegt:

• Pure client met standaard-Windows-API’s (bestand, netwerk, afdrukken via standaarddrivers): emulatie kan op korte termijn volstaan; native ARM64 is op middellange termijn technisch schoner.
• Client met veel native third-party DLLs (PDF, OCR, hardware): eerst beschikbaarheid controleren, daarna beslissen. Vaak is een hybride pad zinvol.
• Client met COM-DLLs / shell-uitbreidingen: reken op architectuurconflicten; onderzoek ontkoppeling buiten het proces.
• Client met directe DB-driver-zoo: ofwel drivers consolideren, of de datatoegang naar services verplaatsen.
• Hoge regulering/handtekeningen/smartcard: vroegtijdig de ARM64-compatibiliteit van de security- en middlewareketen verifiëren.

Belangrijk: emulatie is geen „tweede klasse“, maar het is een exploitatie-risico als u op lange termijn ARM64-apparaten in de omgeving verwacht. Op zijn vroegst bij grotere updates, driverwissels of wissels 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 wanneer het in golven uitrolbaar is, duidelijke acceptatiecriteria heeft en de support niet overbelast. In Delphi-landschappen heeft een vijfstapsaanpak zich bewezen.

Stap 1: Inventarisatie met de „operationele bril“

Breng niet alleen modules in kaart, maar vooral operationele punten:

• Welke apparaatsklassen: notebooks, robuuste apparaten, terminals?
• Welke randapparatuur: printers, scanners, kaartlezers, labelprinters?
• Welke integraties: Office, DMS, ERP, lokale services, browsercomponenten?
• Welke installatiewijze: MSI, setup-EXE, ClickOnce, handmatige installatie?
• Welke rechten: admin nodig, lokale diensten, firewall-regels?

Deze blik maakt snel zichtbaar of „slechts één client“ in werkelijkheid vijf systeemafhankelijkheden betekent.

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 kritische paden: afdrukken in alle varianten, export/import, handtekening, offline/online, updates, wisselen van tenant, proxy-/VPN-scenario’s. Documenteer afwijkingen als operationele voorvallen, niet als ontwikkelaarsbugs. Zo blijft de prioritering zuiver.

Stap 3: afhankelijkheden verminderen – eerst die met grote impact op support

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 serverzijdige documentgeneratie onderzoeken.
• DB-toegang consolideren: een gedefinieerd driverpad in plaats van „ODBC per werkplek“.
• Hardware-koppeling kapselen: indien mogelijk via externe processen/services die apart geüpdatet kunnen worden.

Stap 4: deployment en updatebaarheid moderniseren

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

• Pakketisering: MSI vs. MSIX (MSIX is Microsofts moderne app-pakketformaat met schone installatie/deïnstallatie en signatuur).
• Signering: code signing (digitale handtekening van EXE/DLL) vermindert SmartScreen- en EDR-wrijving en is relevant voor gecontroleerde rollouts.
• Configuratiemanagement: scheiding van programbestanden en configuratie, heldere 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 de moeite waard is

Native ARM64-builds zijn zinvol als u (a) de afhankelijkheden onder controle heeft en (b) de applicatie op lange termijn verder ontwikkelt. Typisch loont het voor kernclients die veel gebruikers dagelijks hebben en die u toch moderniseert. Bij zelden gebruikte tools kan x64-emulatie een acceptabele overgang zijn, zolang ondersteuning en beveiliging 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 beheer en updates sterker aan individuele werkplekconfiguraties. ARM64 maakt zichtbaar waar deze koppeling duur wordt. Een pragmatische moderniseringsstap is daarom vaak niet „UI nieuw“, maar interfaces herontwerpen.

Meer stabiliteit door serverzijdige verantwoordelijkheden

Als kritische logica, data-toegang of documentprocessen naar een centrale dienst verhuizen (Windows- und Linux-Services of Windows- und Linux-Services, dus een achtergrondservice zonder interactieve UI), verkrijgt u:

• uniforme versies van drivers en bibliotheken,
• beter beheersbare beveiliging (certificaten, secrets, netwerk),
• minder 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 serverzijdig sneller reproduceerbaar, in plaats van vast te lopen op „een speciaal notebook“.

REST-API als ontkoppelingslaag

Een REST-API is niet per se ‚modern‘, maar vormt een robuuste ontkoppeling tussen clients en backend. Ze definieert duidelijk welke gegevens en acties zijn toegestaan en kan goed worden beveiligd (bijv. via tokens, certificaten of SAML 2.0 als identiteitsstandaard in enterprise-omgevingen). Voor ARM64 betekent dit: de client hoeft minder „wereldkennis“ over databases, drivers en netwerkdetails te hebben.

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

Test 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 „verkeerde berekening“, maar „component laadt niet“, „driver ontbreekt“, „update faalt“, „Office-integratie breekt“.

Checklijst voor ARM64-gerelateerde acceptatie

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

Belangrijk is de documentatie: als een probleem veroorzaakt wordt door ontbrekende ARM64-drivers, is dat geen ‚bugfix in Delphi‘, maar een inkoop- of standaardiseringsbeslissing.

Operatie en support: hoe u ARM64 in het dagelijkse werk 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 minimale profielen (stuurprogrammastrategie, printstrategie, security-agentversies). Een „draait op ARM64“ zonder deze afbakening leidt tot inconsistente omgevingen en daarmee tot moeilijk reproduceerbare storingen.

Diagnosemogelijkheden 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, verkort de supporttijd aanzienlijk. Dat is geen „nice to have“, maar bedrijfshygiëne.

Licentiëring en dongles

Als hardware-dongles of oudere licentie-drivers in het spel zijn, wordt ARM64 snel kritisch. In veel omgevingen is het zinvol om licentiemodellen om te zetten naar netwerk- of servergebaseerde mechanismen. Daarmee vermindert de afhankelijkheid van drivers op eindgebruikersapparaten en wordt de devicevloot uitwisselbaarder.

Wat betekent dit voor uw Delphi-strategie?

Delphi is in de zakelijke context vaak een stabiele bouwsteen voor desktopclients en services. Windows 11 ARM64 is geen argument „tegen Delphi“, maar een argument voor een schonere inkapseling van afhankelijkheden en voor een operationele modernisering: minder lokale gespecialiseerde stuurprogramma’s, minder in-process-componenten, duidelijkere interfaces, beter deployment.

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

Conclusie: ARM64 is minder een porteringsproject dan een architectuur- en operationeel project

Voor ondernemingen is Windows 11 ARM64 vooral een platformvraag in inkoop, security en support. Voor Delphi‑gebaseerde businesssoftware wordt succes niet bepaald door een compiler‑optie, maar door de keten van stuurprogramma’s, DLLs, COM‑integraties, data‑toegang en updateprocessen. Een beproefde aanpak is: eerst afhankelijkheden en operationele paden zichtbaar maken, vervolgens met pilotapparatuur testen, daarna gericht ontkoppelen en het deployment professionaliseren – en native ARM64‑builds leveren waar ze op lange termijn nut en stabiliteit bieden.

Als u Windows 11 ARM64 in uw fleet wilt introduceren en daarbij Delphi‑applicaties, periferie en interfaces planbaar wilt beveiligen, praat met ons over een gestructureerde inventarisatie en een realistisch migratiepad:

In het vakinhoudelijke speelveld spelen ook Delphi ARM64 Windows en X64‑emulatie Windows 11 een belangrijke rol wanneer integraties, gegevensstromen en verdere ontwikkeling naadloos moeten samenwerken.

Project of moderniseringsvoorstel met Net-Base bespreken.