Planlegg Windows 11 ARM64 for Delphi-applikasjonar tidleg

Windows 11 ARM64 er i B2B-kvardagen ikkje lenger berre eit særtilfelle for teknikkentusiastar. Nye generasjonar av notatberarar, lengre batteritid, „Always-on“-scenario og auka ønske om lette, mobile arbeidsplassar fører til at selskap aukar innkjøp av ARM64-klientar – nokre gonger medvite, andre gonger som standard på rammeavtalar. For team med etablert individualprogramvare er dette ei klar melding: ARM64 må tidleg inn i den tekniske planlegginga, elles blir det eit kostbart etterinstallasjonsprosjekt seinare.

Ved Delphi-applikasjonar er det sjeldan hovudspørsmålet om «kan Delphi kompilere dette?». I praksis strandar ARM64-rulleringar nesten alltid i periferien: i native DLL-ar, utskrift-/skannekomponentar, databasedrivarar, rapportmotorar, COM-integrasjonar, installasjonsrutinar, Code-Signing eller i build-pipelines som stille forheld seg til berre x64. Nøyaktig difor løner det seg å behandle Windows 11 ARM64 som ein arkitektur- og driftskrav – ikkje som eit reint plattformfeature.

Denne artikkelen viser kva tekniske snublesteinar som typisk oppstår ved Delphi, korleis de systematisk identifiserer risikoar og kva pragmatiske migrasjonsvegar som har vist seg å fungere – frå gradvis klargjering av einskilde modulær til ein tydeleg målarkitektur med tenester og REST-serverar.

Kvarfor Windows 11 ARM64 no er eit arkitekturtema

I mange selskap har «Windows» lenge vore likestilt med x86/x64. Den antakinga sit i skript, installerarar, tredjepartskomponentar og somme gongar til og med i datamodellen (t.d. vegar, register-keys, drivergrensesnitt). Når ARM64-klientar kjem inn, vert det synleg kor mykje implisitt kunnskap systemet byggjer på. Og nettopp dette er det økonomiske kjernespørsmålet: seine tilpasningar er ikkje berre «eit par compiler-flagg», men rydding i antakingar som har festa seg over år.

Praktisk relevant blir ARM64 særleg i tre situasjonar:

• Klientprogramvare med lang levetid: Fagapplikasjonar som blir brukte og utvida iterativt i 8–15 år. Ei ny klientplattform midt i livssyklusen er meir sannsynleg enn eit fullstendig nybygg.
• Blandede flåtar: Felt- og servicebrukarar, leiingsbærbare, BYOD-liknande scenario eller dotterselskap som anskaffar anna maskinvare.
• Sikkerheits- og compliance-press: Moderne Code-Signing, hardning, «least privilege», kontrollerte oppdaterarar – då blir installasjons- og updateprosessar uansett tatt tak i. Dette er eit gunstig tidspunkt for å integrere ARM64 som ein sidekrav.

Den gode nyhenda: Dei som uansett arbeider med Delphi Modernisierung, 64-bit-omstigning, avkopling av dataaksess eller ei serviceorientert målarkitektur, kan ofte få Windows 11 ARM64 til å «følgje med» – forutsatt at det står tidleg i backloggen og ikkje først blir eit support-tilfelle når den første ARM-maskina dukkar opp.

Delphi på ARM64: Kva er «lett», kva er «vanskelig»?

Delphi-prosjekt varierer sterkt: frå reine VCL-desktop-klientar til fleirlagsystem med REST-server, Windows-tenester, rapport-workerar, integrasjonskomponentar og bakgrunnsjobbar. For Windows 11 ARM64 er det avgjerande kva delar som verkeleg må køyre nativt på klienten og kva som uansett med fordel kan plasserast i tenester.

Kompliseringa ligg sjeldan i kompilatoren

Når eiga kode er rein (inga inline-assembler, inga gamle 32-bit-antakingar, inga skjøre pointer-casts, inga utdaterte API-kall), er kompilering mot ny målplattform ofte gjennomførbart. Problem oppstår gjennom:

• Tredjepartskomponentar med native delar (DLL-ar, BPL-ar, C/C++-bru)
• Drivarar og enhetskopling (utskrift, skann, signaturpad, donglar)
• Databaseaksess via ODBC/OLE DB/klientbibliotek som ikkje er ARM64-kompatible
• Rapportering og Office-integrasjon (COM-automatisering, gamle eksportfilter)
• Installer/Updater som berre testar x64 eller bruker faste vegar

Dermed blir Windows 11 ARM64 først og fremst ein «økosystemtest»: Kor godt er programvarepakken dykkar løyst frå gamle plattformantakingar?

VCL, FMX og UI-avhengigheiter

Mange B2B-fagapplikasjonar er VCL-baserte og nyttar UI-komponentar som har vakse fram over år. Det er ikkje nødvendigvis eit problem – men UI er ofte staden der avhengigheiter samlar seg: PDF-skrivarar, strekkodegeneratorar, bildebibliotek, nettlesarkontrollar, COM-objekt. For ARM64 gjeld: Jo fleire UI-nære spesialkomponentar de brukar, desto viktigare er ei tidleg kompatibilitetsliste.

Ved multiplatform-strategiar (t.d. Windows + macOS) blir FMX ofte aktuell. Uavhengig av rammeverket er ein robust strategi å skilje faglogikk og integrasjonar frå UI. Dette gavnar både Delphi Multiplattform og Windows 11 ARM64.

Typiske tekniske snublesteinar (og korleis ein identifiserer dei tidleg)

I praksis kan dei fleste ARM64-problem bli oppdaga tidleg om de gjer ei strukturert inventar og ein «ARM64 Readiness»-sjekk. Det er avgjerande å ikkje berre sjå på Delphi-koden, men på alt som høyrer til produktet: Installer, drivarar, konfigurasjon, pluginar, tredjepartsverktøy, oppdateringskjede, support-skript.

1) Native DLL-ar, BPL-ar og blandande prosesslandskap

Mange Delphi-applikasjonar lastar ekstra DLL-ar: kryptografi, CAD-viewer, OCR, signatur, hardware-SDK, spesialparserar. På x64 blir det ofte teke for gitt at «det finst ein 64-bit DLL». For ARM64 er det annleis: De treng eksplisitte ARM64-binærar eller ei arkitektur som flyttar denne avhengigheita bort frå klienten.

Praktisk framgangsmåte:

• Lag ei liste over alle lasta native modul (også indirekte gjennom komponentar).
• Klassifiser: «ARM64 tilgjengeleg», «x64-only», «32-bit-only», «uklart».
• Vurder om modulen verkeleg må liggje lokalt eller om ho kan flyttast ut som ein teneste.

Eit vanleg funn: Éin x64-only-modul kan blokkere heile ARM64-klienten. Det er då eit tidspunkt der ei reinlagd sjikt- eller Layer-3 Architektur blir økonomisk riktig: UI/klient held seg lett, integrasjonar flyttar til kontrollerte server-/tenestelag.

2) COM, Office-automatisering og Shell-integrasjonar

I mange selskap er Word/Excel-eksport, Outlook-kopling, Explorer-kontekstmenyar eller DMS-integrasjonar historisk bygd via COM. COM er ikkje automatisk «ARM64-ready», særleg ikkje når tredjeparts COM-servrar eller add-ins berre finst som x64. Også drift av 32-bit/64-bit-blandingar (Out-of-Proc vs. In-Proc) blir raskt komplekst.

Tidleg avklaring:

• Kva COM-objekt blir brukte (ProgIDs/CLSID-liste)?
• In-Proc eller Out-of-Proc? Finnst det ARM64-registreringar?
• Kan eksport løysast via serverside-bibliotek (t.d. dokumentbaserte format) i staden for Office-automatisering?

Dette er ofte eit moderniseringsgrep: Ein går vekk frå UI-tilknytt automatisering til repeterbare eksporttenester (t.d. PDF/Excel via bibliotek) som kan brukast frå både Windows x64, ARM64 eller til og med Linux-serverar.

3) Databaseaksess: ODBC, klientbibliotek, legacy-BDE

Databaseaksess er ein vanleg ARM64-flaskehals, fordi driverlandskap og klientbibliotek spelar inn. Særleg kritiske er gamle ODBC-oppsett, proprietære databaseklientar eller lokale databasar med historiske aksesslag.

For Delphi-stakkar er dette klassisk: Når framleis Borland BDE, gamle Paradox-strukturar eller tungt vedlikehaldne driverkjeder er i bruk, blir ARM64 ein katalysator. Ei BDE-avløysing og overgang til BDE-Ablösung mit nativer Anbindung med ein klar DB-driverstrategi reduserer plattformrisikoar vesentleg.

Konkrete sjekkpunkt:

• Kva databasar er i bruk (SQL Server, PostgreSQL, MariaDB, Firebird, lokale engine)?
• Kva driverar blir brukte (ODBC, native client, BDE-Ablosung mit nativer Anbindung-driver, OLE DB)?
• Kor ligg connection-strings og DSN-ar (per brukar, per maskin, i installasjonsprogrammet)?
• Finnst det avhengigheitar til 32-bit ODBC-driverar eller gamle providerar?

Særleg med SQL Server/ODBC kan ein ARM64-klient fungere – men berre viss driverkjeda og installasjonsrutina er ryddig. Dette er ikkje noko ein vil feilsøkje «i feltet».

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

Output er i fagapplikasjonar ofte forretningskritisk: følgeskriv, etikettar, fakturaer, protokollar, målaravlesingar, sertifikat, fraktetikettar. Mange av desse arbeidsflytane heng på rapportkomponentar eller spesifikke utskrifts-/skannerdrivarar.

På Windows 11 ARM64 er snublesteinane typisk:

• Etikett-skrivardrivar/specialdrivar berre som x64
• Skanner-program/SDK utan ARM64-støtte
• Gamle rapportmotorar med native preview-/export-modular
• PDF-generering via «virtuelle skrivarar» i staden for bibliotek

Ein robust tilnærming er å standardisere output-workflows: produser PDF/Office-format via bibliotek, skriv ut gjennom standardiserte grensesnitt, kapsle spesiell hardware-tilgang. Der dette ikkje er mogleg, trengs tidleg ei maskinvare-/driver-matrise for ARM64.

5) Installer, Updater, Code-Signing og drift

Mange ARM64-prosjekt strandar ikkje på programmet, men på levering: Setup oppdagar feil arkitektur, installerer ikkje drivarar, registrerer ikkje COM, brukar feil vegar eller feilar på Code-Signing-reglar. Også automatiske oppdateringar (delta-oppdateringar, self-updater) er ofte sterkt arkitekturavhengige.

Viktige driftsrelaterte spørsmål:

• Korleis blir det installert (MSI, Inno Setup, eigen updater)?
• Korleis blir avhengigheiter installerte (VC++ Runtimes, drivarar, sertifikat)?
• Kva blir signert (EXE, DLL, installer, driverpakke)?
• Kva blir testa: ekte ARM64-maskinvare eller berre antakingar?

For selskap er dette eit governance-tema: Når Windows 11 ARM64 dukkar opp i klientflåten, må deployment vere reproduserbart – inkludert rollback, supportmoglegheiter og klar versjonshandtering.

Strategi: Windows 11 ARM64 som «tidleg ikkje-funksjonelt krav»

Den økonomisk fornuftige tilnærminga er å behandle ARM64 som eit ikkje-funksjonelt krav (NFA) – på same måte som ytelse, sikkerleik eller offline-funksjonalitet. Det betyr: ikkje først i eit sprint «når det brenn», men som definerte føringar for arkitektur og leveransekjede.

ARM64-Readiness-Check: inventar i staden for magekjensle

Ein robust sjekk omfattar typisk:

• Avhengighetsinventar: alle tredjepartskomponentar, DLL-ar, drivarar, SDK-ar, nettlesarkontrollar, kryptomodular, rapportering.
• Build-/pipeline-analyse: build-targets, pakking, signering, artefaktlagring, versjonsnummer, reproducerbarheit.
• Installer-/update-kjede: setup-logikk, prerequisites, register-/filsystemvegar, policyar, rettigheiter.
• Driftsmodell: support, logging, crash-dumps, telemetri (dersom tilgjengeleg), rollout-plan.

Resultatet bør ikkje vere «ARM64: ja/nei», men ei prioritert liste: kva blockerar finst, kva modul er råka, kva alternativ finst og kva investering som er realistisk.

Beslutningsmatrise: Nativt på ARM64 eller entkople?

For kvar problematisk avhengigheit trengs ei klar avgjersle:

• ARM64-nativ erstatning mogleg: oppgradering, leverandørskifte, byte til annan bibliotek.
• Avhengigheita kan utsleppast som teneste: t.d. til ein Windows-teneste, ein bakgrunnsworker eller ein sentral REST-server.
• Avhengigheita må liggje lokalt: t.d. fordi maskinvara er direkte kopla til klienten. Då trengst bindande ARM64-maskinvare-/drivergodkjenningar.

For integrasjonar er utslepping ofte den reinaste løysinga: klienten held seg til UI og fagdialogar, medan kompleks integrasjonslogikk køyrer i kontrollerte tenester. Det støtte både ARM64 og tema som sentrale oppdateringar, rettigheitskonsept og betre testbarheit.

Arkitekturpattern som stabiliserer ARM64-prosjekt

Når Windows 11 ARM64 planleggjast tidleg, kan fleire arkitekturval takast slik at dei ikkje må reverserast kostbart seinare.

1) Klare sjikt: UI, faglogikk, integrasjon, dataaksess

Vaksne Delphi-klientar har ofte «alt i ein prosess»: UI, forretningsreglar, dataaksess, DMS-kopling, utskrift og eksport. Det er heldbart så lenge plattformen er stabil. Når plattformvariantar (ARM64, eventuelt macOS, eventuelt terminalserver) blir relevante, aukar verdien av klar sjikting.

Pragmatiskt målbilete:

• UI-sjikt: minimalt, testbart, inga direkte driver-/SDK-avhengigheit.
• Faglogikk: så plattformnøytral som mogleg, klart modellert.
• Integrasjonssjikt: kapslar COM, filformat, DMS/ERP-connectorar, devices-SDK-ar.
• Dataaksess: konsolidert (t.d. FireDAC), klare transaksjonsgrenser, inga spreidde SQL-fragment.

Dette er ikkje akademisk, men sparar reelle kostnader: Når berre integrasjonssjiktet er ARM64-problematisk, treng ikkje heile klienten byggast på nytt.

2) Tenester og REST-serverar som stabilitetsanker

Mange B2B-system har fordel av å køyre sentrale funksjonar som REST-server eller som Windows-/Linux-tenester: rettigheitskontroll, dokumentarbeidsflyt, data-validering, eksport, import, grensesnitt mot ERP/DMS/CRM. Når desse funksjonane køyrer server-side, minkar kompleksiteten på klienten vesentleg – og dermed også ARM64-angrepsflata.

Typiske oppdelingar som har vist seg robuste:

• Klient: dialogar, visning, offline-logikk (dersom naudsynt), minimale lokale integrasjonar.
• REST-Server: faglege operasjonar, validering, fleirkundestøtte, sentral logging.
• Worker/Service: tidsstyrte jobbar, grensesnittpolling, rapportgenerering, batch-ekspor

Dette passar òg med moderne driftsmodellar: Ei funksjon som køyrer server-side vert oppdatert ein gong – i staden for på kvar ARM64-klient kvar for seg.

3) Eit build-system, fleire targets (x64 + ARM64) frå starten

Når ARM64 er eit mål, bør build-pipelinen spegle det. Ikkje som «vi gjer ein særbygg seinare», men som standard: Kvart release-kandidat byggjer reproducerbart for x64 (og, om føresett, ARM64), inklusive signering og pakking av installer.

Viktigare enn verktøya er konsekvensen:

• Artefakt namngje klart (arkitektur i pakkenamnet/mappestrukturen).
• Skil konfigurasjonsverdiar per target (vegar, prerequisites, driverpakke).
• Definer smoke-testar per arkitektur (start, login, DB-tilkopling, utskrift/PDF).

Slik blir ARM64 ikkje eit «Big Bang», men eit kontrollert tilleggsmål.

Delphi-modernisering: ARM64 som høve til målretta nedbygging av teknisk gjeld

Mange selskap brukar ny plattformkrav som påskot for «alt på nytt». Det er risikabelt og ofte unødvendig. Meir økonomisk er å bruke Windows 11 ARM64 som rettesnor for gradvis modernisering: ta bort teknisk gjeld der ho blokkerer ARM64 eller trugar leveranseevna.

64-bit og Unicode: ikkje skyv gamle problem vidare

Når kodebasen framleis inneheld 32-bit-antakingar eller etterlatt materiale frå tidlege Delphi-versjonar, kjem desse problema opp ved plattformskifte. Sjølv om ARM64 ikkje automatisk betyr «Unicode», sørgjer mange prosjekt som tek ARM64 alvorleg for at Unicode-handtering er rein, 64-bit-vegane er etablerte og at minne-/pointertema er reinsa.

Målet er ikkje perfekt, men ein påliteleg standard: kode som kan byggjast for nye target utan å gjenta same feilklasse kvar gong.

BDE-avløysing og konsolidert dataaksess som ARM64-enabler

Dersom historiske aksesslag framleis finst (BDE, lokale Paradox-data, blandede dataaksessar), er konsolidering eit grep med fleire effektar: meir vedlikehaldbart, stabilare deployment, klarare driverstrategi. Med FireDAC kan ein ofte standardisere aksessen, inkl. sentral parameterstyring, pooling-strategiar og god feilhandtering.

Viktig: Ein BDE-avløysing er ikkje berre «byte komponent». Ho rører ved transaksjonslogikk, datatypar, sorteringar, filtreringssemantikk og delvis datamodell. Difor bør ho planleggjast – ikkje gjennomførast som naudtiltak når ARM64-klientar plutseleg dukkar opp i feltet.

Test og kvalitetssikring: ARM64 er planleggbar berre når han er måleleg

Å planleggje ARM64 tidleg betyr òg at det må testast – ikkje som full test av alle funksjonar, men som målretta risikotesting av den kritiske kjeda. Viktigaste steget er å ha eit reelt ARM64-testmiljø. Emulering kan i enkelttilfelle hjelpe, men erstattar ikkje praksis med ekte maskinvare, ekte drivarar og ekte sikkerheitsreglar.

Minimal ARM64-smoke-test: kva som bør vere dekka tidleg

Eit pragmatisk men effektivt smoke-test-set for kvar release-kandidat:

• Programstart, login, grunnleggjande UI-funksjonar
• DB-tilkopling (inkl. autentisering, sertifikat, DNS/Proxy om relevant)
• Ein kjerneprosess «end-to-end» (t.d. opprett oppdrag, lagre, skriv ut/eksporter)
• Updater/Installer: nyinstallasjon og oppdatering over ein versjon
• Logging/Feilmeldingar: er diagnoseinformasjonen også nyttig på ARM64?

Med dette vert dei typiske ARM64-blokkerane tidleg synlege: manglande DLL-ar, feil drivarar, setup-problem, uventa rettigheitskrav.

Diagnoseevne: crash-dumps, loggar, versjonstransparens

Når ARM64 finst i flåten, vil supporttilfelle kome – berre på grunn av nye driverkombinasjonar. Difor løner det seg å standardisere diagnostikk: klare build-ID-ar, informative loggar, reproduserbare installasjons- og updatevegar. Dette er ikkje spesifikt for ARM64, men ARM64 gjer manglar her særleg kostbare raskt.

Rollout og drift: blandede flåtar utan kaos

De fleste selskap vil på mellomlang sikt køyre blandede klientflåtar: ein del x64, ein del ARM64. Nøkkelen er å forme denne situasjonen med vilje.

Pakketering: separate installarar, klar deteksjon, entydige nedlastingsstader

I praksis fungerer det best når installarpakkar er entydige: x64-pakke er x64, ARM64-pakke er ARM64. Ein «ein-installer-for-alt» kan verke praktisk, men veks raskt i kompleksitet (sjekklogikk, prerequisites, drivervegar, signering, reparasjonsinstallasjon). For kontrollerte enterprise-rolloutar er tydelegheit ofte det mest robuste vala.

Update-strategi: inga særvegar for ARM64

ARM64 bør ikkje vere eit særtilfelle i update-prosessen. Målet er: same releasefrekvens, same fagversjonsnummer, men separate artefakt. Når ARM64 berre blir oppdatert manuelt, oppstår avvik i flåten som seinare aukar supportkostnadene.

Integrasjonar dokumenterast nøye

Mange ARM64-problem ligg ikkje i eiga kode, men i integrasjonar: ERP-connector, DMS-klient, signaturteneste, skannerprogram, etikett-skrivar. Ei oppdatert integrasjonsliste med versjonar og arkitekturnotat er for B2B-system uansett fornuftig – og gjer ARM64-beslutningar transparente.

Kva selskap bør gjere no konkret (utan aksjonisme)

Å planleggje Windows 11 ARM64 tidleg betyr ikkje å byggje om alt med ein gong. Det betyr å svare på dei rette spørsmåla tidleg og fjerne blokkeringar medan innsatsen er planleggbar. Ein vanleg og velprøvd framgangsmåte er:

• 1) Kartlegging (2–10 dagar avhengig av systemstorleik): avhengigheiter, installer, drivarar, dataaksess, COM, rapportering.
• 2) Målbilete og veg: Kva må køyre nativt på klient? Kva blir teneste/REST? Kva komponentar blir erstatta?
• 3) Proof of Feasibility: ein køyrebar ARM64-build med installer og eit end-to-end-arbeidsflytsscenario.
• 4) Gradvis herding: restfunksjonar, testar, update-kjede, diagnoseevne.

Slik oppstår ikkje eit isolert «ARM64-prosjekt» som køyrer i månadar, men ei kontrollert utviding av leveranseevna.

Konklusjon: Windows 11 ARM64 er ikkje eit hype, men ein tidlegindikator på teknisk modenheit

Windows 11 ARM64 vil for mange selskap bli realiteten – gjennom maskinvareanskaffing, mobilitetskrav eller standardisering. For Delphi-applikasjonar er den reelle utfordringa ikkje berre kjeldekoden, men heile systemet av avhengigheiter, installasjons- og updateprosessar, integrasjonar og drivarar. Dei som planlegg ARM64 tidleg, kan strukturert avklare desse punkta i staden for å «lappe» under tidspress seinare.

Til slutt er ARM64 ein nyttig prøvestein: Kor godt er applikasjonen dykkar entkopla, testbar og leveringsdyktig? Om de svarar på dette no, vinn de ikkje berre plattformsval, men òg eit meir stabilt grunnlag for modernisering, tenester, REST-arkitekturar og langsiktig vedlikehald.

Ta kontakt med Net-Base Software GmbH, om de ønskjer ei belastbar vurdering av Windows 11 ARM64 i dykkar Delphi-roadmap og eit klart teknisk veikart for gjennomføring.