Planlegg Windows 11 ARM64 tidlig for Delphi-applikasjoner

Windows 11 ARM64 er i B2B-hverdagen ikke lenger bare et særsyn for teknikkentusiaster. Nye generasjoner av bærbare, lengre batteritid, „Always-on“-scenarioer og et økende ønske om lette, mobile arbeidsplasser gjør at bedrifter kjøper ARM64-klienter – noen ganger bevisst, andre ganger ved siden av gjennom standardmodeller i rammeavtalen. For team med etablert skreddersydd programvare er dette en klar beskjed: ARM64 må tidlig inn i den tekniske planleggingen, ellers blir det et kostbart etterslepprosjekt senere.

For Delphi-applikasjoner er det sentrale spørsmålet sjelden «kan Delphi kompilere dette?». I praksis feiler ARM64-utrullinger nesten alltid i periferien: native DLL-er, utskrifts-/skanningskomponenter, databasedrivere, rapportmotorer, COM-integrasjoner, installasjonsrutiner, code-signing eller build-pipelines som stille antar kun x64. Nettopp derfor lønner det seg å behandle Windows 11 ARM64 som et arkitektur- og driftskrav – ikke som et rent plattformfeature.

Denne artikkelen viser hvilke tekniske snubletråder som typisk oppstår for Delphi, hvordan du systematisk identifiserer risikoene og hvilke pragmatiske migrasjonsveier som har vist seg nyttige – fra trinnvis klargjøring av enkelte moduler til en tydelig målarkitektur med tjenester og REST-servere.

Hvorfor Windows 11 ARM64 nå er et arkitekturtema

I mange virksomheter har «Windows» lenge vært likestilt med x86/x64. Denne antagelsen ligger i skript, installere, tredjepartskomponenter og noen ganger til og med i datamodellen (f.eks. baner, registernøkler, drivergrensesnitt). Når ARM64-klienter dukker opp, blir det synlig hvor mye implisitt kunnskap systemet baserer seg på. Og nettopp dette er det økonomiske kjernen: sene tilpasninger er ikke bare «noen compiler-flagg», men et oppryddingsarbeid i antakelser som har festet seg over år.

ARM64 blir praktisk relevant særlig i tre situasjoner:

• Klientprogramvare med lang levetid: Fagapplikasjoner som brukes i 8–15 år og videreutvikles iterativt. En ny klientplattform midt i livssyklusen er mer sannsynlig enn et fullstendig nybygg.
• Blandet maskinpark: Feltservice/utenlandstjeneste, lederbærbare, BYOD-nære scenarier eller datterselskaper som anskaffer annen maskinvare.
• Sikkerhets- og compliance-press: Moderne code-signing, hardening, «least privilege», kontrollerte oppdateringsmekanismer – da blir installasjons- og updaterutiner berørt uansett. Da er ARM64 en kostnadseffektiv tilleggskrav å innføre.

Gode nyheter: Den som uansett arbeider med Delphi-modernisering, 64-bit-omstilling, avkobling av dataaksesser eller en tjenesteorientert målarkitektur, kan ofte «ta med» Windows 11 ARM64 – forutsatt at det står tidlig i backloggen og ikke først ender opp ved den første ARM-maskinen i supporten.

Delphi på ARM64: Hva er «enkelt», hva er «vanskelig»?

Delphi-prosjekter varierer mye: fra rene VCL-desktopklienter til flerlagsystemer med REST-servere, Windows-tjenester, rapport-workere, integrasjonskomponenter og bakgrunnsjobber. For Windows 11 ARM64 er avgjørende hvilke deler som faktisk må kjøre nativt på klienten og hvilke deler som uansett kan flyttes ut til tjenester.

Compileren er sjelden hovedproblemet

Hvis egen kode er ryddig (ingen inline-assembler, ingen gamle 32-bit-antakelser, ingen fragile pointer-casts, ingen utdaterte API-kall), er kompilering mot en ny målplattform ofte gjennomførbar. Problemene oppstår gjennom:

• Tredjepartskomponenter med native andeler (DLL-er, BPL-er, C/C++-broer)
• Drivere og enhetstilknytning (utskrift, skanning, signaturpads, dongler)
• Databaseadgang over ODBC/OLE DB/klientbiblioteker som ikke er ARM64-kompatible
• Rapportering og Office-integrasjon (COM-automatisering, gamle eksportfiltre)
• Installer/Updater som kun tester x64 eller bruker hardkodede baner

Dermed er Windows 11 ARM64 først og fremst en «økosystem-test»: Hvor godt er programvarepakken din løst fra gamle plattformantakelser?

VCL, FMX og UI-avhengigheter

Mange B2B-fagapplikasjoner er VCL-baserte og bruker UI-komponenter som har vokst over år. Det er ikke i seg selv et problem – men UI er ofte stedet hvor avhengigheter samler seg: PDF-printere, strekkodegeneratorer, bildebiblioteker, nettleserkontroller, COM-objekter. For ARM64 gjelder: jo flere UI-nære spesialkomponenter du bruker, desto viktigere blir en tidlig kompatibilitetsliste.

Ved multiplattformstrategier (f.eks. Windows + macOS) kommer FMX ofte inn i bildet. Uavhengig av rammeverk er en robust strategi å skille faglogikk og integrasjoner fra UI. Det gagner både Delphi Multiplattform og Windows 11 ARM64.

Typiske tekniske snubletråder (og hvordan oppdage dem tidlig)

I praksis kan de fleste ARM64-problemene oppdages tidlig hvis du gjør en strukturert inventar og gjennomfører en «ARM64 Readiness»-sjekk. Det er avgjørende å ikke bare se på Delphi-koden, men alt som hører til produktet: installere, drivere, konfigurasjon, plugins, tredjepartsverktøy, oppdateringskjede, support-skript.

1) Native DLL-er, BPL-er og blandede prosesslandskaper

Mange Delphi-applikasjoner laster ekstra DLL-er: kryptografi, CAD-viewer, OCR, signatur, hardware-SDK-er, spesialparsere. På x64 antas det ofte stilletiende at «det finnes vel en 64-bit-DLL». For ARM64 er det annerledes: du trenger eksplisitte ARM64-binærfiler eller en arkitektur som fjerner denne avhengigheten fra klienten.

Praksistiltak:

• Lag en liste over alle innlastede native moduler (også indirekte via komponenter).
• Klassifiser: «ARM64 tilgjengelig», «x64-only», «32-bit-only», «uklar».
• Vurder om modulen må være lokal eller kan flyttes til en tjeneste.

Et vanlig funn: én enkelt x64-only-modul blokkerer hele ARM64-klienten. Da blir en ryddig lagdelt eller Layer-3 arkitektur økonomisk fornuftig: UI/klient holdes lett, integrasjoner flyttes til kontrollerte server-/tjenestelag.

2) COM, Office-automatisering og Shell-integrasjoner

I mange virksomheter er Word/Excel-eksport, Outlook-tilkobling, Explorer-kontekstmenyer eller DMS-integrasjoner historisk bygd med COM. COM er ikke automatisk «ARM64-ready», spesielt hvis tredjeparts COM-servere eller add-ins kun leveres for x64. Drift av 32-bit/64-bit-blandinger (Out-of-Proc vs. In-Proc) blir også raskt komplekst.

Tidlig avklaring:

• Hvilke COM-objekter benyttes (ProgIDs/CLSID-liste)?
• In-Proc eller Out-of-Proc? Finnes ARM64-registreringer?
• Kan eksport løses via server-side biblioteker (f.eks. dokumentbaserte formater) i stedet for Office-automatisering?

Ofte er dette et moderniseringsgrep: bort fra UI-knyttet automatisering mot reproduserbare eksporttjenester (f.eks. PDF/Excel via bibliotek) som kan brukes både for Windows x64, ARM64 eller til og med Linux-servere.

3) Databaseadgang: ODBC, klientbiblioteker, legacy-BDE

Dataadgangen er et hyppig ARM64-smeltepunkt, fordi driverlandskap og klientbiblioteker spiller inn. Spesielt kritisk er gamle ODBC-oppsett, proprietære databaseklienter eller lokale databaser med historiske tilgangslag.

For Delphi-stabler er dette en klassiker: Hvis Borland BDE, gamle Paradox-strukturer eller tungt vedlikeholdbare driverkjeder fortsatt er i bruk, blir ARM64 en katalysator. En BDE-avvikling og overgang til BDE-avvikling med native tilkobling med en klar DB-driverstrategi reduserer plattformrisiko betydelig.

Konkrete sjekkpunkter:

• Hvilke DB-er er i bruk (SQL Server, PostgreSQL, MariaDB, Firebird, lokale motorer)?
• Hvilke drivere brukes (ODBC, native client, BDE-Ablosung mit nativer Anbindung-driver, OLE DB)?
• Hvor ligger connection-strings og DSN-er (per bruker, per maskin, i installer)?
• Finnes avhengigheter til 32-bit ODBC-drivere eller gamle providere?

Spesielt for SQL Server/ODBC kan en ARM64-klient fungere – men kun hvis driverkjeden og installasjonsrutinen er korrekt. Dette er ikke noe man ønsker å debugge «i felten».

4) Rapportering, utskrift, skanning, PDF og output-workflows

Output er ofte forretningskritisk i fagapplikasjoner: følgesedler, etiketter, fakturaer, protokoller, måleravlesninger, sertifikater, forsendelsesspor. Mange av disse workflowene avhenger av rapportkomponenter eller spesifikke skriver-/skannerdrivere.

På Windows 11 ARM64 er snubletrådene typisk:

• Etikettskriver-/spesialdrivere kun tilgjengelig som x64
• Skannerprogramvare/SDK-er uten ARM64-støtte
• Gamle rapportmotorer med native preview-/eksportmoduler
• PDF-generering via «virtuelle skrivere» i stedet for biblioteker

En robust tilnærming er å standardisere output-workflows: generere PDF/Office-formater via biblioteker, styre utskrift gjennom standardiserte grensesnitt, og kapsle spesielle hardwaretilganger. Der dette ikke er mulig, trenger man tidlig en enhets-/drivermatrise for ARM64.

5) Installer, Updater, Code-Signing og drift

Mange ARM64-prosjekter feiler ikke på programmet, men på leveransen: setup gjenkjenner arkitekturen feil, installerer ikke drivere, registrerer ikke COM, skriver feil baner eller feiler mot code-signing-policyer. Også automatiske oppdateringer (delta-oppdateringer, self-updater) er ofte sterkt arkitekturavhengige.

Viktige driftsrelaterte spørsmål:

• Hvordan installeres det (MSI, Inno Setup, egen updater)?
• Hvordan installeres avhengigheter (VC++ Runtimes, drivere, sertifikater)?
• Hvordan signeres artefaktene (EXE, DLL, installer, driverpakker)?
• Hvordan testes det: ekte ARM64-maskinvare eller bare antagelser?

For bedrifter er dette et styringstema: Når Windows 11 ARM64 dukker opp i klientparken, må deployet være reproduserbart – inkludert rollback, supportmuligheter og entydig versjonshåndtering.

Strategi: Windows 11 ARM64 som en «tidlig ikke-funksjonell krav»

Den økonomisk fornuftige tilnærmingen er å behandle ARM64 som et ikke-funksjonelt krav (NFA) – på linje med ytelse, sikkerhet eller offline-funksjonalitet. Det betyr: ikke vent til et sprint «når det brenner», men etabler det som en definert retningslinje for arkitektur og leveransekjede.

ARM64-Readiness-Check: inventar i stedet for magefølelse

En pålitelig sjekk omfatter typisk:

• Avhengighetsinventar: alle tredjepartskomponenter, DLL-er, drivere, SDK-er, nettleserkontroller, kryptomoduler, rapportering.
• Build-/pipelineanalyse: build-targets, pakking, signering, artefaktlagring, versjonsnummer, reproducerbarhet.
• Installer-/update-kjede: setup-logikk, forutsetninger, register-/filsystembaner, policyer, rettigheter.
• Driftsmodell: support, logging, crash-dumps, telemetri (hvis aktuelt), utrullingsplan.

Resultatet bør ikke være «ARM64: ja/nei», men en prioritert liste: hvilke blocker finnes, hvilke moduler er berørt, hvilke alternativer finnes og hvilke investeringer er realistiske.

Beslutningsmatrise: Nativt på ARM64 eller avkople?

For hver problematiske avhengighet kreves en tydelig beslutning:

• Nativ ARM64-erstatning mulig: oppgradering, leverandørskifte, bytte til annet bibliotek.
• Avhengigheten kan flyttes ut: f.eks. til en Windows-tjeneste, en bakgrunnsworker eller en sentral REST-server.
• Avhengigheten må forbli lokal: f.eks. fordi hardware sitter direkte på klienten. Da kreves håndfaste ARM64-maskinvare-/drivergodkjenninger.

For integrasjoner er ofte utplassering den mest ryddige løsningen: klienten beholder UI og fagdialoger, mens kompleks integrasjonslogikk flyttes til kontrollerte tjenester. Det støtter foruten ARM64 også sentrale oppdateringer, rettighetskonsepter og bedre testbarhet.

Arkitekturmønstre som stabiliserer ARM64-prosjekter

Når Windows 11 ARM64 planlegges tidlig, kan flere arkitekturvalg treffes slik at de senere ikke blir kostbare å reversere.

1) Klare lag: UI, faglogikk, integrasjon, dataadgang

Etablert Delphi-klienter har ofte «alt i én prosess»: UI, forretningsregler, dataadgang, DMS-tilkobling, utskrift og eksport. Det er vedlikeholdbart så lenge plattformen er stabil. Når plattformvarianter (ARM64, eventuelt macOS, eventuelt terminalserver) blir relevante, øker verdien av tydelig lagdeling.

Et pragmatisk målbilde:

• UI-laget: minimalt, testbart, uten direkte driver-/SDK-avhengigheter.
• Faglogikk: så plattformnøytral som mulig, klart modellert.
• Integrasjonslaget: kapsler COM, filformater, DMS/ERP-connectors, enhets-SDK-er.
• Dataadgang: konsolidert (f.eks. FireDAC), klare transaksjonsgrenser, ingen spredte SQL-fragmenter.

Dette er ikke akademisk; det sparer reelle kostnader senere: hvis kun integrasjonslaget skaper ARM64-problemer, trenger ikke hele klienten bygges om.

2) Tjenester og REST-servere som stabilitetspunkt

Mange B2B-systemer har gevinst av å kjøre sentrale funksjoner som REST-servere eller som Windows-/Linux-tjenester: rettighetssjekk, dokumentworkflows, datavalidering, eksport, import og grensesnitt til ERP/DMS/CRM. Når slike funksjoner kjøres server-side, reduseres kompleksiteten på klienten betydelig – og dermed også ARM64-eksponeringen.

Typiske oppdelinger som fungerer i praksis:

• Klient: dialoger, visning, offline-logikk (hvis nødvendig), minimale lokale integrasjoner.
• REST-server: forretningsoperasjoner, validering, flerselskapstøtte, sentral logging.
• Worker/Service: tidsstyrte jobber, polling mot grensesnitt, rapportgenerering, batch-eksporter.

Dette passer også moderne driftsmodeller: en funksjon som kjører server-side oppdateres ett sted – i stedet for å måtte oppdateres på hver ARM64-klient enkeltvis.

3) Ett build-system, flere targets (x64 + ARM64) fra starten

Hvis ARM64 er et mål, bør build-pipelinen gjenspeile det. Ikke som «vi lager en egen build senere», men som standard: hver releasekandidat bygger reproducerbart for x64 (og, om planlagt, ARM64), inkludert signering og pakking av installer.

Viktigere enn verktøyvalget er konsekvensen:

• Gi artefakter entydige navn (arkitektur i pakkenavn/mapper).
• Skill konfigurasjonsverdier per target (baner, prerequisites, driverpakker).
• Definer smoke-tester per arkitektur (start, login, DB-tilkobling, utskrift/PDF).

Slik blir ARM64 ikke en «big bang», men et kontrollert ekstra target.

Delphi-modernisering: ARM64 som mulighet til å rydde teknisk gjeld

Mange bedrifter bruker nye plattformkrav som anledning til «alt nytt». Det er risikabelt og ofte unødvendig. Mer økonomisk er å bruke Windows 11 ARM64 som en retningslinje for trinnvis modernisering: fjern teknisk gjeld der den blokkerer ARM64 eller truer leveranseevnen.

64-bit og Unicode: ikke utsett gamle problemer

Hvis kodebasen fortsatt inneholder 32-bit-antakelser eller restarven fra tidlige Delphi-versjoner, vil disse gjøre seg gjeldende ved plattformskifte. Selv om ARM64 ikke automatisk betyr «Unicode», sørger mange prosjekter som tar ARM64 seriøst samtidig for at Unicode håndteres korrekt, at 64-bit-baner etableres og at minne-/pointerproblematikk ryddes opp.

Målet er ikke perfeksjon, men en pålitelig standard: kode som kan bygges mot nye targets uten å reprodusere de samme feilklassene hver gang.

BDE-avvikling og konsolidert dataadgang som ARM64-enabler

Dersom historiske tilgangslag fortsatt finnes (BDE, lokale Paradox-data, blandede dataaksesser), er konsolidering et kraftfullt grep: mer vedlikeholdbar kode, stabilere deployer, klarere driverstrategi. Med FireDAC kan adgangen i mange scenarier standardiseres, inkludert sentral parameterstyring, pooling-strategier og ryddig feilbehandling.

Viktig: En BDE-avvikling er ikke bare «bytte komponenter». Den påvirker transaksjonslogikk, datatyper, sortering, filtersemantikk og delvis datamodellen. Derfor bør den planlegges – ikke gjøres som nødtiltak når ARM64-klienter plutselig dukker opp i felt.

Test og kvalitetssikring: ARM64 er planbart kun når det måles

Å planlegge ARM64 tidlig betyr også at det må testes – ikke fulltest av alle funksjoner, men målrettet risikotesting av den kritiske kjeden. Det viktigste steget er å ha et reelt ARM64-testmiljø. Emulering kan hjelpe i enkeltstående tilfeller, men erstatter ikke praksis med ekte maskinvare, ekte drivere og reelle sikkerhetspolicyer.

Minimalt ARM64-smoke-test: hva som bør dekkes tidlig

Et pragmatisk, men effektivt smoke-test-sett for hver releasekandidat:

• Programstart, login, grunnleggende UI-funksjoner
• DB-tilkobling (inkl. autentisering, sertifikater, DNS/Proxy om relevant)
• En kjerneprosess «end-to-end» (f.eks. opprette oppdrag, lagre, skrive ut/eksportere)
• Updater/Installer: nyinstallasjon og oppdatering over en versjon
• Logging/feilmeldinger: er diagnostikk nyttig også på ARM64?

Slik blir typiske ARM64-blokkere synlige tidlig: manglende DLL-er, feil drivere, setup-problemer, uventede rettighetskrav.

Diagnosekapasitet: crash-dumps, logger, versjonstransparens

Når ARM64 finnes i parken, vil supporthenvendelser komme – alene på grunn av nye driverkonstellasjoner. Derfor lønner det seg å standardisere diagnostikk: klare build-ID-er, informative logger, reproducerbare installasjons- og updatebaner. Dette er ikke unikt for ARM64, men ARM64 gjør mangler her spesielt kostbare raskt.

Utrulling og drift: blandede flåter uten kaos

De fleste virksomheter vil på mellomlang sikt ha blandede klientflåter: delvis x64, delvis ARM64. Nøkkelen er å forme denne tilstanden bevisst.

Pakking: separate installere, entydig gjenkjenning, klare nedlastningsstier

I praksis fungerer det best når installere/pakker er entydige: x64-pakken er x64, ARM64-pakken er ARM64. «En installer for alle» høres praktisk ut, men blir raskt kompleks (sjekkelogikk, prerequisites, driverbaner, signering, reparasjonsinstallasjon). For kontrollerte bedriftsutrullinger er entydighet ofte det mest robuste valget.

Oppdateringsstrategi: ingen særveier for ARM64

ARM64 bør ikke være en særtilstand i updateprosessen. Målet er: samme releasefrekvens, samme fagversjonsnummer, men separate artefakter. Hvis ARM64 kun oppdateres «manuelt», oppstår avvik i flåten som senere øker supportkostnadene.

Integrasjoner dokumenteres grundig

Mange ARM64-problemer ligger ikke i egen kode, men i integrasjoner: ERP-connector, DMS-klient, signaturtjeneste, skannerprogramvare, etikettprinter. En vedlikeholdt integrasjonsliste med versjonsstand og arkitekturnotater er for B2B-systemer uansett fornuftig – og gjør ARM64-beslutninger transparente.

Hva virksomheter bør gjøre nå (uten aksjonisme)

Å planlegge Windows 11 ARM64 tidlig betyr ikke å rive alt omgående. Det betyr å stille riktige spørsmål tidlig og fjerne blokkerne mens innsatsen er planbar. Et velprøvd framgangsmåte er:

• 1) Statuskartlegging (2–10 dager avhengig av systemstørrelse): avhengigheter, installer, drivere, dataadgang, COM, rapportering.
• 2) Målbilde og vei: Hva må være nativt på klienten? Hva blir tjeneste/REST? Hvilke komponenter byttes ut?
• 3) Proof of Feasibility: en fungerende ARM64-build med installer og et end-to-end-brukstilfelle.
• 4) Trinnvis harding: resterende funksjoner, tester, update-kjede, diagnosekapasitet.

Slik oppstår ikke et isolert «ARM64-prosjekt» som går måneder i silo, men en kontrollert utvidelse av leveranseevnen.

Konklusjon: Windows 11 ARM64 er ingen hype, men en tidlig indikator på teknisk modenhet

Windows 11 ARM64 blir for mange virksomheter simpelthen realitet – gjennom maskinvareanskaffelser, mobilitetskrav eller standardisering. For Delphi-applikasjoner er den egentlige utfordringen ikke bare kildekoden, men hele økosystemet av avhengigheter, installasjons- og updateprosesser, integrasjoner og drivere. Den som planlegger ARM64 tidlig, kan strukturert avklare disse punktene i stedet for å måtte «lappe» dem senere under tidspress.

Til syvende og sist er ARM64 en nyttig prøvestein: hvor godt er applikasjonen din avkoblet, testbar og leverbar? Hvis du svarer på dette nå, vinner du ikke bare plattformvalg, men også et mer stabilt grunnlag for modernisering, tjenester, REST-arkitekturer og langsiktig vedlikeholdbarhet.

Ta kontakt med Net-Base Software GmbH, hvis du ønsker en pålitelig vurdering av Windows 11 ARM64 i din Delphi-roadmap og en klar teknisk gjennomføringsplan.