Planlæg Windows 11 ARM64 tidligt for Delphi-applikationer

Windows 11 ARM64 er i B2B-hverdagen ikke længere kun et særsyn for teknikentusiaster. Nye generationer af notebooks, længere batterilevetid, „Always-on“-scenarier og det stigende ønske om lette, mobile arbejdspladser betyder, at virksomheder køber ARM64-klienter – nogle gange bevidst, andre gange ved siden af gennem standardmodeller i rammeaftaler. For teams med etableret specialsoftware er det en klar besked: ARM64 skal tidligt ind i den tekniske planlægning, ellers bliver det senere et dyrt eftermonteringsprojekt.

Hos Delphi-applikationer er det centrale spørgsmål sjældent „kan Delphi kompilere det?“. I praksis fejler ARM64-rollouts næsten altid i periferien: native DLL’er, print-/scan-komponenter, database-drivere, report-engines, COM-integrationer, setup-rutiner, code-signing eller build-pipelines, der tavst kun kender x64. Netop derfor giver det mening at behandle Windows 11 ARM64 som en arkitektur- og driftskrav – ikke blot som et platformsegenskab.

Denne artikel viser, hvilke tekniske faldgruber der typisk opstår ved Delphi, hvordan I systematisk identificerer risiciene, og hvilke pragmatiske migrationsveje der har vist sig effektive – fra trinvise tilpasninger af enkeltmoduler til en klar målarkitektur med services og REST-servere.

Warum Windows 11 ARM64 jetzt ein Architekturthema ist

I mange virksomheder har „Windows“ længe været lig med x86/x64. Den antagelse ligger i scripts, installere, tredjepartskomponenter og nogle gange endda i datamodellen (fx stier, registry-nøgler, driver-interfaces). Når ARM64-klienter dukker op, bliver det synligt, hvor meget implicit viden systemet rummer. Og netop det er den økonomiske kerne: Senere tilpasninger er ikke bare „et par compiler-flags“, men en oprydning af antagelser, som har sat sig over år.

Praktisk bliver ARM64 relevant især i tre situationer:

• Klientsoftware med lang levetid: Fagsystemer, der bruges i 8–15 år og udvides iterativt. En ny klientplatform midt i livscyklussen er mere sandsynlig end et komplet nybyg.
• Blandede flåder: Eksternt salg/service, ledelses-notebooks, BYOD-nære scenarier eller datterselskaber, der indkøber anden hardware.
• Sikkerheds- og compliance-pres: Moderne code-signing, hardening, „least privilege“, kontrollerede updatere – installations- og opdateringsprocesser ændres alligevel. Netop dér er det billigere at integrere ARM64 som en sidekrav.

Den gode nyhed: Dem, der i forvejen arbejder med Delphi Modernisierung, 64-bit-migration, afkobling af dataadgang eller en serviceorienteret målarkitektur, kan ofte „tage Windows 11 ARM64 med“ – forudsat at det står tidligt i backloggen og ikke først dukker op ved den første ARM-maskine i support.

Delphi auf ARM64: Was ist „easy“, was ist „hard“?

Delphi-projekter varierer stærkt: fra rene VCL-desktop-klienter til flerlags-systemer med REST-Server, Windows-services, report-workere, integrations-komponenter og baggrundsjob. For Windows 11 ARM64 er det afgørende, hvilke dele der virkelig skal køre nativt på klienten, og hvilke der med fordel kan outsources til services.

Der Compiler ist selten das Hauptproblem

Hvis egen kode er ren (ingen inline-assembler, ingen gamle 32-bit-antagelser, ingen skrøbelige pointer-casts, ingen forældede API-kald), er kompilering til en ny målplatform ofte gennemførlig. Problemer opstår gennem:

• Tredjepartskomponenter med native dele (DLL’er, BPL’er, C/C++-broer)
• Drivere og enhedstilslutning (print, scan, signaturpads, dongles)
• Databaseadgang via ODBC/OLE DB/klientbiblioteker, som ikke understøtter ARM64
• Reporting og Office-integration (COM-automation, gamle eksportfiltre)
• Installer/Updater, der kun tester x64 eller bruger hårdkodede stier

Dermed er Windows 11 ARM64 først og fremmest en „økosystemtest“: Hvor godt er jeres softwarepakke afkoblet fra gamle platformantagelser?

VCL, FMX und UI-Abhängigkeiten

Mange B2B-fagsystemer er VCL-baserede og bruger gennem årene opbyggede UI-komponenter. Det er ikke i sig selv et problem – men UI er ofte stedet, hvor afhængigheder samler sig: PDF-printere, stregkode-generatorer, billedbiblioteker, browser-controls, COM-objekter. For Windows 11 ARM64 gælder: Jo flere UI-nære specialkomponenter I bruger, desto vigtigere er en tidlig kompatibilitetsliste.

Ved multiplatform-strategier (fx Windows + macOS) kommer FMX ofte i spil. Uanset rammeværk er en robust strategi at adskille faglogik og integrationer fra UI. Det gavner både Delphi Multiplattform og Windows 11 ARM64.

Typische technische Stolpersteine (und wie man sie früh erkennt)

I praksis kan de fleste ARM64-problemer identificeres tidligt, hvis I laver en struktureret inventarliste og gennemfører en „ARM64 Readiness“-check. Det er afgørende ikke kun at se på Delphi-koden, men alt hvad der hører til produktet: installer, drivere, konfiguration, plugins, tredjepartsværktøjer, update-kæde, support-scripts.

1) Native DLLs, BPLs und gemischte Prozesslandschaften

Mange Delphi-applikationer loader ekstra DLL’er: kryptografi, CAD-viewere, OCR, signaturer, hardware-SDKs, special-parsere. På x64 antages det ofte tavst, at „der findes en 64-bit DLL“. For ARM64 er det anderledes: I har eksplicit brug for ARM64-binaries eller en arkitektur, der fjerner denne afhængighed fra klienten.

Praktisk fremgangsmåde:

• Lav en liste over alle indlæste native moduler (også indirekte via komponenter).
• Klassificer: „ARM64 tilgængelig“, „x64-only“, „32-bit-only“, „uklar“.
• Vurdér, om modulet virkelig skal være lokalt, eller om det kan flyttes til en service.

Et hyppigt fund: Et enkelt x64-only-modul blokerer hele ARM64-klienten. Det er det tidspunkt, hvor en klar lagdelt eller Layer-3 Architektur bliver økonomisk: UI/klient holdes let, integrationer flyttes til kontrollerede server-/service-lag.

2) COM, Office-Automation und Shell-Integrationen

I mange virksomheder er Word/Excel-eksport, Outlook-tilknytning, Explorer-kontekstmenuer eller DMS-integrationer vokset frem via COM. COM er ikke automatisk „ARM64-ready“, især hvis tredjeparts COM-servere eller add-ins kun leveres som x64. Drift af 32-bit/64-bit-miks (out-of-proc vs. in-proc) bliver hurtigt kompleks.

Tidlig afklaring:

• Hvilke COM-objekter bruges (ProgIDs/CLSID-liste)?
• In-Proc eller Out-of-Proc? Findes der ARM64-registreringer?
• Kan eksport løses via serverside-biblioteker (fx dokumentbaserede formater) i stedet for Office-automation?

Ofte er det et moderniseringsgreb: Væk fra UI-koblet automation og hen imod reproducerbare eksportservices (fx PDF/Excel via bibliotek), som kan anvendes både fra Windows x64-klienter, ARM64 eller endda Linux-servere.

3) Datenbankzugriff: ODBC, Client-Libraries, Legacy-BDE

Dataadgang er en hyppig ARM64-flaskehals, fordi driverlandskaber og klientbiblioteker spiller ind. Særligt kritiske er gamle ODBC-opsætninger, proprietære database-klienter eller lokale databaser med historiske adgangslag.

For Delphi-stacks er det klassisk: Hvis der stadig er Borland BDE, gamle Paradox-strukturer eller svært vedligeholdelige driverkæder, bliver ARM64 en katalysator. En BDE-afvikling og en overgang til BDE-Ablösung mit nativer Anbindung med en klar DB-driverstrategi reducerer platformrisici markant.

Konkrete tjekpunkter:

• Hvilke DB’er er i brug (SQL Server, PostgreSQL, MariaDB, Firebird, lokale engines)?
• Hvilke drivere bruges (ODBC, native client, BDE-Ablosung mit nativer Anbindung-drivere, OLE DB)?
• Hvor ligger connection-strings og DSNs (per bruger, per maskine, i installeren)?
• Er der afhængigheder til 32-bit ODBC-drivere eller gamle providere?

Især med SQL Server/ODBC kan en ARM64-klient fungere – men kun hvis driverkæden og installationsrutinen er i orden. Det er ikke noget, man vil debugge „in the field“.

4) Reporting, Druck, Scan, PDF und Output-Workflows

Output er i fagsystemer ofte forretningskritisk: følgesedler, etiketter, fakturaer, rapporter, måleraflæsninger, certifikater, forsendelseslabels. Mange af disse workflows er bundet til reporting-komponenter eller specifikke printer-/scanner-drivere.

På Windows 11 ARM64 er de typiske faldgruber:

• Etiket-/specialprinterdrivere kun tilgængelige som x64
• Scanner-software/SDK’er uden ARM64-support
• Gamle report-engines med native preview-/export-moduler
• PDF-generering via „virtual printers“ i stedet for biblioteker

En robust tilgang er at standardisere output-workflows: generer PDF/Office-formater via biblioteker, print via standardiserede interfaces, kapsl specialhardwareadgang mest muligt. Hvor det ikke er muligt, skal der tidligt en enheds-/drivermatrix for ARM64 på plads.

5) Installer, Updater, Code-Signing und Betrieb

Mange ARM64-projekter fejler ikke på selve programmet, men på leverancen: Setup registrerer forkert arkitektur, installerer ikke drivere, registrerer ikke COM, sætter forkerte stier eller fejler pga. code-signing-politikker. Også automatiske opdateringer (delta-updates, self-updaters) er ofte stærkt arkitekturafhængige.

Vigtige drifts-spørgsmål:

• Hvordan installeres der (MSI, Inno Setup, egen updater)?
• Hvordan installeres afhængigheder (VC++ runtimes, drivere, certifikater)?
• Hvordan signeres artefakter (EXE, DLL, installer, driverpakker)?
• Hvordan testes: ægte ARM64-hardware eller kun antagelser?

For virksomheder er det et governance-tema: Når Windows 11 ARM64 dukker op i klientflåden, skal deployment være reproducerbart – inklusive rollback, supportbarhed og klar versionsstyring.

Strategie: Windows 11 ARM64 als „frühe Nicht-Funktionale Anforderung“

Den økonomisk fornuftige tilgang er at behandle ARM64 som en ikke-funktionel krav (NFA) – på linje med performance, sikkerhed eller offline-evne. Det betyder: ikke først i en sprint „når det brænder“, men som en defineret styringsramme for arkitektur og leverancekæde.

ARM64-Readiness-Check: Inventar statt Bauchgefühl

En robust check omfatter typisk:

• Afhængighedsinventar: alle tredjepartskomponenter, DLL’er, drivere, SDK’er, browser-controls, kryptomoduler, reporting.
• Build-/pipeline-analyse: build-targets, pakkeproces, signering, artefaktlagring, versionsnumre, reproducerbarhed.
• Installer-/update-kæde: setup-logik, prerequisites, registry-/filsystemstier, policies, rettigheder.
• Driftsmodel: support, logging, crash-dumps, telemetri (hvis til stede), rollout-plan.

Resultatet bør ikke være „ARM64: ja/nej“, men en prioriteret liste: hvilke blockere findes, hvilke moduler er berørt, hvilke alternativer findes, og hvilken investering er realistisk.

Entscheidungsmatrix: Nativ auf ARM64 oder entkoppeln?

For hver problematisk afhængighed bør der træffes en klar beslutning:

• ARM64-native erstatninger mulige: opgradering, leverandørskifte, skift til et andet bibliotek.
• Afhængighed kan outsources: fx til en Windows- und Linux-Services, en baggrundsworker eller en central REST-Server.
• Afhængighed skal blive lokal: fx fordi hardware er direkte tilsluttet klienten. Så kræves bindende ARM64-hardware-/driver-godkendelser.

Særligt for integrationer er outsourcing ofte den reneste løsning: klienten forbliver UI + fagsamtaler, mens kompleks integrationslogik kører i kontrollerede services. Det hjælper ud over ARM64 også med centrale opdateringer, rettighedskoncepter og bedre testbarhed.

Architektur-Pattern, die ARM64-Projekte stabil machen

Hvis Windows 11 ARM64 planlægges tidligt, kan flere arkitekturvalg træffes, så de ikke senere skal revideres dyrt.

1) Klare Schichten: UI, Fachlogik, Integration, Datenzugriff

Voksede Delphi-klienter har ofte „alt i én proces“: UI, forretningsregler, dataadgang, DMS-tilknytning, print og eksport. Det er holdbart, så længe platformen er stabil. Når platformvarianter (ARM64, evt. macOS, evt. terminalserver) bliver relevante, stiger værdien af en klar lagdeling.

Pragmatiske målbilleder:

• UI-lag: minimalt, testbart, ingen direkte driver-/SDK-afhængigheder.
• Faglogik: så platformneutral som muligt, klart modelleret.
• Integrationslag: kapsler COM, filformater, DMS/ERP-connectorer, enheds-SDKs.
• Dataadgang: konsolideret (fx FireDAC), klare transaktionsgrænser, ingen spredte SQL-fragmenter.

Det er ikke teori, men reelle besparelser: Hvis kun integrationslaget er ARM64-problemfyldt, behøver hele klienten ikke genudvikles.

2) Services und REST-Server als Stabilitätsanker

Mange B2B-systemer har gavn af at køre centrale funktioner som REST-servere eller som Windows-/Linux-services: rettighedstjek, dokumentworkflows, datavalidering, eksport, import, interfaces til ERP/DMS/CRM. Når disse funktioner kører server-side, reduceres kompleksiteten på klienten betydeligt – og dermed også ARM64-angrebsfladen.

Typiske opdelinger, der har vist sig robuste:

• Klient: dialoger, visning, offline-logik (hvis nødvendigt), minimale lokale integrationer.
• REST-Server: faglige operationer, validering, multi-tenant-support, central logning.
• Worker/Service: tidsstyrede jobs, interface-polling, report-generering, batch-eksporter.

Det passer også til moderne driftsmodeller: En funktion, der kører server-side, opdateres ét sted – i stedet for på hver ARM64-klient individuelt.

3) Ein Build-System, mehrere Targets (x64 + ARM64) von Anfang an

Hvis ARM64 er et mål, bør build-pipelinen afspejle det. Ikke som „vi laver en særlig build senere“, men som standard: Hver release-kandidat bygges reproducerbart for x64 (og, hvis planlagt, ARM64), inklusive signering og installer-pakning.

Vigtigt er mindre værktøjerne end konsekvensen:

• Benævn artefakter klart (arkitektur i pakkenavn/mappe).
• Adskil konfigurationsværdier per target (stier, prerequisites, driverpakker).
• Definér smoke-tests per arkitektur (start, login, DB-forbindelse, print/PDF).

Derved bliver ARM64 ikke et „big bang“, men et kontrolleret ekstra target.

Delphi-Modernisierung: ARM64 als Gelegenheit, technische Schulden gezielt abzubauen

Mange virksomheder bruger nye platformkrav som anledning til „alt nyt“. Det er risikabelt og ofte unødvendigt. Mere økonomisk er det at bruge Windows 11 ARM64 som en styringsramme for trinvis modernisering: fjern teknisk gæld, hvor den blokerer ARM64 eller truer leveringsdygtighed.

64-Bit und Unicode: alte Baustellen nicht verschleppen

Hvis kodebasen stadig rummer 32-bit-antagelser eller arvegods fra tidlige Delphi-versioner, dukker de igen op ved platformskift. Selvom ARM64 ikke automatisk betyder „Unicode“, sørger mange projekter, der tager ARM64 alvorligt, samtidig for at få Unicode på plads, etablere 64-bit-stier og rydde op i hukommelse-/pointer-spørgsmål.

Målet er ikke perfektion, men en pålidelig standard: kode der kan bygges for nye targets uden at gentage de samme fejlklasser hver gang.

BDE-Ablösung und konsolidierter Datenzugriff als ARM64-Enabler

Hvor historiske adgangslag stadig findes (BDE, lokale Paradox-data, blandede dataadgange), er konsolidering et løft med multipel effekt: mere vedligeholdelsesvenlig kode, stabilere deployment, klarere driverstrategi. Med FireDAC kan adgangen i mange scenarier standardiseres, inkl. central parameterstyring, pooling-strategier og ordentlig fejlbehandling.

Vigtigt: En BDE-afvikling er ikke blot „komponentudskiftning“. Den påvirker transaktionslogik, datatyper, sortering, filtersemantik og delvist datamodellen. Derfor bør den planlægges – ikke håndteres som nødforanstaltning, når ARM64-klienter pludselig dukker op i feltet.

Test und Qualitätssicherung: ARM64 ist nur dann planbar, wenn es messbar wird

At planlægge ARM64 tidligt betyder også: det skal testes – ikke nødvendigvist fuldt ud hver funktion, men målrettet risikotest af den kritiske kæde. Det vigtigste skridt er at have et reelt ARM64-testmiljø. Emulering kan i enkelte tilfælde hjælpe, men erstatter ikke praksis med ægte hardware, rigtige drivere og faktiske sikkerhedspolitikker.

Minimaler ARM64-Smoke-Test: was wirklich früh abgedeckt sein sollte

Et pragmatisk, men effektivt smoke-test-sæt for hver release-kandidat:

• Programstart, login, grundlæggende UI-funktioner
• DB-forbindelse (inkl. autentificering, certifikater, DNS/proxy hvis relevant)
• En kerneproces „end-to-end“ (fx oprette ordre, gemme, printe/eksportere)
• Updater/Installer: nyinstallation og opdatering over en version
• Logging/fejl-dialoger: er diagnostik også brugbar på ARM64?

Derved bliver typiske ARM64-blokkere tidligt synlige: manglende DLL’er, forkerte drivere, setup-problemer, uventede rettighedskrav.

Diagnosefähigkeit: Crash-Dumps, Logs, Versionstransparenz

Når ARM64 er i flåden, vil supporttilfælde opstå – alene pga. nye driverkombinationer. Derfor betaler det sig at standardisere diagnostik: klare build-IDs, meningsfulde logs, reproducerbare installations- og updateveje. Det er ikke specifikt for ARM64, men ARM64 gør mangler her særligt kostbare.

Rollout und Betrieb: gemischte Flotten ohne Chaos

De fleste virksomheder vil på mellemlang sigt køre blandede klientflåder: en del x64, en del ARM64. Nøglen er at designe denne tilstand bevidst.

Paketierung: getrennte Installer, klare Erkennung, eindeutige Downloadwege

I praksis fungerer det bedst, når installer/pakker er entydige: x64-pakken er x64, ARM64-pakken er ARM64. „En installer til alt“ lyder praktisk, men bliver hurtigt kompleks (tjeklogik, prerequisites, driverstier, signering, repair-install). Til kontrollerede virksomhedsrollouts er entydighed ofte mere robust.

Update-Strategie: keine Sonderpfade für ARM64

ARM64 bør ikke være en undtagelse i updateprocessen. Målet er: samme releasefrekvens, samme funktionsversionsnummer, men adskilte artefakter. Hvis ARM64 kun opdateres „manuelt“, opstår afvigelser i flåden, som senere øger supportomkostningerne.

Integrationen sauber dokumentieren

Mange ARM64-problemer ligger ikke i egen kode, men i integrationer: ERP-connector, DMS-klient, signaturservice, scanner-software, etiketprinter. En vedligeholdt integrationsliste med versionsstand og arkitekturnoter er for B2B-systemer i forvejen fornuftig – og gør ARM64-beslutninger transparente.

Was Unternehmen jetzt konkret tun sollten (ohne Aktionismus)

Windows 11 ARM64 tidligt på radaren betyder ikke, at alt skal ombygges straks. Det betyder at besvare de rigtige spørgsmål tidligt og fjerne blockere, mens indsatsen er planbar. Et gennemprøvet forløb er:

• 1) Statusoptælling (2–10 dage afhængig af systems størrelse): afhængigheder, installer, drivere, dataadgang, COM, reporting.
• 2) Målbillede og vej: Hvad skal køre nativt på klienten? Hvad bliver service/REST? Hvilke komponenter udskiftes?
• 3) Proof of Feasibility: en kørende ARM64-build med installer og et end-to-end use-case.
• 4) Trinvise hærdninger: resterende funktioner, tests, update-kæde, diagnostikmuligheder.

Så opstår der ikke et isoleret „ARM64-projekt“, der kører i månedsvis, men en kontrolleret udvidelse af leveringsevnen.

Fazit: Windows 11 ARM64 ist kein Hype, sondern ein Frühindikator für technische Reife

Windows 11 ARM64 bliver for mange virksomheder ganske enkelt en realitet – gennem hardwareindkøb, mobilitetskrav eller standardisering. For Delphi-applikationer er den egentlige udfordring ikke kun kildekoden, men hele systemet af afhængigheder, installations- og update-processer, integrationer og drivere. Dem, der planlægger ARM64 tidligt, kan strukturere afklaringerne i stedet for at skulle „patche“ dem under tidspres.

Til sidst er ARM64 en nyttig prøve: Hvor godt er jeres applikation afkoblet, testbar og leveringsdygtig? Hvis I svarer på det nu, får I ikke blot flere platformmuligheder, men også en mere stabil base for modernisering, services, REST-arkitekturer og langsigtet vedligehold.

Kontaktieren Sie Net-Base Software GmbH, hvis I vil vurdere Windows 11 ARM64 i jeres Delphi-roadmap på et solidt teknisk grundlag og implementere det med en klar teknisk vej.