Windows 11 ARM64 voor Delphi-toepassingen vroeg inplannen

Windows 11 ARM64 is in de dagelijkse B2B-praktijk niet langer slechts een bijzonderheid voor technische enthousiastelingen. Nieuwe generaties notebooks, langere accuduur, „always-on“-scenario’s en de toenemende vraag naar lichte, mobiele werkplekken zorgen ervoor dat bedrijven ARM64-clients aanschaffen – soms bewust, soms naast de standaardmodellen binnen het raamcontract. Voor teams met gegroeide maatwerksoftware is dat een duidelijke aanwijzing: ARM64 moet vroeg in de technische planning, anders wordt het later een kostbare retrofit-operatie.

Bij Delphi-toepassingen is de centrale vraag zelden „kan Delphi dat compileren?“. In de praktijk mislukken ARM64-rollouts vrijwel altijd op de periferie: native DLLs, print-/scan-componenten, databasetrijvers, rapportengines, COM-integraties, setup-routines, code-signing of build-pipelines die stilzwijgend alleen x64 kennen. Juist daarom loont het om Windows 11 ARM64 als architectuur- en operationele eis te behandelen – niet als puur platformfeature.

Dit artikel toont welke technische valkuilen bij Delphi typisch optreden, hoe u de risico’s systematisch identificeert en welke pragmatische migratieroutes zich hebben bewezen – van het stapsgewijs klaarstomen van individuele modules tot een eenduidige doelarchitectuur met services en REST-servers.

Waarom Windows 11 ARM64 nu een architectuurthema is

In veel bedrijven stond „Windows“ lange tijd gelijk aan x86/x64. Die aanname zit verankerd in scripts, installers, third-party componenten en soms zelfs in het datamodel (bijv. paden, registry-keys, driver-interfaces). Zodra ARM64-clients verschijnen, wordt zichtbaar hoeveel impliciete aannames het systeem bevat. En dat is precies de economische kern: late aanpassingen zijn niet slechts „een paar compilerflags“, maar het opschonen van aannames die zich over jaren hebben gefixeerd.

Praktisch relevant wordt ARM64 met name in drie situaties:

• Client-software met lange levensduur: brancheapplicaties die 8–15 jaar worden gebruikt en iteratief worden uitgebreid. Een nieuw clientplatform midden in de levenscyclus is waarschijnlijker dan een volledige herbouw.
• Gemengde fleets: buitendienst/service, management-notebooks, BYOD-achtige scenario’s of dochterondernemingen die andere hardware inkopen.
• Veiligheids- en compliance-druk: modern code-signing, verharding, „least privilege“, gecontroleerde updaters – bij zulke trajecten worden installatie- en updateprocessen toch aangepast. Dat is het moment om ARM64 als neveneis mee te nemen.

Het goede nieuws: wie toch al werkt aan Delphi Modernisierung, de overstap naar 64-bit, het ontkoppelen van data-access of een servicegerichte doelarchitectuur, kan Windows 11 ARM64 vaak „meeliftend“ meenemen – mits het vroeg in het backlog staat en niet pas bij de eerste ARM-machine in de supportafdeling opdookt.

Delphi op ARM64: wat is „easy“, wat is „hard“?

Delphi-projecten verschillen sterk: van zuivere VCL-desktopclients tot meerslachtige systemen met REST-servers, Windows-services, report-workers, integratiecomponenten en achtergrondjobs. Voor Windows 11 ARM64 is doorslaggevend welke onderdelen echt native op de client moeten draaien en welke onderdelen sowieso beter als services uitgevoerd kunnen worden.

De compiler is zelden het hoofdprobleem

Als uw code schoon is (geen inline-assembler, geen oude 32-bit-aannames, geen fragiele pointercasts, geen verouderde API-aanroepen), is compileren voor een nieuw target vaak haalbaar. Problemen ontstaan door:

• Third-party componenten met native delen (DLLs, BPLs, C/C++-bruggen)
• Drivers en apparaatkoppelingen (print, scan, signatuurpads, dongles)
• Database-access via ODBC/OLE DB/client-libraries die niet ARM64-compatibel zijn
• Reporting en Office-integratie (COM-automatisering, oude exportfilters)
• Installer/updater die alleen x64 testen of hardgecodeerde paden gebruiken

Daarmee is Windows 11 ARM64 vooral een „ecosysteemtest“: hoe goed is uw softwarepakket ontkoppeld van oude platformaannames?

VCL, FMX en UI-afhankelijkheden

Veel B2B-brancheapplicaties zijn VCL-gebaseerd en gebruiken in de loop der jaren opgebouwde UI-componenten. Dat is op zich geen probleem – maar UI is vaak de plek waar afhankelijkheden samenkomen: PDF-printers, barcode-generators, beeldbibliotheken, browser-controls, COM-objecten. Voor ARM64 geldt: hoe meer UI-gerelateerde specialcomponents u inzet, hoe belangrijker een vroege compatibiliteitslijst wordt.

Bij multiplatformstrategieën (bijv. Windows + macOS) komt vaak FMX in beeld. Ongeacht het framework is een robuuste strategie het scheiden van vaklogica en integraties van de UI. Dat betaalt zowel uit op Delphi Multiplattform als op Windows 11 ARM64.

Typische technische valkuilen (en hoe u ze vroeg herkent)

In de praktijk zijn de meeste ARM64-problemen vroeg te detecteren als u gestructureerd inventariseert en een „ARM64 Readiness“-check uitvoert. Cruciaal is om niet alleen naar de Delphi-code te kijken, maar naar alles wat bij het product hoort: installer, drivers, configuratie, plugins, third-party tools, update-keten, support-scripts.

1) Native DLLs, BPLs en gemengde process-landschappen

Veel Delphi-toepassingen laden extra DLLs: cryptografie, CAD-viewer, OCR, signatuur, hardware-SDKs, special-parsers. Op x64 wordt vaak stilzwijgend aangenomen dat „er wel een 64-bit DLL is“. Voor ARM64 is dat anders: u heeft expliciet ARM64-binaries nodig of een architectuur die die afhankelijkheid uit de client haalt.

Praktische aanpak:

• Maak een lijst van alle geladen native modules (ook indirect via componenten).
• Klassificeer: „ARM64 beschikbaar“, „x64-only“, „32-bit-only“, „onduidelijk“.
• Beoordeel of het module echt lokaal moet draaien of kan worden uitbesteed aan een service.

Een veelvoorkomend resultaat: één enkele x64-only module blokkeert de hele ARM64-client. Dat is het moment waarop een schone lagen- of Layer-3 Architectuur economisch interessant wordt: de UI/client blijft licht, integraties verhuizen naar gecontroleerde server-/service-lagen.

2) COM, Office-automatisering en Shell-integraties

In veel bedrijven zijn Word/Excel-export, Outlook-koppeling, Explorer-contextmenu’s of DMS-integraties historisch via COM opgebouwd. COM is niet automatisch „ARM64-ready“, zeker wanneer third-party COM-servers of add-ins uitsluitend x64 leveren. Ook het beheer van 32-bit/64-bit-mengvormen (out-of-proc vs. in-proc) wordt snel complex.

Vroege verkenning:

• Welke COM-objecten worden gebruikt (ProgIDs/CLSID-lijst)?
• In-proc of out-of-proc? Zijn er ARM64-registraties?
• Is export via server-side bibliotheken (bijv. documentformaten) mogelijk in plaats van Office-automatisering?

Vaak is dit een moderniseringshefboom: weg van UI-gekoppelde automatisering naar reproduceerbare exportservices (bijv. PDF/Excel via bibliotheek) die zowel voor Windows x64 als voor ARM64 of zelfs Linux-servers inzetbaar zijn.

3) Database-access: ODBC, client-libraries, legacy-BDE

Database-access is een veelvoorkomende ARM64-grens, omdat driverlandschappen en client-libraries hier een rol spelen. Vooral oude ODBC-setups, propriëtaire database-clients of lokale databases met historische toegangslagen zijn kritisch.

Voor Delphi-stacks is dit een klassieker: als er nog Borland BDE, oude Paradox-structuren of moeilijk onderhoudbare driverketens in de mix zitten, wordt ARM64 een katalysator. Een BDE-afbouw en de migratie naar een BDE-Ablösung met native aansluiting en een duidelijke DB-driverstrategie vermindert platformrisico’s aanzienlijk.

Concrete controlevragen:

• Welke DB’s zijn in gebruik (SQL Server, PostgreSQL, MariaDB, Firebird, lokale engines)?
• Welke drivers worden gebruikt (ODBC, native client, BDE-Ablosung mit nativer Anbindung-drivers, OLE DB)?
• Waar staan connection-strings en DSN’s (per gebruiker, per machine, in de installer)?
• Zijn er afhankelijkheden van 32-bit ODBC-drivers of oude providers?

Vooral bij SQL Server/ODBC kan een ARM64-client werken – maar alleen als de driverketen en de installatieroutine op orde zijn. Dat is geen onderwerp om „in het veld“ te debuggen.

4) Reporting, print, scan, PDF en output-workflows

Output is in brancheapplicaties vaak bedrijfskritisch: pakbonnen, etiketten, facturen, protocollen, meterstanden, certificaten, verzendlabels. Veel van deze workflows hangen aan reportingcomponenten of aan specifieke printer-/scanner-drivers.

Op Windows 11 ARM64 zijn de valkuilen typisch:

• Labelprinters/gespecialiseerde drivers alleen als x64 beschikbaar
• Scanner-software/SDK’s zonder ARM64-ondersteuning
• Oude report-engines met native preview-/exportmodules
• PDF-generatie via „virtuele printers“ in plaats van libraries

Een robuuste aanpak is het standaardiseren van outputworkflows: PDF/Office-formaten via libraries genereren, print via gestandaardiseerde interfaces, speciale hardwaretoegang zo veel mogelijk kapselen. Waar dat niet kan, is vroeg een apparaat-/drivermatrix voor ARM64 noodzakelijk.

5) Installer, updater, code-signing en operatie

Veel ARM64-trajecten lopen niet stuk op de applicatie zelf, maar op de levering: setup herkent de architectuur verkeerd, installeert drivers niet, registreert COM niet, zet foute paden of faalt door code-signing regels. Ook automatische updates (delta-updates, self-updater) zijn vaak sterk architectuurafhankelijk.

Belangrijke operationele vragen:

• Hoe wordt geïnstalleerd (MSI, Inno Setup, eigen updater)?
• Hoe worden afhankelijkheden geïnstalleerd (VC++ runtimes, drivers, certificaten)?
• Hoe wordt gesigneerd (EXE, DLL, installer, driverpakketten)?
• Hoe wordt getest: echte ARM64-hardware of alleen aannames?

Voor bedrijven is dit een governance-onderwerp: zodra Windows 11 ARM64 in de clientvloot verschijnt, moet deployment reproduceerbaar zijn – inclusief rollback, supportbaarheid en duidelijke versievoering.

Strategie: Windows 11 ARM64 als „vroege niet-functionele eis“

De economisch verstandige aanpak is om ARM64 als een niet-functionele eis (NFA) te behandelen – vergelijkbaar met performance, security of offline-capaciteit. Dat betekent: niet pas in een sprint „als het echt nodig is“, maar als een gedefinieerde richtlijn voor architectuur en leverketen.

ARM64-Readiness-Check: inventaris in plaats van onderbuik

Een deugdelijke check omvat doorgaans:

• Afhankelijkheidsinventaris: alle third-party componenten, DLLs, drivers, SDKs, browser-controls, cryptomodules, reporting.
• Build-/pipeline-analyse: build-targets, verpakking, signing, artefactopslag, versienummers, reproduceerbaarheid.
• Installer-/update-keten: setup-logica, prerequisites, registry-/bestandsysteem-paden, policies, rechten.
• Operatiemodel: support, logging, crash-dumps, telemetrie (indien aanwezig), rollout-plan.

Het resultaat zou niet „ARM64: ja/nee“ moeten zijn, maar een geprioriteerde lijst: welke blockers bestaan, welke modules zijn betroffen, welke alternatieven zijn er en welke investering is realistisch.

Beslissingsmatrix: native op ARM64 of ontkoppelen?

Bij elke problematische afhankelijkheid is een heldere beslissing nodig:

• ARM64-native vervanging mogelijk: upgrade, leverancier wisselen, overstap naar andere bibliotheek.
• Afhankelijkheid kan worden uitbesteed: bijv. naar een Windows- und Linux-Services, een achtergrondworker of een centrale REST-server.
• Afhankelijkheid moet lokaal blijven: bijv. omdat hardware direct aan de client hangt. Dan zijn bindende ARM64-hardware-/drivergoedkeuringen nodig.

Voor integraties is uitbesteding vaak de zuiverste weg: de client blijft UI + vakdialogen, terwijl complexe integratielogica in gecontroleerde services draait. Dat ondersteunt naast ARM64 ook centrale updates, rechtenconcepten en betere testbaarheid.

Architectuurpatronen die ARM64-projecten stabiel maken

Als Windows 11 ARM64 vroeg wordt ingepland, kunnen meerdere architectuurbeslissingen zo worden genomen dat ze later niet kostbaar herroepen hoeven te worden.

1) Duidelijke lagen: UI, vaklogica, integratie, data-access

Gegroeide Delphi-clients bevatten vaak „alles in één proces“: UI, businessregels, data-access, DMS-koppeling, print en export. Dat is onderhoudbaar zolang het platform stabiel blijft. Zodra platformvarianten (ARM64, mogelijk macOS, mogelijk Terminalserver) relevant worden, neemt de waarde van een heldere scheiding toe.

Pragmatisch doelbeeld:

• UI-laag: minimaal, testbaar, geen directe driver-/SDK-afhankelijkheden.
• Vaklogica: zo veel mogelijk platformneutraal, goed gemodelleerd.
• Integratielaag: kapselt COM, bestandsformaten, DMS/ERP-connectoren, apparaat-SDKs.
• Data-access: geconsolideerd (bijv. FireDAC), duidelijke transactionele grenzen, geen verspreide SQL-fragmenten.

Dat is geen academische discussie maar bespaart later echte kosten: als alleen de integratielaag ARM64-problemen heeft, hoeft de hele client niet opnieuw gebouwd te worden.

2) Services en REST-servers als stabiliteitsanker

Veel B2B-systemen profiteren ervan centrale functies als REST-servers of als Windows-/Linux-services te draaien: rechtencontrole, documentworkflows, data-validatie, export, import, koppelingen naar ERP/DMS/CRM. Als deze functies server-side draaien, vermindert de complexiteit aan de clientzijde sterk – en daarmee ook het ARM64-aanvalsoppervlak.

Typische verdelingen die zich bewezen hebben:

• Client: dialogen, weergave, offline-logica (indien nodig), minimale lokale integraties.
• REST-server: vakmatige operaties, validatie, multi-tenant-capaciteit, centrale logging.
• Worker/Service: geplande jobs, interface-polling, rapportgeneratie, batch-exports.

Dat past ook bij moderne operationele modellen: een functie die server-side draait wordt één keer geüpdatet – in plaats van op elke ARM64-client afzonderlijk.

3) Eén build-systeem, meerdere targets (x64 + ARM64) vanaf het begin

Als ARM64 een doel is, moet de build-pipeline dat weerspiegelen. Niet als „we doen later een speciale build“, maar als standaard: elke releasecandidate wordt reproduceerbaar gebouwd voor x64 (en, indien voorzien, ARM64), inclusief signering en installer-packaging.

Belangrijker dan tooling is consistentie:

• Artefacten duidelijk benoemen (architectuur in pakketnaam/mappenstructuur).
• Configuratiewaarden per target scheiden (paden, prerequisites, driverpakketten).
• Smoke-tests per architectuur definiëren (start, login, DB-verbinding, print/PDF).

Zo wordt ARM64 geen „Big Bang“, maar een gecontroleerd extra target.

Delphi-modernisering: ARM64 als gelegenheid om technische schuld gericht af te bouwen

Veel bedrijven gebruiken nieuwe platformeisen als aanleiding voor „alles vernieuwen“. Dat is risicovol en vaak onnodig. Veel rendabeler is het om Windows 11 ARM64 als richtsnoer te gebruiken voor stapsgewijze modernisering: technische schuld wegnemen waar die ARM64 blokkeert of de leverbaarheid in gevaar brengt.

64-bit en Unicode: oude bouwplaatsen niet doorschuiven

Als de codebase nog 32-bit-aannames of ballast uit vroege Delphi-versies bevat, komen die bij een platformwisseling opnieuw naar boven. Ook al betekent ARM64 niet automatisch „Unicode“: veel projecten die ARM64 serieus oppakken, nemen tegelijkertijd zekerheid dat Unicode correct is, dat 64-bit-paden zijn ingericht en dat geheugen-/pointervragen zijn opgeschoond.

Het doel is geen perfectie, maar een betrouwbaar niveau: code die zonder herhaaldelijk dezelfde foutklassen voor nieuwe targets kan worden gebouwd.

BDE-afbouw en geconsolideerde data-access als ARM64-enabler

Waar nog historische toegangslagen bestaan (BDE, lokale Paradox-data, gemixte data-accessen), is consolidatie een hefboom met meervoudig effect: onderhoudbaardere code, stabielere deployments, duidelijkere driverstrategie. Met FireDAC kan de toegang in veel scenario’s worden geharmoniseerd, inclusief centrale parameterbeheer, poolingstrategieën en robuuste foutafhandeling.

Belangrijk: een BDE-afbouw is niet slechts „componenten vervangen“. Het raakt transactielogica, datatypen, sorteerregels, filtersemantiek en deels ook het datamodel. Daarom verdient het planning – en geen ad-hocmaatregel wanneer ARM64-clients ineens in het veld verschijnen.

Test en kwaliteit: ARM64 is alleen planbaar als het meetbaar wordt

ARM64 vroeg inplannen betekent ook: testen – niet per se een volledige featuretest, maar gericht risicotesten van de kritische keten. De belangrijkste stap is een reële ARM64-testomgeving. Emulatie kan in specifieke gevallen helpen, maar vervangt niet het testen op echte hardware, met echte drivers en echte beveiligingsregels.

Minimale ARM64-smoke-test: wat echt vroeg afgedekt moet zijn

Een pragmatische maar effectieve smoke-testset voor elke releasecandidate:

• Programma-start, login, basis-UI-functionaliteit
• DB-verbinding (incl. authenticatie, certificaten, DNS/proxy indien relevant)
• Een kernproces „end-to-end“ (bijv. opdracht aanmaken, opslaan, printen/exporteren)
• Updater/installer: nieuwe installatie en update over een versie heen
• Logging/foutdialogen: zijn diagnoses op ARM64 ook bruikbaar?

Zo worden typische ARM64-blockers vroeg zichtbaar: ontbrekende DLLs, foute drivers, setup-problemen, onverwachte rechtenvereisten.

Diagnosevermogen: crash-dumps, logs, versionstransparantie

Als ARM64 in de vloot zit, zullen supportgevallen komen – al vanwege nieuwe drivercombinaties. Daarom loont standaardisatie van diagnose: duidelijke build-IDs, informatieve logs, reproduceerbare installatie- en updatepaden. Dit is niet specifiek voor ARM64, maar ARM64 maakt tekortkomingen hier snel kostbaar.

Rollout en operatie: gemengde fleets zonder chaos

De meeste bedrijven zullen middellang gemengde clientvloten draaien: een deel x64, een deel ARM64. De sleutel is om die toestand bewust te ontwerpen.

Packaging: gescheiden installers, duidelijke detectie, eenduidige downloadpaden

In de praktijk werkt het het beste wanneer installers/pakketten eenduidig zijn: x64-pakket is voor x64, ARM64-pakket is voor ARM64. „Één installer voor alles“ klinkt comfortabel, maar wordt snel complex (detectielogica, prerequisites, driverpaden, signing, reparatie-installatie). Voor gecontroleerde bedrijfsrollouts is eenduidigheid vaak robuuster.

Update-strategie: geen speciale paden voor ARM64

ARM64 moet geen uitzondering zijn in het updateproces. Doel is: gelijke releaserythme, gelijke functionele versie, maar gescheiden artefacten. Als ARM64 alleen handmatig wordt bijgewerkt ontstaat er drift in de vloot die later supportkosten opjaagt.

Integraties goed documenteren

Veel ARM64-problemen zitten niet in de eigen code, maar in integraties: ERP-connector, DMS-client, signatuurdienst, scanner-software, labelprinter. Een bijgehouden integratielijst met versiestanden en architectuurnotities is voor B2B-systemen sowieso verstandig – en maakt ARM64-beslissingen transparant.

Wat bedrijven nu concreet moeten doen (zonder actiegerichtheid)

Windows 11 ARM64 vroeg inplannen betekent niet meteen alles omgooien. Het betekent de juiste vragen vroeg beantwoorden en blockers elimineren zolang inspanning planbaar is. Een bewezen aanpak is:

• 1) Inventarisatie (2–10 dagen afhankelijk van systeemgrootte): afhankelijkheden, installer, drivers, data-access, COM, reporting.
• 2) Doelbeeld en pad: wat moet native op de client? Wat wordt service/REST? Welke componenten worden vervangen?
• 3) Proof of feasibility: een werkende ARM64-build met installer en een end-to-end use case.
• 4) Stapsgewijze verharding: resterende functies, tests, updateketen, diagnosevermogen.

Zo ontstaat geen „ARM64-project“ dat maandenlang geïsoleerd draait, maar een gecontroleerde uitbreiding van de leverbaarheid.

Conclusie: Windows 11 ARM64 is geen hype maar een vroegtijdige indicator voor technische volwassenheid

Windows 11 ARM64 wordt voor veel bedrijven eenvoudigweg realiteit – door hardwareinkoop, mobiliteitseisen of standaardisatie. Voor Delphi-toepassingen is de eigenlijke uitdaging niet alleen de broncode, maar het gehele systeem van afhankelijkheden, installatie- en updateprocessen, integraties en drivers. Wie ARM64 vroeg meeneemt, kan deze punten gestructureerd oplossen in plaats van ze later onder tijdsdruk te „patchen“.

Uiteindelijk is ARM64 een nuttige toetssteen: hoe goed is uw applicatie ontkoppeld, testbaar en leverbaar? Als u die vraag nu beantwoordt, wint u niet alleen platformopties, maar ook een stabielere basis voor modernisering, services, REST-architecturen en langdurige onderhoudbaarheid.

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.