Windows 11 ARM64 med Delphi i företag: alternativ, risker och en robust migrationsväg

Windows-enheter med ARM64-CPU (ARM64 är en 64‑bitars processorarkitektur, känd från mobila SoC:er och allt mer även i affärsnotebooks) är i många företag inte längre bara „exotiska“. De kommer via standardiserade notebook-flottor, längre batteritider, nya säkerhetsfunktioner i hårdvaran och en strategisk diversifiering av leverantörskedjan. Senast när verksamhetsområden tar in nya enheter eller OEM:tillverkare erbjuder vissa modeller endast som Windows on ARM, uppstår för IT-ansvariga den praktiska frågan: Hur beter sig vår Delphi-baserade affärsprogramvara under Windows 11 ARM64 – och hur säkerställer vi drift, support och vidareutveckling?

Kärnfrågan är: Windows 11 ARM64 med Delphi i företag är mindre en ren utvecklingsfråga än en fråga om beroenden, deploy-strategier, drivrutiner, gränssnitt och det verkliga beteendet i fält. I praktiken finns det tre vägar: fortsatt drift via emulering, native ARM64-builds eller en övergångsmodell som kontrollerat minskar riskerna. Detta inlägg kategoriserar de typiska fallgroparna och visar en robust väg som fungerar i IT-planering, rollout och drift – utan reflexen att „allt måste bli nytt“.

Varför Windows 11 ARM64 blir relevant nu

Windows on ARM är inte nytt, men förutsättningarna har förändrats: Enheterna är tillgängliga i affärsmiljön, Windows 11 medför en avsevärt mer mogen x64-emulering, och programvaruleverantörer levererar allt oftare ARM64-varianter. För företag innebär det: ARM64 dyker inte upp som ett enstaka pilotprojekt, utan som en plattform som integreras i upphandlings- och livscykelplanering.

För processnära programvarulösningar är det mindre CPU:n i sig som är problemet, och mer perifer- och integrationsrealiteten: skrivare, signaturkort, skannrar, Office-tillägg, COM-komponenter (COM är Microsofts komponentmodell för integration av applikationer och bibliotek), shelldragningar, VPN-klienter eller säkerhetsagenter. Om något av detta inte är ARM64-kompatibelt uppstår supportarbete – och ofta blir då „applikationen“ den som pekas ut som ansvarig.

Bedömning: Vad innebär ARM64 tekniskt för Delphi-applikationer?

Delphi-applikationer i företagsmiljö är ofta klassiska Windows-desktopklienter (vanligtvis VCL, alltså Visual Component Library för Windows-GUI:er) med databasåtkomst (t.ex. via BDE-ersättning med native anslutning, Delphis dataåtkomstlager) och en blandning av lokala och fjärrintegrationer. Under Windows 11 ARM64 uppstår därmed tre körningssätt:

1) Native ARM64-exekvering

Applikationen och alla native-bibliotek (DLL:er) finns som ARM64. Det är på längre sikt det renaste alternativet eftersom det gör prestanda och stabilitet förutsägbara och undviker emuleringsrelaterade begränsningar. Det är dock bara realistiskt om alla native beroenden följer med: databasdrivrutiner, utskrift/förhandsvisning, PDF-motor, kryptobibliotek, OCR/scan-SDK:er, drivrutiner för hårdvarudonglar etc.

2) x64-emulering under Windows 11 ARM64

Windows 11 kan emulera x64-applikationer. För många rena skrivbordsklienter fungerar det förvånansvärt bra. I praktiken är emulering dock ingen „fri biljett“: Så snart drivrutiner, shellintegrationer eller in-process-komponenter (DLL:er som laddas in i processen) är involverade avgörs det av arkitekturen. En x64-process kan inte ladda en ARM64-DLL och vice versa. Just denna gräns avgör ofta „fungerar“ eller „fungerar inte“.

3) Hybrid: ARM64-klient — koppla isär x64-komponenter

En övergångsväg är att dra ut kritiska x64-komponenter ur processen: t.ex. som en extern tjänst, som ett REST-backend (REST är en HTTP-baserad gränssnittsmodell) eller som ett separat hjälpprogram. Det är mindre elegant än „allt nativt“, men ofta den mest ekonomiska vägen för att säkra drift och successivt modernisera beroenden.

Windows 11 ARM64 med Delphi i företag: De typiska beroenden som avgör framgång

I projekt visar det sig snabbt: Det är inte GUI:t som är flaskhalsen, utan ekosystemet. En strukturerad beroendeanalys sparar här veckor av trial-and-error.

Native DLLs och SDKs: Den osynliga risken

Många Delphi-applikationer binder in tredjeparts-DLL:er: PDF-generering, streckkod/QR, bildbehandling, kryptering, proprietära kommunikationsbibliotek. Under ARM64 gäller det strikt: En DLL måste passa processarkitekturen. Emulering hjälper bara om hela processen förblir x64. Så snart man vill köra native måste dessa bibliotek finnas som ARM64 eller ersättas.

Praktiskt tips för IT: Be programansvarig om en lista över vilka DLL:er som ligger i installationskatalogen och vilka som laddas via systemvägar. Det är grunden för att bedöma tillverkarstöd och alternativ.

COM, Office-automatisering och shelltillägg

COM används i företagsvardagen ofta utan att det alltid benämns så: Outlook-integration, Excel-export via automation, DMS-klienter, förhandsvisningshanterare i Explorer, kontextmeny-tillägg. Problemet under ARM64 är mindre COM självt än bitness-kopplingen: In-process-COM-servrar (DLL-baserade COM-komponenter) måste ha samma arkitektur. Out-of-process-COM (EXE-baserade servrar) är flexiblare eftersom de kan köras i en separat process.

Om din Delphi-applikation t.ex. använder en gammal 32‑bitars eller 64‑bitars COM-DLL är det vid native ARM64-körning en blockerare. Emulerat som x64 kan det fungera – så länge alla COM-beroenden också är x64 och inga ARM64-only-delar griper in.

Utskrift, PDF och drivrutinslandskapet

Utskriftsproblem är klassiska vid plattformsbyten. Under Windows 11 ARM64 är det avgörande om skrivartillverkaren tillhandahåller ARM64-drivrutiner eller om Universal Print/IPP-klassdrivrutiner (IPP är ett standardiserat utskriftsprotokoll) kan användas. Även PDF-skrivare, batchutskrift, etikettutskrift och specialenheter (t.ex. termiska skrivare) kan vara beroende av drivrutiner som bara finns för x64.

För IT-ledning och administration är den viktiga konsekvensen: ARM64-utrullningar måste samordnas med utskriftsstrategin. „Applikationen skriver inte ut“ är ofta „drivrutinen finns inte“ eller „utskrifts-pipelinen är annorlunda“.

Åtkomst till data: FireDAC, ODBC/OLE DB och databas-klienter

På datanivån är en tydlig separation mellan protokoll och klientbibliotek fördelaktig. BDE-Ablosung mit nativer Anbindung kan beroende på databas arbeta med native klientbibliotek eller med drivrutiner. Om t.ex. en Oracle-klient, en äldre PostgreSQL-klient eller en specifik ODBC-drivrutin krävs måste den finnas som ARM64 – eller så väljer ni en arkitektur som kapslar in dataåtkomst på serversidan (t.ex. via REST-Services eller en Windows-/ Windows- och Linux-Services).

För stabil drift är detta en central hävstång: ju mindre skrivbordsklienten är direkt bunden till databasdrivrutiner och lokala databasstackar, desto enklare blir ARM64. Detta gäller även ur säkerhetssynpunkt: databasinloggningsuppgifter, certifikat och nätverksregler kan hanteras mer konsekvent på serversidan.

Krypto, smartkort, signaturer, VPN, EDR

Många affärsprocesser är idag beroende av kryptografiska komponenter: S/MIME, klientcertifikat, smartkortsmiddleware, signaturkort, TLS-inspektion i proxys. Därtill kommer endpoint-säkerhetslösningar (EDR är Endpoint Detection and Response) och VPN-klienter. Dessa komponenter måste vara ARM64-kompatibla, annars uppstår ett „enheten finns men får inte gå ut på nätet“-problem.

För Delphi-tillämpningen innebär det: Om ni t.ex. använder certifikat från Windows-certifikatlagret eller hanterar TLS via systemkomponenter är det oftast mindre kritiskt än om en specifik tredjeparts-krypto-DLL ligger i processen.

Beslutsmatris: Emulering eller native ARM64-portering?

Företag behöver ett beslut som speglar support- och livscykelrealiteten. En enkel ja/nej-fråga („Portar vi?“) är sällan användbar. Bättre är en matris som väger beroenden och risker:

• Ren klient med standard-Windows-API:er (fil, nätverk, utskrift via standarddrivrutiner): emulering kan räcka på kort sikt; native ARM64 är på medellång sikt renare.
• Klient med många native tredjeparts-DLL:er (PDF, OCR, hårdvara): kontrollera tillgänglighet först, sedan fatta beslut. Ofta är en hybridväg lämplig.
• Klient med COM-DLL:er / shelltillägg: förvänta arkitekturkonflikter; pröva out-of-process-avkoppling.
• Klient med direkt DB-drivrutinszoo: antingen konsolidera drivrutiner eller flytta dataåtkomst till Services.
• Hög reglering/signatur/smartkort: verifiera tidigt ARM64-kompatibiliteten i säkerhets- och middlewarekedjan.

Viktigt: emulering är inte en „andra klass“, men det är en driftsrisk om ni ser ARM64-enheter i flottan på lång sikt. Senast vid större uppdateringar, drivrutinsbyten eller byte av säkerhetsagent vill ni inte sitta fast i en kedja av specialfall.

En robust migrationsväg: Från idag till ARM64 utan Big Bang

För IT- och projektansvariga är en väg bra om den kan rullas ut i vågor, har tydliga godkriterier och inte överbelastar supporten. I Delphi-landskap har en femstegsmetod visat sig fungera.

Steg 1: Inventering ur driftperspektiv

Fånga inte bara moduler utan framför allt driftpunkter:

• Vilka enhetsklasser: bärbara datorer, rugged-enheter, terminaler?
• Vilken perifer utrustning: skrivare, skannrar, kortläsare, etikettskrivare?
• Vilka integrationer: Office, DMS, ERP, lokala tjänster, webbläsarkomponenter?
• Vilken installationsform: MSI, Setup-EXE, ClickOnce, manuell installation?
• Vilka behörigheter: krävs administratör, lokala tjänster, brandväggsregler?

Detta synsätt visar snabbt om „bara en klient“ i själva verket innebär fem systemberoenden.

Steg 2: Kompatibilitetskontroll med representativ ARM64-pilot

Piloten bör inte vara ”den finaste enheten”, utan en typisk kandidat från målflottan. Testa medvetet de kritiska flödena: utskrift i alla varianter, export/import, signatur, offline/online, uppdateringar, växling mellan klienter, proxy-/VPN-scenarier. Dokumentera avvikelser som driftsfall, inte som utvecklarbuggar. Så förblir prioriteringen tydlig.

Steg 3: Minska beroenden – börja med de med hög supportpåverkan

Typiska åtgärder som ger mycket i vardagen:

• Standardisera PDF-/utskriftsflödet: bort från proprietära skrivar-DLLs, mot stabila, testade pipelines.
• Lösgör Office-integrationen: istället för in-process-add-ins, pröva exportformat och serverbaserad dokumentgenerering.
• Konsolidera databasåtkomst: en definierad drivrutinsväg istället för „ODBC beroende av arbetsplats“.
• Kapsla hårdvaruanslutningar: om möjligt via externa processer/tjänster som kan uppdateras separat.

Steg 4: Modernisera distribution och uppdateringsförmåga

ARM64 är ett bra tillfälle att rensa upp installation och uppdateringar. För företag räknas här inte funktioner, utan möjlighet till rollback, reproducerbarhet och policykonformitet. Granska:

• Paketering: MSI vs. MSIX (MSIX är Microsofts moderna app-paketformat med ren installation/avinstallation och signering).
• Signering: Code Signing (digital signatur av EXE/DLL) minskar friktion mot SmartScreen och EDR och är relevant för kontrollerade utrullningar.
• Konfigurationshantering: separation av programfiler och konfiguration, tydliga sökvägar, inga „dolda“ beroenden i registret.
• Uppdateringskanaler: pilot, ring 1, ring 2 – med telemetri/loggning på applikations- och driftsnivå.

Steg 5: Native ARM64 där det verkligen lönar sig

Native ARM64-builds är motiverade när ni (a) har kontroll över beroenden och (b) avser att vidareutveckla applikationen långsiktigt. Vanligtvis lönar det sig för kärnklienter som många användare använder dagligen och som ni ändå moderniserar. För sällan använda verktyg kan x64-emulering vara en acceptabel övergång så länge support och säkerhet samspelar.

Arkitekturimpulser: ARM64 som anledning att stärka gränssnitt och tjänster

Många Delphi-landskap har historiskt vuxit fram som „tjock klient“. Det fungerar, men det binder drift och uppdateringar mer till enskilda arbetsplatskonfigurationer. ARM64 synliggör var denna koppling blir kostsam. Ett pragmatiskt moderniseringssteg är därför ofta inte „ny UI“, utan nya gränssnitt.

Mer stabilitet genom serversidiga ansvarsområden

När kritisk logik, dataåtkomst eller dokumentprocesser flyttas till en central tjänst (Windows- und Linux-Services eller Windows- und Linux-Services, alltså en bakgrundstjänst utan interaktivt UI), får ni:

• enhetliga drivrutins- och biblioteksnivåer,
• bättre kontrollerbar säkerhet (certifikat, secrets, nätverk),
• mindre komplexitet på klienten (ARM64, x64, framöver även andra plattformar),
• tydligare övervaknings- och loggpunkter.

För IT-beslutsfattare är det en verklig driftfördel: problem blir snabbare reproducerbara på serversidan i stället för att fastna på „en särskild bärbar dator“.

REST-API som avkopplingslager

En REST-API är inte automatiskt „modern“, men den är en robust avkoppling mellan klienter och backend. Den definierar tydligt vilka data och åtgärder som är tillåtna och kan säkras på ett rent sätt (t.ex. via tokens, certifikat eller SAML 2.0 som identitetsstandard i företagsmiljöer). För ARM64 betyder det: klienten behöver bära mindre „världskunskap“ om databaser, drivrutiner och nätverksdetaljer.

Även om ni inte byter allt omedelbart: redan en liten, väl avgränsad API-komponent (t.ex. dokumentgenerering, licenskontroll, stamdataavstämning) kan ta bort beroenden ur klienten och därigenom minska ARM64-riskerna.

Test och kvalitet: Vad ni bör testa annorlunda för ARM64

Många team testar desktopmjukvara främst funktionellt. För ARM64 bör ni testa mer ur driftperspektiv, eftersom felbilderna ser annorlunda ut: inte „felaktig beräkning“, utan „komponent laddas inte“, „drivrutin saknas“, „uppdatering misslyckas“, „Office-integration bryts“.

Checklista för ARM64-relaterad acceptans

• Installera/Avinstallera: rent, utan kvarvarande filer eller administrativa tillfälliga lösningar.
• Uppdateringsväg: uppgradering över flera versioner, återgångsscenario, signaturkontroll.
• Loggning: centrala loggar, tydliga felkoder vid inläsningsproblem av DLL, spårbara utskriftsvägar.
• Prestanda: starttid, dataoperationer, stora listor/rapporter – mät separat under emulering och nativt.
• Periferi: skrivarprofiler, specialutskrift, skannerarbetsflöden, smartkortfunktioner.
• Säkerhet: EDR/AV-interaktion, Proxy/TLS, certifikatlagring, drift enligt principen om minsta behörighet.

Viktig är dokumentationen: om ett problem uppstår på grund av saknade ARM64-drivrutiner är det inte en „Bugfix in Delphi“, utan ett upphandlings- eller standardiseringsbeslut.

Drift och support: Hur ni integrerar ARM64 i vardagen

I vardagen räknas hur snabbt supportärenden löses. För ARM64 lönar det sig att proaktivt öka supportbarheten:

Standardiserade enhetsprofiler och tydliga godkännanden

Definiera stödda ARM64-modeller eller åtminstone minimiprofil (drivrutinstrategi, utskriftsstrategi, versioner av säkerhetsagent). Ett „fungerar på ARM64“ utan denna avgränsning leder till inhomogena miljöer och svårreproducerade störningar.

Diagnoskapacitet i applikationen

Även utan utvecklarfokus är en tydlig funktion i mjukvaran klok: en systeminformationssida som visar arkitektur (x64 emulerat vs. ARM64 nativt), viktiga sökvägar, versioner av kärnkomponenter och utskriftskonfiguration minskar supporttider avsevärt. Det är inte ett „nice to have“, utan driftshygien.

Licenshantering och donglar

Om hårdvarudonglar eller äldre licensdrivrutiner är involverade blir ARM64 snabbt kritiskt. I många miljöer är det lämpligt att flytta licenshantering till nätverksbaserade eller serversidiga mekanismer. Det minskar beroendet av drivrutiner på klienterna och gör flotta mer utbytbar.

Vad betyder detta för er Delphi-strategi?

Delphi är i företagskontext ofta en stabil byggsten för desktopklienter och tjänster. Windows 11 ARM64 är inget argument „mot Delphi“, men ett argument för en renare kapsling av beroenden och för en driftsorienterad modernisering: färre lokala specialdrivrutiner, färre in-process-komponenter, tydligare gränssnitt, bättre driftsättning.

Om ni redan idag är på en moderniseringsbana (t.ex. BDE-Ablösung, 64‑bit-övergång, starkare REST-integration, konsoliderad dataåtkomst med FireDAC), så är ARM64 ofta „bara“ en ytterligare målsättning som skärper prioriteringarna. Om er applikation däremot är starkt beroende av gamla drivrutiner, proprietära DLL:er och arbetsplatsspecifika konfigurationer, är ARM64 ett rimligt tillfälle att göra dessa risker transparenta och planbart minska dem.

Slutsats: ARM64 är mindre ett porteringsprojekt än ett arkitektur- och driftprojekt

För företag är Windows 11 ARM64 framför allt en plattformsfråga inom upphandling, säkerhet och support. För Delphi-baserad affärsprogramvara avgörs framgång inte av en kompilatorinställning, utan av kedjan av drivrutiner, DLL:er, COM-integrationer, dataåtkomst och uppdateringsprocesser. En hållbar väg är: först synliggöra beroenden och driftspår, sedan testa med pilotenheter, därefter avkoppla riktat och professionalisera driftsättningen – och leverera native ARM64-builds där de på lång sikt ger nytta och stabilitet.

Om ni vill införa Windows 11 ARM64 i er flotta och samtidigt planmässigt säkra Delphi-applikationer, kringutrustning och gränssnitt, tala med oss om en strukturerad inventering och en realistisk migrationsväg:

I det fackliga sammanhanget spelar också Delphi ARM64 Windows och X64-emulering Windows 11 en viktig roll när integrationer, dataflöden och vidareutveckling behöver samspela väl.

Diskutera projekt eller moderniseringsprojekt med Net-Base.