Windows 11 ARM64 z Delphi w przedsiębiorstwach: opcje, ryzyka i wiarygodna ścieżka migracji

Windows-Geräte mit ARM64-CPU (ARM64 ist eine 64‑Bit-Prozessorarchitektur, bekannt aus mobilen SoCs und zunehmend auch aus Business-Notebooks) sind in vielen Unternehmen nicht mehr nur „Exoten“. Sie kommen über standardisierte Notebook-Flotten, längere Akkulaufzeiten, neue Sicherheitsfunktionen in der Hardware und eine strategische Diversifizierung der Lieferkette. Spätestens wenn Fachbereiche neue Geräte beschaffen oder OEMs bestimmte Modelle nur noch als Windows on ARM anbieten, stellt sich für IT-Verantwortliche die praktische Frage: Wie verhält sich unsere Delphi-basierte Business-Software unter Windows 11 ARM64 – und wie sichern wir Betrieb, Support und Weiterentwicklung?

Der Kernpunkt ist: Windows 11 ARM64 mit Delphi in Unternehmen ist weniger eine reine Entwicklungsfrage als eine Frage von Abhängigkeiten, Deployment-Strategien, Treibern, Schnittstellen und dem realen Verhalten im Feld. In der Praxis gibt es drei Wege: Weiterbetrieb über Emulation, native ARM64-Builds oder ein Übergangsmodell, das Risiken kontrolliert reduziert. Dieser Beitrag ordnet die typischen Stolpersteine ein und zeigt einen belastbaren Pfad, der in IT-Planung, Rollout und Betrieb funktioniert – ohne „Alles neu“-Reflex.

Warum Windows 11 ARM64 jetzt relevant wird

Windows on ARM ist nicht neu, aber die Rahmenbedingungen haben sich geändert: Die Geräte sind im Business-Umfeld verfügbar, Windows 11 bringt eine deutlich ausgereiftere x64-Emulation, und Softwarehersteller liefern immer häufiger ARM64-Varianten. Für Unternehmen heißt das: ARM64 taucht nicht als einmaliges Pilotprojekt auf, sondern als Plattform, die in Beschaffungs- und Lebenszyklusplanungen eingeht.

Für prozessnahe Softwarelösungen ist dabei weniger die CPU selbst das Problem, sondern die Peripherie- und Integrationsrealität: Druck, Signaturkarten, Scanner, Office-Add-ins, COM-Komponenten (COM ist Microsofts Komponentenmodell zur Integration von Anwendungen und Bibliotheken), Shell-Erweiterungen, VPN-Clients oder Security-Agenten. Wenn davon etwas nicht ARM64-tauglich ist, entsteht Supportaufwand – und häufig wird dann „die Anwendung“ verantwortlich gemacht.

Einordnung: Was bedeutet ARM64 technisch für Delphi-Anwendungen?

Delphi-Anwendungen im Unternehmensumfeld sind oft klassische Windows-Desktop-Clients (häufig VCL, also die Visual Component Library für Windows-GUIs) mit Datenbankzugriff (z. B. über BDE-Ablosung mit nativer Anbindung, Delphis Datenzugriffsschicht) und einer Mischung aus lokalen und entfernten Integrationen. Unter Windows 11 ARM64 ergeben sich dabei drei Ausführungsarten:

1) Native ARM64-Ausführung

Die Anwendung und alle nativen Bibliotheken (DLLs) liegen als ARM64 vor. Das ist langfristig die sauberste Option, weil sie Performance und Stabilität planbar macht und Emulationsrandbedingungen vermeidet. Sie ist aber nur dann realistisch, wenn alle nativen Abhängigkeiten mitziehen: Datenbanktreiber, Druck/Preview, PDF-Engine, Kryptobibliotheken, OCR/Scan-SDKs, Hardware-Dongle-Treiber etc.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 potrafi emulować aplikacje x64. Dla wielu czystych klientów desktopowych działa to zaskakująco dobrze. W praktyce emulacja nie jest jednak „bezpłatnym biletem“: Gdy w grę wchodzą sterowniki, integracje powłoki lub komponenty uruchamiane w procesie (DLL ładowane do procesu), decydująca staje się architektura. Proces x64 nie może załadować biblioteki ARM64 i odwrotnie. To właśnie ta granica często przesądza o „działa“ lub „nie działa“.

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

Ścieżką przejścia jest wydzielenie krytycznych komponentów x64 z procesu: np. jako zewnętrznego serwisu, jako backendu REST (REST to model interfejsu oparty na HTTP) lub jako oddzielne narzędzie pomocnicze. To mniej eleganckie niż „wszystko natywnie“, ale często najekonomiczniejsza droga do zapewnienia działania oraz stopniowej modernizacji zależności.

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

W projektach szybko widać: wąskim gardłem nie jest GUI, lecz ekosystem. Ustrukturyzowana analiza zależności oszczędza tu tygodnie prób i błędów.

Native DLLs und SDKs: Das unsichtbare Risiko

Wiele aplikacji Delphi integruje biblioteki firm trzecich: generowanie PDF, kody kreskowe/QR, przetwarzanie obrazu, szyfrowanie, zamknięte biblioteki komunikacyjne. Dla ARM64 obowiązuje zasada twarda: biblioteka DLL musi pasować do architektury procesu. Emulacja pomaga tylko wtedy, gdy cały proces pozostaje x64. Gdy chcemy uruchomić natywnie, te biblioteki muszą być dostępne w wersji ARM64 albo trzeba je zastąpić.

Wskazówka praktyczna dla IT: Poproś osobę odpowiedzialną za oprogramowanie o listę bibliotek DLL, które znajdują się w katalogu instalacyjnym oraz tych ładowanych z ścieżek systemowych. To podstawa do oceny gotowości producentów i dostępnych alternatyw.

COM, Office-Automation und Shell-Erweiterungen

COM jest w codziennej pracy przedsiębiorstwa często używany, nawet jeśli nie nazywa się go wprost: integracja z Outlook, eksport do Excel przez automatyzację, klienci DMS, handler podglądu w Eksploratorze, rozszerzenia menu kontekstowego. Problem przy ARM64 nie dotyczy samego COM, lecz powiązania bitowości: serwery COM działające w procesie (komponenty COM oparte na DLL) muszą mieć taką samą architekturę. Out-of-Process-COM (serwery oparte na EXE) jest bardziej elastyczny, bo może działać w odrębnym procesie.

Jeśli Twoja aplikacja Delphi korzysta np. ze starej 32‑bitowej lub 64‑bitowej biblioteki COM (DLL), to przy natywnym uruchomieniu na ARM64 stanowi to blokadę. Emulowane jako x64 może działać — pod warunkiem że wszystkie zależności COM również są x64 i nie wkraczają komponenty dostępne tylko dla ARM64.

Druck, PDF und Treiberlandschaft

Problemy z drukiem to klasyka przy zmianie platformy. Dla Windows 11 ARM64 kluczowe jest, czy producent drukarki dostarcza sterowniki ARM64, albo czy można użyć sterowników klasy Universal Print/IPP (IPP to standardowy protokół drukowania). Również drukarki PDF, druk masowy, druk etykiet oraz urządzenia specjalistyczne (np. drukarki termiczne) mogą zależeć od sterowników dostępnych tylko dla x64.

Dla kierownictwa IT i administracji ważna konsekwencja jest taka: wdrożenia ARM64 muszą być skoordynowane ze strategią druku. „Aplikacja nie drukuje“ często oznacza „brak sterownika“ albo „pipeline drukowania działa inaczej“.

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

Na poziomie danych opłaca się wyraźne rozdzielenie między protokołem a biblioteką klienta. BDE-Ablosung mit nativer Anbindung może, w zależności od bazy danych, pracować z natywnymi bibliotekami klienckimi lub przez sterowniki. Jeśli np. wymagany jest klient Oracle, starszy klient PostgreSQL lub specyficzny sterownik ODBC, musi on być dostępny dla ARM64 – albo stosuje się architekturę, która kapsułuje dostęp do danych po stronie serwera (np. przez usługi REST lub Windows-/ Windows- i Linux-services).

Dla stabilnej eksploatacji to kluczowy dźwignia: im mniej klient desktopowy jest bezpośrednio związany ze sterownikami bazy danych i lokalnymi „stackami” bazy danych, tym łatwiejsze staje się wdrożenie ARM64. Dotyczy to także kwestii bezpieczeństwa: dane dostępu do bazy, certyfikaty i reguły sieciowe można spójniej zarządzać po stronie serwera.

Kryptografia, Smartcardy, podpisy, VPN, EDR

Wiele procesów biznesowych opiera się dziś na komponentach kryptograficznych: S/MIME, certyfikaty klienta, middleware smartcard, karty podpisu, TLS-Inspection w proxy. Dochodzą do tego rozwiązania zabezpieczające punkt końcowy (EDR – Endpoint Detection and Response) oraz klienci VPN. Te komponenty muszą być zgodne z ARM64, w przeciwnym razie powstaje problem „urządzenie jest dostępne, ale nie może wejść do sieci”.

Dla aplikacji Delphi oznacza to: jeśli np. korzystacie z certyfikatów ze sklepu certyfikatów Windows lub wykonujecie TLS przez komponenty systemowe, jest to zazwyczaj mniej krytyczne niż sytuacja, gdy specyficzna zewnętrzna biblioteka kryptograficzna (DLL) działa wewnątrz procesu.

Macierz decyzyjna: emulacja czy natywne portowanie na ARM64?

Firma musi podjąć decyzję odzwierciedlającą realia wsparcia i cyklu życia. Proste pytanie tak/nie („Czy portujemy?”) rzadko bywa pomocne. Lepsza jest macierz, która ważeniem uwzględnia zależności i ryzyka:

• Czysty klient ze standardowymi API Windows (plik, sieć, druk przez standardowe sterowniki): emulacja może wystarczyć krótkoterminowo; natywne ARM64 jest w średnim terminie bardziej porządne.
• Klient z wieloma natywnymi DLL-ami firm trzecich (PDF, OCR, sprzęt): najpierw sprawdzić dostępność, potem podjąć decyzję. Często sensowna ścieżka hybrydowa.
• Klient z COM-DLL-ami / rozszerzeniami powłoki: należy spodziewać się konfliktów architektonicznych; rozważyć odseparowanie poza procesem.
• Klient z bezpośrednim zestawem sterowników baz danych: albo skonsolidować sterowniki, albo przenieść dostęp do danych do usług.
• Wysokie wymogi regulacyjne / podpisy / smartcardy: wcześnie zweryfikować zgodność łańcucha zabezpieczeń i warstwy pośredniej z ARM64.

Ważne: emulacja nie jest „drugą klasą”, ale stanowi ryzyko operacyjne, jeśli planujecie długoterminowo widzieć urządzenia ARM64 w infrastrukturze. Najpóźniej przy większych aktualizacjach, zmianie sterowników lub zmianie agentów bezpieczeństwa nie chcecie utknąć w łańcuchu wyjątków.

Wiarygodny plan migracji: od dziś do ARM64 bez podejścia Big Bang

Dla działów IT i osób odpowiedzialnych za projekt ścieżka jest dobra, jeśli można ją wprowadzać falami, ma jasne kryteria akceptacji i nie przeciąża wsparcia. W środowiskach Delphi sprawdzone jest podejście pięcioetapowe.

Krok 1: Inwentaryzacja z perspektywy operacyjnej

Zidentyfikuj nie tylko moduły, ale przede wszystkim punkty operacyjne:

• Jakie klasy urządzeń: laptopy, urządzenia klasy Rugged, terminale?
• Jakie peryferia: drukarki, skanery, czytniki kart, drukarki etykiet?
• Jakie integracje: Office, DMS, ERP, usługi lokalne, komponenty przeglądarki?
• Jaka forma instalacji: MSI, Setup-EXE, ClickOnce, ręczna instalacja?
• Jakie uprawnienia: konieczne konto administratora, usługi lokalne, reguły zapory?

Ta perspektywa szybko ujawnia, czy „tylko jeden klient” w rzeczywistości oznacza pięć zależności systemowych.

Krok 2: sprawdzenie zgodności z reprezentatywnym urządzeniem pilotażowym ARM64

Urządzenie pilotażowe nie powinno być „najładniejszym sprzętem”, lecz typowym kandydatem z docelowej floty. Świadomie testuj krytyczne ścieżki: druk we wszystkich wariantach, eksport/import, podpis, tryb offline/online, aktualizacje, przełączanie tenantów, scenariusze z Proxy/VPN. Dokumentuj odchylenia jako zdarzenia operacyjne, nie jako błędy deweloperskie. Dzięki temu priorytetyzacja pozostaje klarowna.

Krok 3: redukcja zależności – najpierw te o największym wpływie na wsparcie

Typowe działania, które w codziennej eksploatacji przynoszą dużo korzyści:

• Standaryzacja ścieżki PDF/druku: odejście od własnościowych DLL drukarek na rzecz stabilnych, przetestowanych potoków.
• Oddzielenie integracji z Office: zamiast In-Process-Add-ins lepiej rozważyć formaty eksportu i generowanie dokumentów po stronie serwera.
• Konsolidacja dostępu do bazy danych: zdefiniowana ścieżka sterownika zamiast „ODBC zależnie od stanowiska”.
• Oddzielanie integracji sprzętowej: jeśli to możliwe przez zewnętrzne procesy/usługi, które można aktualizować niezależnie.

Krok 4: modernizacja wdrażania i możliwości aktualizacji

ARM64 to dobry pretekst, by uporządkować instalację i aktualizacje. Dla przedsiębiorstw ważne są nie funkcje, lecz możliwość przywracania, odtwarzalność i zgodność z politykami. Sprawdź:

• Pakietowanie: MSI vs. MSIX (MSIX to nowoczesny format pakietów aplikacji Microsoftu zapewniający czystą instalację/deinstalację i podpisywanie).
• Podpisywanie: Code Signing (cyfrowy podpis EXE/DLL) zmniejsza problemy ze SmartScreen i EDR oraz jest istotne przy kontrolowanych wdrożeniach.
• Zarządzanie konfiguracją: oddzielenie plików aplikacji od konfiguracji, czytelne ścieżki, brak „ukrytych” zależności w rejestrze.
• Kanały aktualizacji: pilot, Ring 1, Ring 2 – z telemetrią/logowaniem na poziomie aplikacji i operacyjnym.

Krok 5: natywne buildy ARM64 tam, gdzie rzeczywiście się opłaca

Natywne buildy ARM64 mają sens, gdy (a) masz opanowane zależności i (b) aplikacja będzie rozwijana długoterminowo. Zazwyczaj opłaca się to dla kluczowych klientów używanych codziennie przez wielu użytkowników i planowanych do modernizacji. Dla rzadko używanych narzędzi emulacja x64 może być akceptowalnym rozwiązaniem przejściowym, o ile wsparcie i bezpieczeństwo na to pozwalają.

Impulsy architektoniczne: ARM64 jako okazja do wzmocnienia interfejsów i usług

Wiele Delphi-środowisk historycznie rozwinęło się jako „gruby klient”. To działa, ale wiąże operacje i aktualizacje silniej z pojedynczymi konfiguracjami stanowisk. ARM64 uwidacznia, gdzie to sprzężenie staje się kosztowne. Pragmatyczny krok modernizacyjny często nie polega na „nowym UI”, lecz na nowych interfejsach.

Większa stabilność dzięki przeniesieniu odpowiedzialności na serwer

Gdy krytyczna logika, dostęp do danych lub procesy dokumentowe przeniosą się do centralnej usługi (Windows- i Linux-usługi lub Linux-usługa, czyli usługa działająca w tle bez interaktywnego UI), zyskujesz:

• jednolite wersje sterowników i bibliotek,
• lepiej kontrolowane bezpieczeństwo (certyfikaty, sekrety, sieć),
• mniejsza złożoność po stronie klienta (ARM64, x64, w przyszłości także inne platformy),
• jaśniejsze punkty monitoringu i logowania.

Dla decydentów IT to realna przewaga operacyjna: problemy są szybciej odtwarzalne po stronie serwera, zamiast utknąć na „specjalnym notebooku”.

REST-API jako warstwa odseparowania

REST-API nie jest automatycznie „nowoczesne”, ale stanowi solidną warstwę odseparowania między klientami a backendem. Definiuje jasno, które dane i akcje są dozwolone, i można ją solidnie zabezpieczyć (np. przy użyciu tokenów, certyfikatów lub SAML 2.0 jako standardu tożsamości w środowiskach korporacyjnych). Dla ARM64 oznacza to: klient musi wiedzieć mniej „o świecie” baz danych, sterowników i szczegółów sieciowych.

Nawet jeśli nie przerzucą Państwo wszystkiego od razu: już niewielki, dobrze ograniczony moduł API (np. generowanie dokumentów, weryfikacja licencji, synchronizacja danych podstawowych) może usunąć zależności z klienta i w ten sposób zmniejszyć ryzyka związane z ARM64.

Test i jakość: co powinni Państwo sprawdzać inaczej przy ARM64

Wiele zespołów testuje oprogramowanie desktopowe głównie funkcjonalnie. Przy ARM64 warto silniej koncentrować się na testach operacyjnych, ponieważ obrazy błędów są inne: nie „błędne obliczenie”, lecz „komponent się nie ładuje”, „brak sterownika”, „aktualizacja nie powiodła się”, „integracja z Office przestaje działać”.

Lista kontrolna dla odbioru bliskiego ARM64

• Instalacja/Deinstalacja: czysto, bez pozostałości, bez obejść wymagających uprawnień administratora.
• Ścieżka aktualizacji: uaktualnienie przez kilka wersji, scenariusz przywracania (rollback), weryfikacja podpisu.
• Logowanie: centralne logi, jednoznaczne kody błędów przy problemach z ładowaniem DLL, przejrzyste ścieżki wydruku.
• Wydajność: czas uruchamiania, operacje na danych, duże listy/raporty – mierzyć oddzielnie pod emulacją i natywnie.
• Urządzenia peryferyjne: profile drukarek, druk specjalny, workflowy skanera, funkcje kart inteligentnych.
• Bezpieczeństwo: interakcja EDR/AV, proxy/TLS, magazyn certyfikatów, działanie w modelu najmniejszych uprawnień.

Ważna jest dokumentacja: jeśli problem wynika z brakujących sterowników ARM64, to nie jest to „Bugfix in Delphi”, lecz decyzja zakupowa lub standaryzacyjna.

Operacje i wsparcie: jak zintegrować ARM64 z codzienną pracą

W codziennej eksploatacji liczy się, jak szybko rozwiązywane są zgłoszenia serwisowe. Dla ARM64 opłaca się proaktywnie zwiększyć możliwość wsparcia:

Standardyzowane profile urządzeń i jasne akceptacje

Zdefiniujcie wspierane modele ARM64 lub przynajmniej profile minimalne (strategia sterowników, strategia drukowania, wersje agentów security). „Działa na ARM64” bez takiego uściślenia prowadzi do niejednolitych środowisk i tym samym do trudniej odtwarzalnych awarii.

Możliwość diagnostyki w aplikacji

Nawet bez nastawienia na deweloperów przydatne jest, aby oprogramowanie oferowało jasne narzędzia: strona informacji systemowej pokazująca architekturę (x64 emulowany vs. ARM64 natywny), kluczowe ścieżki, wersje komponentów rdzeniowych i konfigurację drukowania znacząco skraca czas wsparcia. To nie jest „miły dodatek”, lecz higiena operacyjna.

Licencjonowanie i dongle

Gdy w grę wchodzą dongle sprzętowe lub starsze sterowniki licencyjne, ARM64 szybko staje się krytyczny. W wielu środowiskach sensowne jest przeniesienie licencjonowania na mechanizmy sieciowe lub serwerowe. Dzięki temu zależność od sterowników na stacjach końcowych maleje, a flota staje się łatwiej wymienialna.

Co to oznacza dla Państwa strategii Delphi?

Delphi jest w kontekście przedsiębiorstwa często stabilnym elementem dla klientów desktopowych i serwisów. Windows 11 ARM64 nie jest argumentem „przeciwko Delphi”, lecz argumentem za czystszą enkapsulacją zależności i za modernizacją ukierunkowaną na eksploatację: mniej lokalnych sterowników specjalnych, mniej komponentów działających w tym samym procesie, jaśniejsze interfejsy, lepsze wdrażanie.

Jeśli są Państwo już na ścieżce modernizacji (np. BDE-zastąpienie, przejście na 64‑bity, mocniejsza integracja REST, skonsolidowany dostęp do danych z użyciem FireDAC), to ARM64 często jest „tylko” dodatkowym celem, który wyostrza priorytety. Jeśli natomiast Państwa aplikacja silnie zależy od starych sterowników, własnościowych DLL i specyficznych konfiguracji stanowisk, ARM64 jest sensowną okazją, by te ryzyka uczynić przejrzystymi i planowalnie je ograniczyć.

Wniosek: ARM64 to mniej projekt portowania, a bardziej projekt architektoniczny i eksploatacyjny

Dla przedsiębiorstw Windows 11 ARM64 jest przede wszystkim kwestią platformową w zakupach, bezpieczeństwie i wsparciu. W przypadku oprogramowania biznesowego opartego na Delphi powodzenie nie zależy od opcji kompilatora, lecz od łańcucha sterowników, DLL, integracji COM, dostępu do danych i procesów aktualizacji. Rzetelna droga to: najpierw uczynić widocznymi zależności i ścieżki operacyjne, następnie testować na urządzeniach pilotażowych, potem celowo odsprzęgać komponenty i profesjonalizować wdrażanie – oraz dostarczać natywne kompilacje ARM64 tam, gdzie przynoszą długoterminowe korzyści i stabilność.

Jeśli chcą Państwo wprowadzić Windows 11 ARM64 w swoim parku maszynowym i jednocześnie planowo zabezpieczyć aplikacje, peryferia i interfejsy oparte na Delphi, prosimy porozmawiać z nami o ustrukturyzowanej inwentaryzacji i realistycznej ścieżce migracji:

W środowisku merytorycznym istotną rolę odgrywają także Delphi ARM64 Windows i X64-Emulation Windows 11, gdy integracje, przepływy danych i dalszy rozwój muszą współgrać bez zakłóceń.

Omówić projekt lub przedsięwzięcie modernizacyjne z Net-Base.