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 kun „eksotiske“. De kommer via standardiserede notebook-flåder, længere batterilevetid, nye sikkerhedsfunktioner i hardwaren og en strategisk diversificering af leverandørkæden. Senest når fagområder anskaffer nye enheder eller OEMs bestemte modeller kun tilbyder som Windows on ARM, står IT-ansvarlige over for det praktiske spørgsmål: Hvordan opfører vores Delphi-baserede business-software sig under Windows 11 ARM64 – og hvordan sikrer vi drift, support og videreudvikling?

Kernen er: Windows 11 ARM64 med Delphi i virksomheder er mindre et rent udviklingsspørgsmål end et spørgsmål om afhængigheder, deploymentsstrategier, drivere, grænseflader og reel adfærd i felten. I praksis er der tre veje: fortsat drift via emulation, native ARM64-builds eller en overgangsmodel, der kontrolleret reducerer risici. Dette indlæg placerer de typiske faldgruber og viser en robust vej, der fungerer i IT-planlægning, rollout og drift – uden „Alles neu“-refleks.

Hvorfor Windows 11 ARM64 nu bliver relevant

Windows on ARM er ikke ny, men rammebetingelserne har ændret sig: Enhederne er tilgængelige i business-miljøet, Windows 11 leverer en markant mere moden x64-emulation, og softwareleverandører leverer oftere ARM64-variationer. 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 selve CPU’en, der er problemet, og mere periferi- og integrationsrealiteten: print, signaturkort, scannere, Office-add-ins, COM-komponenter (COM er Microsofts komponentmodel til integration af applikationer og biblioteker), shell-udvidelser, VPN-clients eller security-agenter. Hvis noget af dette ikke er ARM64-kompatibelt, opstår der supportarbejde – og ofte bliver så „applikationen“ gjort ansvarlig.

Indplacering: 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-Ablösung mit nativer Anbindung, Delphi’s dataadgangslag) og en blanding af lokale og fjernintegrationer. Under Windows 11 ARM64 opstår der tre kørselstyper:

1) Native ARM64-kørsel

Applikationen og alle native biblioteker (DLLs) foreligger som ARM64. Det er på lang sigt den mest holdbare løsning, fordi den gør performance og stabilitet planbar og undgår emulationsrandbetingelser. Den er dog kun realistisk, hvis alle native afhængigheder følger med: databasedrivere, print/preview, PDF-motor, kryptobiblioteker, OCR/Scan-SDKs, hardware-dongle-drivere osv.

2) x64-emulation under Windows 11 ARM64

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

3) Hybrid: ARM64-klient, frakoble 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 en HTTP-baseret grænseflademodel) eller som et separat hjælpeprogram. Det er mindre elegant end „alt native“, men ofte den mest økonomiske vej til at sikre drift og modernisere afhængigheder trinvis.

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

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

Native DLLs og SDKs: Den usynlige risiko

Mange Delphi-applikationer benytter tredjeparts-DLL’er: PDF-generering, stregkode/QR, billedbehandling, kryptering, proprietære kommunikationsbiblioteker. Under ARM64 gælder det strengt: En DLL skal passe til processens arkitektur. Emulering hjælper kun, hvis hele processen forbliver x64. Når man ønsker at køre nativt, skal disse biblioteker være tilgængelige som ARM64 eller udskiftes.

Praktisk tip til IT: Bed softwareansvarlige om 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-automatisering og shell-udvidelser

COM bruges ofte i virksomhedsdrift uden at blive navngivet sådan: Outlook-integration, Excel-eksport via Automation, DMS-klienter, preview-handlere i Explorer, kontekstmenuudvidelser. 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 fleksibelt, fordi det 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 blocker. Emuleret som x64 kan det fungere – så længe alle COM-afhængigheder også er x64, og der ikke blander sig ARM64-only-komponenter.

Udskrivning, PDF og driverlandskabet

Udskrivningsproblemer er en klassiker ved platformskifte. Under Windows 11 ARM64 er det afgørende, om printerproducenten leverer ARM64-drivere, eller om Universal Print/IPP-klasse-drivere (IPP er en standardiseret udskriftsprotokol) kan anvendes. Også PDF-printere, batchudskrift, etiketudskrift og specialenheder (f.eks. termiske printere) 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 udskriver ikke“ er ofte „driveren findes ikke“ eller „udskrifts-pipelinen er anderledes“.

Dataadgang: FireDAC, ODBC/OLE DB og databaseklienter

På data-niveau er en klar adskillelse mellem protokol og clientbibliotek fordelagtig. BDE-Ablosung mit nativer Anbindung kan afhængigt af database arbejde med native Clientlibs eller med drivere. Hvis f.eks. en Oracle-Client, en ældre PostgreSQL-Client eller en specifik ODBC-Treiber kræves, skal der findes en ARM64-version – eller I vælger en arkitektur, der kapsler dataadgangen på serversiden (f.eks. via REST-tjenester eller en Windows-/Windows- og Linux-tjenester).

Det er et centralt greb for stabil drift: Jo mindre desktop-klienten er direkte bundet til databasedrivere og lokale database-„Stacks“, desto lettere bliver ARM64. Det gælder også sikkerhedsmæssigt: Databaseadgangsdata, certifikater og netværksregler kan administreres mere konsekvent på serversiden.

Krypto, Smartcards, Signaturen, VPN, EDR

Mange forretningsprocesser afhænger i dag af kryptografiske komponenter: S/MIME, Client-Zertifikate, Smartcard-Middleware, Signaturkarten, TLS-Inspection i proxies. Hertil kommer endpoint-sikkerhedsløsninger (EDR står for Endpoint Detection and Response) og VPN-Clients. Disse komponenter skal være ARM64-kompatible, ellers opstår et „enheden er der, 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.

Entscheidungsmatrix: Emulation oder native ARM64-Portierung?

Virksomheder har brug for en beslutning, der afspejler support- og livscyklussituationen. Et enkelt Ja/Nein-spørgsmål („Portieren wir?“) er sjældent nyttigt. Bedre er en matrix, der vægter afhængigheder og risici:

• Reiner Client mit Standard-Windows-APIs (Datei, Netzwerk, Druck über Standardtreiber): Emulation kann kurzfristig reichen; native ARM64 ist mittelfristig sauber.
• Client mit vielen nativen Drittanbieter-DLLs (PDF, OCR, Hardware): erst Verfügbarkeit prüfen, dann entscheiden. Häufig Hybridpfad sinnvoll.
• Client mit COM-DLLs / Shell-Erweiterungen: Architekturkonflikte erwarten; Out-of-Process-Entkopplung prüfen.
• Client mit direktem DB-Treiber-Zoo: entweder Treiber konsolidieren oder Datenzugriff in Services verlagern.
• Hohe Regulierung/Signatur/Smartcard: ARM64-Fähigkeit der Security- und Middleware-Kette früh verifizieren.

Vigtigt: Emulation er ikke en „zweite Klasse“, men den er et driftsrisiko, hvis I på længere sigt ser ARM64-enheder i flåden. Senest ved større opdateringer, Treiberwechseln eller skift af Security-Agent vil I ikke sidde fast i en kæde af Sonderfällen.

Ein belastbarer Migrationspfad: Von heute nach ARM64 ohne Big Bang

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

Schritt 1: Bestandsaufnahme mit „Betriebsbrille“

Kortlæg ikke kun moduler, men især driftsrelevante punkter:

• Hvilke enhedsklasser: Notebooks, Rugged Devices, Terminals?
• Hvilken Peripherie: Drucker, Scanner, Kartenleser, Labeler?
• Hvilke Integrationen: Office, DMS, ERP, lokale Dienste, Browser-Komponenten?
• Hvilche Installationsform: MSI, Setup-EXE, ClickOnce, manuelle Ablage?
• Hvilke rettigheder: administrator nødvendigt, lokale tjenester, firewall-regler?

Dette overblik viser hurtigt, 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 flotteste enhed“, men en typisk kandidat fra målflåden. Test bevidst de kritiske baner: udskrivning i alle varianter, eksport/import, signatur, offline/online, opdateringer, skift af klient/tenant, proxy/VPN-scenarier. Dokumentér afvigelser som driftshændelser, ikke som udvikler-fejl. Så forbliver prioriteringen ren.

Trin 3: Reducer afhængigheder – start med dem, hvor supportindsatsen har størst effekt

Typiske tiltag, der giver stor effekt i hverdagen:

• Standardiser PDF-/udskrivningssti: væk fra proprietære printer-DLLs, mod stabile, testede pipelines.
• Frakobl Office-integration: i stedet for In-Process-Add-ins foretrækkes at undersøge eksportformater og serverbaseret dokumentgenerering.
• Konsolider DB-adgang: en defineret driversti i stedet for „ODBC je nach Arbeitsplatz“.
• Kapsl hardwaretilslutning: hvor 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 handler det ikke om features, men om Rollback-evne, reproducerbarhed og policy-overholdelse. Undersøg:

• Paketering: MSI vs. MSIX (MSIX er Microsofts moderne app-pakkeformat med ren installation/deinstallation og signering).
• Signering: Code Signing (digital signatur af EXE/DLL) reducerer SmartScreen- og EDR-friktion og er relevant for kontrollerede udrulninger.
• 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 dér, hvor det virkelig giver mening

Native ARM64-builds er relevante, når I (a) har styr på afhængighederne og (b) videreudvikler applikationen på lang sigt. Typisk er det relevant for kerneklienter, som mange brugere anvender dagligt og som I alligevel moderniserer. For sjældent brugte værktøjer kan x64-emulering være en acceptabel overgang, så længe support og sikkerheden spiller med.

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

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

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 drivere og biblioteksversioner,
• bedre kontrollerbar sikkerhed (certifikater, Secrets, netværk),
• lavere kompleksitet på klienten (ARM64, x64, fremtidigt også andre platforme),
• klarere overvågnings- og logpunkter.

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

REST-API som afkoblingslag

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

Selv hvis I ikke omlægger alt med det samme: Et lille, velafgrænset API-modul (f.eks. dokumentgenerering, licenskontrol, stamdataafstemning) kan fjerne afhængigheder fra klienten og dermed reducere ARM64-risici.

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

Mange teams tester skrivebordssoftware primært funktionelt. Under ARM64 bør I teste mere driftorienteret, fordi fejlbillederne er anderledes: ikke „forkert beregning“, men „komponent indlæses ikke“, „driver mangler“, „opdatering fejler“, „Office-integration går ned“.

Tjekliste til ARM64-nær accept

• Installation/afinstallation: rent, uden rester, uden admin-workarounds.
• Opdateringssti: opgradering over flere versioner, rollback-scenarie, signaturkontrol.
• Logning: centrale logs, klare fejlkoder ved DLL-indlæsningsproblemer, eftersporbare udskriftsstier.
• Performance: opstartstid, dataoperationer, store lister/rapporter – mål separat under emulering og native kørsel.
• Periferi: printerprofiler, specialudskrift, scanner-workflows, smartcard-funktioner.
• Sikkerhed: EDR/AV-interaktion, proxy/TLS, certifikatlager, least-privilege-drift.

Vigtig er dokumentationen: Hvis et problem skyldes manglende ARM64-drivere, er det ikke en „bugfix in Delphi“, men en anskaffelses- eller standardiseringsbeslutning.

Drift og support: Hvordan I integrerer ARM64 i hverdagen

I hverdagen tæller, hvor hurtigt supportsager løses. For ARM64 er det værd at øge supportmulighederne proaktivt:

Standardiserede enhedsprofiler og klare godkendelser

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

Diagnosefunktionalitet i applikationen

Selv uden udviklerfokus giver en klar forventning til softwaren mening: en systeminfo-side, der viser arkitektur (x64 emuleret vs. ARM64 native), vigtige stier, versioner af kernekomponenter og udskriftskonfiguration, reducerer supporttider markant. Det er ikke „nice to have“, men driftshygiejne.

Licensering og Dongles

Hvis hardware-dongles eller ældre licensdrivere er i spil, bliver ARM64 hurtigt kritisk. I mange miljøer giver det mening at skifte licensering til netværksbaserede eller serverside-mekanismer. Dermed falder afhængigheden af drivere på endepunkter, og flåden bliver mere udskiftelig.

Was bedeutet das für Ihre Delphi-Strategie?

Delphi er i virksomhedskontekst ofte en stabil byggesten for desktop-klienter og services. 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 i dag allerede er på en moderniseringssti (f.eks. BDE-Ablösung, overgang til 64‑bit, tættere REST-integration, konsolideret dataadgang med FireDAC), så er ARM64 ofte „kun“ et ekstra målepunkt, der skærper prioriteterne. Hvis jeres applikation derimod er stærkt afhængig af gamle drivere, proprietære DLL’er og arbejdsplads-specifikke konfigurationer, er ARM64 en relevant anledning til at gøre disse risici synlige 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 inden for indkøb, sikkerhed og support. For Delphi-baseret forretningssoftware afgøres succes ikke af en kompilatorindstilling, men af kæden af drivere, DLL’er, COM-integrationer, dataadgang og opdateringsprocesser. En robust vej er: først gøre afhængigheder og driftsstier synlige, derefter teste med pilotenheder, efterfølgende målrettet afkoble og professionalisere udrulningen – og levere native ARM64-Builds dér, hvor de på lang sigt skaber værdi og stabilitet.

Hvis I ønsker at indføre Windows 11 ARM64 i jeres flåde og samtidig planmæssigt sikre Delphi-applikationer, periferiudstyr og grænseflader, 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, dataflow og videreudvikling skal spille rent sammen.

Drøft projekt eller moderniseringsprojekt med Net-Base.