Windows 11 ARM64 pro Delphi-aplikace včas naplánovat

Windows 11 ARM64 už v B2B-provozu není jen okrajová záležitost pro technické nadšence. Nové generace notebooků, delší výdrž baterie, scénáře „always-on“ a rostoucí poptávka po lehkých mobilních pracovištích vedou firmy k nákupu ARM64-klientů – někdy záměrně, někdy jako vedlejší efekt standardních modelů v rámcové smlouvě. Pro týmy s rostoucím objemem vlastní obchodní softwaru je to jasné sdělení: ARM64 musí být zahrnut do technického plánování brzy, jinak z toho bude pozdě drahý doplňkový projekt.

U Delphi-aplikací není ústřední otázka obvykle „dokáže Delphi to zkompilovat?“. V praxi selhávají ARM64-rollouty téměř vždy na periferii: nativní DLL, tiskové/skanovací komponenty, databázové ovladače, reportovací enginy, COM-integrace, instalační rutiny, podepisování kódu nebo build-pipeline, které implicitně znají jen x64. Právě proto se vyplatí brát Windows 11 ARM64 jako požadavek architektury a provozu – ne jako čistě platformní feature.

Tento příspěvek ukazuje, jaké technické nástrahy se u Delphi typicky objevují, jak rizika systematicky identifikovat a které pragmatické migrační cesty se osvědčily – od postupné přípravy jednotlivých modulů až po jasnou cílovou architekturu se službami a REST-servery.

Proč je Windows 11 ARM64 nyní téma architektury

V mnoha firmách byla dlouho „Windows“ synonymem pro x86/x64. Toto předpokládání se ukrývá ve skriptech, instalátorech, third‑party komponentách a někdy i v datovém modelu (např. cesty, registry klíče, rozhraní ovladačů). Jakmile se objeví ARM64‑klienti, vyjde najevo, kolik implicitních znalostí je v systému uloženo. A přesně to je ekonomické jádro: pozdní úpravy nejsou jen „několik kompilátorových přepínačů“, ale úklid předpokladů, které se během let zpevnily.

Prakticky se ARM64 stává relevantním zejména ve třech situacích:

• Klientský software s dlouhou životností: oborové aplikace, které se používají 8–15 let a iterativně rozšiřují. Nová klientská platforma uprostřed životního cyklu je pravděpodobnější než úplné přepsání.
• Smíšené flotily: obchodní/servisní pracovníci, manažerské notebooky, BYOD‑scénáře nebo pobočky, které pořizují jiný hardware.
• Tlak na bezpečnost a compliance: moderní code‑signing, hardening, „least privilege“, řízené updatery – při těchto aktivitách se instalační a aktualizační procesy stejně upravují. Právě tehdy se ARM64 dá výhodně integrovat jako vedlejší požadavek.

Dobrá zpráva: Kdo už pracuje na Delphi Modernizaci, přechodu na 64‑bit, oddělení přístupu k datům nebo na service‑orientované cílové architektuře, může často Windows 11 ARM64 „včlenit“ – pokud je to včas zařazeno do backlogu a nečeká se, až přijde první ARM‑stroj do supportu.

Delphi na ARM64: co je „easy“ a co „hard“?

Delphi‑projekty se výrazně liší: od čistých VCL desktop klientů až po vícevrtvové systémy s REST‑servery, Windows službami, report‑workery, integračními komponentami a background joby. Pro Windows 11 ARM64 je rozhodující, které části skutečně musí běžet nativně na klientu a které je rozumné přesunout do služeb.

Compiler je zřídka hlavní problém

Pokud je vlastní kód čistý (žádný inline assembler, žádné zastaralé 32bitové předpoklady, žádné křehké pointer‑casty, žádné zastaralé API volání), je kompilace pro novou cílovou platformu často proveditelná. Problémy vznikají kvůli:

• Third‑party komponentám s nativními částmi (DLL, BPL, C/C++ mosty)
• Ovladačům a připojení zařízení (tisk, skenování, podpisová zařízení, dongly)
• Přístupu k databázi přes ODBC/OLE DB/klientské knihovny, které nejsou ARM64‑schopné
• Reportingu a Office‑integraci (COM‑automation, staré exportní filtry)
• Installeru/Updateru, které testují jen x64 nebo používají natvrdo zakódované cesty

Tím je Windows 11 ARM64 především „ekosystémový test“: jak dobře je váš software od starých platformních předpokladů odpojen?

VCL, FMX a závislosti UI

Mnoho B2B oborových aplikací je založeno na VCL a používá roky akumulované UI komponenty. To samo o sobě není problém – ale UI je často místo, kde se závislosti kumulují: PDF tiskárny, generátory čárových kódů, obrazové knihovny, browser‑control, COM‑objekty. Pro ARM64 platí: čím více specializovaných komponent blízkých UI používáte, tím důležitější je včasný seznam kompatibility.

U multiplatformních strategií (např. Windows + macOS) často přichází do hry FMX. Bez ohledu na framework je robustní strategií oddělit obchodní logiku a integrace od UI. To přispívá jak k Delphi Multiplatformě, tak k Windows 11 ARM64.

Typické technické nástrahy (a jak je včas rozpoznat)

V praxi lze většinu ARM64 problémů odhalit včas, pokud provedete strukturovanou inventuru a „ARM64 Readiness“ kontrolu. Důležité je neohlížet se jen na Delphi‑kód, ale na vše, co k produktu patří: instalátory, ovladače, konfigurace, pluginy, nástroje třetích stran, update řetězec, support skripty.

1) Nativní DLL, BPL a smíšené procesní krajiny

Mnoho Delphi aplikací načítá dodatečné DLL: kryptografii, CAD‑viewer, OCR, podpisy, hardware‑SDK, specializované parsery. Na x64 se často implicitně předpokládá, že „existuje 64bitová DLL“. U ARM64 je to jiné: potřebujete explicitně ARM64 binárky nebo architekturu, která tuto závislost odstraní z klienta.

Praxe:

• Sestavte seznam všech načítaných nativních modulů (i nepřímo přes komponenty).
• Klasifikujte: „ARM64 dostupné“, „pouze x64“, „pouze 32‑bit“, „nejasné“.
• Zhodnoťte, zda modul opravdu musí být lokální, nebo může být přesunut do služby.

Častý nález: jeden x64‑only modul blokuje celý ARM64 klient. To je okamžik, kdy se ekonomicky vyplatí čisté vrstevné nebo Layer-3 architektonické rozdělení: UI/klient zůstane lehký, integrace se přesunou do řízených serverových/službových vrstev.

2) COM, Office‑Automation a Shell‑integrace

V mnoha firmách jsou export do Word/Excel, připojení Outlooku, kontextová menu v Exploreru nebo DMS‑integrace historicky řešeny přes COM. COM není automaticky „ARM64‑ready“, obzvlášť když COM servery třetích stran nebo add‑iny dodávají jen x64 verze. Provoz 32‑/64‑bitových mixů (out‑of‑proc vs. in‑proc) rychle komplikuje situaci.

Včasné otázky:

• Které COM objekty se používají (seznam ProgIDs/CLSIDs)?
• In‑Proc nebo Out‑of‑Proc? Existují ARM64 registrace?
• Lze export vyřešit serverovými knihovnami (např. generování dokumentů) místo Office‑automation?

Často je to páka modernizace: posun od UI‑vázané automatizace směrem k reprodukovatelným export‑servisům (např. PDF/Excel přes knihovnu), které lze nasadit jak pro Windows x64, tak pro ARM64 nebo dokonce Linux‑servery.

3) Přístup k databázi: ODBC, klientské knihovny, legacy BDE

Přístup k datům je častým místem, kde se objevují ARM64 problémy, protože zde hrají roli ovladačská prostředí a klientské knihovny. Obzvlášť kritické jsou staré ODBC konfigurace, proprietární databázoví klienti nebo lokální databáze s historickými přístupovými vrstvami.

Pro Delphi stacky je to klasika: pokud jsou stále v provozu Borland BDE, staré Paradox struktury nebo obtížně udržovatelné řetězce ovladačů, stane se z ARM64 katalyzátor. Silné snížení rizika platformy přinese BDE‑Ablösung a přechod na BDE‑Ablösung mit nativer Anbindung s jasnou DB‑ovladačovou strategií.

Konkrétní kontrolní body:

• Které DB se používají (SQL Server, PostgreSQL, MariaDB, Firebird, lokální enginy)?
• Které ovladače se využívají (ODBC, native client, BDE-Ablosung mit nativer Anbindung‑ovladač, OLE DB)?
• Kde jsou connection‑stringy a DSN (per user, per machine, v instalátoru)?
• Existují závislosti na 32‑bitových ODBC‑ovladačích nebo starých providerech?

U SQL Serveru/ODBC může ARM64‑klient fungovat – ale jen pokud je ovladačová cesta a instalační rutina dobře provedená. To není něco, co byste chtěli „ladit v terénu“.

4) Reporting, tisk, skenování, PDF a output‑workflows

Výstupy jsou v oborových aplikacích často kritické: dodací listy, štítky, faktury, protokoly, údaje z měřidel, certifikáty, přepravní štítky. Mnoho těchto workflow závisí na reportovacích komponentech nebo specifických tiskárenských/ skenerových ovladačích.

Na Windows 11 ARM64 jsou typické nástrahy:

• Ovladače pro tiskárny/štítkové tiskárny dostupné jen v x64
• Skenovací software/SDK bez ARM64 podpory
• Staré reportovací enginy s nativními preview/export moduly
• Generování PDF přes „virtuální tiskárny“ místo knihovny

Robustní přístup je standardizovat output‑workflows: generovat PDF/Office formáty přes knihovny, tisk přes standardizovaná rozhraní, speciální přístupy k hardware co nejvíce kapslovat. Kde to nelze, je potřeba včas vytvořit matrici zařízení/ovladačů pro ARM64.

5) Installer, Updater, Code‑Signing a provoz

Mnoho ARM64 projektů neselže na aplikaci, ale na způsobu doručení: setup detekuje architekturu chybně, nenainstaluje ovladače, neregistruje COM, nastaví nesprávné cesty nebo narazí na pravidla pro podepisování kódu. Automatické updatery (delta‑updaty, self‑updater) jsou často silně závislé na architektuře.

Důležité provozní otázky:

• Jak se instaluje (MSI, Inno Setup, vlastní updater)?
• Jak se instalují závislosti (VC++ runtimes, ovladače, certifikáty)?
• Co a jak se podepisuje (EXE, DLL, installer, driver balíčky)?
• Jak se testuje: na reálném ARM64 hardwaru nebo jen hypoteticky?

Pro firmy je to governance záležitost: pokud se ARM64 objeví ve flotě, musí být deployment reprodukovatelný – včetně rollbacku, supportability a jasného verzování.

Strategie: Windows 11 ARM64 jako „časný nefunkční požadavek“

Ekonomicky rozumný přístup je považovat ARM64 za nefunkční požadavek (NFA) – podobně jako výkon, bezpečnost nebo offline schopnosti. To znamená: nečekat na „krizový sprint“, ale definovat to jako vodítko pro architekturu a dodavatelský řetězec.

ARM64‑Readiness‑Check: inventura místo pocitu

Spolehlivá kontrola obvykle zahrnuje:

• Inventář závislostí: všechny third‑party komponenty, DLL, ovladače, SDK, browser‑kontroly, kryptomoduly, reporting.
• Analýzu build/pipeline: build targety, balení, podepisování, úložiště artefaktů, číslování verzí, reprodukovatelnost.
• Řetězec installer/update: logika setupu, prerequisities, registry/cestní politiky, práva.
• Provozní model: support, logování, crash‑dumpy, telemetrie (pokud existuje), plán rolloutu.

Výsledek by neměl být „ARM64: ano/ne“, ale prioritní seznam: jaké blokátory existují, které moduly jsou zasaženy, jaké alternativy jsou k dispozici a jaká investice je realistická.

Rozhodovací matice: nativně na ARM64 nebo oddělit?

U každé problematické závislosti je potřeba jasné rozhodnutí:

• Možný ARM64‑nativní náhradník: upgrade, změna dodavatele, přechod na jinou knihovnu.
• Závislost lze přesunout: např. do Windows služby, background workera nebo centrálního REST‑serveru.
• Závislost musí zůstat lokální: např. protože je hardware přímo připojen k klientu. Pak jsou nutné závazné ARM64 hardwarové/ovladačové schválení.

Pro integrace je často nejčistší cesta přesun: klient zůstane UI + uživatelské dialogy, zatímco komplexní integrační logika běží v řízených službách. To vedle ARM64 rovněž podporuje centrální aktualizace, modely práv a lepší testovatelnost.

Architektonické vzory, které ARM64 projekty stabilizují

Pokud je Windows 11 ARM64 plánováno včas, lze učinit několik architektonických rozhodnutí tak, aby je později nebylo třeba nákladně měnit.

1) Jasné vrstvy: UI, obchodní logika, integrace, přístup k datům

Rostoucí Delphi klienti často obsahují „vše v jednom procesu“: UI, business pravidla, přístup k datům, DMS integraci, tisk a export. To je udržitelné, dokud platforma zůstává jednotná. Jakmile se ale objeví platformní varianty (ARM64, případně macOS, případně terminálové servery), roste hodnota jasného vrstvení.

Pragmatický cíl:

• UI vrstva: co nejmenší, testovatelná, bez přímých ovladačových/SDK závislostí.
• Obchodní logika: co nejplatformně neutrálnější, čistě modelovaná.
• Integrationschicht: kapsluje COM, formáty souborů, DMS/ERP konektory, device SDK.
• Přístup k datům: konsolidovaný (např. FireDAC), jasné transakční hranice, žádné rozházené SQL fragmenty.

To není akademická teorie, ale úspora reálných nákladů: pokud je problém jen v integrační vrstvě, nemusí se celý klient přestavovat.

2) Služby a REST‑servery jako kotevní body stability

Mnoho B2B systémů má přínos v tom, že centrální funkce běží jako REST‑servery nebo jako Windows/ Linux‑services: autorizace, workflow dokumentů, validace dat, export, import, integrace s ERP/DMS/CRM. Pokud tyto funkce běží serverově, zjednodušuje se klient a snižuje se tím i ARM64 povrch rizik.

Osvědčené dělení:

• Klient: dialogy, zobrazení, offline logika (pokud nutné), minimální lokální integrace.
• REST‑server: obchodní operace, validace, multi‑tenant režimy, centrální protokolování.
• Worker/Service: periodické úlohy, polling rozhraní, generování reportů, batch exporty.

To také ladí s moderními provozními modely: funkci, která běží serverově, stačí aktualizovat jednou – místo aktualizace na každém ARM64 klientu zvlášť.

3) Build systém, více targetů (x64 + ARM64) od začátku

Pokud je ARM64 cílem, měla by to odrážet build‑pipeline. Ne jako „uděláme později speciální build“, ale jako standard: každý release kandidát se reprodukovatelně staví pro x64 (a pokud je plánováno, i pro ARM64), včetně podepisování a balení instalačních balíčků.

Důležitější než konkrétní nástroje je konzistence:

• Jasné pojmenování artefaktů (architektura v názvu balíčku/adresáře).
• Oddělené konfigurační hodnoty pro každý target (cesty, prerequisities, balíčky ovladačů).
• Definované smoke‑testy pro každou architekturu (start, login, DB připojení, tisk/PDF).

Tím se ARM64 nestane „velkým třeskem“, ale kontrolovaným dalším targetem.

Delphi‑modernizace: ARM64 jako příležitost cíleně odbourat technický dluh

Mnoho firem využívá nové platformní požadavky jako argument pro „všechno znovu“. To je rizikové a často zbytečné. Výhodnější je použít Windows 11 ARM64 jako pravidlo pro postupnou modernizaci: odstranit technický dluh tam, kde blokuje ARM64 nebo ohrožuje schopnost dodávek.

64‑bit a Unicode: neodkládejte staré otevřené problémy

Pokud v kódu stále přetrvávají 32bitové předpoklady nebo dědictví z raných verzí Delphi, projeví se při změně platformy. I když ARM64 neznamená automaticky „Unicode“, mnoho projektů, které se seriózně zabývají ARM64, při tom zároveň řeší Unicode, etablování 64‑bitových cest a úklid problémů s pamětí/pointery.

Cíl není dokonalost, ale spolehlivý standard: kód, který lze sestavit pro nové targety, aniž by se opakovaně vracely stejné třídy chyb.

BDE‑Ablösung a konsolidovaný přístup k datům jako enabler pro ARM64

Kde existují historické přístupové vrstvy (BDE, lokální Paradox data, smíšené přístupy), je konsolidace pákou s vícenásobným efektem: udržitelnější kód, stabilnější nasazení, jasnější strategie ovladačů. S FireDAC lze přístup v mnoha scénářích sjednotit, včetně centrální správy parametrů, pooling strategií a čistého ošetření chyb.

Důležité: BDE‑Ablösung není jen „výměna komponent“. Dotýká se transakční logiky, datových typů, řazení, filtrační sémantiky a částečně i datového modelu. Proto by měla být plánovaná – ne havarijní opatření, když se ARM64‑klienti náhle objeví v poli.

Testování a QA: ARM64 je plánovatelný jen pokud je měřitelný

ARM64 včas naplánovat znamená i to, že se musí testovat – ne kompletně každá funkce, ale cílené rizikové testy kritických řetězců. Nejpodstatnější krok je mít reálné ARM64 testovací prostředí. Emulace může někdy pomoci, ale nenahradí provoz na skutečném hardware s reálnými ovladači a bezpečnostními politikami.

Minimální ARM64 smoke test: co by mělo být brzy pokryto

Pragmatická, ale účinná sada smoke testů pro každý release kandidát:

• Spuštění programu, login, základní UI funkce
• DB připojení (vč. autentizace, certifikátů, DNS/Proxy, pokud relevantní)
• Jeden klíčový end‑to‑end proces (např. vytvoření zakázky, uložení, tisk/export)
• Updater/installer: čistá instalace a upgrade přes verzi
• Logging/chybové dialogy: jsou diagnostiky na ARM64 použitelné?

Tím se typické ARM64 blokátory rychle objeví: chybějící DLL, nesprávné ovladače, problémy se setupem, neočekávané požadavky na práva.

Diagnostická schopnost: crash‑dumpy, logy, transparentnost verzí

Jakmile je ARM64 ve flotě, budou přicházet supportní případy – už kvůli novým kombinacím ovladačů. Proto se vyplatí standardizovat diagnostiku: jasné build‑ID, vypovídající logy, reprodukovatelné instalační a update cesty. Není to specifické pouze pro ARM64, ale ARM64 rychle ukáže nedostatky jako nákladné.

Rollout a provoz: smíšené flotily bez chaosu

Většina firem bude střednědobě provozovat smíšené klientské flotily: část x64, část ARM64. Klíčové je tento stav záměrně řídit.

Balíčkování: oddělené instalátory, jasná detekce, jednoznačné stahovací cesty

V praxi funguje nejlépe, když jsou instalátory/ balíčky jednoznačné: x64‑balíček je x64, ARM64‑balíček je ARM64. „Jeden instalátor na všechno“ zní pohodlně, ale rychle se komplikuje (kontrolní logika, prerequisities, cesty ovladačů, podepisování, opravná instalace). Pro řízené podnikové rollouty je jednoznačnost často robustnějším postupem.

Strategie aktualizací: žádné speciální cesty pro ARM64

ARM64 by neměl být v update procesu zvláštním případem. Cílem je: stejná frekvence releasů, stejná verze funkcí, ale oddělené artefakty. Pokud se ARM64 aktualizuje jen „ručně“, vznikají divergence ve flotě, které později zvyšují náklady na support.

Integrace dobře dokumentovat

Mnoho ARM64 problémů není v vlastním kódu, ale v integracích: ERP konektor, DMS klient, podpisová služba, skenovací software, tiskárna na štítky. Udržovaný seznam integrací s verzemi a architektonickými poznámkami je pro B2B systémy přirozeně užitečný – a dělá rozhodnutí o ARM64 transparentní.

Co by firmy měly nyní konkrétně udělat (bez akcionismu)

Windows 11 ARM64 včas plánovat neznamená okamžitě vše přestavět. Znamená to odpovědět včas na správné otázky a odstranit blokátory, dokud je náklad plánovatelný. Ověřený postup je:

• 1) Inventura (2–10 dní dle velikosti systému): závislosti, instalátory, ovladače, přístup k datům, COM, reporting.
• 2) Cílový stav a cesta: co musí běžet nativně na klientu? Co bude služba/REST? Které komponenty se nahradí?
• 3) Proof of Feasibility: funkční ARM64 build s instalátorem a end‑to‑end use‑casem.
• 4) Postupné zpevňování: ostatní funkce, testy, update‑řetězec, diagnostika.

Tím nevznikne „ARM64‑projekt“, který měsíců běží izolovaně, ale kontrolované rozšíření schopnosti doručovat.

Závěr: Windows 11 ARM64 není módní trend, ale raný indikátor technické zralosti

Windows 11 ARM64 se pro mnohé firmy stane prostou realitou – vlivem nákupu hardwaru, požadavků na mobilitu nebo standardizace. U Delphi aplikací není hlavní výzvou pouze zdrojový kód, ale celý systém závislostí, instalačních a update procesů, integrací a ovladačů. Kdo ARM64 plánuje včas, může tyto body strukturovaně vyřešit, místo aby je později „zašpuntoval“ pod tlakem termínů.

Nakonec je ARM64 užitečným testem: jak dobře je vaše aplikace oddělená, testovatelná a dodavatelná? Pokud na tuto otázku odpovíte nyní, získáte nejen další platformní možnosti, ale i stabilnější základnu pro modernizaci, služby, REST‑architektury a dlouhodobou udržitelnost.

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.