Windows 11 ARM64 med Delphi i virksomheder: Muligheder, risici og en pålidelig migrationsvej

Windows-enheder med ARM64-CPU (ARM64 er en 64‑bit-processorarkitektur, kendt fra mobile SoC’er og i stigende grad også fra business-notebooks) er i mange virksomheder ikke længere blot „eksotiske“. De dukker op via standardiserede notebook-flåder, længere batterilevetid, nye sikkerhedsfunktioner i hardwaren og en strategisk diversificering af forsyningskæden. Senest når fagafdelinger anskaffer nye enheder eller OEM’er tilbyder bestemte modeller kun som Windows on ARM, opstår det for IT‑ansvarlige det praktiske spørgsmål: Hvordan opfører vores Delphi-baserede forretningssoftware sig under Windows 11 ARM64 – og hvordan sikrer vi drift, support og videreudvikling?

Kernekernen er: Windows 11 ARM64 med Delphi i virksomheder er i mindre grad et rent udviklingsspørgsmål end et spørgsmål om afhængigheder, deployment-strategier, drivere, grænseflader og den faktiske adfærd i felten. I praksis er der tre veje: fortsat drift via emulering, native ARM64-builds eller en overgangsmodel, der kontrolleret reducerer risici. Dette indlæg klassificerer de typiske faldgruber og viser en holdbar vej, der fungerer i IT-planlægning, rollout og drift – uden en „alt nyt“-refleks.

Hvorfor Windows 11 ARM64 nu bliver relevant

Windows on ARM er ikke nyt, men rammebetingelserne har ændret sig: Enhederne er tilgængelige i business-miljøet, Windows 11 bringer en væsentligt mere moden x64-emulering, og softwareleverandører leverer stadig oftere ARM64-varianter. For virksomheder betyder det: ARM64 optræder ikke som et enkelt pilotprojekt, men som en platform, der indgår i indkøbs- og livscyklusplanlægning.

For procesnære softwareløsninger er det mindre CPU’en i sig selv, der er problemet, og mere periferi- og integrationsrealiteten: print, signaturkort, scannere, Office-tilføjelser, COM-komponenter (COM er Microsofts komponentmodel til integration af applikationer og biblioteker), shell-udvidelser, VPN-klienter eller sikkerhedsagenter. Hvis noget af dette ikke er ARM64-kompatibelt, opstår der supportarbejde – og ofte får „applikationen“ skylden.

Vurdering: Hvad betyder ARM64 teknisk for Delphi-applikationer?

Delphi-applikationer i virksomhedsmiljøet er ofte klassiske Windows-desktop-klienter (ofte VCL, altså Visual Component Library til Windows-GUI’er) med databaseadgang (f.eks. via BDE-afløsning med native tilslutning, Delphis dataadgangslag) og en blanding af lokale og fjerne integrationer. Under Windows 11 ARM64 optræder der tre udførelsesmåder:

1) Native ARM64-udførelse

Applikationen og alle native biblioteker (DLL’er) findes som ARM64. Det er på lang sigt den reneste løsning, fordi den gør ydeevne og stabilitet planlæggelig og undgår emuleringsbetingelser. Den er dog kun realistisk, hvis alle native afhængigheder følger med: databasetreivere, print/preview, PDF-motor, kryptobiblioteker, OCR/scan-SDK’er, hardware-dongle-drivere osv.

2) x64-emulering under Windows 11 ARM64

Windows 11 kan emulere x64-applikationer. For mange rene desktop-klienter fungerer det overraskende godt. I praksis er emulering dog ingen „fribillet“: Så snart drivere, shell-integrationer eller in-process-komponenter (DLLs, der indlæses i processen) er involveret, afgør arkitekturen. En x64-proces kan ikke indlæse en ARM64-DLL og omvendt. Netop denne grænse afgør ofte, om noget „kører“ eller „ikke kører“.

3) Hybrid: ARM64-klient, løsgøring af x64-komponenter

En overgangsvej er at trække kritiske x64-komponenter ud af processen: f.eks. som en ekstern service, som et REST-backend (REST er et HTTP-baseret grænseflademodel) eller som et separat hjælpeprogram. Det er mindre elegant end „alt native“, men ofte den økonomisk mest fornuftige rute til at sikre drift og modernisere afhængigheder gradvist.

Windows 11 ARM64 med Delphi i virksomheder: De typiske afhængigheder, der afgør succes

I projekter bliver det hurtigt tydeligt: Det er ikke GUI’en, der er flaskehalsen, men økosystemet. En struktureret afhængighedsanalyse sparer her uger med trial-and-error.

Native DLLs og SDKer: Den usynlige risiko

Mange Delphi-applikationer binder tredjeparts-DLLs ind: PDF-generering, stregkode/QR, billedbehandling, kryptering, proprietære kommunikationsbiblioteker. Under ARM64 gælder det klart: En DLL skal passe til procesarkitekturen. Emulering hjælper kun, hvis hele processen forbliver x64. Så snart man vil køre native, skal disse biblioteker foreligge som ARM64 eller udskiftes.

Praktisk tip til IT: Få den softwareansvarlige til at levere en liste over, hvilke DLL’er der ligger i installationsmappen, og hvilke der indlæses via systemstier. Det er grundlaget for at vurdere leverandørunderstøttelse og alternativer.

COM, Office-automation og shell-udvidelser

COM bruges ofte i virksomhedsmiljøet uden at blive kaldt det: Outlook-integration, Excel-eksport via Automation, DMS-klienter, preview-handlere i Explorer, kontekstmenu-udvidelser. Problemet under ARM64 er mindre COM i sig selv end bitness-koblingen: In-process-COM-servere (DLL-baserede COM-komponenter) skal have samme arkitektur. Out-of-process-COM (EXE-baserede servere) er mere fleksibel, fordi den kan køre i en separat proces.

Hvis din Delphi-applikation f.eks. bruger en gammel 32‑bit- eller 64‑bit-COM-DLL, er det ved native ARM64-udførelse et blockeringspunkt. Emuleret som x64 kan det fungere – så længe alle COM-afhængigheder også er x64, og ingen ARM64-only-delsystemer trænger ind.

Udskrivning, PDF og driverlandskabet

Udskriftsproblemer er en klassiker ved platformskift. Under Windows 11 ARM64 er det afgørende, om printerproducenten stiller ARM64-drivere til rådighed, eller om Universal Print/IPP-klasse-drivere (IPP er et standardiseret udskriftsprotokol) kan bruges. Også PDF-printere, stabeludskrivning, etiketudskrivning og specialenheder (f.eks. termoprintere) kan afhænge af drivere, der kun findes til x64.

For IT-ledelse og administration er den vigtige konsekvens: ARM64-udrulninger skal koordineres med udskriftsstrategien. „Programmet printer ikke“ er ofte „driveren findes ikke“ eller „udskrifts-pipelinen er anderledes“.

Dataadgang: FireDAC, ODBC/OLE DB og databaseklienter

På data­laget betaler det sig med en klar adskillelse mellem protokol og klientbibliotek. BDE-Ablosung mit nativer Anbindung kan afhængigt af databasen arbejde med native klientbiblioteker eller med drivere. Hvis der f.eks. kræves en Oracle‑client, en ældre PostgreSQL‑client eller en specifik ODBC‑driver, skal der findes en version til ARM64 – eller I vælger en arkitektur, der kapsler dataadgangen serverside (f.eks. via REST-services eller en Windows-/Windows- und Linux-Services).

For stabil drift er det en central løftestang: Jo mindre desktop‑klienten er direkte bundet til database‑drivere og lokale database‑„stacks“, desto lettere bliver overgangen til ARM64. Det gælder også med hensyn til sikkerhed: databaseadgangsoplysninger, certifikater og netværksregler kan administreres mere konsistent på serversiden.

Krypto, smartcards, signaturer, VPN, EDR

Mange forretningsprocesser afhænger i dag af kryptografiske komponenter: S/MIME, klientcertifikater, smartcard‑middleware, signaturkort, TLS‑inspektion i proxies. Derudover kommer endpoint‑sikkerhedsløsninger (EDR står for Endpoint Detection and Response) og VPN‑klienter. Disse komponenter skal være ARM64‑kompatible, ellers opstår der et „enheden findes, men må ikke på netværket“‑problem.

For Delphi-applikationen betyder det: Hvis I f.eks. bruger certifikater fra Windows-certifikatlageret eller håndterer TLS via systemkomponenter, er det som regel mindre kritisk, end når en specifik tredjeparts‑KryptodLL ligger i processen.

Beslutningsmatrix: Emulering eller native ARM64‑portering?

Virksomheder har brug for en beslutning, der afspejler support‑ og livscyklusrealiteten. Et simpelt ja/nej‑spørgsmål („Porterer vi?“) er sjældent nyttigt. Bedre er en matrix, der vægter afhængigheder og risici:

• Ren klient med standard-Windows-API’er (fil, netværk, print via standarddrivere): Emulering kan være tilstrækkelig på kort sigt; native ARM64 er renere på mellemlang sigt.
• Klient med mange native tredjeparts‑DLL’er (PDF, OCR, hardware): først tjek tilgængelighed, så beslutning. Ofte er en hybridvej fornuftig.
• Klient med COM‑DLL’er / shell‑udvidelser: forvent arkitekturkonflikter; undersøg out‑of‑process‑afkobling.
• Klient med direkte DB‑driver‑zoo: enten konsolidér drivere eller flyt dataadgang til services.
• Høj regulering / signatur / smartcard: verificér tidligt ARM64‑kompatibiliteten i sikkerheds‑ og middleware‑kæden.

Vigtigt: Emulering er ikke „andenrangs“, men det er en driftsrisiko, hvis I på lang sigt planlægger ARM64‑enheder i flåden. Senest ved større opdateringer, driverudskiftninger eller skift af sikkerhedsagent ønsker I ikke at sidde fast i en kæde af specialtilfælde.

En pålidelig migrationsvej: Fra i dag til ARM64 uden Big Bang

For IT og projektansvarlige er en vej god, når den kan rulles ud i bølger, har klare acceptkriterier og ikke overbelaster supporten. I Delphi‑landskaber har en fremgangsmåde i fem trin vist sig effektiv.

Trin 1: Statusopgørelse med „driftsbriller“

Registrer ikke kun moduler, men først og fremmest driftsrelevante punkter:

• Hvilke enhedsklasser: Notebooks, Rugged Devices, terminaler?
• Hvilken perifer hardware: printere, scannere, kortlæsere, labelere?
• Hvilke integrationer: Office, DMS, ERP, lokale tjenester, browser‑komponenter?
• Hvilken installationsform: MSI, Setup‑EXE, ClickOnce, manuel placering?

Dette overblik gør hurtigt synligt, om „kun en klient“ i virkeligheden betyder fem systemafhængigheder.

Trin 2: Kompatibilitetscheck med repræsentativ ARM64-pilot

Piloten bør ikke være „den pæneste enhed“, men en typisk kandidat fra målflåden. Test bevidst de kritiske stier: udskrivning i alle varianter, eksport/import, signatur, offline/online, opdateringer, skift mellem klienter, proxy-/VPN-scenarier. Dokumenter afvigelser som driftsbegivenheder, ikke som udvikler-fejl. Så forbliver prioriteringen ren.

Trin 3: Reducer afhængigheder – først dem med høj support-påvirkning

Typiske tiltag, der i dagligdagen giver stor effekt:

• Standardiser PDF-/udskriftsvejen: væk fra proprietære printer-DLLs, hen imod stabile, testede pipelines.
• Frakobl Office-integration: i stedet for In-Process-add-ins bør eksportformater og serverside dokumentgenerering foretrækkes.
• Konsolider databaseadgang: en defineret drivervej i stedet for „ODBC afhængig af arbejdsplads“.
• Kapsl hardwaretilslutning: om muligt via eksterne processer/services, som kan opdateres separat.

Trin 4: Moderniser deployment og opdaterbarhed

ARM64 er en god anledning til at rydde op i installation og opdateringer. For virksomheder tæller her ikke features, men mulighed for rollback, reproducerbarhed og politikoverholdelse. Undersøg:

• Paketering: MSI vs. MSIX (MSIX er Microsofts moderne app-pakkeformat med ren installation/deinstallation og signatur).
• Signering: Code Signing (digital signatur af EXE/DLL) reducerer SmartScreen- og EDR-friktion og er relevant for kontrollerede rollouts.
• Konfigurationsstyring: adskillelse af programfiler og konfiguration, klare stier, ingen „skjulte“ Registry-afhængigheder.
• Opdateringskanaler: pilot, Ring 1, Ring 2 – med telemetri/logning på applikations- og driftsniveau.

Trin 5: Native ARM64 der, hvor det virkelig betaler sig

Native ARM64-builds giver mening, når I (a) har styr på afhængighederne og (b) planlægger langsigtet videreudvikling af applikationen. Typisk er det relevant for kerneklienter, som mange brugere bruger dagligt, og som I alligevel moderniserer. For sjældent anvendte værktøjer kan x64-emulation være en acceptabel overgang, så længe support og security spiller med.

Arkitekturimpulser: ARM64 som anledning til at styrke grænseflader og services

Mange Delphi-landskaber er historisk vokset som „tyk klient“. Det fungerer, men det binder drift og opdateringer stærkere til individuelle arbejdspladskonfigurationer. ARM64 gør synligt, hvor denne kobling bliver dyr. Et pragmatisk moderniseringstrin er derfor ofte ikke „UI-nyt“, men grænseflader fornyes.

Mere stabilitet gennem serverside-ansvar

Når kritisk logik, dataadgang eller dokumentprocesser flyttes til en central tjeneste (Windows- und Linux-Services eller Windows- und Linux-Services, altså en baggrundstjeneste uden interaktivt UI), opnår I:

• ensartede driver- og biblioteksversioner,
• bedre kontrollerbar sikkerhed (certifikater, secrets, netværk),
• lavere kompleksitet på klienten (ARM64, x64, fremover også andre platforme),
• tydeligere overvågnings- og logningspunkter.

For IT-beslutningstagere er det en reel driftsfordel: problemer kan reproduceres hurtigere på serversiden i stedet for at hænge på „en særlig bærbar“.

REST-API som afkoblingslag

En REST-API er ikke automatisk „moderne“, men den er en robust afkobling mellem klienter og backend. Den definerer klart, hvilke data og handlinger der er tilladt, og kan sikres ordentligt (f.eks. via Tokens, certifikater eller SAML 2.0 som identitetsstandard i virksomhedsmiljøer). For ARM64 betyder det: klienten behøver mindre „verdensviden“ om databaser, drivere og netværksdetaljer.

Selv hvis De ikke omlægger alt med det samme: Selv en lille, velafgrænset API-komponent (f.eks. dokumentgenerering, licenskontrol, stamdata-afstemning) kan fjerne afhængigheder fra klienten og dermed reducere ARM64-risici.

Test og kvalitet: Hvad De bør teste anderledes under ARM64

Mange teams tester desktop-software primært funktionelt. På ARM64 bør De i højere grad teste driftsmæssigt, fordi fejltyperne er anderledes: ikke „forkert beregning“, men „komponent indlæses ikke“, „driver mangler“, „opdatering fejler“, „Office-integration bryder sammen“.

Tjekliste til ARM64-nær godkendelse

• Installation/Afinstallation: ren, uden rester, uden administrator-workarounds.
• Opdateringssti: opgradering over flere versioner, rollback-scenarie, signaturkontrol.
• Logning: centrale logfiler, klare fejlkoder ved DLL-indlæsningsproblemer, eftersporelige udskriftsstier.
• Performance: opstartstid, dataoperationer, store lister/rapporter – mål separat under emulation og nativt.
• Periferi: printerprofiler, specialudskrivning, scanner-arbejdsgange, smartcard-funktioner.
• Sikkerhed: EDR/AV-interaktion, proxy/TLS, certifikatlager, drift efter mindst-privilegium-princippet.

Dokumentation er vigtig: Hvis et problem opstår på grund af manglende ARM64-drivere, er det ikke en „bugfix i Delphi“, men en indkøbs- eller standardiseringsbeslutning.

Drift og support: Hvordan De integrerer ARM64 i hverdagen

I hverdagen tæller det, hvor hurtigt supportsager løses. For ARM64 kan det betale sig at øge Deres supportkapacitet proaktivt:

Standardiserede enhedsprofiler og klare godkendelser

Definer understøttede ARM64-modeller eller i det mindste minimumsprofiler (driverstrategi, udskriftsstrategi, Security-Agent-versioner). Et „kører på ARM64“ uden denne ramme fører til uensartede miljøer og dermed svært reproducerbare forstyrrelser.

Diagnosemuligheder i applikationen

Selv uden udviklerfokus er det rimeligt at stille et klart krav til softwaren: En systeminfo-side, der viser arkitektur (x64 emuleret vs. ARM64 nativt), vigtige stier, versioner af kernekomponenter og udskriftskonfiguration, reducerer supporttider væsentligt. Det er ikke et „nice to have“, men driftshygiejne.

Licensering og dongles

Hvis hardware-dongles eller ældre licensdrivere er involveret, bliver ARM64 hurtigt kritisk. I mange miljøer er det fornuftigt at skifte licensering til netværksbaserede eller serverside-mekanismer. Derved reduceres afhængigheden af drivere på endpunkterne, og flåden bliver mere udskiftelig.

Hvad betyder det for Deres Delphi-strategi?

Delphi er i virksomhedskontekst ofte en stabil byggesten for desktop-klienter og tjenester. Windows 11 ARM64 er ikke et argument „mod Delphi“, men et argument for en renere indkapsling af afhængigheder og for en driftsorienteret modernisering: færre lokale specialdrivere, færre in-process-komponenter, klarere grænseflader, bedre udrulning.

Hvis I allerede i dag er på en moderniseringsvej (f.eks. BDE-afvikling, 64-bit-overgang, stærkere REST-integration, konsolideret dataadgang med FireDAC), så er ARM64 ofte „kun“ et yderligere målepunkt, der skærper prioriteterne. Hvis jeres applikation derimod i høj grad afhænger af gamle drivere, proprietære DLL’er og arbejdsplads-specifikke konfigurationer, er ARM64 en relevant anledning til at gøre disse risici gennemsigtige og reducere dem planmæssigt.

Konklusion: ARM64 er mindre et porteringsprojekt end et arkitektur- og driftsprojekt

For virksomheder er Windows 11 ARM64 først og fremmest et platformspørgsmål i indkøb, security og support. For Delphi-baseret business-software afgøres succes ikke af en compilerindstilling, men af kæden af drivere, DLL’er, COM-integrationer, dataadgang og opdateringsprocesser. En holdbar vej er: først gøre afhængigheder og driftsstier synlige, derefter teste med pilotudstyr, så målrettet afkoble og professionalisere udrulning – og levere native ARM64-builds dér, hvor de på lang sigt giver nytte og stabilitet.

Hvis I ønsker at indføre Windows 11 ARM64 i jeres flåde og samtidig sikre Delphi-applikationer, periferi og grænseflader på en planbar måde, så tal med os om en struktureret kortlægning og en realistisk migrationsvej:

I det faglige miljø spiller også Delphi ARM64 Windows og X64-emulering Windows 11 en vigtig rolle, når integrationer, dataflows og videreudvikling skal fungere sammen pålideligt.

Drøft projekt eller moderniseringsprojekt med Net-Base.