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 stále častěji i z business notebooků) už v mnoha společnostech nejsou jen „exoti“. Dostávají se do firem prostřednictvím standardizovaných flotil notebooků, delší výdrže baterie, nových bezpečnostních funkcí v hardwaru a strategické diverzifikace dodavatelského řetězce. Nejpozději když odborná oddělení pořizují nová zařízení nebo OEM výrobci nabízejí určité modely pouze jako Windows on ARM, řeší IT odpovědní praktickou otázku: Jak se naše Delphi-založená business software chová pod Windows 11 ARM64 – a jak zajistíme provoz, podporu a další vývoj?

Jádrem je: Windows 11 ARM64 s Delphi ve firmách je méně otázka čistě vývojová a více otázka závislostí, strategií nasazení, ovladačů, rozhraní a reálného chování v terénu. V praxi existují tři cesty: pokračování provozu přes emulaci, nativní ARM64 buildy nebo přechodný model, který rizika kontrolovaně snižuje. Tento příspěvek zařazuje typické kamení úrazu a ukazuje spolehlivou cestu, která funguje v IT plánování, nasazení a provozu – bez reflexu „vše znovu“.

Proč se Windows 11 ARM64 nyní stává relevantním

Windows on ARM není nic nového, ale rámcové podmínky se změnily: Zařízení jsou dostupná v business prostředí, Windows 11 přináší výrazně vyspělejší x64 emulaci a výrobci softwaru č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ákupů a životního cyklu.

Pro procesně orientovaná softwarová řešení není méně problémem samotné CPU, ale realita periferií a integrací: tisk, podpisové karty, skenery, Office add-iny, COM-komponenty (COM je Microsoftův komponentní model pro integraci aplikací a knihoven), rozšíření shellu, VPN klienti nebo bezpečnostní agenti. Když něco z toho není kompatibilní s ARM64, vzniká náročná podpora – a často je pak „aplikace“ označena za viníka.

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

Delphi-aplikace v podnikovém prostředí jsou často klasické Windows desktopové klienty (často VCL, tedy Visual Component Library pro Windows GUI) s přístupem k databázi (např. přes BDE-náhradu s nativním napojením, datová přístupová vrstva Delphi) a směs lokálních a vzdálených integrací. Pod Windows 11 ARM64 se proto nabízejí tři režimy běhu:

1) Nativní ARM64 provedení

Aplikace a všechny nativní knihovny (DLLs) jsou dostupné jako ARM64. To je dlouhodobě nejčistší volba, protože umožňuje plánovat výkon a stabilitu a vyhýbat se okrajovým podmínkám emulace. Je však reálná pouze tehdy, když se všechny nativní závislosti přizpůsobí: databázové ovladače, tisk/náhled, PDF engine, kryptoknihovny, OCR/scan SDK, ovladače hardwarových donglů apod.

2) x64-Emulace unter Windows 11 ARM64

Windows 11 může 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 zapojeny ovladače, integrace do shellu nebo in‑process komponenty (DLL, které se načítají do procesu), rozhoduje architektura. x64 proces nemůže načíst ARM64‑DLL a naopak. Právě tato hranice často rozhoduje o „běží“ nebo „neběží“.

3) Hybrid: ARM64‑klient, oddělení x64 komponent

Pro přechod je jednou z možností vytáhnout kritické x64 komponenty z procesu: např. jako externí službu, jako REST‑backend (REST je HTTP‑based model rozhraní) nebo jako samostatný pomocný program. To není tak elegantní jako „vše nativně“, ale často nejhospodárnější cesta, jak zajistit provoz a postupně modernizovat závislosti.

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

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

Native DLLs und SDKs: Das unsichtbare Risiko

Mnoho Delphi‑aplikací začleňuje 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. Pod ARM64 platí tvrdě: DLL musí odpovídat architektuře procesu. Emulace pomůže jen pokud zůstane celý proces x64. Jakmile chcete běžet nativně, musí být tyto knihovny dostupné jako ARM64 nebo musí být nahrazeny.

Praktický tip pro IT: Požádejte odpovědného za software o seznam, které DLL leží 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 dostupných alternativ.

COM, Office‑Automation und Shell‑Erweiterungen

COM se v každodenním firemním provozu často používá, aniž by se to explicitně nazývalo: integrace do Outlooku, export z Excelu přes automatizaci, DMS klienti, preview handlery v Exploreru, rozšíření kontextového menu. Problém na ARM64 není toliko v COM samotném, ale v propojení bitnosti: in‑process COM servery (COM komponenty založené na DLL) musí mít stejnou architekturu. Out‑of‑process COM (servery založené na EXE) je flexibilnější, protože může běžet v samostatné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 blokující. Emulovaně jako x64 to může fungovat — pokud jsou všechny COM závislosti také x64 a žádné ARM64‑only části do toho nezasahují.

Druck, PDF und Treiberlandschaft

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

Pro vedení IT a administraci vyplývá důležitý závěr: rollout ARM64 musí být sladěn s tiskovou strategií. „Aplikace netiskne“ často znamená „ovladač neexistuje“ nebo „tisková pipeline je jiná“.

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

Na datové úrovni se vyplatí čisté oddělení mezi protokolem a klientskou knihovnou. BDE-Ablosung mit nativer Anbindung může v závislosti na databázi pracovat s nativními klientskými knihovnami nebo s ovladači. Pokud je například potřeba Oracle‑client, starší PostgreSQL‑client nebo specifický ODBC‑ovladač, musí pro něj existovat verze pro ARM64 – nebo zvolíte architekturu, která přístup k datům na straně serveru zapouzdří (např. přes REST‑služby nebo Windows‑/Windows‑ a Linux‑služby).

Pro stabilní provoz je to rozhodující prostředek: čí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ší je přechod na ARM64. Platí to i z hlediska bezpečnosti: přístupové údaje k databázi, certifikáty a síťová pravidla lze spravovat konzistentněji na straně serveru.

Krypto, smartkarty, podpisy, VPN, EDR

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

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

Rozhodovací matice: emulace nebo nativní portování na ARM64?

Podniky potřebují rozhodnutí, které odráží realitu podpory a životního cyklu. Jednoduchá ano/ne otázka („Portujeme?“) je zřídka užitečná. Vhodnější je matice, která ohodnotí 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 střednědobě vhodné.
• Klient s mnoha nativními DLL třetích stran (PDF, OCR, hardware): nejprve ověřit dostupnost, potom rozhodnout. Často smysluplná hybridní cesta.
• Klient s COM‑DLLs / rozšířeními shellu: očekávejte architektonické konflikty; prověřte oddělení mimo proces (out‑of‑process).
• Klient s množstvím přímých databázových ovladačů: buď ovladače konsolidovat, nebo přenést přístup k datům do služeb.
• Vysoká regulace/podpisy/smartkarty: včas ověřte kompatibilitu bezpečnostního a middleware řetězce s ARM64.

Důležité: emulace není „druhá kategorie“, ale představuje provozní riziko, pokud v dlouhodobém horizontu plánujete zařízení ARM64 ve flotě. Nejpozději při větších aktualizacích, změnách ovladačů nebo výměně bezpečnostních agentů nechcete zůstávat s řetězcem výjimek.

Robustní migrační cesta: od dneška na ARM64 bez Big Bang

Pro IT a projektově odpovědné je cesta dobrá, pokud je možné ji rozložit do vln, má jasná akceptační kritéria a nepřetěžuje podporu. V Delphi‑prostředích se osvědčil postup v pěti krocích.

Krok 1: Inventarizace s „provozní perspektivou“

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

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

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

Krok 2: Kontrola kompatibility s reprezentativním ARM64-pilotem

Pilot by neměl být „to nejhezčí zařízení“, ale typický kandidát z cílové flotily. Při testování se záměrně zaměřte na kritické cesty: tisk ve všech variantách, export/import, podpis, offline/online, aktualizace, přepínání mezi nájemci, proxy/VPN scénáře. Dokumentujte odchylky jako provozní události, nikoli jako chyby vývojářů. Tím zůstane prioritizace čistá.

Krok 3: Snížit závislosti – nejdříve ty s největším dopadem na podporu

Typická opatření, která v praxi přinášejí nejvíce:

• Standardizovat PDF-/tiskovou cestu: odejít od proprietárních tiskových DLL směrem ke stabilním, testovaným pipelinám.
• Oddělit integraci Office: místo in-process add-inů raději ověřit exportní formáty a serverové generování dokumentů.
• Konsolidovat přístup k DB: jednotná cesta ovladače místo „ODBC podle pracovního místa“.
• Kapslovat připojení k hardwaru: pokud možno přes externí procesy/služby, které lze aktualizovat samostatně.

Krok 4: Modernizovat nasazení a schopnost aktualizací

ARM64 je dobrou příležitostí vyčistit instalace a aktualizace. Pro podniky zde nejsou rozhodující funkce, ale možnost návratu k předchozí verzi, reprodukovatelnost a shoda s politikami. Prověřte:

• 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 problémy 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 aplikační a provozní úrovni.

Krok 5: Nativní ARM64 tam, kde se to opravdu vyplatí

Nativní ARM64 buildy dávají smysl, pokud (a) máte závislosti pod kontrolou a (b) aplikaci plánujete dlouhodobě rozví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ým přechodem, pokud podpora a bezpečnost tomu vyhovují.

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

Mnohá Delphi-prostředí historicky vyrostla jako „těžký klient“. To funguje, ale provoz a aktualizace jsou pak silně vázány na jednotlivé konfigurace pracovišť. ARM64 odhaluje, kde je tato vazba nákladná. Pragmatický krok modernizace proto často není „nové UI“, ale přepracování rozhraní.

Větší stabilita díky serverové odpovědnosti

Když se kritická logika, přístup k datům nebo procesy dokumentů přesunou do centrální služby (Windows- und Linux-Services nebo Windows- und Linux-Services, tedy background service bez interaktivního UI), získáte:

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

Pro IT-rozhodovatele je to skutečná provozní výhoda: problémy jsou serverově reprodukovatelné rychleji, místo aby „visely na nějakém speciálním notebooku“.

REST-API jako vrstva oddělení

Eine REST-API ist nicht automatisch „modern“, aber sie ist eine robuste Entkopplung zwischen Clients und Backend. Sie definiert klar, welche Daten und Aktionen erlaubt sind, und kann sauber abgesichert werden (z. B. über Tokens, Zertifikate oder SAML 2.0 als Identitätsstandard in Unternehmensumgebungen). Für ARM64 bedeutet das: Der Client muss weniger „Weltwissen“ über Datenbanken, Treiber und Netzwerkdetails tragen.

I když všechno nepřevedete okamžitě: už malý, dobře omezený API-komponent (např. generování dokumentů, ověření licence, synchronizace základních dat) může odstranit závislosti z klienta a tím snížit rizika spojená s ARM64.

Test und Qualität: Was Sie unter ARM64 anders prüfen sollten

Mnoho týmů testuje desktopový software primárně funkčně. U ARM64 byste měli více testovat provozně, protože chybové stavy jsou jiné: ne „špatný výpočet“, sondern „komponente se nenačte“, „chybí ovladač“, „aktualizace selže“, „integrace s Office selže“.

Checkliste für ARM64-nahe Abnahme

• Instalace/Odinstalace: čistě, bez zbytků, bez obcházení oprávnění administrátora.
• Aktualizační cesta: aktualizace přes více verzí, rollback scénář, kontrola podpisu.
• Logování: centrální logy, jasné kódy chyb u problémů s načítáním DLL, sledovatelné tiskové cesty.
• Výkon: doba startu, operace s daty, velké seznamy/reporty – měřit odděleně pod emulací a nativně.
• Periferní zařízení: profily tiskáren, speciální tisk, pracovní postupy skenerů, funkce smartkaret.
• Bezpečnost: interakce EDR/AV, Proxy/TLS, úložiště certifikátů, provoz s principem nejmenších práv.

Důležitá je dokumentace: pokud problém vznikne kvůli chybějícím ARM64 ovladačům, nejde o „Bugfix in Delphi“, sondern o rozhodnutí v oblasti nákupu nebo standardizace.

Provoz a podpora: Jak integrovat ARM64 do běžného provozu

V praxi rozhoduje, jak rychle jsou podporované případy vyřešeny. U 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 bezpečnostních agentů). „Běží na ARM64“ bez tohoto omezení vede k nejednotným prostředím a tím k těžko reprodukovatelným poruchám.

Diagnostické schopnosti v aplikaci

I bez zaměření na vývojáře je tu rozumné požadovat od softwaru jasnou funkci: stránku systémových informací, která uvádí architekturu (x64 emulováno vs. ARM64 nativně), důležité cesty, verze klíčových komponent a konfiguraci tisku; to výrazně zkracuje dobu podpory. To není „nice to have“, sondern provozní hygiena.

Licencování a dongly

Pokud jsou v hře hardwarové dongly nebo staré licenční ovladače, stává se ARM64 rychle kritickým. V mnoha prostředích je smysluplné přesunout licencování na síťové nebo serverové mechanismy. Tím klesá závislost na ovladačích na koncových zařízeních a flota se stává zaměnitelnější.

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

Delphi je v podnikové oblasti často stabilní stavební prvek pro desktopové klienty a služby. Windows 11 ARM64 není argument „proti Delphi“, ale argument pro čistší zapouzdření závislostí a pro provozní modernizaci: méně lokálních specializovaných ovladačů, méně komponent v rámci procesu, jasnější rozhraní, lepší nasazení.

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

Závěr: ARM64 není primárně portovací projekt, ale projekt architektury a provozu

Pro firmy je Windows 11 ARM64 především otázkou platformy v oblasti nákupu, bezpečnosti a podpory. U podnikového softwaru založeného na Delphi se úspěch nerozhoduje volbou kompilátoru, ale řetězcem ovladačů, DLL, COM-integrací, přístupu k datům a aktualizačních procesů. Rozumná cesta je: nejprve zpřehlednit závislosti a provozní cesty, pak testovat s pilotními zařízeními, následně cíleně oddělovat součásti a profesionalizovat nasazení – a dodávat nativní ARM64 buildy tam, kde dlouhodobě přinášejí užitek a stabilitu.

Pokud chcete ve své flotě zavést Windows 11 ARM64 a zároveň plánovitě zajistit Delphi-aplikace, periferie a rozhraní, kontaktujte nás ohledně strukturovaného průzkumu stavu a realistické migrační cesty:

V odborném kontextu hrají také Delphi ARM64 Windows a X64-emulace Windows 11 významnou roli, pokud integrace, toky dat a další vývoj musí hladce spolupracovat.

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