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å i forretningsbærbare) er i mange selskaper ikke lenger bare «eksotiske». De kommer via standardiserte bærbarflåter, lengre batteritid, nye sikkerhetsfunksjoner i maskinvaren og en strategisk diversifisering av leverandørkjeden. Spørsmålet blir for IT-ansvarlige så snart fagavdelinger anskaffer nye enheter eller OEMer tilbyr visse modeller kun som Windows on ARM: Hvordan oppfører vår Delphi-baserte forretningsprogramvare seg under Windows 11 ARM64 – og hvordan sikrer vi drift, support og videreutvikling?

Kjernen er: Windows 11 ARM64 med Delphi i bedriften er mindre et rent utviklingsspørsmål enn et spørsmål om avhengigheter, deploy-strategier, drivere, grensesnitt og faktisk oppførsel i felt. I praksis finnes det tre veier: videre drift via emulering, native ARM64-builds eller en overgangsmodell som kontrollerer og reduserer risikoene. Denne artikkelen klassifiserer de typiske fallgruvene og viser en robust vei som fungerer i IT-planlegging, utrulling og drift – uten «alt-nytt»-refleks.

Hvorfor Windows 11 ARM64 nå blir relevant

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

For prosessnære programvareløsninger er det derfor sjeldnere selve CPU-en som er problemet, og mer perifer- 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. Hvis noe av dette ikke er ARM64-kompatibelt, oppstår supportarbeid – og ofte blir «applikasjonen» holdt ansvarlig.

Vurdering: Hva betyr ARM64 teknisk for Delphi-applikasjoner?

Delphi-applikasjoner i bedriftsmiljøet er ofte klassiske Windows-desktop-klienter (ofte VCL, altså Visual Component Library for Windows-GUI-er) med databaseadgang (f.eks. via BDE-utskifting med native tilkobling, Delphis dataadgangslag) og en blanding av lokale og eksterne integrasjoner. Under Windows 11 ARM64 oppstår tre kjøremåter:

1) Native ARM64-eksekvering

Applikasjonen og alle native biblioteker (DLL-ene) finnes som ARM64. Det er på lang sikt det reneste alternativet, fordi det gjør ytelse og stabilitet forutsigbar og unngår emuleringsrandbetingelser. Det er imidlertid kun realistisk dersom alle native avhengigheter følger med: databasedrivere, utskrift/forhåndsvisning, PDF-motor, kryptobiblioteker, OCR-/skannings-SDK-er, maskinvare-dongledrivere osv.

2) x64-emulering under Windows 11 ARM64

Windows 11 kan emulere x64-applikasjoner. For mange rene skrivebords‑klienter fungerer det overraskende godt. I praksis er emulering imidlertid ingen „fribillet“: Så snart drivere, shell-integrasjoner eller in-process-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 «kjører» eller «kjører ikke».

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

En overgangsvei er å trekke kritiske x64-komponenter ut av prosessen: for eksempel som en ekstern tjeneste, som REST-backend (REST ist ein HTTP-basiertes Schnittstellenmodell) eller som et separat hjelpeprogram. Det er mindre elegant enn «alt native», men ofte den mest kostnadseffektive veien 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: Det er ikke GUI-et som 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 tredjeparts-DLL-er: PDF-generering, strekkode/QR, bildebehandling, kryptering, proprietære kommunikasjonsbiblioteker. Under ARM64 gjelder det strengt: En DLL må passe prosessarkitekturen. Emulering hjelper bare hvis hele prosessen forblir x64. Når man vil kjøre nativt, må disse bibliotekene finnes som ARM64 eller erstattes.

Praksis-tips for IT: Be ansvarlig for programvaren om å gi en liste over hvilke DLL-er som ligger i installasjonskatalogen og hvilke som lastes via systemstier. Dette er grunnlaget for å vurdere leverandørstøtte og alternativer.

COM, Office-Automation und Shell-Erweiterungen

COM brukes ofte i bedriftsdrift uten at det betegnes slik: Outlook-integrasjon, Excel-eksport via automatisering, DMS-klienter, forhåndsvisningshandlere i Explorer, kontekstmenyutvidelser. Problemet under ARM64 er mindre COM i seg selv, men bithetskoblingen: In-process-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 deler som kun finnes for ARM64 blander seg inn.

Druck, PDF und Treiberlandschaft

Utskriftsproblemer er klassikere ved plattformskifter. Under Windows 11 ARM64 er det avgjørende om skriverprodusenten leverer ARM64-drivere eller om Universal Print/IPP-klasse-drivere (IPP ist ein standardisiertes Druckprotokoll) kan brukes. Også PDF-skrivere, stabelutskrift, etikettutskrift og spesialenheter (f.eks. termiske skrivere) 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 utskriftsstrategien. «Applikasjonen skriver ikke ut» er ofte «driveren finnes ikke» eller «utskriftsrørledningen er annerledes».

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

På data­nivået lønner det seg med en klar separasjon mellom protokoll og klientbibliotek. BDE-Ablosung mit nativer Anbindung kan, avhengig av database, arbeide med native klientbiblioteker eller med drivere. Hvis f.eks. en Oracle‑Client, en eldre PostgreSQL‑Client eller en spesifikk ODBC‑driver kreves, må disse finnes for ARM64 – eller dere velger en arkitektur som kapsler datatilgangen server­siden (f.eks. via REST‑tjenester eller en Windows‑/Windows‑ og Linux‑tjenester).

For stabil drift er dette et sentralt grep: Jo mindre skrivebords­klienten er direkte bundet til database­drivere og lokale database‑“stacks“, desto enklere blir overgangen til ARM64. Dette gjelder også fra et sikkerhets­perspektiv: Database­tilgangsopplysninger, sertifikater og nettverksregler kan forvaltes mer konsistent på serversiden.

Krypto, smartkort, signaturer, VPN, EDR

Mange forretningsprosesser er i dag avhengige av kryptografiske komponenter: S/MIME, klientsertifikater, smartcard‑middleware, signaturkort, TLS‑inspeksjon i proxyer. I tillegg kommer endepunkt­sikkerhetsløsninger (EDR står for Endpoint Detection and Response) og VPN‑klienter. Disse komponentene må være ARM64‑kompatible, ellers oppstår et «enheten finnes, men får ikke tilgang til nettverket»‑problem.

For Delphi‑applikasjonen betyr dette: 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 krypto‑DLL kjører i prosessen.

Beslutningsmatrise: Emulering eller native ARM64‑portering?

Organisasjoner 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 vekter avhengigheter og risikoer:

• 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): undersøk først tilgjengelighet, deretter ta beslutning. Ofte er en hybrid‑tilnærming fornuftig.
• Klient med COM‑DLLer / shell‑utvidelser: forvent arkitekturkonflikter; vurder avkobling i egen prosess.
• Klient med et direkte DB‑driver‑zoo: enten konsolider drivere eller flytt datatilgang til tjenester.
• Høy regulering / signatur / smartkort: verifiser ARM64‑kompatibiliteten i sikkerhets‑ og middleware‑kjeden tidlig.

Viktig: Emulering er ikke «andreklasses», men det er en driftsrisiko hvis dere planlegger ARM64‑enheter i flåten på lang sikt. Senest ved større oppdateringer, driverbytter eller bytte av sikkerhets‑agenter vil dere ikke ønske å sitte igjen med en kjede av unntakstilfeller.

En robust migrasjonsvei: Fra i dag til ARM64 uten Big Bang

For IT og prosjektansvarlige er en god vei én som kan rulles ut i bølger, har klare akseptkriterier og ikke overbelaster support. I Delphi‑landskaper har en femtrinns fremgangsmåte vist seg å fungere.

Trinn 1: Kartlegging med „driftsperspektiv“

Registrer ikke bare moduler, men særlig driftsrelaterte punkter:

• Hvilke enhetsklasser: bærbare, robuste enheter, terminaler?
• Hvilken perifer hardware: skrivere, skannere, kortlesere, etikettskrivere?
• Hvilke integrasjoner: Office, DMS, ERP, lokale tjenester, nettleserkomponenter?
• Hvilken installasjonsform: MSI, Setup‑EXE, ClickOnce, manuell distribusjon?
• Hvilke rettigheter: nødvendig admin, lokale tjenester, brannmurregler?

Dette gjør det raskt synlig om „bare en klient“ i realiteten betyr fem systemavhengigheter.

Trinn 2: Kompatibilitetssjekk med en representativ ARM64-pilot

Piloten bør ikke være „den peneste enheten“, men en typisk kandidat fra målflåten. Test bevisst de kritiske banene: utskrift i alle varianter, eksport/import, signatur, offline/online, oppdateringer, skifte av leietaker (tenant), proxy-/VPN-scenarier. Dokumenter avvik som driftsforhold, ikke som utviklerfeil. Slik forblir prioriteringen ren.

Trinn 3: Reduser avhengigheter – start med de som har størst supportpåvirkning

Typiske tiltak som gir mye i hverdagen:

• Standardiser PDF-/utskriftsflyt: vekk fra proprietære skriver-DLLs, mot stabile, testede pipelines.
• Avkople Office-integrasjon: i stedet for In-Process-Add-ins heller vurdere eksportformater og serverside dokumentgenerering.
• Konsolider DB-tilgang: en definert drivervei i stedet for „ODBC avhengig av arbeidsstasjon“.
• Kapsle maskinvaretilkobling: om mulig via eksterne prosesser/tjenester som kan oppdateres separat.

Trinn 4: Moderniser utrulling og oppdaterbarhet

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

• Paketering: MSI vs. MSIX (MSIX er Microsofts moderne app-pakkeformat med ren installasjon/avinstallasjon og signatur).
• Signering: Code Signing (digital signatur av EXE/DLL) reduserer SmartScreen- og EDR-friksjon 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-builds er fornuftig når du (a) har kontroll på avhengighetene og (b) videreutvikler 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 spiller med.

Arkitekturimpulser: ARM64 som anledning til å styrke grensesnitt og tjenester

Mange Delphi-landskap har historisk vokst fram som en „tykk klient“. Det fungerer, men det binder drift og oppdateringer tettere til enkeltarbeidsstasjoners konfigurasjoner. ARM64 gjør synlig hvor denne koblingen blir kostbar. Et pragmatisk moderniseringstiltak er derfor ofte ikke „ny UI“, men nye grensesnitt.

Mer stabilitet gjennom serverside ansvarsområder

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

• ensartede drivere og bibliotekversjoner,
• bedre kontrollerbar sikkerhet (sertifikater, secrets, nettverk),
• lavere kompleksitet på klienten (ARM64, x64, på sikt også andre plattformer),
• klarere overvåkings- og loggingspunkter.

For IT-beslutningstakere er dette en reell driftsfordel: problemer blir enklere å reprodusere på serversiden, i stedet for å henge på „et spesielt bærbart“.

REST-API som avkoblingslag

En REST-API er ikke automatisk «moderne», men den er en robust avkobling 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å bære mindre «helhetskunnskap» om databaser, drivere og nettverksdetaljer.

Selv om dere ikke migrerer alt med en gang: allerede en liten, godt avgrenset API-komponent (f.eks. dokumentgenerering, lisenskontroll, stamdatasynkronisering) kan fjerne avhengigheter fra klienten og dermed redusere ARM64-risiko.

Testing og kvalitet: Hva dere bør sjekke annerledes under ARM64

Mange team tester skrivebordsprogramvare først og fremst funksjonelt. På ARM64 bør dere teste mer driftssentrert, fordi feilmønstrene er annerledes: ikke «feil beregning», men «komponenten laster ikke», «driver mangler», «oppdatering feiler», «Office-integrasjon bryter».

Sjekkliste for ARM64-nær aksept

• Installasjon/avinstallasjon: ren, uten rester, uten behov for administratoromgåelser.
• Oppdateringssti: oppgradering over flere versjoner, tilbake­rullingsscenario, signaturkontroll.
• Logging: sentrale logger, klare feilkoder ved DLL-lasteproblemer, etterprøvbare utskriftsstier.
• Ytelse: oppstartstid, dataoperasjoner, store lister/rapporter – måles separat under emulering og nativt.
• Periferi: skriverprofiler, spesialutskrift, skannerarbeidsflyter, smartkortfunksjoner.
• Sikkerhet: EDR/AV-interaksjon, proxy/TLS, sertifikatlagring, drift etter prinsippet om minste privilegier.

Viktig er dokumentasjonen: Hvis et problem skyldes manglende ARM64-drivere, er det ikke en «bugfix i Delphi», men et anskaffelses- eller standardiseringsvalg.

Drift og support: Hvordan dere integrerer ARM64 i hverdagen

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

Standardiserte enhetsprofiler og tydelige godkjenninger

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

Diagnosemuligheter i applikasjonen

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

Lisensiering og dongler

Hvis hardware-dongler eller eldre lisensdrivere er i bildet, blir ARM64 raskt kritisk. I mange miljøer er det fornuftig å flytte lisensiering til nettverksbaserte eller serverside-mekanismer. Da reduseres avhengigheten av drivere på endepunktene og flåten blir enklere å bytte ut.

Hva betyr dette for deres Delphi-strategi?

Delphi er i bedriftskontekst ofte en stabil byggekloss for desktop-klienter og tjenester. Windows 11 ARM64 er ikke et argument „mot Delphi“, men et argument for en renere kapsling av avhengigheter og for en driftsorientert modernisering: færre lokale spesialdrivere, færre in-process-komponenter, klarere grensesnitt, bedre utrulling.

Hvis du i dag allerede er på en moderniseringsbane (f.eks. BDE-Ablösung, overgang til 64‑bit, sterkere REST-integrasjon, konsolidert datatilgang med FireDAC), så er ARM64 ofte „bare“ et tilleggsmål som skjerper prioriteringene. Hvis applikasjonen din derimot i stor grad er avhengig av gamle drivere, proprietære DLL-er og spesialkonfigurasjoner på arbeidsstasjonen, er ARM64 en fornuftig anledning til å gjøre disse risikoene synlige og redusere dem planmessig.

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, DLL-er, COM-integrasjoner, datatilgang og oppdateringsprosesser. En robust fremgangsmåte er: først gjøre avhengigheter og driftsflyter synlige, deretter teste med pilotmaskiner, så målrettet løsne koblinger og profesjonalisere utrullingen – og levere native ARM64-builds der de gir langsiktig nytte og stabilitet.

Hvis du ønsker å innføre Windows 11 ARM64 i flåten din og samtidig planmessig sikre Delphi-applikasjoner, periferiutstyr og grensesnitt, 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å samhandle sømløst.

Drøft prosjekt eller moderniseringsprosjekt med Net-Base.