Včas naplánovať Windows 11 ARM64 pre Delphi aplikácie

Windows 11 ARM64 už nie je v B2B-bežnej praxi len okrajovou záležitosťou pre technických nadšencov. Nové generácie notebookov, dlhšia výdrž batérie, „Always-on“-scenáre a rastúca požiadavka na ľahké, mobilné pracovné miesta vedú k tomu, že firmy nakupujú ARM64-klientov – niekedy cielene, inokedy vedľajšie v rámci štandardných modelov v rámcovej zmluve. Pre tímy so zrelým riešením s individuálnym softvérom je to jasné posolstvo: ARM64 musí byť včas v technickom plánovaní, inak sa neskôr premení na nákladný projekt dodatočných úprav.

Pri Delphi-aplikáciách je ústredná otázka zriedka „dokáže Delphi to skompilovať?“. V praxi zlyhávajú ARM64-rollouty takmer vždy na periférii: na natívnych DLL, tlačiarenských/scan-komponentách, databázových driveroch, reportovacích engine-och, COM-integráciách, inštalačných rutinách, code-signingu alebo v build-pipeline, ktoré potichu poznajú len x64. Práve preto sa oplatí považovať Windows 11 ARM64 za požiadavku architektúry a prevádzky – nie len za platformové „feature“.

Tento článok ukazuje, ktoré technické nástrahy sa pri Delphi typicky objavujú, ako systematicky identifikovať riziká a aké pragmatické migračné cesty sa osvedčili – od postupného pripravenia jednotlivých modulov až po jasnú cieľovú architektúru s servismi a REST-servermi.

Prečo je Windows 11 ARM64 teraz otázkou architektúry

V mnohých firmách znamenalo „Windows“ dlhú dobu v podstate x86/x64. Toto predpokladanie je v scriptoch, inštalátoroch, third-party komponentoch a niekedy dokonca v dátovom modeli (napr. cesty, registry-kľúče, rozhrania driverov). Hneď ako sa objavia ARM64-klienti, stáva sa viditeľným, koľko implicitných predpokladov je v systéme ukotvených. A práve to je ekonomické jadro: neskoré úpravy nie sú len „pár compiler-flagov“, ale upratovanie predpokladov, ktoré sa počas rokov stvrdli.

Prakticky je ARM64 relevantný najmä v troch situáciách:

• Klientský softvér s dlhým životným cyklom: Odborné aplikácie používané 8–15 rokov a iteratívne rozširované. Nová klientská platforma uprostred životného cyklu je pravdepodobnejšia než kompletné prebudovanie.
• Zmiešané flotily: Field service/servis, manažérske notebooky, scenáre blízke BYOD alebo dcérske spoločnosti, ktoré obstarávajú inú HW.
• Tlak na bezpečnosť a compliance: Moderný code-signing, hardening, princíp least privilege, kontrolované updatery – pri týchto zásahoch sa inštalačné a update procesy tak či tak menia. Práve vtedy sa ARM64 dá výhodne integrovať ako vedľajšia požiadavka.

Dobrá správa: Ten, kto už pracuje na Delphi Modernizácii, prechode na 64-bit, oddelení prístupu k dátam alebo na service-orientovanej cieľovej architektúre, môže často nechať Windows 11 ARM64 „ísť s nimi“ – pokiaľ je to včas zaradené v backlogu a nie až v momente, keď sa prvá ARM-strojňa objaví v supporte.

Delphi na ARM64: čo je „ľahké“, čo je „ťažké“?

Delphi projekty sa výrazne líšia: od čisto VCL desktop klientov až po viacvrstvové systémy s REST-servermi, Windows servicami, report-worker-mi, integračnými komponentmi a background jobmi. Pre Windows 11 ARM64 je rozhodujúce, ktoré časti musia skutočne natívne bežať na klienskom zariadení a ktoré je rozumnejšie už tak či tak presunúť do servisov.

Kompatibilita kompilátora zriedka predstavuje hlavný problém

Ak je vlastný kód čistý (žiadny inline-assembler, žiadne staré 32-bit predpoklady, žiadne krehké pointer-casty, žiadne zastarané API volania), kompilácia pre novú cieľovú platformu je často uskutočniteľná. Problémy vznikajú cez:

• Third-party komponenty s natívnymi časťami (DLLs, BPLs, C/C++ mosty)
• Drivery a pripojenie zariadení (tlač, scan, signatúrne pady, dongly)
• Prístup k databáze cez ODBC/OLE DB/klientské knižnice, ktoré nie sú ARM64-compatibilné
• Reporting a Office-integrácia (COM-automácia, staré export-filtre)
• Inštalátory/Updatery, ktoré testujú len x64 alebo používajú natvrdo zakódované cesty

Takže Windows 11 ARM64 je najmä „ekosystémový test“: Ako dobre je váš softvérový balík od viazanosti na staré platformné predpoklady odpojený?

VCL, FMX a UI-závislosti

Mnohé B2B odborové aplikácie sú založené na VCL a používajú dlhodobo rastúce UI-komponenty. To samo o sebe nie je problém – ale UI je často miesto, kde sa závislosti sústreďujú: PDF-tlačiarne, barcode generátory, knižnice pre obrázky, browser-controllery, COM-objekty. Pre ARM64 platí: čím viac UI-blízkych špecializovaných komponentov používate, tým skoršie je potrebné mať kompatibilitný zoznam.

Pri multiplatformných stratégiách (napr. Windows + macOS) sa často objavuje FMX. Nezávisle od frameworku je robustná stratégia oddeliť aplikačnú logiku a integrácie od UI. To prispieva rovnako k Delphi Multiplatforme ako k Windows 11 ARM64.

Typické technické návleky (a ako ich skoro odhaliť)

V praxi sa väčšina ARM64-problémov dá odhaliť včas, ak inventarizujete systematicky a vykonáte „ARM64 Readiness“-check. Kľúčové je nepozerať sa len na Delphi-kód, ale na všetko, čo k produktu patrí: inštalátory, drivery, konfigurácie, pluginy, nástroje tretích strán, update-kaskádu, support-skripty.

1) Natívne DLL, BPL a zmiešané procesné krajiny

Mnohé Delphi-aplikácie načítavajú dodatočné DLL: kryptografiu, CAD-viewer, OCR, signatúry, hardware-SDK, špeciálne parsery. Na x64 sa často ticho predpokladá, že „existuje 64-bit DLL“. Pre ARM64 to neplatí: potrebujete explicitne ARM64 binárky alebo architektúru, ktorá túto závislosť z klienta odstráni.

Praktický postup:

• Vytvorte zoznam všetkých načítaných natívnych modulov (aj nepriamo cez komponenty).
• Klasifikujte: „ARM64 dostupné“, „x64-only“, „32-bit-only“, „nejasné“.
• Zhodnoťte, či modul naozaj musí byť lokálny alebo môže byť presunutý do servisu.

Častý zistenie: jediný x64-only modul blokuje celý ARM64-klient. To je moment, kedy sa ekonomicky oplatí čistá vrstvená alebo Layer-3 Architektúra: UI/klient zostane ľahký, integrácie sa presúvajú do kontrolovaných server-/service vrstiev.

2) COM, Office-Automation a Shell-integrácie

V mnohých firmách sa export do Word/Excel, integrácia s Outlookom, kontextové menu Explorera alebo DMS-integrácie vyvinuli historicky cez COM. COM nie je automaticky „ARM64-ready“, obzvlášť keď third-party COM-servery alebo add-iny dodávajú len x64. Prevádzka 32-bit/64-bit mixov (Out-of-Proc vs. In-Proc) sa rýchlo stáva zložitá.

Skoré zistenie:

• Ktoré COM-objekty sa používajú (zoznam ProgIDs/CLSID)?
• In-Proc alebo Out-of-Proc? Existujú ARM64 registrácie?
• Dá sa export riešiť serverovými knižnicami (napr. dokumentovo orientované formáty) namiesto Office-Automation?

Často je to páka modernizácie: od UI-spútanej automatizácie k reprodukovateľným export-servisom (napr. PDF/Excel cez knižnicu), ktoré sú použiteľné pre Windows x64 aj pre ARM64 alebo dokonca pre Linux-servery.

3) Prístup k databáze: ODBC, klientské knižnice, legacy-BDE

Prístup k dátam je častou ARM64-skrinou, pretože tu zohrávajú úlohu driverové krajiny a klientské knižnice. Obzvlášť kritické sú staré ODBC-setupy, proprietárne databázové klienty alebo lokálne databázy s historickými vrstvami prístupu.

Pre Delphi-stacky je to klasika: ak sú v hre ešte Borland BDE, staré Paradox-štruktúry alebo ťažko udržiavateľné driver-reťazce, ARM64 sa stane katalyzátorom. BDE-ablácia a prechod na BDE-Ablösung s natívnym napojením s jasnou DB-driver stratégiou výrazne znižuje platformové riziká.

Konkrétne kontrolné body:

• Ktoré DB sa používajú (SQL Server, PostgreSQL, MariaDB, Firebird, lokálne enginy)?
• Aké drivere sa používajú (ODBC, natívny klient, BDE-Ablosung mit nativer Anbindung-driver, OLE DB)?
• Kde sú umiestnené connection-stringy a DSN (pre používateľa, pre stroj, v inštalátore)?
• Existujú závislosti na 32-bit ODBC driveroch alebo starých provideroch?

Práve pri SQL Server/ODBC môže ARM64-klient fungovať – ale len ak je driverová reťaz a inštalačná rutina korektná. To nie je niečo, čo chcete „debugovať“ priamo v teréne.

4) Reporting, tlač, scan, PDF a output-workflowy

Output v odborných aplikáciách je často kľúčový pre biznis: dodacie listy, etikety, faktúry, protokoly, odpočty, certifikáty, štítky na expedíciu. Mnohé z týchto workflowov sú viazané na reportovacie komponenty alebo špecifické tlačiarenské/scan driver-y.

Na Windows 11 ARM64 sú nástrahy typicky:

• Driveri pre etikety/špecializované tlačiarne dostupní len ako x64
• Scanner-softvér/SDK bez ARM64-supportu
• Staré report-enginy s natívnymi preview-/export modulmi
• Generovanie PDF cez „virtuálne tlačiarne“ namiesto knižnice

Robustný prístup je štandardizovať output-workflowy: generovať PDF/Office-formáty cez knižnice, tlač cez štandardizované rozhrania, špecializované HW-prístupy dôkladne kapsulovať. Kde to nie je možné, treba včas zostaviť zariadenia-/driver-matrix pre ARM64.

5) Inštalátory, Updaty, Code-Signing a prevádzka

Mnohé ARM64-projekty nezlyhávajú na programe, ale na dodávke: setup nesprávne rozpozná architektúru, neinštaluje drivery, neregistruje COM, nastaví nesprávne cesty alebo zlyhá kvôli pravidlám code-signingu. Aj automatické updaty (delta-updates, self-updater) sú často silne závislé na architektúre.

Dôležité otázky pre prevádzku:

• Ako sa inštaluje (MSI, Inno Setup, vlastný updater)?
• Ako sa inštalujú závislosti (VC++ runtimes, drivery, certifikáty)?
• Ako sa signuje (EXE, DLL, inštalátor, driver-pakety)?
• Ako sa testuje: na reálnom ARM64-hardvéri alebo len domnienky?

Pre firmy je to governance-otázka: ak sa Windows 11 ARM64 objaví v klientskej flotile, musí byť deployment reprodukovateľný – vrátane rollbacku, supportability a jasnej verziovacej politiky.

Stratégia: Windows 11 ARM64 ako „včasná nefunkčná požiadavka“

Ekonomicky rozumný prístup je zaobchádzať s ARM64 ako s nefunkčnou požiadavkou (NFA) – podobne ako výkon, bezpečnosť alebo offline schopnosti. To znamená: nie až v sprints „keď to začne horieť“, ale ako definovaná smernica pre architektúru a dodávateľský reťazec.

ARM64-Readiness-Check: Inventár namiesto pocitu

Rýchly, spoľahlivý check typicky obsahuje:

• Inventár závislostí: všetky third-party komponenty, DLLs, drivery, SDK, browser-control-y, kryptomoduly, reporting.
• Analýzu build/pipeline: build-targety, paketizácia, signovanie, ukladanie artefaktov, verzovanie, reprodukovateľnosť.
• Inštalačnú/update-kaskádu: logika setupu, prerequisites, registry/filesystem-cesty, politiky, práva.
• Prevádzkový model: support, logging, crash-dumpy, telemetria (ak existuje), rollout-plán.

Výsledkom by nemalo byť len „ARM64: áno/nie“, ale priorizovaný zoznam: ktoré blokátory existujú, ktoré moduly sú postihnuté, aké sú alternatívy a aká investícia je reálna.

Rozhodovacia matica: natívne na ARM64 alebo oddeliť?

Pri každej problematickej závislosti je potrebné jasné rozhodnutie:

• ARM64-natívna náhrada možná: upgrade, zmena výrobcu, prechod na inú knižnicu.
• Závislosť sa dá presunúť: napr. do Windows servisu, background-workera alebo centralizovaného REST-servera.
• Závislosť musí zostať lokálna: napr. keď je HW priamo pripojený k klientovi. Potom sú potrebné záväzné ARM64-hardware/driver schválenia.

Pri integráciách je často najčistejším riešením presun: klient zostane UI + fachdialogy, zatiaľ čo komplexná integračná logika beží v kontrolovaných servisoch. To podporuje okrem ARM64 aj centrálne updaty, koncepty práv a lepšiu testovateľnosť.

Architektonické patterny, ktoré ARM64-projekty stabilizujú

Keď je Windows 11 ARM64 včas naplánovaný, dá sa urobiť viacero architektonických rozhodnutí tak, aby neskoršie nebolo treba draho prepisovať.

1) Jasné vrstvy: UI, aplikačná logika, integrácia, dátový prístup

Zrelé Delphi-klienty majú často „všetko v jednom procese“: UI, biznis-pravidlá, dátový prístup, DMS-pripojenie, tlač a export. To je udržiavateľné, pokiaľ platforma zostáva stabilná. Akonáhle sú však relevantné platformové varianty (ARM64, prípadne macOS, prípadne Terminal server), hodnota jasného vrstvenia rastie.

Pragmatický cieľ:

• UI-vrstva: minimálna, testovateľná, bez priamej závislosti na driveroch/SDK.
• Aplikačná logika: čo najplatformovo neutrálna, čisto modelovaná.
• Integrácia: kapsuluje COM, formáty súborov, DMS/ERP konektory, device-SDKs.
• Dátový prístup: konsolidovaný (napr. FireDAC), jasné transakčné hranice, bez roztiahnutých SQL-fragmentov.

To nie je „akademické“, ale reálne šetrí náklady: ak je len integračná vrstva ARM64-problémová, netreba prepisovať celý klient.

2) Servisy a REST-servery ako kotevná stabilita

Mnohé B2B-systémy profitujú z prevádzky centrálnych funkcií ako REST-server alebo ako Windows-/Linux-servisy: kontrola práv, dokumentové workflowy, validácia dát, export, import, rozhrania na ERP/DMS/CRM. Keď tieto funkcie bežia server-side, zložitosť na klientovi sa výrazne znižuje – a s ňou aj ARM64-povrch zraniteľný na problémy.

Typické rozdelenia, ktoré sa osvedčili:

• Klient: dialógy, zobrazenie, offline logika (ak treba), minimálne lokálne integrácie.
• REST-server: fachové operácie, validácia, multitenancy, centrálne protokolovanie.
• Worker/Service: časovo riadené joby, polling rozhraní, generovanie reportov, batch exporty.

To korešponduje s modernými prevádzkovými modelmi: funkciu, ktorá beží server-side, aktualizujete raz – namiesto toho, aby ste ju aktualizovali na každom ARM64-klientovi zvlášť.

3) Jeden build-systém, viacero targetov (x64 + ARM64) od začiatku

Ak je ARM64 cieľom, mala by to reflected aj build-pipeline. Nie ako „urobíme neskôr špeciálny build“, ale ako štandard: každý release-candidate sa reprodukovateľne zostaví pre x64 (a ak je plánované, aj pre ARM64), vrátane signovania a balenia inštalátora.

Dôležitejšia než toolchain je dôslednosť:

• Artefakty jasne pomenovať (architektúra v názve balíka/mape).
• Konfiguračné hodnoty pre jednotlivé targety oddeliť (cesty, prerequisites, driver-pakety).
• Definovať smoke-testy pre každú architektúru (štart, login, DB-pripojenie, tlač/PDF).

Tak ARM64 nebude „Big Bang“, ale kontrolovaný ďalší target.

Delphi-modernizácia: ARM64 ako príležitosť cielene znížiť technický dlh

Mnohé firmy používajú nové platformové požiadavky ako výhovorku pre „všetko nanovo“. To je rizikové a často zbytočné. Výhodnejšie je využiť Windows 11 ARM64 ako smernicu pre postupnú modernizáciu: odstraňovať technický dlh tam, kde blokuje ARM64 alebo ohrozuje dodávateľskú schopnosť.

64-bit a Unicode: nerobiť zo starých problémov nove

Ak v kódbáze stále pretrvávajú 32-bit predpoklady alebo dedičné záťaže zo starých verzií Delphi, pri platformovej zmene sa znovu prejavia. Hoci ARM64 sám o sebe neznamená „Unicode“, mnohé projekty, ktoré ARM64 vážne riešia, pri tom súčasne zabezpečia čistý Unicode, etablovanie 64-bit ciest a odstránenie problémov so správou pamäte/pointerov.

Cieľ nie je dokonalosť, ale spoľahlivý štandard: kód, ktorý sa dá zostaviť pre nové targety bez opakovaného riešenia rovnakých typov chýb.

BDE-ablácia a konsolidovaný prístup k dátam ako enabler pre ARM64

Kde ešte existujú historické prístupové vrstvy (BDE, lokálne Paradox-dáta, zmiešané zdroje), je konsolidácia pákou s viacerými prínosmi: udržiavateľnejší kód, stabilnejšie deploye, jasnejšia driver-stratégia. S FireDAC sa v mnohých scenároch dá prístup zjednotiť, vrátane centrálneho manažmentu parametrov, pooling-stratégií a korektného spracovania chýb.

Dôležité: BDE-ablácia nie je len „vymeniť komponent“. Dotýka sa transakčnej logiky, typov dát, triedenia, semantiky filtrov a čiastočne aj dátového modelu. Preto by mala byť plánovaná – nie riešená ad hoc, keď sa ARM64-klienti objavia náhle v teréne.

Testovanie a QA: ARM64 je plánovateľný len keď ho viete merať

Včasné plánovanie ARM64 znamená aj to, že sa musí testovať – nie kompletné testovanie každej funkcie, ale cielené testovanie rizikových ciest. Najdôležitejší krok je mať reálne ARM64 testovacie prostredie. Emulácia v niektorých prípadoch pomôže, no nenahradí skúsenosť s reálnym hardvérom, skutočnými drivery a reálnymi bezpečnostnými politikami.

Minimálny ARM64-smoke-test: čo treba pokryť ako prvé

Pragmatická, no účinná sada smoke-testov pre každý release-candidate:

• Štart programu, login, základné UI-funkcie
• DB-pripojenie (vrátane autentifikácie, certifikátov, DNS/Proxy, ak relevantné)
• Jeden kľúčový proces „end-to-end“ (napr. vytvoriť objednávku, uložiť, vytlačiť/exportovať)
• Updater/Inštalátor: čistá inštalácia a update cez jednu verziu
• Logging/error-dialógy: sú diagnostiky na ARM64 použiteľné?

Tak sa typické ARM64-blokátory ukážu skoro: chýbajúce DLL, nesprávne drivery, inštalačné problémy, neočakávané požiadavky na práva.

Diagnostická schopnosť: crash-dumpy, logy, verziová transparentnosť

Keď je ARM64 v flotile, budú pribúdať support-cases – aj len kvôli novým kombináciám driverov. Preto sa oplatí štandardizovať diagnostiku: jednoznačné build-ID, výpovedné logy, reprodukovateľné inštalačné a update cesty. To nie je špecifické len pre ARM64, ale ARM64 rýchlejšie odhalí nedostatky, ktoré sú potom drahé.

Rollout a prevádzka: zmiešané flotily bez chaosu

Väčšina firiem bude strednodobo prevádzkovať zmiešané klienské flotily: časť x64, časť ARM64. Kľúčom je tento stav vedome riadiť.

Paketizácia: oddelené inštalátory, jasné rozpoznanie, jednoznačné cesty na stiahnutie

V praxi funguje najlepšie, keď sú inštalátory/packety jednoznačné: x64-paket je x64, ARM64-paket je ARM64. „Jeden inštalátor pre všetko“ môže znieť pohodlne, ale rýchlo sa stáva zložitým (overovacia logika, prerequisites, cesty k driverom, signovanie, reparácia inštalácie). Pre kontrolované podnikové roll-outy je jednoznačnosť často robustnejšia cesta.

Update-stratégia: žiadne špeciálne cesty pre ARM64

ARM64 by nemal byť v update procese výnimkou. Cieľom je: rovnaká frekvencia release-ov, rovnaké fach-verzovanie, ale oddelené artefakty. Ak sa ARM64 aktualizuje len „manuálne“, vznikajú v flotile divergencie, ktoré neskôr navýšia náklady na support.

Integrácie dôkladne dokumentovať

Mnohé ARM64-problémy nie sú v vlastnom kóde, ale v integráciách: ERP-connector, DMS-client, signatúrne služby, scanner-softvér, etiketa-tlačiarne. Udržiavaný zoznam integrácií s verziami a architektonickými poznámkami je pre B2B-systémy bežný benefit – a robí ARM64-rozhodnutia transparentnými.

Čo by mali firmy teraz konkrétne robiť (bez akcionizmu)

Včasné plánovanie Windows 11 ARM64 neznamená okamžité prepisovanie všetkého. Znamená to včas zodpovedať správne otázky a odstrániť blokátory, kým je námaha plánovateľná. Overený postup je:

• 1) Inventúra (2–10 dní podľa veľkosti systému): závislosti, inštalátory, drivery, prístup k dátam, COM, reporting.
• 2) Cieľový obraz a cesta: Čo musí bežať natívne na kliensovi? Čo bude service/REST? Ktoré komponenty sa nahradia?
• 3) Proof of Feasibility: bežiaci ARM64-build s inštalátorom a end-to-end use-case.
• 4) Postupné zosilňovanie: zostávajúce funkcie, testy, update-kaskáda, diagnostická schopnosť.

Tým nevznikne „ARM64-projekt“, ktorý beží mesiace izolovane, ale kontrolované rozšírenie dodávateľskej schopnosti.

Záver: Windows 11 ARM64 nie je módny kurz, ale skorý indikátor technickej zrelosti

Windows 11 ARM64 sa pre mnohé firmy stane realitou – cez hardware-obstarávanie, mobilitné požiadavky alebo štandardizáciu. Pre Delphi-aplikácie nie je hlavnou výzvou len zdrojový kód, ale celý systém závislostí, inštalačných a update procesov, integrácií a driverov. Kto plánuje ARM64 včas, môže tieto body systematicky riešiť namiesto toho, aby ich neskôr pod časovým tlakom „zašiel“.

Na konci je ARM64 užitočným testom: ako dobre je vaša aplikácia odpojená, testovateľná a dodávateľná? Ak túto otázku zodpoviete teraz, získate nielen ďalšie platformové možnosti, ale aj stabilnejší základ pre modernizáciu, servisy, REST-architektúry a dlhodobú udržateľnosť.

Kontaktieren Sie Net-Base Software GmbH, wenn Sie Windows 11 ARM64 in Ihrer Delphi-Roadmap belastbar bewerten und mit einem klaren technischen Pfad umsetzen möchten.