Windows 11 ARM64 s Delphi v podnicích: možnosti, rizika a robustní migrační cesta

Windows-zařízení s ARM64-CPU (ARM64 je 64bitová procesorová architektura, známá z mobilních SoC a postupně i z podnikových notebooků) už v mnoha firmách nejsou jen „exoti“. Dostávají se sem prostřednictvím standardizovaných flotil notebooků, delší výdrže baterií, nových bezpečnostních funkcí v hardwaru a strategické diverzifikace dodavatelského řetězce. Nejpozději když odbory pořizují nová zařízení nebo OEM výrobci nabízejí určité modely pouze jako Windows na ARM, klade si IT vedení praktickou otázku: Jak se naše Delphi-založená podniková software chová na Windows 11 ARM64 – a jak zajistíme provoz, podporu a další rozvoj?

Jádrem je: Windows 11 ARM64 s Delphi ve firemním prostředí není primárně otázka vývoje, ale otázka závislostí, strategií nasazení, ovladačů, rozhraní a reálného chování v terénu. V praxi existují tři cesty: pokračovat v provozu přes emulaci, nativní ARM64 buildy nebo přechodný model, který řízeně snižuje rizika. Tento příspěvek zařazuje typické nástrahy a ukazuje prověřenou cestu, která funguje v IT plánování, rollout a provozu – bez reflexu „vše nové“.

Proč je Windows 11 ARM64 nyní relevantní

Windows na ARM není nové, ale rámcové podmínky se změnily: zařízení jsou dostupná v podnikové sféře, Windows 11 přináší výrazně vyspělejší x64 emulaci a výrobci softwaru stále častěji dodávají ARM64 varianty. Pro firmy to znamená: ARM64 se neobjevuje jako jednorázový pilot, ale jako platforma, která vstupuje do plánování nákupu a životního cyklu.

Pro procesně orientovaná softwarová řešení není hlavním problémem sama CPU, ale realita periferií a integrací: tisk, podpisové karty, skenery, doplňky Office, COM komponenty (COM je Microsoftův komponentní model pro integraci aplikací a knihoven), rozšíření shellem, VPN klienti nebo bezpečnostní agenti. Pokud něco z toho není kompatibilní s ARM64, vzniká dodatečný servisní náklad – a často je následně obviňována „aplikace“.

Zařazení: Co technicky znamená ARM64 pro Delphi-aplikace?

Delphi-aplikace v podnikovém prostředí jsou často klasické Windows desktop klienty (často VCL, tedy Visual Component Library pro Windows GUI) s přístupem k databázi (např. přes BDE-nahrazení s nativním připojením, datová přístupová vrstva Delphi) a kombinací lokálních a vzdálených integrací. Pod Windows 11 ARM64 z toho vyplývají tři způsoby spuštění:

1) Nativní spuštění pro ARM64

Aplikace a všechny nativní knihovny (DLL) jsou k dispozici jako ARM64. To je dlouhodobě nejčistší varianta, protože umožňuje plánovat výkon a stabilitu a eliminuje okrajové podmínky emulace. Je však realistická pouze tehdy, pokud všechny nativní závislosti přejdou: ovladače databází, tisk/preview, PDF engine, kryptografické knihovny, OCR/scan SDK, ovladače hardwarových donglů apod.

2) x64 emulace pod Windows 11 ARM64

Windows 11 umí emulovat x64 aplikace. Pro mnoho čistě desktopových klientů to funguje překvapivě dobře. V praxi ale emulace není „volná jízda“: jakmile jsou v hře ovladače, integrace do shellu nebo In-Process komponenty (DLL, které jsou načteny do procesu), rozhoduje architektura. x64 proces nemůže načíst ARM64 DLL a naopak. Právě tato hranice často rozhoduje o tom, zda to „běží“ nebo „neběží“.

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

Jednou z přechodových cest je vyjmout kritické x64 komponenty z procesu: např. jako externí službu, jako REST-backend (REST je ein HTTP-basiertes Schnittstellenmodell) nebo jako samostatný pomocný program. Není to tak elegantní jako „vše nativně“, ale často jde o ekonomicky nejvýhodnější cestu k zajištění provozu a postupné modernizaci závislostí.

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

V projektech se rychle ukáže: ne GUI je úzké místo, ale ekosystém. Strukturovaná analýza závislostí ušetří týdny pokusů a omylů.

Native DLLs und SDKs: Das unsichtbare Risiko

Mnoho Delphi aplikací integruje DLL třetích stran: generování PDF, čtečky čárových kódů/QR, zpracování obrazu, šifrování, proprietární komunikační knihovny. Pro ARM64 platí tvrdé pravidlo: DLL musí odpovídat architektuře procesu. Emulace pomůže jen pokud zůstane celý proces x64. Jakmile se chce jít nativně, musí být tyto knihovny dostupné jako ARM64 nebo nahrazeny.

Praktická rada pro IT: Nechte si od odpovědné osoby za software poskytnout seznam, které DLL jsou v instalačním adresáři a které se načítají přes systémové cesty. To je základ pro posouzení podpory výrobcem a alternativ.

COM, Office-Automation und Shell-Erweiterungen

COM se v podnikovém provozu často používá, aniž by se tak pojmenovávalo: integrace Outlooku, export do Excelu přes automatizaci, DMS klienti, preview handler v Exploreru, rozšíření kontextového menu. Problém u ARM64 není tolik COM samotný, ale propojení bitnosti: In-Process-COM-Server (COM komponenty založené na DLL) musí mít shodnou architekturu. Out-of-Process-COM (EXE-based servery) je flexibilnější, protože může běžet v odděleném procesu.

Pokud vaše Delphi aplikace např. používá starou 32‑Bit- nebo 64‑Bit-COM-DLL, je to při nativním běhu na ARM64 blokátor. Emulovaně jako x64 to může fungovat – pokud jsou všechny COM závislosti rovněž x64 a žádné ARM64-only části do toho nezasahují.

Druck, PDF und Treiberlandschaft

Problémy s tiskem jsou při změně platformy klasika. Pod Windows 11 ARM64 je rozhodující, zda výrobce tiskáren poskytuje ARM64 ovladače, nebo zda lze použít Universal Print/IPP třídní ovladače (IPP je standardizovaný tiskový protokol). I PDF tiskárny, dávkový tisk, tisk štítků a speciální zařízení (např. termo tiskárny) mohou záviset na ovladačích, které existují jen pro x64.

Pro IT vedení a administraci je důsledek jasný: ARM64-Rollouts musí být sladěny s tiskovou strategií. „Aplikace netiskne“ často znamená „ovladač neexistuje“ nebo „tisková pipeline je jiná“.

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

Na úrovni dat se vyplatí čisté oddělení mezi protokolem a klientskou knihovnou. BDE-Ablosung mit nativer Anbindung může podle databáze pracovat s nativními klientskými knihovnami nebo s ovladači. Například pokud je potřeba Oracle‑client, starší PostgreSQL‑client nebo specifický ODBC‑ovladač, musí být k dispozici ve verzi pro ARM64 – nebo zvolíte architekturu, která přístup k datům zapouzdří na serverové straně (např. přes REST‑služby nebo Windows-/Windows‑ a Linux‑služby).

Pro stabilní provoz je to zásadní páka: čím méně je desktopový klient přímo vázán na databázové ovladače a lokální databázové „stacky“, tím snazší bude přechod na ARM64. To platí i z hlediska bezpečnosti: přihlašovací údaje do databáze, certifikáty a síťová pravidla lze spravovat konzistentněji na serverové straně.

Krypto, chytré karty, podpisy, VPN, EDR

Mnoho business procesů dnes závisí na kryptografických komponentách: S/MIME, klientské certifikáty, middleware pro chytré karty, podpisové karty, TLS‑inspekce v proxy. K tomu se přidávají řešení pro zabezpečení koncových bodů (EDR je Endpoint Detection and Response) a VPN klienti. Tyto komponenty musí být kompatibilní s ARM64, jinak vznikne problém „zařízení je k dispozici, ale nesmí do sítě“.

Pro aplikaci Delphi to znamená: Pokud např. používáte certifikáty z Windows‑úložiště certifikátů nebo realizujete TLS přes systémové komponenty, je to obvykle méně kritické než když v procesu visí specifická kryptografická DLL třetí strany.

Rozhodovací matice: emulace nebo nativní portace na ARM64?

Firmy potřebují rozhodnutí, které zohlední realitu podpory a životního cyklu. Jednoduchá ano/ne otázka („Budeme portovat?“) je zřídka užitečná. Vhodnější je matice, která váží závislosti a rizika:

• Čistý klient se standardními Windows‑API (soubor, síť, tisk přes standardní ovladače): Emulace může krátkodobě stačit; nativní ARM64 je ve střednědobém horizontu čisté.
• Klient s mnoha nativními DLL třetích stran (PDF, OCR, hardware): nejprve ověřit dostupnost, pak rozhodnout. Často smysluplná hybridní cesta.
• Klient s COM‑DLL a rozšířeními Shellu: očekávejte architektonické konflikty; prověřte odpojení mimo proces.
• Klient s přímým zoo DB‑ovladačů: buď ovladače konsolidovat, nebo přenést přístup k datům do služeb.
• Vysoká regulace/podpis/chytré karty: včas ověřte schopnost řetězce bezpečnostních a middleware komponent fungovat na ARM64.

Důležité: Emulace není „druhá třída“, ale je to ein provozní riziko, pokud dlouhodobě plánujete zařízení ARM64 ve flotile. Nejpozději při větších aktualizacích, změnách ovladačů nebo výměnách bezpečnostních agentů nechcete zůstat na řetězci výjimek.

Spolehlivý migrační postup: z dneška na ARM64 bez Big Bangu

Pro IT a projektově odpovědné je postup dobrý, pokud se dá nasazovat ve vlnách, má jasná akceptační kritéria a nepřetíží podporu. V Delphi‑prostředích se osvědčil pětikrokový přístup.

Krok 1: Inventarizace s „provozním pohledem“

Zaznamenejte nejen moduly, ale především provozní body:

• Jaké třídy zařízení: notebooky, Rugged Devices, terminály?
• Jaká periferie: tiskárny, skenery, čtečky karet, labelery?
• Jaké integrace: Office, DMS, ERP, lokální služby, komponenty prohlížeče?
• Jaká forma instalace: MSI, Setup‑EXE, ClickOnce, ruční nasazení?
• Jaká oprávnění: nutné administrátorské oprávnění, lokální služby, pravidla firewallu?

Tento pohled rychle odhalí, zda „pouze jeden klient“ ve skutečnosti znamená pět systémových závislostí.

Krok 2: Kontrola kompatibility s reprezentativním pilotním zařízením ARM64

Pilot by neměl být „to nejhezčí zařízení“, ale typický zástupce cílové flotily. Záměrně otestujte kritické cesty: tisk ve všech variantách, export/import, podpis, offline/online, aktualizace, přepínání tenantů, scénáře s proxy/VPN. Dokumentujte odchylky jako provozní události, ne jako chyby vývoje. Tak zůstane prioritizace čistá.

Krok 3: Snižování závislostí – nejprve ty s vysokým dopadem na podporu

Typická opatření, která v praxi přinesou velký užitek:

• Standardizovat PDF-/tiskovou cestu: pryč od proprietárních tiskových DLL, směrem ke stabilním, testovaným zpracovacím tokům.
• Oddělit integraci Office: místo in-process add-inů raději prověřte exportní formáty a serverové generování dokumentů.
• Konsolidovat přístup k DB: definovaná cesta přes ovladač místo „ODBC podle pracoviště“.
• Zapouzdřit hardwarové připojení: pokud možno přes externí procesy/služby, které lze aktualizovat samostatně.

Krok 4: Modernizovat nasazení a schopnost aktualizací

ARM64 je vhodný důvod pro vyčištění instalace a aktualizací. Pro podniky nejsou rozhodující funkce, ale možnost rollbacku, reprodukovatelnost a shoda s politikami. Zkontrolujte:

• Balíčkování: MSI vs. MSIX (MSIX je moderní formát aplikací od Microsoftu s čistou instalací/odinstalací a podepisováním).
• Podepisování: Code Signing (digitální podpis EXE/DLL) snižuje tření se SmartScreen a EDR a je relevantní pro kontrolovaná nasazení.
• Správa konfigurace: oddělení programových souborů a konfigurace, jasné cesty, žádné „skryté“ závislosti na registru.
• Kanály aktualizací: pilot, Ring 1, Ring 2 – s telemetrií/logováním na úrovni aplikace a provozu.

Krok 5: Nativní ARM64 tam, kde se to skutečně vyplatí

Nativní ARM64 sestavení dávají smysl tehdy, když (a) máte závislosti pod kontrolou a (b) aplikaci budete dlouhodobě vyvíjet. Typicky se to vyplatí u klíčových klientů, které denně používá mnoho uživatelů a které stejně modernizujete. U zřídka používaných nástrojů může být x64 emulace přijatelný přechod, pokud podpora a bezpečnost umožňují.

Architektonické impulzy: ARM64 jako příležitost posílit rozhraní a služby

Mnohá Delphi prostředí historicky vznikla jako „tlustý klient“. To funguje, ale provoz a aktualizace jsou více vázány na jednotlivé konfigurace pracovišť. ARM64 ukáže, kde se tato vazba stává nákladnou. Pragmatický krok modernizace tedy často není „nové UI“, ale nová rozhraní.

Větší stabilita díky serverovým odpovědnostem

Když se kritická logika, přístup k datům nebo zpracování dokumentů přesunou do centrální služby (Windows- a Linux-služby nebo Linux-služba, tedy služba na pozadí bez interaktivního uživatelského rozhraní), získáte:

• jednotné verze ovladačů a knihoven,
• lépe kontrolovatelnou bezpečnost (certifikáty, tajné údaje, síť),
• nižší složitost na klientu (ARM64, x64, v budoucnu i jiné platformy),
• jasnější body monitoringu a logování.

Pro IT-vedoucí představuje skutečnou provozní výhodu: problémy jsou na straně serveru rychleji reprodukovatelné, místo aby visely na „nějakém specifickém notebooku“.

REST-API als Entkopplungsschicht

REST-API není automaticky „moderní“, ale tvoří robustní odpojovací vrstvu mezi klienty a backendem. Jasně definuje, která data a akce jsou povolené, a lze ji důsledně zabezpečit (např. pomocí tokenů, certifikátů nebo SAML 2.0 jako identitního standardu v podnikových prostředích). Pro ARM64 to znamená: klient nemusí nést tolik „světových znalostí“ o databázích, ovladačích a síťových detailech.

I když neplánujete vše přestavět okamžitě: už malý, dobře ohraničený API-komponent (např. generování dokumentů, ověření licence, porovnání základních dat) může odstranit závislosti z klienta a tím snížit rizika spojená s ARM64.

Test a kvalita: Co byste měli při ARM64 kontrolovat jinak

Mnoho týmů testuje desktopový software především funkčně. U ARM64 byste měli více testovat provozně, protože chybové obrazy jsou jiné: ne „špatný výpočet“, ale „komponenta se nenačte“, „chybí ovladač“, „aktualizace selže“, „integrace s Office se zhroutí“.

Checklist pro ARM64-blízké přejímky

• Instalace/Odinstalace: čistě, bez zbytků, bez administrátorských obcházek.
• Aktualizační cesta: upgrade přes několik verzí, rollback-scenář, ověření podpisu.
• Logování: centrální protokoly, jasné chybové kódy při problémech s načítáním DLL, sledovatelné tiskové cesty.
• Výkon: doba spuštění, operace s daty, velké seznamy/reporty – měřit odděleně v emulaci a nativně.
• Periférie: profily tiskáren, speciální tisk, workflow skeneru, funkce smartkarty.
• Bezpečnost: interakce EDR/AV, Proxy/TLS, úložiště certifikátů, provoz podle principu nejmenších oprávnění.

Důležitá je dokumentace: pokud problém vznikne kvůli chybějícím ARM64-ovladačům, nejde o „bugfix v Delphi“, ale o rozhodnutí o pořízení nebo standardizaci.

Provoz a podpora: Jak ARM64 začlenit do každodenního provozu

V praxi rozhoduje, jak rychle se podpora dokáže vrátit k provozu. Pro ARM64 se vyplatí proaktivně zvýšit schopnost podpory:

Standardizované profily zařízení a jasná schválení

Definujte podporované modely ARM64 nebo alespoň minimální profily (strategie ovladačů, strategie tisku, verze security agentů). „Funguje na ARM64“ bez těchto omezení vede k nejednotným prostředím a tím k hůře reprodukovatelným poruchám.

Diagnostické schopnosti v aplikaci

I bez vývojářského zaměření má smysl v softwaru podpořit jasné možnosti diagnostiky: stránka systémových informací, která ukáže architekturu (x64 emulováno vs. ARM64 nativně), důležité cesty, verze jádrových komponent a konfiguraci tisku, výrazně zkracuje dobu řešení podpory. To není „nice to have“, ale provozní hygiena.

Licencování a dongly

Pokud jsou v provozu hardwarové dongly nebo starší licenční ovladače, může se ARM64 rychle stát kritickým. V mnoha prostředích se vyplatí přejít na licencování přes síť nebo serverové mechanismy. Tím se sníží závislost na ovladačích na koncových zařízeních a flotila bude lépe zaměnitelná.

Co to znamená pro vaši Delphi-strategii?

Delphi je v podnikových prostředích často stabilní stavební kámen pro desktopové klienty a služby. Windows 11 ARM64 není argument „proti Delphi“, ale argument pro čistší zapouzdření závislostí a pro provozně orientovanou modernizaci: méně lokálních speciálních ovladačů, méně komponent běžících v procesu, jasnější rozhraní, lepší nasazování.

Pokud jste dnes již na cestě k modernizaci (např. BDE-Ablösung, přechod na 64 bitů, silnější integrace REST, konsolidovaný přístup k datům s FireDAC), pak je ARM64 často „pouze“ další cílový bod, který zpřesňuje priority. Pokud vaše aplikace naopak silně závisí na starých ovladačích, proprietárních DLL a speciálních konfiguracích pracovních stanic, je ARM64 vhodnou příležitostí tato rizika zpřehlednit a plánovat jejich snížení.

Shrnutí: ARM64 je spíše architektonický a provozní projekt než pouhé portování

Pro firmy je Windows 11 ARM64 především otázkou platformy v oblastech nákupu, bezpečnosti a podpory. U business softwaru založeného na Delphi se úspěch nerozhoduje volbou překladače, ale řetězcem ovladačů, DLL, COM integrací, přístupu k datům a procesů aktualizací. Robustní postup je: nejprve učinit viditelnými závislosti a provozní cesty, pak testovat na pilotních zařízeních, následně cíleně oddělovat komponenty a profesionalizovat nasazování – a dodávat nativní ARM64 buildy tam, kde dlouhodobě přinesou užitek a stabilitu.

Pokud chcete Windows 11 ARM64 ve své flotile zavést a přitom plánovatelně zabezpečit Delphi aplikace, periferie a rozhraní, poraďte se s námi o strukturované inventuře a realistické migrační cestě:

V odborném kontextu hrají také Delphi ARM64 Windows a X64-Emulation Windows 11 důležitou roli, pokud musí integrace, datové toky a další vývoj hladce spolupracovat.

Projednat projekt nebo modernizační záměr s Net-Base.