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:ar och allt fler gånger även i företagsbärbara datorer) är i många företag inte längre bara „exoter“. De kommer via standardiserade bärbara-flottor, längre batteritid, nya säkerhetsfunktioner i hårdvaran och en strategisk diversifiering av leverantörskedjan. Senast när verksamhetsområden anskaffar nya enheter eller OEM:er 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äkrar vi drift, support och vidareutveckling?

Huvudpoängen är: Windows 11 ARM64 med Delphi i företag är i mindre utsträckning en ren utvecklingsfråga än en fråga om beroenden, driftsättningsstrategier, drivrutiner, gränssnitt och verkligt beteende i fältet. I praktiken finns tre vägar: fortsatt drift via emulering, native ARM64-byggar eller en övergångsmodell som kontrollerat reducerar risker. Detta inlägg placerar de typiska fallgroparna och visar en hållbar väg som fungerar i IT-planering, rollout och drift – utan reflexen att „börja om från noll“.

Varför Windows 11 ARM64 blir relevant nu

Windows on ARM är inte nytt, men förutsättningarna har förändrats: Enheterna finns tillgängliga i företagsmiljön, Windows 11 levererar en klart mer mogen x64-emulering, och mjukvaruleverantörer levererar allt oftare ARM64-varianter. För företag innebär detta att ARM64 inte dyker upp som ett engångspilotprojekt, utan som en plattform som ingår i inköps- och livscykelplaneringen.

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

Inplacering: 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-Ablösung mit nativer Anbindung, Delphis dataåtkomstlager) och en blandning av lokala och fjärrintegrationer. Under Windows 11 ARM64 uppstår därvid tre körningssätt:

1) Native ARM64-Ausführung

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

2) x64-Emulation unter Windows 11 ARM64

Windows 11 kan emulera x64-applikationer. För många rena desktopklienter fungerar det överraskande bra. I praktiken är emulering dock ingen „fri biljett“: Så snart drivrutiner, shell‑integrationer eller in‑process‑komponenter (DLLs som laddas in i processen) är involverade, spelar arkitekturen roll. En x64‑process kan inte ladda en ARM64‑DLL och vice versa. Just denna gräns avgör ofta om det „fungerar“ eller „fungerar inte“.

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

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

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

I projekt framgår det snabbt: Det är inte GUI:t som är flaskhalsen, utan ekosystemet. En strukturerad beroendeanalys sparar veckor av trial‑and‑error.

Native DLLs und SDKs: Das unsichtbare Risiko

Många Delphi‑applikationer binder in tredjeparts‑DLLs: PDF‑generering, streckkod/QR, bildbehandling, kryptering, proprietära kommunikationsbibliotek. Under ARM64 gäller det strikt: En DLL måste passa processens arkitektur. 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 ansvarig för mjukvaran om en lista över vilka DLLs som ligger i installationskatalogen och vilka som laddas via systemvägar. Det är grunden för att bedöma leverantörsstöd och alternativ.

COM, Office-Automation und Shell-Erweiterungen

COM används i företagsvardagen ofta utan att det alltid kallas vid namn: Outlook‑integration, Excel‑export via automation, DMS‑klienter, preview‑handlers i Explorer, kontextmeny‑förlängningar. Problemet under ARM64 är mindre COM i sig än bitness‑kopplingen: In‑process‑COM‑servrar (DLL‑baserade COM‑komponenter) måste ha samma arkitektur. Out‑of‑process‑COM (EXE‑baserade servrar) är mer flexibelt eftersom det kan köras i en separat process.

Om er Delphi‑applikation till exempel använder en gammal 32‑bit eller 64‑bit COM‑DLL blir det ett blockerande problem vid native ARM64‑körning. Emulerat som x64 kan det fungera — så länge alla COM‑beroenden också är x64 och inga ARM64‑only‑delar griper in.

Druck, PDF und Treiberlandschaft

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 endast 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‑pipeline är annorlunda“.

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

På data­nivån är en tydlig separation mellan protokoll och klientbibliotek fördelaktig. BDE-Ablosung mit nativer Anbindung kan beroende på databas arbeta med native clientlibs eller med drivrutiner. Om till exempel en Oracle‑client, en äldre PostgreSQL‑client eller en specifik ODBC‑drivrutin krävs måste den finnas för ARM64 – eller så väljer ni en arkitektur som kapslar databastillgången server­sidan (t.ex. via REST‑tjänster eller en Windows-/ Windows‑ och Linux‑tjänster).

För stabil drift är detta en central hävstång: Ju mindre desktop‑klienten är direkt bunden till databas­drivrutiner och lokala databas‑“stackar“, desto enklare blir övergången till ARM64. Detta gäller även ur säkerhetssynpunkt: databastillgångs­uppgifter, certifikat och nätverksregler kan hanteras mer konsekvent server­sidan.

Krypto, smartcards, signaturer, VPN, EDR

Många affärsprocesser är idag beroende av kryptografiska komponenter: S/MIME, klientcertifikat, smartcard‑middleware, signaturkort, TLS‑inspektion i proxies. 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å in i nätverket”‑problem.

För Delphi‑applikationen innebär det: Om ni till exempel använder certifikat från Windows‑certifikatlager eller hanterar TLS via systemkomponenter är det ofta mindre kritiskt än när en specifik tredjeparts‑kryptodLL 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 („Porterar vi?“) är sällan hjälpsam. Bättre är en matris som viktar beroenden och risker:

• Ren klient med standard‑Windows‑API:er (fil, nätverk, utskrift via standard­drivrutiner): Emulering kan räcka på kort sikt; native ARM64 är en renare lösning på medellång sikt.
• Klient med många native tredjeparts‑DLL:er (PDF, OCR, hårdvara): kontrollera först tillgänglighet, därefter besluta. Ofta är en hybridväg rimlig.
• Klient med COM‑DLL:er / shell‑tillägg: förvänta er arkitekturkonflikter; överväg out‑of‑process‑avkoppling.
• Klient med direkt DB‑drivrutins‑zoo: antingen konsolidera drivrutiner eller flytta databastillgång till tjänster.
• Hög reglering/signatur/smartcard: verifiera tidigt ARM64‑kapaciteten i säkerhets‑ och middleware‑kedjan.

Viktigt: Emulering är ingen „andra klassens“ lösning, men det är en driftsrisk om ni planerar att ha ARM64‑enheter i er flotta på lång sikt. Vid större uppdateringar, drivrutinsbyten eller byte av säkerhetsagenter vill ni inte sitta fast i en kedja av specialfall.

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

För IT och projektansvariga är en väg bra när den kan rullas ut i vågor, har tydliga acceptanskriterier och inte överbelastar supporten. I Delphi‑landskap har ett förfarande i fem steg visat sig fungera väl.

Steg 1: Inventering med „driftsglasögon“

Fånga inte bara upp moduler, utan framför allt driftspunkter:

• Vilka enhetsklasser: bärbara, Rugged Devices, terminaler?
• Vilken perifer utrustning: skrivare, skannrar, kortläsare, etikettmaskiner?
• Vilka integrationer: Office, DMS, ERP, lokala tjänster, webbläsarkomponenter?
• Vilken installationsform: MSI, Setup‑EXE, ClickOnce, manuell distribution?

Denna vy visar snabbt om „bara en klient“ i verkligheten innebär fem systemberoenden.

Steg 2: Kompatibilitetskontroll med en representativ ARM64-pilot

Piloten bör inte vara „den finaste enheten“, utan en typisk kandidat från målflottan. Testa medvetet de kritiska vägarna: utskrift i alla varianter, export/import, signering, offline/online, uppdateringar, växling mellan klienter/tenanter, proxy-/VPN‑scenarier. Dokumentera avvikelser som driftincidenter, inte som utvecklarbuggar. Så förblir prioriteringen ren.

Steg 3: Minska beroenden – börja med de som har högst supportpåverkan

Typiska åtgärder som ger mycket i vardagen:

• Standardisera PDF-/utskriftsflödet: bort från proprietära skrivardll:er, mot stabila, testade pipeliner.
• Avkoppla Office-integrationen: istället för In-process-tillägg, överväg exportformat och serverside dokumentgenerering.
• Konsolidera databasåtkomst: en definierad drivrutinväg istället för „ODBC beroende på arbetsstation“.
• Kapsla hårdvaruanslutningar: om möjligt via externa processer/tjänster som kan uppdateras separat.

Steg 4: Modernisera distribution och uppdaterbarhet

ARM64 är en bra anledning att rensa upp installation och uppdateringar. För företag räknas här inte funktioner, utan Återställningsförmåga, Reproducerbarhet och Policy-efterlevnad. 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 med SmartScreen och EDR och är relevant för kontrollerade utrullningar.
• Konfigurationshantering: separation av programfiler och konfiguration, tydliga sökvägar, inga „gömda“ registerberoenden.
• 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‑byggen är meningsfulla när ni (a) har kontroll över beroenden och (b) planerar långsiktig vidareutveckling av applikationen. Typiskt lönar det sig för kärnclients som många användare nyttjar 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 medspelar.

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

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

Mer stabilitet genom serversidigt ansvar

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

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

För IT-beslutsfattare är det en verklig driftfördel: problem blir snabbare reproducerbara på serversidan, istället för att hänga kvar på „en särskild bärbar dator“.

REST-API som avkopplingslager

En REST-API är inte automatiskt „modern“, men den utgö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 innebär 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, stamdata-synkronisering) kan ta bort beroenden från klienten och därmed minska ARM64-risker.

Test och kvalitet: vad ni bör kontrollera annorlunda under ARM64

Många team testar desktopmjukvara huvudsakligen funktionellt. För ARM64 bör ni testa mer driftorienterat, eftersom felbilderna är annorlunda: inte „felaktig beräkning“, utan „komponenten laddas inte“, „drivrutin saknas“, „uppdatering misslyckas“, „Office-integrationen bryts“.

Checklista för ARM64-nära godkännande

• Install/Uninstall: rena installationer och avinstallationer, utan rester, utan administrativa tillfälliga lösningar.
• Updatepfad: uppgradering över flera versioner, rollback-scenario, signaturkontroll.
• Logging: centrala loggar, tydliga felkoder vid DLL-laddningsproblem, spårbara utskriftsflöden.
• Performance: starttid, dataoperationer, stora listor/rapporter – mät separat under emulering och nativt.
• Peripherie: skrivarprofiler, specialutskrifter, scannerarbetsflöden, smartkortsfunktioner.
• Sicherheit: EDR/AV-interaktion, proxy/TLS, certifikatlager, principen om minsta privilegier i drift.

Dokumentation är viktig: Om ett problem uppstår på grund av saknade ARM64-drivrutiner är det inte en „buggfix i Delphi“, utan ett anskaffnings- eller standardiseringsbeslut.

Drift och support: hur ni integrerar ARM64 i vardagen

I vardagen räknas hur snabbt supportfall löses. För ARM64 lönar det sig att proaktivt öka supportförmågan:

Standardiserade enhetsprofiler och tydliga godkännanden

Definiera stödda ARM64-modeller eller åtminstone miniminivåer (drivrutinstrategi, utskriftsstrategi, versioner av security-agenter). Ett „fungerar på ARM64“ utan denna ram leder till heterogena miljöer och därmed svårt reproducerbara störningar.

Diagnosförmåga i applikationen

Även utan utvecklarfokus är en tydlig kravbild mot mjukvaran lämplig: en systeminformationssida som visar arkitektur (x64 emulerat vs. ARM64 nativt), viktiga sökvägar, versioner av kärnkomponenter och utskriftskonfiguration minskar supporttiderna avsevärt. Det är ingen „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 licenshanteringen till nätverksbaserade eller serversidiga mekanismer. Då minskar beroendet av drivrutiner på slutpunkter och enhetsflottan blir mer utbytbar.

Vad innebär det för er Delphi-strategi?

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

Om ni redan idag är på en moderniseringsväg (t.ex. BDE-Ablösung, övergång till 64‑bit, starkare REST-integration, konsoliderad dataåtkomst med FireDAC), ä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 särskilda arbetsstationskonfigurationer, är ARM64 en rimlig anledning att göra dessa risker synliga och planerat 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, security och support. För Delphi-baserad affärsprogramvara avgörs framgång inte av en compiler-option, utan av kedjan av drivrutiner, DLL:er, COM-integrationer, dataåtkomst och uppdateringsprocesser. En robust väg är: först göra beroenden och driftvägar synliga, sedan testa med pilotenheter, därefter målmedvetet entkoppla och professionalisera distributionen – 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 säkra Delphi-applikationer, periferi och gränssnitt på ett planerat sätt, tala med oss om en strukturerad inventering och en realistisk migrationsväg:

I det tekniska sammanhanget spelar också Delphi ARM64 Windows och X64-emulering Windows 11 en viktig roll när integrationer, dataflöden och vidareutveckling måste fungera väl tillsammans.

Diskutera projekt eller moderniseringsprojekt med Net-Base.