Windows 11 ARM64 med Delphi i verksemder: alternativ, risikoar og ei påliteleg migrasjonsveg

Windows-enheter med ARM64-CPU (ARM64 er ein 64‑bit prosessorarkitektur, kjend frå mobile SoC-ar og i aukande grad også frå forretningsbærbare) er i mange bedrifter ikkje lenger berre «eksotar». Dei kjem via standardiserte bærbarflåtar, lengre batteritid, nye sikkerheitsfunksjonar i maskinvaret og ei strategisk diversifisering av leverandørkjedene. Seineast når fagavdelingar skaffar nye einingar eller OEM-ar tilbyr visse modellar berre som Windows on ARM, står IT-ansvarlege overfor det praktiske spørsmålet: Korleis oppfører vår Delphi-baserte forretningsprogramvare seg under Windows 11 ARM64 – og korleis tryggar vi drift, support og vidareutvikling?

Kjernen er: Windows 11 ARM64 med Delphi i bedrifter er i mindre grad eit reint utviklingsspørsmål enn eit spørsmål om avhengigheiter, utrullingsstrategiar, drivarar, grensesnitt og det reelle åtferda i feltet. I praksis finst tre vegar: vidare drift via emulering, native ARM64-buildar eller ein overgangsmodell som kontrollerer og reduserer risiko. Denne artikkelen set opp dei typiske fallgruvene og viser ein handfast veg som fungerer i IT-planlegging, utrulling og drift – utan «Alt nytt»-refleks.

Kvifor Windows 11 ARM64 no blir relevant

Windows on ARM er ikkje nytt, men rammevilkåra har endra seg: Einingane er tilgjengelege i forretningsmiljøet, Windows 11 gir ei klart meir moden x64-emulering, og programvareleverandørar leverer tyrlegare ARM64-variantar. For bedrifter betyr det at ARM64 ikkje dukkar opp som eit enkelt pilotprosjekt, men som ei plattform som går inn i innkjøps- og livssyklusplanar.

For prosessnære programvareløysingar er det ofte mindre CPU-en i seg sjølv som er problemet, og meir periferi- og integrasjonsrealiteten: utskrift, signaturkort, skannarar, Office-tillegg, COM-komponentar (COM er Microsofts komponentmodell for integrasjon av applikasjonar og bibliotek), skalutvidingar, VPN-klientar eller sikkerheitsagentar. Dersom noko av dette ikkje er ARM64-kompatibelt, oppstår supportarbeid – og ofte blir då «applikasjonen» halden ansvarleg.

Vurdering: Kva betyr ARM64 teknisk for Delphi-applikasjonar?

Delphi-applikasjonar i bedriftsmiljø er ofte klassiske Windows-desktop-klientar (ofte VCL, altså Visual Component Library for Windows-GUI-ar) med databasetilgang (t.d. via BDE-erstatting med native tilkopling, Delphi sitt dataaksesslag) og ei blanding av lokale og eksterne integrasjonar. Under Windows 11 ARM64 oppstår tre kjøremodusar:

1) Nativ ARM64-køyring

Applikasjonen og alle native bibliotek (DLL-ar) finst i ARM64-format. Det er på lang sikt det mest konsistente alternativet, fordi det gjer ytelse og stabilitet planbar og unngår emuleringsvilkår. Det er likevel berre realistisk dersom alle native avhengigheiter følgjer med: database-drivarar, utskrift/forhandsvising, PDF-motor, kryptobibliotek, OCR/scan-SDK-ar, drivarar for maskinvare-donglar osv.

2) x64-emulering under Windows 11 ARM64

Windows 11 kan emulere x64-applikasjonar. For mange reine skrivebords-klientar fungerer det overraskande godt. I praksis er emulering likevel ingen «frikort»: Så snart drivarar, shell-integrasjonar eller in-process-komponentar (DLL-ar som blir lasta inn i prosessen) er involvert, spelar arkitekturen ei avgjerande rolle. Ein x64-prosess kan ikkje laste ei ARM64-DLL, og omvendt. Det er nett denne grensa som ofte avgjer om det «køyrer» eller ikkje.

3) Hybrid: ARM64-klient, separer x64-komponentar

Ein mulig overgangsveg er å trekke kritiske x64-komponentar ut av prosessen: til dømes som ein ekstern teneste, som eit REST-backend (REST er eit HTTP-basert grensesnittmodell) eller som eit eige hjelpeprogram. Det er mindre elegant enn å ha «alt natift», men ofte den mest økonomiske løysinga for å sikre drift og modernisere avhengigheiter trinnvis.

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

I prosjekt viser det seg raskt: Det er ikkje GUI-et som er flaskehalsen, men økosystemet. Ein strukturert avhengighetsanalyse sparar her veker med trial-and-error.

Native DLL-ar og SDK-ar: Den usynlege risikoen

Mange Delphi-applikasjonar bind tredjeparts-DLL-ar: PDF-generering, strekkode/QR, bilethandtering, kryptering, proprietære kommunikasjonsbibliotek. Under ARM64 gjeld det hardt: Ein DLL må passe prosessarkitekturen. Emulering hjelper berre dersom heile prosessen held seg som x64. I det augeblinken du går nativt, må desse biblioteka finnast som ARM64 eller erstattast.

Praksis-tips for IT: Be programvareansvarleg om ei liste over kva DLL-ar ligg i installasjonskatalogen og kva som blir lasta frå systembaner. Det er grunnlaget for å vurdere leverandørevner og alternativ.

COM, Office-automatisering og shell-utvidingar

COM blir i bedriftskvardagen ofte brukt utan at det alltid blir kalla det: Outlook-integrasjon, Excel-eksport via automatisering, DMS-klientar, preview-handlarar i Explorer, kontekstmeny-utvidingar. Problemet under ARM64 er mindre COM i seg sjølv, og meir bitness-koplinga: In-process-COM-serverar (DLL-baserte COM-komponentar) må ha same arkitektur. Out-of-process-COM (EXE-baserte serverar) er meir fleksibelt, sidan det kan køyre i ein separat prosess.

Dersom din Delphi-applikasjon til dømes nyttar ein gammal 32‑bit- eller 64‑bit-COM-DLL, er det ved natift ARM64-køyring eit blockeringspunkt. Emulert som x64 kan det fungere – så lenge alle COM-avhengigheiter òg er x64 og ingen ARM64-only-delar blandar seg inn.

Skriver, PDF og driver-landskapet

Skrivarsaker er ein klassikar ved plattformsbytte. Under Windows 11 ARM64 er det avgjerande om skrivarfabrikanten leverer ARM64-drivarar eller om Universal Print/IPP-klasse-drivarar (IPP er eit standardisert utskriftsprotokoll) kan brukast. Også PDF-skrivarar, buntutskrift, etikettutskrift og spesialutstyr (t.d. termisk skrivare) kan vere avhengige av drivarar som berre finst for x64.

For IT-leiing og administrasjon er den viktige konsekvensen: ARM64-utrulling må koordinerast med utskriftsstrategien. «Applikasjonen skriv ikkje ut» er ofte «drivar finst ikkje» eller «utskrifts-pipelinen er annleis».

Dataråkomst: FireDAC, ODBC/OLE DB und Datenbank-Clients

På dataeininga lønner det seg med ei klar skilnad mellom protokoll og klientbibliotek. BDE-Ablosung mit nativer Anbindung kan, avhengig av database, arbeide med native klientbibliotek eller med drivarar. Om det til dømes krevst ein Oracle-Client, ein eldre PostgreSQL-Client eller ein spesifikk ODBC-driver, må det finnast ein slik for ARM64 – eller dykk satsar på ei arkitektur som innkapslar datatilgangen på serversida (t.d. over REST-tenester eller ein Windows-/Windows- og Linux-tenester).

For stabil drift er dette eit sentralt grep: Jo mindre skrivebordsklienten er direkte knytt til databasedrivarar og lokale database‑«stakkar», desto enklare blir ARM64-adopsjon. Det gjeld også med omsyn til sikkerheit: Databasetilgangsopplysningar, sertifikat og nettverksreglar kan handterast meir konsistent på serversida.

Krypto, smartkort, signaturar, VPN, EDR

Mange forretningsprosessar heng i dag på kryptografiske komponentar: S/MIME, klientsertifikat, smartcard‑middleware, signaturkort, TLS‑inspeksjon i proxyar. I tillegg kjem endepunkt‑sikkerheitsløysingar (EDR er Endpoint Detection and Response) og VPN‑klientar. Desse komponentane må vere ARM64‑kompatible, elles oppstår eit «enheten finst, men får ikkje vere i nettverket»‑problem.

For Delphi‑applikasjonen inneber dette: Om de til dømes brukar sertifikat frå Windows‑sertifikatlageret eller let TLS handterast av systemkomponentar, er det som regel mindre kritisk enn om ei spesifikk tredjeparts‑krypto‑DLL køyrer i prosessen.

Beslutningsmatrise: Emulering eller native ARM64‑portering?

Bedrifter treng ei avgjerd som speglar support‑ og livssyklusrealiteten. Eit enkelt ja/nei‑spørsmål („Porterer vi?“) er sjeldan tilstrekkeleg. Bedre er ei matrise som vektar avhengigheiter og risikoar:

• Rein klient med standard‑Windows‑APIar (fil, nettverk, utskrift via standarddrivarar): Emulering kan vere tilstrekkeleg på kort sikt; native ARM64 er reinare på mellomlang sikt.
• Klient med mange native tredjeparts‑DLLar (PDF, OCR, maskinvare): sjekk tilgjenge og ver såleis, før de avgjer. Særleg hybriportal ofte fornuftig.
• Klient med COM‑DLLar / shell‑utvidingar: vent arkitekturkonfliktar; vurder utkopling utanfor prosessen (out‑of‑process).
• Klient med direkte DB‑driver‑zoo: anten konsolider drivarar eller flytt datatilgang til tenester.
• Høg regulering / signatur / smartkort: verifiser tidleg at sikkerheits‑ og middleware‑kjeda støttar ARM64.

Viktig: Emulering er ikkje ei «andreklasses» løysing, men det er eit driftsrisiko dersom de ser ARM64‑einheiter i flåten på lang sikt. Spørsmålet blir akutt ved større oppdateringar, drivarskifte eller byte av sikkerheitsagentar — då vil de ikkje sitje fast i ei kjede av spesialløysingar.

Ein robust migrasjonsveg: Frå i dag til ARM64 utan Big Bang

For IT‑ og prosjektansvarlege er ei veg god når ho kan rullast ut i bølgjer, har klare akseptkriterium og ikkje overbelastar support. I Delphi‑landskap har ei femstegs framgangsmåte vist seg å fungere.

Steg 1: Kartlegging med «driftsblikk»

Kartlegg ikkje berre modulane, men først og fremst driftsaspekta:

• Kva for einheitsklassar: bærbare PC‑ar, Rugged Devices, terminalar?
• Kva for periferi: skrivarar, skannarar, kortlesarar, etikett‑skrivarar?
• Kva for integrasjonar: Office, DMS, ERP, lokale tenester, nettlesarkomponentar?
• Kva for installasjonsform: MSI, Setup‑EXE, ClickOnce, manuell plassering?
• Kva rettar: er Admin-nivå naudsynt, lokale tenester, brannmurreglar?

Dette perspektivet synleggjer raskt om «berre ein klient» i røynda betyr fem systemavhengigheiter.

Trinn 2: Kompatibilitetsjekk med ein representativ ARM64-pilot

Piloten bør ikkje vere «det finaste utstyret», men ein typisk kandidat frå målflåten. Test medvite dei kritiske vegane: utskrift i alle variantar, eksport/import, signering, offline/online, oppdateringar, mandantskifte, proxy-/VPN-scenarier. Dokumenter avvik som driftsforhold, ikkje som utviklarfeil. Slik held prioriteringa seg rein.

Trinn 3: Reduser avhengigheiter – fyrst dei med høgast supportpåverknad

Typiske tiltak som i dagleg drift gir stor effekt:

• Standardisere PDF-/utskriftsstraumar: vekk frå proprietære skriver-DLL-ar, mot robuste, testede pipeline-løp.
• Løsrive Office-integrasjon: i staden for In-Process-Add-ins, vurder heller eksportformat og serverside dokumentgenerering.
• Konsolidere DB-tilgang: ein definert drivarveg i staden for «ODBC avhengig av arbeidsstasjon».
• Kapsle maskinvaregrensesnitt: om mogleg via eksterne prosessar/tenester som kan oppdaterast separat.

Trinn 4: Moderniser deployment og oppdateringsevne

ARM64 er eit godt høve til å rydde opp i installasjon og oppdateringar. For verksemder tel ikkje funksjonalitet, men rollback-evne, reproduserbarheit og policy-konformitet. Sjekk:

• Pakking: MSI vs. MSIX (MSIX er Microsofts moderne app-pakkeformat med rein installasjon/deinstallasjon og signering).
• Signering: Code Signing (digital signering av EXE/DLL) reduserer SmartScreen- og EDR-friksjon og er relevant for kontrollerte utrullingar.
• Konfigurasjonsstyring: skilje programfiler og konfigurasjon, tydelege vegar, inga «skjulte» Registry-avhengigheiter.
• Oppdateringskanalar: Pilot, Ring 1, Ring 2 – med telemetri/logging på applikasjons- og driftsnivå.

Trinn 5: Native ARM64 der det verkeleg løner seg

Native ARM64-builds er fornuftige når de (a) har avhengigheitene under kontroll, og (b) planlegg langsiktig vidareutvikling av applikasjonen. Vanlegvis løner det seg for kjerneklientar som mange brukarar nyttar dagleg og som de uansett moderniserer. For sjeldan brukte verktøy kan x64-emulering vere ein akseptabel overgang så lenge support og sikkerheit er på plass.

Arkitekturimpulsar: ARM64 som høve til å styrkje grensesnitt og tenester

Mange Delphi-landskap har vokse fram historisk som ein «tjukk klient». Det fungerer, men det bind drift og oppdateringar tettare til enkeltarbeidsstasjonar. ARM64 synleggjer kvar denne koplinga blir kostbar. Ein pragmatisk moderniseringssteg er derfor ofte ikkje «UI på nytt», men grensesnitt på nytt.

Meir stabilitet gjennom serverside-ansvar

Når kritisk logikk, datatilgang eller dokumentprosessar blir flytta til ein sentral teneste (Windows- und Linux-Services eller Windows- und Linux-Services, altså ein bakgrunnsteneste utan interaktivt UI), vinn de:

• einheitlege driver- og bibliotekversjonar,
• betre kontrollerbar sikkerheit (sertifikat, secrets, nettverk),
• lavare kompleksitet på klienten (ARM64, x64, etter kvart også andre plattformer),
• tydelegare overvakings- og loggpunkt.

For IT-besluttarar er dette ein reell driftsfordel: problem blir raskare å gjenskape på serversida, i staden for å henge att på «ein spesiell bærbar».

REST-API als Entkopplungsschicht

Ein REST-API er ikkje automatisk «modern», men ho er eit robust avkoplingslag mellom klientar og backend. Ho definerer tydeleg kva data og handlingar som er tillatne, og kan sikrast på ein ryddeleg måte (t.d. over tokens, sertifikat eller SAML 2.0 som identitetsstandard i bedriftsmiljø). For ARM64 inneber dette at klienten treng mindre «verdskunnskap» om databasar, drivarar og nettverksdetaljar.

Sjølv om de ikkje byter alt med ein gong: Allereie ein liten, godt avgrensa API-komponent (t.d. dokumentgenerering, lisenskontroll, samkøyring av stamdata) kan fjerne avhengigheiter frå klienten og dermed redusere ARM64-risiko.

Test und Qualität: Was Sie unter ARM64 anders prüfen sollten

Mange team testar desktop-programvare primært funksjonelt. På ARM64 bør de i større grad teste driftsprega, fordi feilmønstra er annleis: ikkje «feil utrekning», men «komponenten lastar ikkje», «drivar manglar», «oppdatering mislykkast», «Office-integrasjon bryt».

Checkliste für ARM64-nahe Abnahme

• Install/Uninstall: reint, utan restar, utan admin-omgåingar.
• Updatepfad: oppgradering over fleire versjonar, rollback-scenario, signaturkontroll.
• Logging: sentrale loggar, tydelege feilkodar ved DLL-lasteproblem, etterprøvbare utskriftsvegar.
• Performance: oppstartstid, dataoperasjonar, store listar/rapportar – mål separat under emulering og nativt.
• Peripherie: skriverprofilar, spesialutskrift, skannararbeidsflyt, smartkort-funksjonar.
• Sicherheit: EDR/AV-interaksjon, proxy/TLS, sertifikatlager, drift etter prinsippet om minste privilegium.

Viktig er dokumentasjonen: Dersom eit problem skuldast manglande ARM64-drivar, er det ikkje ein «Bugfix in Delphi», men ei innkjøps- eller standardiseringsavgjerd.

Betrieb und Support: Wie Sie ARM64 in den Alltag integrieren

I kvardagen tel kor raskt supporttilfelle blir løyst. For ARM64 løner det seg å auke supportevna proaktivt:

Standardisierte Geräteprofile und klare Freigaben

Definer støtta ARM64-modellar eller åtvara minsteprofilar (drivarstrategi, utskriftsstrategi, versjonar av Security-Agent). Eit «køyrer på ARM64» utan slike rammer fører til ujamne miljø og vanskeleg å reprodusere feil.

Diagnosefähigkeit in der Anwendung

Sjølv utan utviklarfokus er eit tydeleg krav til programvara her fornuftig: ei systeminfo-side som viser arkitektur (x64 emulert vs. ARM64 nativ), viktige vegar, versjonar av kjernekomponentar og utskriftskonfigurasjon, reduserer supporttida vesentleg. Det er ikkje eit «nice to have», men driftshygiene.

Lizenzierung und Dongles

Når maskinvarudonglar eller eldre lisensdrivarar er i bruk, blir ARM64 raskt kritisk. I mange miljø er det fornuftig å gå over til nettverks- eller serverbaserte lisensmekanismar. Det reduserer avhengigheita av drivarar på endepunkt og gjer flåten meir utskiftbar.

Was bedeutet das für Ihre Delphi-Strategie?

Delphi er i bedriftskontekst ofte ein stabil byggjestein for desktop-klientar og tenester. Windows 11 ARM64 er ikkje eit argument «mot Delphi», men eit argument for ei ryddigare kapsling av avhengnader og for ei driftsorientert modernisering: færre lokale spesialdrivarar, færre in-process-komponentar, klarare grensesnitt, betre utrulling.

Om de i dag allereie er på ein moderniseringsveg (t.d. BDE-Ablösung, 64‑bit-overgang, sterkare REST-integrasjon, konsolidert datatilgang med FireDAC), er ARM64 ofte «berre» eit tilleggsmål som skjerper prioriteringane. Dersom applikasjonen derimot er sterkt avhengig av gamle drivarar, proprietære DLLs og spesialkonfigurasjonar for arbeidsstasjonar, er ARM64 eit føremålsteneleg høve til å gjere desse risikoane synlege og redusere dei på ein planlagd måte.

Konklusjon: ARM64 ist weniger ein Portierungsprojekt als ein Architektur- und Betriebsprojekt

For verksemder er Windows 11 ARM64 fyrst og fremst eit plattformspørsmål innan innkjøp, sikkerheit og support. For Delphi-basert forretningsprogramvare avgjer ikkje suksess ei kompilatorval, men kjeda av drivarar, DLLs, COM-integrasjonar, datatilgang og oppdateringsprosessar. Ein påliteleg veg er: først gjere avhengnader og driftsløp synlege, deretter teste med pilotutstyr, så målretta avkople og professionalisere utrulling – og levere native ARM64-Builds der dei gir langsiktig nytte og stabilitet.

Om de ønskjer å innføre Windows 11 ARM64 i flåten dykkar og samstundes planmessig sikre Delphi-applikasjonar, periferien og grensesnitt, ta kontakt med oss for ein strukturert kartlegging og ein realistisk migrasjonsveg:

I det faglege biletet spelar òg Delphi ARM64 Windows og X64-emulering Windows 11 ei viktig rolle når integrasjonar, dataflyt og vidareutvikling må fungere ryddig saman.

Drøft prosjekt eller moderniseringsprosjekt med Net-Base.