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

Windows-enheter med ARM64-CPU (ARM64 er ei 64‑bit prosessorarkitektur, kjend frå mobile SoC-ar og i aukande grad òg frå forretnings-notebookar) er i mange verksemder ikkje lenger berre „eksotar“. Dei kjem via standardiserte bærbare flåtar, lengre batteritid, nye sikkerheitsfunksjonar i maskinvara og ei strategisk diversifisering av leverandørkjeda. Seinast når fagavdelingar skaffar nye einingar eller OEM-ar tilbyr bestemte modellar berre som Windows på ARM, oppstår for IT-ansvarlege det praktiske spørsmålet: Korleis oppfører vår Delphi-baserte forretningsprogramvare seg under Windows 11 ARM64 – og korleis sikrar vi drift, support og vidareutvikling?

Kjernen er: Windows 11 ARM64 mit Delphi in Unternehmen er mindre eit reint utviklingsspørsmål enn eit spørsmål om avhengigheiter, deploymentsstrategiar, drivarar, grensesnitt og det reelle åtferda i feltet. I praksis finst det tre vegar: vidare drift via emulering, native ARM64-bygg eller eit overgangsmodell som kontrollerer og reduserer risiko. Denne artikkelen plasserer dei typiske snublesteinane og viser ein robust veg som fungerer i IT-planlegging, utrulling og drift – utan ein „Alles neu“-refleks.

Kvifor Windows 11 ARM64 no blir relevant

Windows på ARM er ikkje nytt, men rammevilkåra har endra seg: Einingane finst i forretningsmiljøet, Windows 11 bringer ei klart meir moden x64-emulering, og programvareleverandørar leverer stadig oftare ARM64-variantar. For verksemder betyr det at ARM64 ikkje berre dukkar opp som eitt enkelt pilotprosjekt, men som ei plattform som blir teken med i innkjøps- og livssyklusplanlegging.

For prosessnære programvareløysingar er det sjeldan CPU-en i seg sjølv som er problemet, men periferi- og integrasjonsrealiteten: utskrift, signaturkort, skannarar, Office-add-ins, COM-komponentar (COM er Microsofts komponentmodell for integrasjon av applikasjonar og bibliotek), shell-utvidingar, VPN-klientar eller sikkerheitsagentar. Om noko av dette ikkje er ARM64-eigna, oppstår supportarbeid – og ofte blir då „applikasjonen“ skulda.

Innordning: 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-Ablosung mit nativer Anbindung, Delphi si dataåtkomstlag) og ei blanding av lokale og fjernintegrasjonar. Under Windows 11 ARM64 oppstår det då tre utføringsmåtar:

1) Nativ ARM64-utføring

Applikasjonen og alle native bibliotek (DLLs) finst som ARM64. Det er på lang sikt den reinaste løysinga, fordi ho gjer ytelse og stabilitet planbar og unngår emuleringsrelaterte randbetingelsar. Ho er likevel berre realistisk om alle native avhengigheiter fylgjer med: databasetriar, utskrift/forhandsvising, PDF-motor, kryptobibliotek, OCR/Scan-SDK-ar, maskinvare-dongle-drivarar osv.

2) x64-emulering under Windows 11 ARM64

Windows 11 kan emulere x64-applikasjonar. For mange reine skrivebordsklientar fungerer det overraskande godt. I praksis er emulering likevel ingen „Freikarte“: Så snart drivarar, skallintegrasjonar eller in-process-komponentar (DLLs, die in den Prozess geladen werden) involverast, blir det avhengig av arkitekturen. Ein x64-prosess kan ikkje laste ei ARM64-DLL og omvendt. Nett denne grensa avgjer ofte over «läuft» eller «läuft nicht».

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

Ein overgangsveg er å flytte kritiske x64-komponentar ut av prosessen: t.d. som ein ekstern teneste, som REST-Backend (REST ist ein HTTP-basiertes Schnittstellenmodell) eller som eit eige hjelpeprogram. Det er mindre elegant enn «alles nativ», men ofte den økonomiskaste vegen 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-en som er flaskehalsen, men økosystemet. Ein strukturert avhengigheitsanalyse sparar her veker med Trial-and-Error.

Native DLLs und SDKs: Das unsichtbare Risiko

Mange Delphi-applikasjonar binder tredjeparts-DLLs ein: PDF-Erzeugung, Barcode/QR, Bildverarbeitung, Verschlüsselung, proprietäre Kommunikationsbibliotheken. Under ARM64 gjeld det strengt: Eine DLL muss zur Prozessarchitektur passen. Emulation hjelper berre om heile prosessen held seg x64. Så snart ein vil køyre nativt, må desse biblioteka finnast som ARM64 eller bli erstatta.

Praxis-Tipp für IT: Lassen Sie sich von der Softwareverantwortung eine Liste geben, welche DLLs im Installationsverzeichnis liegen und welche über Systempfade geladen werden. Das ist die Grundlage, um Herstellerfähigkeit und Alternativen zu bewerten.

COM, Office-Automation und Shell-Erweiterungen

COM blir i næringslivet ofte brukt utan at det blir kalla det: Outlook-Integration, Excel-Export über Automation, DMS-Clients, Vorschau-Handler im Explorer, Kontextmenü-Erweiterungen. Problemet under ARM64 er mindre COM sjølv, sondern die Bitness-Kopplung: In-Process-COM-Server (DLL-basierte COM-Komponenten) müssen architekturgleich sein. Out-of-Process-COM (EXE-basierte Server) ist flexibler, weil er in einem separaten Prozess laufen kann.

Wenn Ihre Delphi-Anwendung z. B. eine alte 32‑Bit- oder 64‑Bit-COM-DLL nutzt, ist das bei nativer ARM64-Ausführung ein Blocker. Emuliert als x64 kann es funktionieren – solange alle COM-Abhängigkeiten ebenfalls x64 sind und keine ARM64-only-Teile hineingreifen.

Druck, PDF und Treiberlandschaft

Utskriftsproblem er klassikaren ved plattformbyte. Unter Windows 11 ARM64 ist entscheidend, ob der Druckerhersteller ARM64-Treiber bereitstellt oder ob Universal Print/IPP-Klassen-Treiber (IPP ist ein standardisiertes Druckprotokoll) genutzt werden können. Auch PDF-Drucker, Stapeldruck, Etikettendruck und Spezialgeräte (z. B. Thermodrucker) können an Treibern hängen, die es nur für x64 gibt.

Für IT-Leitung und Administration ist die wichtige Konsequenz: ARM64-Rollouts müssen mit der Druckstrategie abgestimmt werden. „Die Anwendung druckt nicht“ ist oft „der Treiber existiert nicht“ oder „die Druckpipeline ist anders“.

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

På data-nivået løner det seg med ein klar skilnad mellom protokoll og klientbibliotek. BDE-Ablosung mit nativer Anbindung kan, avhengig av database, arbeide med native klientbibliotek eller med drivarar. Når det til dømes krevst ein Oracle‑klient, ein eldre PostgreSQL‑klient eller ein spesifikk ODBC‑driver, må denne finnast for ARM64 – eller de satsar på ei arkitektur som innkapslar datatilgang på serversida (t.d. gjennom REST-tenester eller ein Windows-/Windows- og Linux-tenester).

For stabil drift er dette eit sentralt grep: Jo mindre skrivebordsklienten er direkte bunden til databasedrivarar og lokale database‑stacks, desto lettare blir overgangen til ARM64. Det gjeld òg for sikkerheita: tilgangsdata til databasen, sertifikat og nettverksreglar kan forvaltast meir konsistent på serversida.

Krypto, Smartcards, Signaturen, VPN, EDR

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

For Delphi‑applikasjonen tyder det: Dersom de til dømes brukar sertifikat frå Windows‑sertifikatlageret eller TLS via systemkomponentar, er det oftare mindre kritisk enn når ei spesifikk tredjeparts krypto‑DLL ligg i prosessen.

Beslutningsmatrise: Emulering oder native ARM64‑portering?

Bedrifter treng ei avgjerd som reflekterer realiteten i support og livssyklus. Eit enkelt ja/nei‑spørsmål („Porterer vi?“) er sjeldan nyttig. Bedre er ei matrise som vektlegg avhengigheiter og risiko:

• Rein klient med standard‑Windows‑APIar (fil, nettverk, utskrift via standarddrivarar): Emulering kan vere tilstrekkeleg på kort sikt; native ARM64 er på mellomlang sikt meir robust.
• Klient med mange native tredjeparts‑DLLer (PDF, OCR, maskinvare): fyrst sjekk tilgjengelegheit, deretter avgjer. Oftast er ein hybridveg fornuftig.
• Klient med COM‑DLLer / shell‑utvidingar: Forventa arkitekturkonfliktar; vurder avkopling utanfor prosessen.
• Klient med direkte DB‑driver‑zoo: anten konsolider drivarar eller flytt datatilgang inn i tenester.
• Høg regulering/signatur/smartkort: Verifiser tidleg ARM64‑kompatibiliteten i sikkerheits‑ og middleware‑kjeda.

Viktig: Emulering er ikkje ei «andre klasse»‑løysing, men ho utgjer eit driftsrisiko dersom de på sikt har ARM64‑einheiter i flåten. Seinast ved større oppdateringar, drivarskifte eller bytte av sikkerheitsagent vil de ikkje ønskje å sitje fast i ei kjede av særtilfelle.

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

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

Steg 1: Kartlegging med „driftsvinkel“

Kartlegg ikkje berre modulane, men særleg driftsaspekta:

• Kva for einingstypar: bærbare (Notebooks), robuste felt‑/rugged‑einheiter, terminalar?
• Kva for periferien: skrivarar, skannarar, kortlesarar, etikett-/labelskrivarar?
• Kva for integrasjonar: Office, DMS, ERP, lokale tenester, nettlesarkomponentar?
• Kva for installasjonsform: MSI, Setup‑EXE, ClickOnce, manuell plassering?
• Kva rettar: krevst admin, lokale tenester, brannmursreglar?

Denne utsikta gjer det raskt synleg om «berre ein klient» i røynda betyr fem systemavhengigheiter.

Steg 2: Kompatibilitetsjekk med representativ ARM64-pilot

Pilotapparatet bør ikkje vere «det finaste utstyret», men ein typisk kandidat frå målflåten. Test medvite dei kritiske bana: utskrift i alle variantar, eksport/import, signering, offline/online, oppdateringar, skifte mellom tenantar, proxy/VPN-scenario. Dokumenter avvik som driftshendingar, ikkje som utviklarbuggar. Slik held prioriteringa seg rein.

Steg 3: Reduser avhengigheiter – fyrst dei med høgst supporteffekt

Typiske tiltak som gir mykje i kvardagen:

• Standardisere PDF-/utskriftsløp: bort frå proprietære skriver-DLL-ar, over til stabile, testede pipeline-løysingar.
• Løsriv Office-integrasjonen: i staden for In-Process-Add-ins bør de vurdere eksportformat og serversidig dokumentgenerering.
• Konsolider databasetilgang: ein definert driverveg i staden for «ODBC avhengig av arbeidsstasjon».
• Kapsle maskinvaretilkoplingar: om mogleg via eksterne prosessar/tenester som kan oppdaterast separat.

Steg 4: Moderniser deployment og oppdaterbarheit

ARM64 er eit godt høve til å rydde opp i installasjon og oppdateringar. For verksemder tel ikkje funksjonar her, men Rollback-evne, Reproduserbarheit og Policy-konformitet. Sjekk:

• Pakketering: MSI vs. MSIX (MSIX er Microsoft sitt moderne app-pakkformat med rein installasjon/avinstallasjon og signering).
• Signering: Code Signing (digital signatur av EXE/DLL) reduserer SmartScreen- og EDR-friksjon og er relevant for kontrollerte utrullingar.
• Konfigurasjonsadministrasjon: skilnad mellom programfiler og konfigurasjon, klare stiar, inga «gøymde» registeravhengigheiter.
• Oppdateringskanalar: Pilot, Ring 1, Ring 2 – med telemetri/logging på applikasjons- og driftsnivå.

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

Native ARM64-bygg gir meining når de (a) har kontroll på avhengigheitene og (b) planlegg å vidareutvikle applikasjonen på lang sikt. Vanlegvis løner det seg for kjernklientar 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 spelar med.

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

Mange Delphi-landskap har historisk vakse fram som ein «tjukken klient». Det fungerer, men det bind drift og oppdateringar tettare til enkelte arbeidsstasjonkonfigurasjonar. ARM64 gjer synleg kvar denne koplinga blir kostbar. Eit pragmatisk moderniseringstiltak er derfor ofte ikkje «ny UI», men nye grensesnitt.

Meir stabilitet gjennom ansvar på serversida

Når kritisk logikk, dataåtkomst eller dokumentprosessar flyttar til ein sentral teneste (Windows- og Linux-tenester eller Linux-teneste, altså ein bakgrunnsteneste utan interaktivt UI), får de:

• ensarta drivarar og biblioteksversjonar,
• betre kontrollerbar sikkerheit (sertifikat, secrets, nettverk),
• lågare kompleksitet på klienten (ARM64, x64, i framtida også andre plattformer),
• tydelegare overvaking- og loggpunkt.

For IT-ansvarlege er dette ein reell driftsfordel: problem blir raskare reproduserte på serversida, i staden for at dei heng på „eit spesielt bærbart“.

REST-API som avkoplingslag

Ein REST-API er ikkje automatisk «modern», men ho utgjer ei robust avkopling mellom klientar og backend. Ho definerer klart kva data og handlingar som er tillate, og kan sikrast på ein ryddig måte (t.d. gjennom token, sertifikat eller SAML 2.0 som identitetsstandard i bedriftsmiljø). For ARM64 betyr dette: klienten treng mindre detaljert kunnskap om databasar, drivarar og nettverksdetaljar.

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

Test og kvalitet: kva de bør teste annleis på ARM64

Mange team testar skrivebordsprogramvare først og fremst funksjonelt. På ARM64 bør de i større grad teste driftsscenario, fordi feilmønstra er annleis: ikkje „feil rekning“, men „komponent lastar ikkje“, „driver manglar“, „oppdatering feilar“, „Office-integrasjon bryt“.

Sjekkliste for ARM64-nær aksept

• Installasjon/avinstallasjon: ryddig, utan restar, utan behov for administrative omgåingar.
• Oppgraderingsveg: oppgradering over fleire versjonar, rollback-scenario, signaturverifisering.
• Loggføring: sentrale loggar, klare feilkodar ved DLL-lasteproblem, etterprøvbare utskriftsløp.
• Ytelse: oppstartstid, dataoperasjonar, store lister/rapporter – målast separat under emulering og nativ drift.
• Periferi: skriverprofilar, spesialutskrift, skannearbeidsflytar, smartkortfunksjonar.
• Sikkerheit: EDR/AV-interaksjon, proxy/TLS, sertifikatlager, drift med minste privilegium.

Viktig er dokumentasjonen: viss eit problem oppstår på grunn av manglande ARM64-drivarar, er det ikkje ein „Bugfix in Delphi“, men ei anskaffings- eller standardiseringsavgjerd.

Drift og support: korleis de integrerer ARM64 i kvardagen

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

Standardiserte enheitsprofilar og klare godkjenningar

Definer støtta ARM64-modellar eller i det minste minstekrav for profilar (drivarstrategi, utskriftsstrategi, versjonar av sikkerheitsagentar). Eit „køyrer på ARM64“ utan denne ramma fører til ujamne miljø og dermed til vanskeleg å reprodusere feil.

Diagnoseevne i applikasjonen

Også utan utviklarfokus er eit klart krav til programvara nyttig her: ei systeminfo-side som viser arkitektur (x64 emulert vs. ARM64 nativ), viktige baner, versjonar av kjernekomponentar og utskriftskonfigurasjon, reduserer supporttida betydeleg. Dette er ikkje eit „nice to have“, men driftshygiene.

Lisensiering og donglar

Når hardware-donglar eller eldre lisensdrivarar er i spel, blir ARM64 raskt kritisk. I mange miljø er det fornuftig å flytte lisensiering til nettverksbaserte eller serversidige mekanismar. Det reduserer avhengigheita av drivarar på endepunkt og gjer flåten meir utskiftbar.

Kva betyr dette for dykkar Delphi-strategi?

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

Hvis De i dag allereie er på ein moderniseringsveg (t.d. BDE-Ablösung, 64‑bit-overgang, sterkare REST-integrasjon, konsolidert datatilgang med FireDAC), så er ARM64 ofte «berre» eit tilleggspunkt som skjerper prioriteringane. Dersom applikasjonen Deres derimot er sterkt avhengig av gamle drivarar, proprietære DLLs og arbeidsplass-spesialkonfigurasjonar, er ARM64 eit fornuftig høve til å synleggje desse risikoane og redusere dei på ein planmessig måte.

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

For verksemder er Windows 11 ARM64 fyrst og fremst eit plattformspørsmål ved anskaffing, sikkerheit og support. For Delphi-basert forretningsprogramvare blir suksess ikkje avgjort av ei kompilatorinnstilling, men av kjeda med drivarar, DLLs, COM-integrasjonar, datatilgang og oppdateringsprosessar. Ein robust veg er: fyrst synleggje avhengigheiter og driftsstiar, så teste med pilotapparat, deretter målretta avkople og profesjonalisere utrullinga – og levere native ARM64-Builds der dei på lang sikt gir nytte og stabilitet.

Hvis De ønskjer å innføre Windows 11 ARM64 i flåten Deres og samstundes planmessig sikre Delphi-applikasjonar, periferien og grensesnitt, ta kontakt med oss for ei strukturert bestandskartlegging og ein realistisk migrasjonsveg:

I det faglege miljøet spelar også Delphi ARM64 Windows og X64-emulering Windows 11 ei viktig rolle når integrasjonar, dataflyt og vidareutvikling må fungere godt saman.

Drøft prosjekt eller moderniseringstiltak med Net-Base.