Planera Windows 11 ARM64 för Delphi-applikationer i god tid.

Windows 11 ARM64 är i B2B-vardagen inte längre bara ett specialfall för teknikentusiaster. Nya generationer bärbara datorer, längre batteritider, „Always-on“-scenarier och en ökad efterfrågan på lätta, mobila arbetsplatser gör att företag köper ARM64-klienter – ibland med avsikt, ibland vid sidan av genom standardmodeller i ramavtal. För team med etablerad kundspecifik mjukvara är det ett tydligt besked: ARM64 måste tidigt ingå i den tekniska planeringen, annars blir det senare ett kostsamt efterinstallationsprojekt.

För Delphi-applikationer är den centrala frågan sällan „kan Delphi kompilera det?“. I praktiken misslyckas ARM64-rullouts nästan alltid i periferin: vid native DLL:er, skrivare-/skanningskomponenter, databasdrivrutiner, rapportmotorer, COM-integrationer, installationsrutiner, kodsignering eller byggpipelines som tyst endast känner x64. Just därför lönar det sig att behandla Windows 11 ARM64 som ett arkitektur- och driftkrav – inte som en ren plattformsfunktion.

Detta inlägg visar vilka tekniska snubbeltrådar som typiskt uppstår i Delphi-projekt, hur ni systematiskt identifierar riskerna och vilka pragmatiska migrationsvägar som har visat sig fungera – från successiv anpassning av enskilda moduler till en tydlig målarkitektur med tjänster och REST-servrar.

Varför Windows 11 ARM64 nu är en arkitekturfråga

I många företag har „Windows“ länge varit liktydigt med x86/x64. Denna antagande ligger i skript, installatörer, tredjepartskomponenter och ibland till och med i datamodellen (t.ex. sökvägar, registry-nycklar, drivrutinsgränssnitt). Så snart ARM64-klienter dyker upp blir det synligt hur mycket implicit kunskap som finns i systemet. Och just det är den ekonomiska kärnan: sena anpassningar är inte bara „några kompilatorflaggor“, utan ett saneringsarbete av antaganden som har cementerats över år.

ARM64 blir praktiskt relevant särskilt i tre situationer:

• Klientprogramvara med lång livslängd: Branschspecifika applikationer som används i 8–15 år och iterativt vidareutvecklas. En ny klientplattform mitt i livscykeln är mer sannolik än en komplett omläggning.
• Blandade flotta: Fältservice/utomsärd, chefers notebookar, BYOD-nära scenarier eller dotterbolag som upphandlar annan hårdvara.
• Säkerhets- och compliance-press: Modern kodsignering, hårdning, „least privilege“, kontrollerade uppdaterare – då berörs installations- och uppdateringsprocesserna ändå. Just då är det kostnadseffektivt att integrera ARM64 som en sido-krav.

Den goda nyheten: Den som ändå arbetar med Delphi-modernisering, 64-bit-omställning, avkoppling av dataåtkomst eller en serviceorienterad målarkitektur kan ofta „ta med“ Windows 11 ARM64 – förutsatt att det ligger tidigt i backloggen och inte först hamnar i support när den första ARM-maskinen dyker upp.

Delphi på ARM64: Vad är „lätt“, vad är „svårt“?

Delphi-projekt skiljer sig kraftigt: från rena VCL-desktopklienter till flerskiktade system med REST-servrar, Windows-tjänster, rapport-workers, integrationskomponenter och bakgrundsjobb. För Windows 11 ARM64 är det avgörande vilka delar faktiskt måste köras nativt på klienten och vilka delar som ändå är lämpliga att flytta till tjänster.

Komplileraren är sällan huvudproblemet

Om den egna koden är ren (ingen inline-assembler, inga gamla 32-bit-antaganden, inga sköra pointer-casts, inga föråldrade API-anrop) är kompilering för en ny målplattform ofta genomförbar. Problem uppstår genom:

• Tredjepartskomponenter med native-inslag (DLLs, BPLs, C/C++-bryggor)
• Drivrutiner och enhetsanslutning (skrivare, scanner, signaturplattor, donglar)
• Databasåtkomst via ODBC/OLE DB/klientbibliotek som inte är ARM64-kompatibla
• Rapportering och Office-integration (COM-automation, gamla exportfilter)
• Installatör/uppdaterare som endast testar x64 eller använder hårdkodade sökvägar

Därmed är Windows 11 ARM64 framför allt ett „ekosystemtest“: Hur väl är ert mjukvarupaket frikopplat från gamla plattformsantaganden?

VCL, FMX och UI-beroenden

Många B2B-facksystem är VCL-baserade och använder UI-komponenter som växt fram över år. Det är i sig inget problem – men UI är ofta den plats där beroenden koncentreras: PDF-skrivare, streckkodsgeneratorer, bildbibliotek, browser-controll, COM-objekt. För ARM64 gäller: Ju fler UI-nära specialkomponenter ni använder, desto viktigare blir en tidig kompatibilitetslista.

Vid multiplattformsstrategier (t.ex. Windows + macOS) kommer FMX ofta in i bilden. Oavsett ramverk är en robust strategi att skilja affärslogik och integrationer från UI. Det gagnar både Delphi Multiplattform och Windows 11 ARM64.

Typiska tekniska snubbeltrådar (och hur man upptäcker dem tidigt)

I praktiken kan de flesta ARM64-problem upptäckas tidigt om ni gör en strukturerad inventering och en „ARM64 Readiness“-kontroll. Avgörande är att inte bara granska Delphi-koden, utan allt som hör till produkten: installatörer, drivrutiner, konfiguration, plugins, tredjepartsverktyg, uppdateringskedja, supportscripts.

1) Native DLLs, BPLs och blandade processlandskap

Många Delphi-applikationer laddar tilläggs-DLLs: Kryptografi, CAD-viewer, OCR, signatur, hårdvaru-SDKs, specialparsare. På x64 antas ofta tyst att „det finns en 64-bit DLL“. För ARM64 är det annorlunda: ni behöver uttryckligen ARM64-binaries eller en arkitektur som tar bort detta beroende från klienten.

Praktiskt angreppssätt:

• Sätt upp en lista över alla laddade native-moduler (även indirekt via komponenter).
• Klassificera: „ARM64 tillgänglig“, „endast x64“, „endast 32-bit“, „oklart“.
• Bedöm om modulen verkligen måste vara lokal eller kan flyttas till en tjänst.

Ett vanligt fynd: Enstaka x64-only-moduler blockerar hela ARM64-klienten. Det är ögonblicket då en ren lager- eller Layer-3-arkitektur blir ekonomiskt försvarbar: UI/klient hålls lätt, integrationer flyttas till kontrollerade server-/tjänstelager.

2) COM, Office-automation och Shell-integrationer

I många företag har Word/Excel-export, Outlook-anslutning, Explorer-kontaktmenyer eller DMS-integrationer vuxit fram historiskt via COM. COM är inte automatiskt „ARM64-ready“, särskilt om tredjeparts COM-servrar eller add-ins endast levereras för x64. Drift av 32-bit/64-bit-blandningar (out-of-proc vs. in-proc) blir snabbt komplext.

Tidiga frågor att klargöra:

• Vilka COM-objekt används (ProgIDs/CLSID-lista)?
• In-Proc eller Out-of-Proc? Finns ARM64-registreringar?
• Går export att lösa via serverbaserade bibliotek (t.ex. dokumentbaserade format) istället för Office-automation?

Ofta är detta en moderniseringshävstång: Flytta från UI-kopplad automation till reproducerbara exporttjänster (t.ex. PDF/Excel via bibliotek) som kan användas av både Windows x64, ARM64 eller till och med Linux-servrar.

3) Databasåtkomst: ODBC, klientbibliotek, legacy-BDE

Dataåtkomst är en vanlig ARM64-gräns eftersom drivrutinslandskap och klientbibliotek spelar in. Särskilt kritiska är gamla ODBC-uppsättningar, proprietära databasclients eller lokala databaser med historiska åtkomstlager.

För Delphi-stackar är detta en klassiker: Om det fortfarande finns Borland BDE, gamla Paradox-strukturer eller svårunderhållna drivrutinskedjor blir ARM64 en katalysator. En BDE-avveckling och övergång till en BDE-avveckling med native-anslutning och en tydlig DB-drivrutinstrategi minskar plattformsrisker avsevärt.

Konkreta kontrollpunkter:

• Vilka DB:er används (SQL Server, PostgreSQL, MariaDB, Firebird, lokala motorer)?
• Vilka drivrutiner används (ODBC, native client, BDE-Ablosung mit nativer Anbindung-drivrutin, OLE DB)?
• Var ligger connection-strings och DSNs (per användare, per maskin, i installatören)?
• Finns beroenden av 32-bit ODBC-drivrutiner eller gamla providers?

Särskilt med SQL Server/ODBC kan en ARM64-klient fungera – men bara om drivrutinskedjan och installationsrutinen är korrekt. Det är inget man vill debugga „i fält“.

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

Output är i fackapplikationer ofta affärskritiskt: följesedlar, etiketter, fakturor, protokoll, mätarställningar, certifikat, fraktlabels. Många av dessa workflows är beroende av rapportkomponenter eller specifika skrivare-/scannerdrivrutiner.

På Windows 11 ARM64 är snubbeltrådarna typiskt:

• Etikettskrivare-/specialdrivrutiner endast tillgängliga som x64
• Scanner-mjukvara/SDKs utan ARM64-stöd
• Gamla rapportmotorer med native preview-/export-moduler
• PDF-generering via „virtuella skrivare“ istället för bibliotek

En robust strategi är att standardisera output-workflows: skapa PDF/Office-format via bibliotek, skriv ut via standardiserade gränssnitt, kapsla specialhårdvaruåtkomst så långt som möjligt. Där det inte är möjligt behövs tidigt en enhets-/drivrutinsmatris för ARM64.

5) Installatörer, uppdaterare, kodsignering och drift

Många ARM64-projekt fallerar inte på programmet, utan på leveransen: Setup identifierar arkitekturen fel, installerar inte drivrutiner, registrerar inte COM, sätter fel sökvägar eller misslyckas med kodsigneringspolicyer. Även automatiska uppdateringar (delta-uppdateringar, self-updaters) är ofta starkt arkitekturberoende.

Viktiga driftfrågor:

• Hur installeras det (MSI, Inno Setup, egen updater)?
• Hur installeras beroenden (VC++ Runtimes, drivrutiner, certifikat)?
• Hur signeras det (EXE, DLL, installatör, drivrutins-paket)?
• Hur testas det: riktig ARM64-hårdvara eller endast antaganden?

För företag är detta en governance-fråga: När Windows 11 ARM64 dyker upp i klientflottan måste deployment vara reproducerbar – inklusive rollback, supportbarhet och tydlig versionshantering.

Strategi: Windows 11 ARM64 som „tidigt icke-funktionellt krav“

Den ekonomiskt rimliga angreppsvinkeln är att behandla ARM64 som ett icke-funktionellt krav (NFA) – likt prestanda, säkerhet eller offline-kapacitet. Det innebär: inte först i sprinten „när det brinner“, utan som definierad riktlinje för arkitektur och leveranskedja.

ARM64-Readiness-Check: Inventering istället för magkänsla

En robust kontroll omfattar typiskt:

• Beroendeinventarium: alla tredjepartskomponenter, DLLs, drivrutiner, SDKs, browser-controls, kryptomoduler, rapportering.
• Bygg-/pipeline-analys: build-targets, paketering, signering, artefaktlagring, versionsnummer, reproducerbarhet.
• Installatör-/uppdateringskedja: setup-logik, prerequisites, registry-/filsystemsvägar, policies, rättigheter.
• Driftsmodell: support, loggning, crash-dumps, telemetri (om befintligt), rollout-plan.

Resultatet bör inte vara „ARM64: ja/nej“, utan en prioriterad lista: vilka blockerare finns, vilka moduler påverkas, vilka alternativ finns och vilken investering som är realistisk.

Beslutsmatris: Native på ARM64 eller frikoppla?

Vid varje problematiskt beroende behövs ett tydligt beslut:

• ARM64-native ersättning möjlig: uppgradering, leverantörsbyte, byte till annan bibliotek.
• Beroendet kan flyttas ut: t.ex. till en Windows-tjänst, en bakgrundsworker eller en central REST-server.
• Beroendet måste vara lokalt: t.ex. eftersom hårdvara är direkt ansluten till klienten. Då krävs bindande ARM64-hårdvaru-/drivrutinsfrigivningar.

Särskilt för integrationer är utlagring ofta det renaste spåret: Klienten förblir UI + fackdialoger, medan komplex integrationslogik körs i kontrollerade tjänster. Det stödjer utöver ARM64 också centrala uppdateringar, rättighetskoncept och bättre testbarhet.

Arkitekturpattern som gör ARM64-projekt stabila

När Windows 11 ARM64 planeras tidigt kan flera arkitekturval göras så att de inte behöver göras om dyrt senare.

1) Tydliga lager: UI, affärslogik, integration, dataåtkomst

Etablerade Delphi-klienter har ofta „allt i en process“: UI, affärsregler, dataåtkomst, DMS-anslutning, utskrift och export. Det är underhållsbart så länge plattformen är stabil. När plattformsvarianter (ARM64, eventuellt macOS, eventuellt terminalserver) blir relevanta, ökar värdet av en tydlig lagerindelning.

Pragmatiskt målbild:

• UI-lager: minimalt, testbart, inga direkta drivrutins-/SDK-beroenden.
• Affärslogik: så plattformsneutral som möjligt, väl modellerad.
• Integrationslager: kapslar COM, filformat, DMS/ERP-connectorer, enhets-SDKs.
• Dataåtkomst: konsoliderad (t.ex. FireDAC), tydliga transaktionsgränser, inga utspridda SQL-fragment.

Det är inte „akademiskt“, utan sparar verkliga kostnader senare: Om endast integrationslagret är ARM64-problematiskt behöver inte hela klienten byggas om.

2) Tjänster och REST-servrar som stabilitetsspärr

Många B2B-system tjänar på att centrala funktioner körs som REST-servrar eller som Windows-/Linux-tjänster: rättighetskontroll, dokumentarbetsflöden, datavalidering, export, import, gränssnitt mot ERP/DMS/CRM. När dessa funktioner körs server-side minskar komplexiteten i klienten avsevärt – och därmed också ARM64-attackytan.

Typiska uppdelningar som har visat sig fungera:

• Klient: dialoger, presentation, offline-logik (vid behov), minimala lokala integrationer.
• REST-server: affärsoperationer, validering, multitenancy, central loggning.
• Worker/Service: schemalagda jobb, gränssnittspolling, rapportgenerering, batch-exporter.

Det passar också moderna driftsmodeller: En funktion som körs server-side uppdateras en gång – istället för på varje ARM64-klient separat.

3) Ett byggsystem, flera targets (x64 + ARM64) från början

Om ARM64 är ett mål bör byggpipen spegla det. Inte som „vi gör en specialbuild senare“, utan som standard: Varje releasekandidat byggs reproducerbart för x64 (och, om planerat, ARM64), inklusive signering och paketering av installatör.

Viktigare än verktygen är konsekvensen:

• Namnge artefakter tydligt (arkitektur i paketnamn/mappstruktur).
• Sekretera konfigurationsvärden per target (sökvägar, prerequisites, drivrutinspaket).
• Definiera smoke-tester per arkitektur (start, login, DB-anslutning, utskrift/PDF).

Då blir ARM64 inte ett „Big Bang“, utan ett kontrollerat extra target.

Delphi-modernisering: ARM64 som möjlighet att riktat beta av teknisk skuld

Många företag använder nya plattformsbehov som ursäkt för „allt nytt“. Det är riskabelt och ofta onödigt. Betydligt mer ekonomiskt är att använda Windows 11 ARM64 som styrning för successiv modernisering: beta ner teknisk skuld där den blockerar ARM64 eller hotar leveransförmåga.

64-bit och Unicode: bär inte med gamla problem

Om kodbasen fortfarande innehåller 32-bit-antaganden eller arv från tidiga Delphi-versioner, kommer dessa problem upp igen vid plattformsbyte. Även om ARM64 inte automatiskt innebär „Unicode“: många projekt som seriöst satsar på ARM64 åtgärdar samtidigt Unicode-stöd, etablerar 64-bit-sökvägar och rensar minnes-/pointerfrågor.

Målet är inte perfektion, utan en pålitlig standard: en kod som kan byggas för nya targets utan att upprepa samma felklass vid varje gång.

BDE-avveckling och konsoliderad dataåtkomst som ARM64-enabler

Där historiska åtstamningslager finns (BDE, lokala Paradox-data, blandade dataåtkomster) är en konsolidering en hävstång med multipla effekter: mer underhållbar kod, stabilare deployment och en tydligare drivrutinstrategi. Med FireDAC kan åtkomsten i många scenarier enhetliggöras, inklusive central parametrisering, pooling-strategier och ren felhantering.

Viktigt: En BDE-avveckling är inte bara „byta komponenter“. Den påverkar transaktionslogik, datatyper, sorteringsordning, filtersemantik och delvis även datamodellen. Därför bör den planeras – inte hanteras som en nödlösning när ARM64-klienter plötsligt dyker upp i fält.

Test och kvalitetssäkring: ARM64 är bara planbart om det blir mätbart

Att planera ARM64 tidigt innebär också: det måste testas – inte som fullständig testning av varje funktionalitet, utan som riktad risktestning av den kritiska kedjan. Det viktigaste steget är att ha en verklig ARM64-testmiljö. Emulering kan i vissa fall hjälpa, men ersätter inte praktiken med riktig hårdvara, riktiga drivrutiner och faktiska säkerhetspolicys.

Minimalt ARM64-smoke-test: vad som verkligen bör täckas tidigt

Ett pragmatiskt men effektivt smoke-testset för varje releasekandidat:

• Programstart, inloggning, grundläggande UI-funktioner
• DB-anslutning (inkl. autentisering, certifikat, DNS/proxy om relevant)
• En kärnprocess „end-to-end“ (t.ex. skapa order, spara, skriva ut/exportera)
• Updater/Installatör: nyinstallation och uppdatering över en version
• Loggning/fel-dialoger: är diagnoser användbara även på ARM64?

Detta gör typiska ARM64-blockerare synliga tidigt: saknade DLLs, fel drivrutiner, setup-problem, oväntade behörighetskrav.

Diagnosförmåga: crash-dumps, loggar, versionstransparens

När ARM64 finns i flottan kommer supportfall – en följd av nya drivrutinskombinationer. Därför är det värt att standardisera diagnostik: tydliga build-IDs, meningsfulla loggar, reproducerbara installations- och uppdateringsflöden. Det är inte unikt för ARM64, men ARM64 gör brister här snabbt kostsamma.

Rollout och drift: blandade flottor utan kaos

De flesta företag kommer på medellång sikt att drifta blandade klientflottor: en del x64, en del ARM64. Nyckeln är att utforma detta tillstånd medvetet.

Paketering: separata installatörer, tydlig identifiering, klara nedladdningsvägar

I praktiken fungerar det bäst när installatörer/paket är entydiga: x64-paket är x64, ARM64-paket är ARM64. „En installatör för allt“ låter bekvämt men blir snabbt komplext (kontrollogik, prerequisites, drivrutinsvägar, signering, reparationsinstallation). För kontrollerade företagsrullouts är entydighet ofta den mer robusta vägen.

Uppdateringsstrategi: inga specialvägar för ARM64

ARM64 bör inte vara ett specialfall i uppdateringsprocessen. Målet är: samma releasefrekvens, samma funktionsversionsnummer, men separata artefakter. Om ARM64 endast uppdateras „manuellt“ uppstår avvikelser i flottan som senare ökar supportkostnaderna.

Dokumentera integrationer noggrant

Många ARM64-problem finns inte i egen kod utan i integrationer: ERP-connector, DMS-klient, signaturtjänst, scanner-mjukvara, etikettskrivare. En underhållen integrationslista med versionsnivåer och arkitekturanteckningar är bra praxis för B2B-system – och gör ARM64-beslut transparenta.

Vad företag bör göra nu konkret (utan aktionism)

Att planera för Windows 11 ARM64 tidigt innebär inte att allt måste byggas om omedelbart. Det innebär att besvara rätt frågor i god tid och eliminera blockerare medan insatsen är planbar. Ett beprövat tillvägagångssätt är:

• 1) Inventering (2–10 dagar beroende på systemstorlek): beroenden, installatörer, drivrutiner, dataåtkomst, COM, rapportering.
• 2) Målbild och väg: Vad måste vara native på klienten? Vad blir tjänst/REST? Vilka komponenter byts ut?
• 3) Proof of Feasibility: en körbar ARM64-build med installatör och ett end-to-end use-case.
• 4) Successiv härdning: återstående funktioner, tester, uppdateringskedja, diagnostikförmåga.

Så uppstår inget isolerat „ARM64-projekt“ som körs månader i isolering, utan en kontrollerad utvidgning av leveransförmågan.

Slutsats: Windows 11 ARM64 är ingen hype utan en tidig indikator på teknisk mognad

Windows 11 ARM64 blir för många företag helt enkelt verklighet – genom hårdvaruupphandling, mobilitetskrav eller standardisering. För Delphi-applikationer är den verkliga utmaningen inte enbart källkoden, utan hela systemet av beroenden, installations- och uppdateringsprocesser, integrationer och drivrutiner. Den som planerar för ARM64 tidigt kan strukturera dessa punkter istället för att senare „patcha“ under tidspress.

I slutändan är ARM64 en nyttig kontrollfråga: Hur väl är er applikation frikopplad, testbar och leveransbar? Om ni besvarar den frågan nu vinner ni inte bara plattformsoptioner, utan också en stabilare bas för modernisering, tjänster, REST-arkitekturer och långsiktig underhållbarhet.

Kontakta Net-Base Software GmbH, om ni vill bedöma Windows 11 ARM64 i er Delphi-roadmap på ett belastbart sätt och genomföra det med en tydlig teknisk väg.