Windows 11 ARM64 med Delphi i virksomheter: alternativer, risikoer og en robust migrasjonsvei

Windows-enheter med ARM64-CPU (ARM64 er en 64‑bits prosessorarkitektur, kjent fra mobile SoC-er og i økende grad også fra forretnings‑notebooks) er i mange virksomheter ikke lenger bare «eksotiske». De kommer via standardiserte bærbarflåter, lengre batteritid, nye sikkerhetsfunksjoner i maskinvaren og en strategisk diversifisering av leverandørkjeden. Snarest når fagavdelinger anskaffer nye enheter eller OEMs tilbyr enkelte modeller kun som Windows on ARM, stiller IT‑ansvarlige seg det praktiske spørsmålet: Hvordan oppfører vår Delphi-baserte forretningsprogramvare seg under Windows 11 ARM64 – og hvordan sikrer vi drift, støtte og videreutvikling?

Kjernen er: Windows 11 ARM64 med Delphi i virksomheter er mindre et rent utviklingsspørsmål enn et spørsmål om avhengigheter, deploy‑strategier, drivere, grensesnitt og reell atferd ute i felt. I praksis finnes det tre veier: videre drift via emulering, native ARM64‑bygg eller en overgangsmodell som kontrollerer og reduserer risiko. Dette innlegget klassifiserer de typiske fallgruvene og viser en robust vei som fungerer i IT‑planlegging, utrulling og drift – uten «alt må skiftes»-refleks.

Hvorfor Windows 11 ARM64 blir relevant nå

Windows on ARM er ikke nytt, men rammebetingelsene har endret seg: Enhetene er tilgjengelige i forretningsmiljøet, Windows 11 bringer en klart mer moden x64‑emulering, og programvareleverandører leverer stadig oftere ARM64‑varianter. For virksomheter betyr det: ARM64 dukker ikke opp som et enkelt pilotprosjekt, men som en plattform som inngår i anskaffelses‑ og livssyklusplanlegging.

For prosessnære programvareløsninger er det mindre CPUen i seg selv som er problemet, og mer periferi‑ og integrasjonsrealiteten: skrivere, signaturkort, skannere, Office‑tillegg, COM‑komponenter (COM er Microsofts komponentmodell for integrasjon av applikasjoner og biblioteker), shell‑utvidelser, VPN‑klienter eller sikkerhetsagenter. Dersom noe av dette ikke er ARM64‑kompatibelt, oppstår det supportarbeid – og ofte blir «applikasjonen» holdt ansvarlig.

Vurdering: Hva betyr ARM64 teknisk for Delphi-applikasjoner?

Delphi-applikasjoner i virksomhetsmiljøer er ofte klassiske Windows-desktopklienter (ofte VCL, altså Visual Component Library for Windows-GUIer) med databaseadgang (f.eks. via BDE-avløsning med native tilkoblinger, Delphis dataadgangslag) og en blanding av lokale og fjerndes integrasjoner. Under Windows 11 ARM64 oppstår det tre kjøremoduser:

1) Native ARM64‑utførelse

Applikasjonen og alle native biblioteker (DLLer) er tilgjengelige som ARM64. På lang sikt er dette det reneste alternativet, fordi det gjør ytelse og stabilitet forutsigbar og unngår emuleringsbetingelser. Det er imidlertid bare realistisk hvis alle native avhengigheter følger med: databasetreivere, utskrift/forhåndsvisning, PDF‑motor, kryptobiblioteker, OCR/scan‑SDKer, maskinvaru‑dongledrivere osv.

2) x64‑emulering under Windows 11 ARM64

Windows 11 kan emulere x64-applikasjoner. For mange rene skrivebordsklienter fungerer det overraskende godt. I praksis er emulering likevel ingen «fri billett»: Så snart drivere, skallintegrasjoner eller in-prosess-komponenter (DLL-er som lastes inn i prosessen) er involvert, spiller arkitekturen en rolle. En x64-prosess kan ikke laste en ARM64-DLL og omvendt. Nettopp denne grensen avgjør ofte om det «fungerer» eller «ikke fungerer».

3) Hybrid: ARM64-Client, x64-Komponenten entkoppeln

En overgangsvei er å trekke kritiske x64-komponenter ut av prosessen: f.eks. som en ekstern tjeneste, som et REST-backend (REST er et HTTP-basert grensesnittmodell) eller som et separat hjelpeprogram. Det er mindre elegant enn «alt native», men ofte den mest økonomiske ruten for å sikre drift og modernisere avhengigheter trinnvis.

Windows 11 ARM64 mit Delphi in Unternehmen: Die typischen Abhängigkeiten, die über Erfolg entscheiden

I prosjekter blir det raskt tydelig: Ikke GUI-en er flaskehalsen, men økosystemet. En strukturert avhengighetsanalyse sparer her uker med prøving og feiling.

Native DLLs und SDKs: Das unsichtbare Risiko

Mange Delphi-applikasjoner binder inn tredjeparts-DLL-er: PDF-generering, strekkode/QR, bildebehandling, kryptering, proprietære kommunikasjonsbiblioteker. Under ARM64 gjelder det klart: En DLL må passe til prosessarkitekturen. Emulering hjelper bare hvis hele prosessen forblir x64. Når man ønsker å kjøre nativt, må disse bibliotekene være tilgjengelige som ARM64 eller erstattes.

Praktisk tips for IT: Be programvareansvarlig om en liste over hvilke DLL-er som ligger i installasjonskatalogen og hvilke som lastes via systembaner. Dette er grunnlaget for å vurdere leverandørstøtte og alternativer.

COM, Office-Automation und Shell-Erweiterungen

COM brukes ofte i daglig drift uten at det alltid navngis slik: Outlook-integrasjon, Excel-eksport via automatisering, DMS-klienter, forhåndsvisningshandlere i Explorer, utvidelser i kontekstmenyer. Problemet under ARM64 er mindre COM i seg selv, og mer bitness-koplingen: In-prosess-COM-servere (DLL-baserte COM-komponenter) må ha samme arkitektur. Out-of-process-COM (EXE-baserte servere) er mer fleksibelt fordi det kan kjøre i en separat prosess.

Hvis din Delphi-applikasjon for eksempel bruker en gammel 32-bit eller 64-bit COM-DLL, er det ved native ARM64-kjøring en blocker. Emulert som x64 kan det fungere – så lenge alle COM-avhengigheter også er x64 og ingen komponenter som kun finnes for ARM64 blander seg inn.

Druck, PDF und Treiberlandschaft

Skriverproblemer er en klassiker ved plattformbytter. Under Windows 11 ARM64 er det avgjørende om skriverprodusenten tilbyr ARM64-drivere eller om Universal Print/IPP-klassen-drivere (IPP er et standardisert skriverprotokoll) kan benyttes. Også PDF-skrivere, batchutskrift, etikettutskrift og spesialenheter (f.eks. termisk skriver) kan være avhengige av drivere som kun finnes for x64.

For IT-ledelse og administrasjon er den viktige konsekvensen: ARM64-utrullinger må koordineres med skriverstrategien. «Applikasjonen skriver ikke» er ofte «driveren eksisterer ikke» eller «utskriftsflyten er annerledes».

Datatilgang: FireDAC, ODBC/OLE DB und Datenbank-Clients

På data­nivå er det verdt å ha en klar separasjon mellom protokoll og klientbibliotek. BDE-Ablosung mit nativer Anbindung kan, avhengig av database, bruke native klientbiblioteker eller drivere. Hvis for eksempel en Oracle-klient, en eldre PostgreSQL-klient eller en spesifikk ODBC-driver kreves, må disse finnes for ARM64 – eller dere satser på en arkitektur som kapsler datatilgangen på serversiden (f.eks. via REST-services eller en Windows-/ Windows- og Linux-services).

For stabil drift er dette et sentralt grep: Jo mindre desktop-klienten er direkte bundet til database­drivere og lokale database-«stacks», desto lettere blir overgangen til ARM64. Det gjelder også med tanke på sikkerhet: database­tilgangsdata, sertifikater og nettverksregler kan administreres mer konsistent på serversiden.

Krypto, smartkort, signaturer, VPN, EDR

Mange forretningsprosesser avhenger i dag av kryptografiske komponenter: S/MIME, klientsertifikater, smartkort-mellomvare, signaturkort, TLS-inspeksjon i proxyer. I tillegg kommer endpoint-sikkerhetsløsninger (EDR er Endpoint Detection and Response) og VPN-klienter. Disse komponentene må være ARM64-kompatible, ellers oppstår et «enheten er der, men får ikke tilgang til nettet»-problem.

For Delphi-applikasjonen betyr det: Hvis dere for eksempel bruker sertifikater fra Windows-sertifikatlageret eller håndterer TLS via systemkomponenter, er det som regel mindre kritisk enn når en spesifikk tredjeparts-KryptodLL kjører i prosessen.

Beslutningsmatrise: Emulering eller native ARM64-portering?

Bedrifter trenger en beslutning som reflekterer support- og livssyklusrealiteten. Et enkelt ja/nei-spørsmål («Porterer vi?») er sjelden nyttig. Bedre er en matrise som veier avhengigheter og risiko:

• Ren klient med standard-Windows-APIer (fil, nettverk, utskrift via standarddrivere): Emulering kan være tilstrekkelig på kort sikt; native ARM64 er ryddigere på mellomlang sikt.
• Klient med mange native tredjeparts-DLLer (PDF, OCR, maskinvare): kontroller tilgjengelighet først, deretter ta en beslutning. Ofte gir en hybridtilnærming mening.
• Klient med COM-DLLer / shell-utvidelser: forvent arkitekturkonflikter; vurder avkobling utenfor prosessen.
• Klient med direkte DB-driver-zoo: enten konsolider drivere eller flytt datatilgang til tjenester.
• Høy regulering/signatur/smartkort: verifiser tidlig ARM64-kompatibiliteten i sikkerhets- og mellomvarekjeden.

Viktig: Emulering er ikke «annenrangs», men den er en driftsrisiko hvis dere langsiktig planlegger ARM64-enheter i flåten. Senest ved større oppdateringer, driverbytter eller bytte av sikkerhetsagenter ønsker dere ikke å sitte fast i en kjede av særtilfeller.

En pålitelig migrasjonsvei: Fra i dag til ARM64 uten Big Bang

For IT og prosjektansvarlige er en vei god når den kan rulles ut i bølger, har klare akseptansekriterier og ikke overbelaster supporten. I Delphi-landskaper har en fremgangsmåte i fem trinn vist seg effektiv.

Trinn 1: Kartlegging med „Betriebsbrille”

Kartlegg ikke bare moduler, men først og fremst driftspunktene:

• Hvilke enhetsklasser: notatbøker, rugged-enheter, terminaler?
• Hvilken periferi: skrivere, skannere, kortlesere, etikettskrivere?
• Hvilke integrasjoner: Office, DMS, ERP, lokale tjenester, nettleserkomponenter?
• Hvilken installasjonsform: MSI, Setup-EXE, ClickOnce, manuell plassering?
• Hvilke rettigheter: Kreves admin, lokale tjenester, brannmurregler?

Denne oversikten gjør raskt synlig om «bare en klient» i realiteten betyr fem systemavhengigheter.

Trinn 2: Kompatibilitetsjekk med representativ ARM64-pilot

Piloten bør ikke være «den fineste enheten», men en typisk kandidat fra målflåten. Test bevisst de kritiske banene: utskrift i alle varianter, eksport/import, signering, offline/online, oppdateringer, skifting mellom klienter/tenants, proxy-/VPN-scenarier. Dokumenter avvik som driftsforhold, ikke som utviklerfeil. Slik forblir prioriteringen ren.

Trinn 3: Reduser avhengigheter – først de med høy supporteffekt

Typiske tiltak som gir mye i hverdagen:

• Standardisere PDF-/utskriftsbane: bort fra proprietære skriver-DLLer, mot stabile, testede pipeliner.
• Frakople Office-integrasjon: i stedet for in-process-tillegg vurder eksportformater og server-side dokumentgenerering.
• Konsolidere DB-tilgang: en definert driversti i stedet for «ODBC avhengig av arbeidsstasjon».
• Kapsle maskinvaretilknytning: om mulig via eksterne prosesser/tjenester som kan oppdateres separat.

Trinn 4: Moderniser deployment og oppdaterbarhet

ARM64 er en god anledning til å rydde opp i installasjon og oppdateringer. For virksomheter teller ikke funksjoner, men mulighet for rollback, reproduserbarhet og policy‑konformitet. Sjekk:

• Pakketering: MSI vs. MSIX (MSIX er Microsofts moderne app-pakkeformat med ren installasjon/avinstallasjon og signering).
• Signering: kode‑signering (digital signering av EXE/DLL) reduserer friksjon med SmartScreen og EDR og er relevant for kontrollerte utrullinger.
• Konfigurasjonsstyring: separasjon av programfiler og konfigurasjon, klare stier, ingen «skjulte» registeravhengigheter.
• Oppdateringskanaler: pilot, Ring 1, Ring 2 – med telemetri/logging på applikasjons- og driftsnivå.

Trinn 5: Native ARM64 der det virkelig lønner seg

Native ARM64‑bygger gir mening når du (a) har kontroll på avhengigheter og (b) skal videreutvikle applikasjonen på lang sikt. Typisk lønner det seg for kjerneklienter som mange brukere benytter daglig og som du uansett moderniserer. For sjeldent brukte verktøy kan x64‑emulering være et akseptabelt overgangsalternativ, så lenge support og sikkerhet støtter det.

Arkitekturimpulser: ARM64 som anledning til å styrke grensesnitt og tjenester

Mange Delphi-landskap har historisk vokst fram som «tykk klient». Det fungerer, men det binder drift og oppdateringer tettere til individuelle arbeidsstasjonskonfigurasjoner. ARM64 synliggjør hvor denne koblingen blir kostbar. Et pragmatisk moderniseringstiltak er derfor ofte ikke «ny UI», men nye grensesnitt.

Mer stabilitet gjennom serversidige ansvarsområder

Når kritisk logikk, dataadgang eller dokumentprosesser flyttes til en sentral tjeneste (Windows- og Linux-Services eller Windows- und Linux-Services, altså en bakgrunnstjeneste uten interaktivt UI), får du:

• ensartede driver- og bibliotekversjoner,
• bedre kontrollerbar sikkerhet (sertifikater, secrets, nettverk),
• lavere kompleksitet på klienten (ARM64, x64, og i fremtiden også andre plattformer),
• tydeligere overvåkings- og loggpunkt.

For IT-beslutningstakere er dette en reell driftsfordel: problemer blir raskere reproduserbare på serversiden, i stedet for å henge på «et spesielt bærbart».

REST-API som et frakoblingslag

En REST-API er ikke automatisk «moderne», men den er en robust frakobling mellom klienter og backend. Den definerer klart hvilke data og handlinger som er tillatt, og kan sikres ryddig (f.eks. via tokens, sertifikater eller SAML 2.0 som identitetsstandard i bedriftsmiljøer). For ARM64 betyr det: klienten må ikke lenger bære like omfattende kunnskap om databaser, drivere og nettverksdetaljer.

Selv om dere ikke endrer alt umiddelbart: En liten, godt avgrenset API-komponent (f.eks. dokumentgenerering, lisenskontroll, stamdata-synkronisering) kan fjerne avhengigheter fra klienten og dermed redusere ARM64-risikoen.

Test og kvalitet: Hva dere bør teste annerledes for ARM64

Mange team tester desktop-programvare primært funksjonelt. For ARM64 bør dere i sterkere grad teste driftsmessig, fordi feilmønstrene er annerledes: ikke «feil beregning», men «komponenten laster ikke», «driver mangler», «oppdatering feiler», «Office-integrasjon bryter».

Sjekkliste for ARM64-nær akseptans

• Installasjon/Avinstallasjon: ryddig, uten rester, uten admin-omgåelser.
• Oppdateringsvei: oppgradering over flere versjoner, tilbakeføringsscenario, signaturkontroll.
• Logging: sentrale logger, tydelige feilkoder ved DLL-innlastingsproblemer, ettersporbare utskriftsflyter.
• Ytelse: oppstartstid, dataoperasjoner, store lister/rapporter – mål separat under emulering og i native omgivelser.
• Periferi: skriverprofiler, spesialutskrift, skannerarbeidsflyter, smartkortfunksjoner.
• Sikkerhet: EDR/AV-interaksjon, Proxy/TLS, sertifikatlager, drift med minste privilegier.

Viktig er dokumentasjonen: Hvis et problem oppstår på grunn av manglende ARM64-drivere, er det ikke en «Bugfix in Delphi», men et anskaffelses- eller standardiseringsvalg.

Drift og support: Hvordan dere integrerer ARM64 i hverdagen

I hverdagen teller det hvor raskt supporttilfeller løses. For ARM64 lønner det seg å øke supportkapasiteten proaktivt:

Standardiserte enhetsprofiler og klare godkjenninger

Definer støttede ARM64-modeller eller i det minste minimumsprofiler (driverstrategi, utskriftsstrategi, versjoner av sikkerhetsagenter). Et «kjører på ARM64» uten denne rammen fører til uensartede miljøer og dermed vanskelig reproducerbare feil.

Diagnosefunksjonalitet i applikasjonen

Selv uten utviklerfokus er et klart krav til programvaren fornuftig her: en systeminformasjonside som viser arkitektur (x64 emulert vs. ARM64 nativ), viktige stier, versjoner av kjernekomponenter og utskriftskonfigurasjon, reduserer supporttider betydelig. Dette er ikke et «nice to have», men driftshygiene.

Lisensiering og dongler

Hvis hardware-dongler eller eldre lisensdrivere er i bruk, blir ARM64 raskt kritisk. I mange miljøer er det fornuftig å gå over til nettverksbaserte eller serverside lisensmekanismer. Det reduserer avhengigheten av drivere på endepunktene og gjør flåten mer utskiftbar.

Hva betyr dette for deres Delphi-strategi?

Delphi er i virksomhetskontekst ofte en stabil byggestein for desktopklienter og tjenester. Windows 11 ARM64 er ikke et argument „mot Delphi“, men et argument for en renere innkapsling av avhengigheter og for en driftsorientert modernisering: færre lokale spesialdrivere, færre in-process-komponenter, tydeligere grensesnitt, bedre utrulling.

Hvis dere i dag allerede er på en moderniseringsbane (f.eks. BDE-utskifting, 64-bit-overgang, sterkere REST-integrasjon, konsolidert dataadgang med FireDAC), er Windows 11 ARM64 ofte „bare“ et tilleggsmål som skjerper prioriteringene. Hvis applikasjonen deres derimot er sterkt avhengig av gamle drivere, proprietære DLLs og spesielle klientkonfigurasjoner, er Windows 11 ARM64 en fornuftig anledning til å gjøre disse risikoene transparente og redusere dem på en planlagt måte.

Konklusjon: ARM64 er mindre et porteringsprosjekt enn et arkitektur- og driftsprosjekt

For virksomheter er Windows 11 ARM64 først og fremst et plattformspørsmål innen anskaffelse, sikkerhet og support. For Delphi-basert forretningsprogramvare avgjøres suksess ikke av en kompilatoropsjon, men av kjeden av drivere, DLLs, COM-integrasjoner, dataadgang og oppdateringsprosesser. En robust fremgangsmåte er: først gjøre avhengigheter og driftsspor synlige, så teste med pilotenheter, deretter målrettet avkople og profesjonalisere utrullingen – og levere native ARM64-builds der de på lang sikt gir nytte og stabilitet.

Hvis dere ønsker å innføre Windows 11 ARM64 i deres flåte og samtidig sikre Delphi-applikasjoner, periferiutstyr og grensesnitt på en planbar måte, snakk med oss om en strukturert kartlegging og en realistisk migrasjonsvei:

I faglig sammenheng spiller også Delphi ARM64 Windows og X64-emulering Windows 11 en viktig rolle når integrasjoner, dataflyter og videreutvikling må fungere sammen på en ryddig måte.

Drøft prosjekt eller moderniseringsinitiativ med Net-Base.