Wcześnie zaplanuj Windows 11 ARM64 dla aplikacji Delphi

Windows 11 ARM64 nie jest już w codziennej pracy B2B tylko wyjątkiem dla entuzjastów technologii. Nowe generacje notebooków, dłuższy czas pracy na akumulatorze, scenariusze „always-on” i rosnące zapotrzebowanie na lekkie, mobilne stanowiska pracy powodują, że firmy kupują klienty ARM64 – czasem świadomie, czasem przy okazji w ramach standardowych modeli w umowie ramowej. Dla zespołów z rozwiniętym oprogramowaniem indywidualnym to wyraźny sygnał: ARM64 musi być uwzględnione wcześnie w planowaniu technicznym, inaczej później powstanie kosztowny projekt doposażenia.

W przypadku Delphi-aplikacji centralne pytanie rzadko brzmi „czy Delphi to skompiluje?“. W praktyce wdrożenia ARM64 niemal zawsze zawodzą z powodu peryferii: natywnych DLL, komponentów druk/scan, sterowników baz danych, silników raportujących, integracji COM, rutyn instalacyjnych, podpisywania kodu lub potoków buildów, które domyślnie znają tylko x64. Właśnie dlatego opłaca się traktować Windows 11 ARM64 jako wymaganie architektoniczne i operacyjne – nie tylko jako funkcję platformy.

Ten artykuł pokazuje, jakie techniczne pułapki typowo występują przy Delphi, jak systematycznie identyfikować ryzyka i jakie pragmatyczne ścieżki migracji się sprawdziły – od stopniowego przygotowania pojedynczych modułów po klarowną architekturę docelową z serwisami i REST-serwerami.

Dlaczego Windows 11 ARM64 jest teraz tematem architektonicznym

W wielu firmach „Windows” przez długi czas było tożsame z x86/x64. To założenie tkwi w skryptach, instalatorach, komponentach third-party, a czasem nawet w modelu danych (np. ścieżki, klucze rejestru, interfejsy sterowników). Gdy pojawiają się klienty ARM64, staje się widoczne, ile implikowanego Wissen jest w systemie. I to jest ekonomiczne sedno: późne dostosowania to nie tylko „kilka flag kompilatora”, lecz sprzątanie założeń, które utrwaliły się przez lata.

Praktyczne znaczenie ARM64 rośnie szczególnie w trzech sytuacjach:

• Oprogramowanie klienckie o długim okresie użytkowania: aplikacje branżowe używane przez 8–15 lat i rozwijane iteracyjnie. Nowa platforma klienta w środku cyklu życia jest bardziej prawdopodobna niż całkowity rewamp.
• Mieszane floty: służbowe/serwisowe komputery mobilne, notebooki kadry zarządzającej, scenariusze zbliżone do BYOD lub spółki zależne kupujące inną hurtownie sprzętu.
• Presja bezpieczeństwa i zgodności: nowoczesne code-signing, utwardzanie, zasada najmniejszego uprzywilejowania, kontrolowane mechanizmy aktualizacji – przy tych zmianach procesy instalacji i aktualizacji i tak są poddawane modyfikacji. Wtedy ARM64 można korzystnie dodać jako wymaganie uboczne.

Dobra wiadomość: kto i tak pracuje nad Delphi Modernisierung, przejściem na 64-bit, oddzieleniem dostępu do danych lub nad architekturą docelową z usługami, często może „pociągnąć” za sobą Windows 11 ARM64 – pod warunkiem, że temat jest wcześnie w backlogu, a nie dopiero gdy pierwsza maszyna ARM pojawi się w zgłoszeniu supportowym.

Delphi na ARM64: co jest „łatwe”, co jest „trudne”?

Projekty Delphi bardzo się różnią: od czystych VCL-desktopowych klientów po wielowarstwowe systemy z REST-serwerami, Windows-serwisami, workerami raportującymi, komponentami integracyjnymi i zadaniami backgroundowymi. Dla Windows 11 ARM64 kluczowe jest to, które części muszą naprawdę działać natywnie na kliencie, a które i tak sensownie wydzielić do usług.

Kompilator rzadko jest głównym problemem

Jeśli własny kod jest czysty (brak inline-assemblera, brak starych założeń 32-bitowych, brak kruchych rzutowań wskaźników, brak przestarzałych wywołań API), kompilacja na nowy target jest często wykonalna. Problemy pojawiają się z powodu:

• Komponentów third-party z natywnymi fragmentami (DLL, BPL, mostki C/C++)
• Sterowników i połączeń z urządzeniami (druk, skan, panele podpisu, dongle)
• Dostępu do baz danych przez ODBC/OLE DB/biblioteki klienckie, które nie są zgodne z ARM64
• Raportowania i integracji z Office (automatyzacja COM, stare filtry eksportu)
• Instalatorów/Updaterów, które testują tylko x64 lub używają na stałe zakodowanych ścieżek

Dlatego Windows 11 ARM64 jest przede wszystkim „testem ekosystemu”: jak dobrze Wasze oprogramowanie jest odłączone od starych założeń platformowych?

VCL, FMX i zależności UI

Wiele aplikacji B2B opiera się na VCL i wykorzystuje przez lata rosnące komponenty UI. To nie jest z definicji problem – ale UI często jest miejscem, gdzie koncentrują się zależności: drukarki PDF, generatory kodów kreskowych, biblioteki obrazów, kontrolki przeglądarkowe, obiekty COM. Dla Windows 11 ARM64 zasada jest prosta: im więcej komponentów blisko UI, tym ważniejsza jest wczesna lista zgodności.

W strategiach multiplatformowych (np. Windows + macOS) często pojawia się FMX. Niezależnie od frameworku solidną strategią jest oddzielenie logiki biznesowej i integracji od warstwy UI. To korzystnie wpływa zarówno na Delphi Multiplattform, jak i na Windows 11 ARM64.

Typowe techniczne pułapki (i jak je wcześnie wykryć)

W praktyce większość problemów z ARM64 da się wcześnie wykryć, jeśli przeprowadzicie uporządkowaną inwentaryzację i „ARM64 Readiness”-check. Kluczowe jest, by nie patrzeć tylko na kod Delphi, lecz na wszystko, co należy do produktu: instalatory, sterowniki, konfiguracje, pluginy, narzędzia trzecie, łańcuch aktualizacji, skrypty wsparcia.

1) Natywne DLL, BPL i mieszane środowiska procesów

Wiele aplikacji Delphi ładuje dodatkowe DLL: kryptografia, CAD-viewer, OCR, podpisy, SDK sprzętowe, specjalne parsery. Na x64 często przyjmuje się milcząco, że „istnieje wersja 64-bitowa”. Dla ARM64 jest inaczej: potrzebne są wyraźnie ARM64-binarne pliki lub architektura, która usuwa tę zależność z klienta.

Praktyczne podejście:

• Sporządź listę wszystkich ładowanych modułów natywnych (także pośrednich przez komponenty).
• Sklasyfikuj: „dostępne na ARM64”, „tylko x64”, „tylko 32-bit”, „niejasne”.
• Oceń, czy moduł musi być lokalny, czy można go przenieść do serwisu.

Częsty wniosek: pojedynczy moduł x64-only blokuje cały klient ARM64. To moment, w którym opłaca się klarowna warstwowa lub Layer-3 Architektur: UI/klient pozostaje lekki, a integracje przenoszone są do kontrolowanych warstw serwerowych/usługowych.

2) COM, automatyzacja Office i integracje z shellem

W wielu firmach eksport do Word/Excel, integracja z Outlook, menu kontekstowe Eksploratora czy integracje DMS opierały się historycznie na COM. COM nie jest automatycznie „gotowy na ARM64”, szczególnie jeśli COM-serverzy lub dodatki od dostawców zewnętrznych dostarczane są wyłącznie w x64. Również operowanie mieszanką 32-bit/64-bit (Out-of-Proc vs. In-Proc) szybko się komplikuje.

Wczesne ustalenia:

• Jakich obiektów COM używacie (lista ProgID/CLSID)?
• In-Proc czy Out-of-Proc? Czy istnieją rejestracje ARM64?
• Czy eksport można zrealizować przez biblioteki po stronie serwera (np. formaty dokumentowe) zamiast automatyzacji Office?

Często jest to dźwignia modernizacyjna: odejście od UI-sparowanej automatyzacji w kierunku powtarzalnych serwisów eksportowych (np. PDF/Excel przez bibliotekę), które nadają się zarówno dla Windows x64, jak i dla ARM64 czy nawet Linux-serwerów.

3) Dostęp do bazy danych: ODBC, biblioteki klienckie, legacy-BDE

Dostęp do danych to częste miejsce styku z ARM64, bo tu liczą się scenariusze sterowników i biblioteki klienckie. Szczególnie krytyczne są stare konfiguracje ODBC, proprietarne klienty baz danych lub lokalne bazy z historycznymi warstwami dostępu.

Dla stacków Delphi to klasyczny przypadek: jeśli w grze są jeszcze Borland BDE, stare struktury Paradox lub trudne do utrzymania łańcuchy sterowników, ARM64 staje się katalizatorem zmian. BDE-Ablösung i przejście na BDE-Ablösung mit nativer Anbindung z jasną strategią driverów DB zmniejsza ryzyko platformowe znacząco.

Konkretnie sprawdźcie:

• Jakie DB są używane (SQL Server, PostgreSQL, MariaDB, Firebird, silniki lokalne)?
• Jakie sterowniki są wykorzystywane (ODBC, natywny client, BDE-Ablosung mit nativer Anbindung-driver, OLE DB)?
• Gdzie leżą connection-stringi i DSN (na użytkownika, na maszynę, w instalatorze)?
• Czy są zależności od 32-bitowych sterowników ODBC lub starych providerów?

Zwłaszcza przy SQL Server/ODBC klient ARM64 może działać – ale tylko jeśli łańcuch sterowników i procedury instalacyjne są poprawne. To nie jest coś, co warto debugować „w terenie”.

4) Raportowanie, druk, skan, PDF i workflowy outputu

Output w aplikacjach branżowych jest często krytyczny biznesowo: listy przewozowe, etykiety, faktury, protokoły, odczyty stanu liczników, zaświadczenia, etykiety wysyłkowe. Wiele tych workflowów opiera się na komponentach raportujących lub specyficznych sterownikach drukarek/skanerów.

Na Windows 11 ARM64 typowe pułapki to:

• Sterowniki drukarek etykiet/specjalne sterowniki dostępne tylko w x64
• Oprogramowanie/SDK skanerów bez wsparcia ARM64
• Stare silniki raportowe z natywnymi modułami podglądu/eksportu
• Generowanie PDF przez „wirtualne drukarki” zamiast biblioteki

Robustowe podejście to standaryzacja workflowów outputu: generowanie PDF/formatów Office przez biblioteki, druk przez zunifikowane interfejsy, kapsułkowanie specyficznego dostępu do sprzętu. Tam, gdzie to niemożliwe, konieczna jest wczesna matryca urządzeń/sterowników dla ARM64.

5) Instalator, updater, podpisywanie kodu i eksploatacja

Wiele projektów ARM64 nie pada z powodu programu, lecz z powodu dostawy: setup błędnie wykrywa architekturę, nie instaluje sterowników, nie rejestruje COM, ustawia błędne ścieżki lub zawodzą polityki podpisywania kodu. Również automatyczne aktualizacje (delta-updates, self-updater) są często silnie zależne od architektury.

Kluczowe pytania operacyjne:

• Jak się instaluje (MSI, Inno Setup, własny updater)?
• Jak instalowane są zależności (VC++ Runtimes, sterowniki, certyfikaty)?
• Jak jest podpisywane (EXE, DLL, instalator, paczki sterowników)?
• Jak testujecie: na rzeczywistym sprzęcie ARM64 czy tylko zakładając?

Dla firm to kwestia governance: gdy Windows 11 ARM64 pojawia się w flocie klientów, deployment musi być odtwarzalny – włącznie z rollbackem, możliwością wsparcia i jasną wersjonowalnością.

Strategia: Windows 11 ARM64 jako „wczesne wymaganie niefunkcjonalne”

Ekonomicznie sensowne podejście to traktowanie ARM64 jak wymagania niefunkcjonalnego (NFA) – podobnie jak wydajność, bezpieczeństwo czy zdolność offline. To oznacza: nie dopiero w sprincie „gdy zaczyna palić”, lecz jako zdefiniowaną wytyczną dla architektury i łańcucha dostaw.

ARM64-Readiness-Check: inwentarz zamiast przeczucia

Rzetelny check obejmuje typowo:

• Inwentarz zależności: wszystkie komponenty third-party, DLL, sterowniki, SDK, kontrolki przeglądarkowe, moduły kryptograficzne, raportowanie.
• Analizę build/pipeline: cele builda, pakietowanie, podpisywanie, magazyn artefaktów, numeracja wersji, reprodukowalność.
• Łańcuch instalatora/aktualizacji: logika setupu, prerekwizyty, ścieżki rejestru/systemu plików, polityki, uprawnienia.
• Model operacyjny: wsparcie, logowanie, crash-dumpy, telemetria (jeśli jest), plan rolloutu.

Wynik nie powinien być jedynie „ARM64: tak/nie”, lecz priorytetyzowana lista: jakie blokery istnieją, które moduły są dotknięte, jakie są alternatywy i jaki nakład inwestycyjny jest realistyczny.

Macierz decyzji: natywnie na ARM64 czy rozdzielić?

Przy każdej problematycznej zależności warto podjąć jasną decyzję:

• Możliwy natywny zamiennik ARM64: upgrade, zmiana dostawcy, przejście na inną bibliotekę.
• Zależność da się wydzielić: np. do serwisu Windows, backgroundworkera lub centralnego REST-serwera.
• Zależność musi pozostać lokalna: np. gdy sprzęt jest bezpośrednio podłączony do klienta. Wtedy potrzebne są wiążące zgody sprzętowo-sterownikowe dla ARM64.

Dla integracji wydzielenie bywa najczystszym rozwiązaniem: klient pozostaje UI + dialogi branżowe, natomiast złożona logika integracyjna działa w kontrolowanych serwisach. To wspiera nie tylko ARM64, lecz także centralne aktualizacje, koncepcje uprawnień i lepszą testowalność.

Wzorce architektoniczne, które stabilizują projekty ARM64

Gdy Windows 11 ARM64 jest planowane wcześnie, można podjąć decyzje architektoniczne tak, by później nie trzeba było ich drogo odkręcać.

1) Jasne warstwy: UI, logika biznesowa, integracja, dostęp do danych

Rozwijane klientów Delphi często mają wszystko w jednym procesie: UI, reguły biznesowe, dostęp do danych, integrację DMS, druk i eksport. To jest utrzymywalne dopóki platforma pozostaje stabilna. Gdy jednak pojawiają się warianty platform (ARM64, ewentualnie macOS, ewentualnie terminalserver), rośnie wartość klarownej separacji warstw.

Pragmatyczny obraz docelowy:

• Warstwa UI: minimalna, testowalna, bez bezpośrednich zależności do sterowników/SDK.
• Logika biznesowa: możliwie neutralna względem platformy, dobrze zmodelowana.
• Warstwa integracji: kapsułkuje COM, formaty plików, konektory DMS/ERP, SDK urządzeń.
• Dostęp do danych: skonsolidowany (np. FireDAC), jasne granice transakcyjne, bez rozsianych fragmentów SQL.

To nie jest „akademia”, lecz oszczędność realnych kosztów: jeśli problem dotyczy tylko warstwy integracji, nie trzeba przekompilowywać całego klienta.

2) Serwisy i REST-serwery jako kotwica stabilności

Wiele systemów B2B zyskuje, przenosząc funkcje centralne jako REST-serwery lub jako Windows-/ Linux-serwisy: walidacja uprawnień, workflowy dokumentów, walidacja danych, eksport, import, integracje ERP/DMS/CRM. Gdy te funkcje działają po stronie serwera, złożoność po stronie klienta znacząco maleje – a razem z nią powierzchnia ataku ARM64.

Typowe podziały, które się sprawdzają:

• Klient: dialogi, prezentacja, logika offline (jeśli potrzebna), minimalne lokalne integracje.
• REST-Server: operacje biznesowe, walidacje, wielodostępność, centralne logowanie.
• Worker/Service: zadania czasowe, polling interfejsów, generowanie raportów, eksporty wsadowe.

To pasuje też do nowoczesnych modeli operacyjnych: funkcja po stronie serwera jest aktualizowana raz, zamiast na każdym kliencie ARM64 osobno.

3) System buildów, wiele targetów (x64 + ARM64) od początku

Jeśli ARM64 jest celem, pipeline builda powinien to odzwierciedlać. Nie jako „zrobimy później osobny build”, lecz jako standard: każda wersja kandydująca do wydania budowana jest reproducible dla x64 (i, jeśli przewidziano, ARM64), łącznie z podpisaniem i pakietowaniem instalatora.

Ważniejsza od narzędzi jest konsekwencja:

• Artefakty jasno nazywane (architektura w nazwie pakietu/strukturze folderów).
• Wartości konfiguracyjne rozdzielone per target (ścieżki, prerekwizyty, paczki sterowników).
• Smoke-testy zdefiniowane per architekturę (start, logowanie, połączenie z DB, druk/PDF).

Dzięki temu ARM64 nie staje się „Big Bangiem”, lecz kontrolowanym dodatkowym targetem.

Modernizacja Delphi: ARM64 jako okazja do ukierunkowanego spłacania długu technicznego

Wiele firm wykorzystuje nowe wymagania platformowe jako pretekst do „wszystko od nowa”. To ryzykowne i często niepotrzebne. Ekonomiczniej jest wykorzystać Windows 11 ARM64 jako wytyczną do stopniowej modernizacji: usuwać dług techniczny tam, gdzie blokuje ARM64 lub zagraża zdolności dostarczania.

64-bit i Unicode: nie zamiatać starych problemów pod dywan

Jeśli baza kodu wciąż zawiera założenia 32-bitowe lub balast z wczesnych wersji Delphi, ujawnią się one przy zmianie platformy. Chociaż ARM64 nie oznacza automatycznie „Unicode”, wiele projektów, które poważnie podchodziły do ARM64, jednocześnie upewniało się, że Unicode jest obsłużony poprawnie, że ścieżki 64-bitowe są ugruntowane i że kwestie pamięci/wskaźników zostały uporządkowane.

Celem nie jest perfekcja, lecz wiarygodny standard: kod, który da się budować dla nowych targetów bez powtarzania tych samych klas błędów.

BDE-Ablösung i skonsolidowany dostęp do danych jako enabler dla ARM64

Gdzie istnieją historyczne warstwy dostępu ( [[NBML_TERM_11_901e2bf2 ]], lokalne dane Paradox, mieszane podejścia do dostępu), konsolidacja jest dźwignią o wielokrotnym efekcie: bardziej utrzymywalny kod, stabilniejsze deploymenty, jasna strategia sterowników. Z FireDAC można ujednolicić dostęp w wielu scenariuszach, łącznie z centralnym zarządzaniem parametrów, strategiami poolingowymi i solidnym obsługiwaniem błędów.

Ważne: BDE-Ablösung to nie tylko „wymiana komponentów”. Dotyczy logiki transakcji, typów danych, sortowania, semantyki filtrów i częściowo modelu danych. Dlatego powinna być zaplanowana – a nie traktowana jako środek awaryjny, gdy klienci ARM64 nagle pojawią się w terenie.

Testy i zapewnienie jakości: ARM64 jest planowalne tylko, gdy staje się mierzalne

Wcześniejsze uwzględnienie ARM64 oznacza też: trzeba to testować – nie pełne pokrycie każdego feature’u, lecz skierowane testy ryzyka łańcucha krytycznego. Najważniejszy krok to posiadanie realnego środowiska testowego ARM64. Emulacja może w niektórych przypadkach pomóc, ale nie zastąpi praktyki na rzeczywistym sprzęcie, z prawdziwymi sterownikami i rzeczywistymi zasadami bezpieczeństwa.

Minimalny smoke-test ARM64: co rzeczywiście powinno być wcześnie pokryte

Pragmatyczny, lecz skuteczny zestaw smoke-testów dla każdej wersji kandydującej do wydania:

• Uruchomienie programu, logowanie, podstawowe funkcje UI
• Połączenie z DB (wraz z uwierzytelnianiem, certyfikatami, DNS/Proxy, jeśli istotne)
• Jeden kluczowy proces „end-to-end” (np. utworzenie zlecenia, zapis, druk/eksport)
• Updater/Installer: świeża instalacja i aktualizacja przez wersję
• Logowanie/okna błędów: czy diagnozy są przydatne także na ARM64?

Dzięki temu typowe blokery ARM64 stają się widoczne wcześnie: brakujące DLL, błędne sterowniki, problemy setupu, niespodziewane wymagania uprawnień.

Możliwość diagnozy: crash-dumpy, logi, przejrzystość wersji

Gdy ARM64 jest w flocie, pojawią się przypadki wsparcia – choćby z powodu nowych konfiguracji sterowników. Dlatego warto ustandaryzować diagnostykę: jasne build-ID, znaczące logi, reprodukowalne ścieżki instalacji i aktualizacji. To nie jest specyficzne dla ARM64, ale ARM64 szybko uwydatnia luki w tych obszarach i czyni je kosztownymi.

Rollout i eksploatacja: mieszane floty bez chaosu

Większość firm będzie pośrednio obsługiwać mieszane floty klientów: część x64, część ARM64. Kluczem jest świadome zarządzanie tym stanem.

Pakietowanie: oddzielne instalatory, jasne wykrywanie, jednoznaczne ścieżki pobierania

W praktyce najlepiej działa, gdy instalatory/paczki są jednoznaczne: pakiet x64 jest x64, pakiet ARM64 jest ARM64. „Jeden instalator dla wszystkiego” brzmi wygodnie, ale szybko się komplikuje (logika sprawdzania, prerekwizyty, ścieżki sterowników, podpisywanie, instalacja naprawcza). Dla kontrolowanych rolloutów korporacyjnych jednoznaczność jest często bardziej odporna.

Strategia aktualizacji: bez specjalnych ścieżek dla ARM64

ARM64 nie powinien być wyjątkiem w procesie aktualizacji. Cel: taka sama częstotliwość wydań, ten sam numer wersji funkcjonalnej, ale rozdzielone artefakty. Jeśli ARM64 aktualizowany jest „ręcznie”, powstają rozbieżności we flocie, które później windują koszty wsparcia.

Integracje dokumentować rzetelnie

Wiele problemów ARM64 nie tkwi w własnym kodzie, lecz w integracjach: konektor ERP, klient DMS, usługa podpisu, oprogramowanie skanera, sterownik drukarki etykiet. Prowadzona lista integracji z wersjami i wskazówkami architektonicznymi jest dla systemów B2B i tak zalecana – i czyni decyzje dotyczące ARM64 przejrzystymi.

Co firmy powinny teraz konkretnie zrobić (bez akcji na ślepo)

Wcześniejsze planowanie Windows 11 ARM64 nie oznacza natychmiastowego przebudowania wszystkiego. Oznacza zadanie właściwych pytań wcześnie i eliminowanie blockerów, dopóki wysiłek jest planowalny. Sprawdzone podejście to:

• 1) Inwentaryzacja (2–10 dni w zależności od rozmiaru systemu): zależności, instalator, sterowniki, dostęp do danych, COM, raportowanie.
• 2) Obraz docelowy i ścieżka: co musi działać natywnie na kliencie? Co będzie serwisem/REST? Które komponenty wymieniamy?
• 3) Proof of Feasibility: działający build ARM64 z instalatorem i end-to-end use-case.
• 4) Stopniowe utwardzanie: pozostałe funkcje, testy, łańcuch aktualizacji, zdolność diagnostyczna.

W ten sposób nie powstaje izolowany „projekt ARM64” trwający miesiącami, lecz kontrolowane rozszerzenie zdolności dostawy.

Fazit: Windows 11 ARM64 to nie hype, lecz wczesny wskaźnik dojrzałości technicznej

Windows 11 ARM64 stanie się dla wielu firm po prostu rzeczywistością – przez zakupy sprzętu, wymagania mobilności lub standaryzację. Dla aplikacji Delphi prawdziwym wyzwaniem nie jest wyłącznie kod źródłowy, lecz cały system zależności, procesy instalacji i aktualizacji, integracje i sterowniki. Kto planuje ARM64 wcześnie, może te punkty uporządkować strukturalnie, zamiast łatkę je później pod presją czasu.

Ostatecznie ARM64 jest użytecznym testem: jak dobrze Wasza aplikacja jest odseparowana, testowalna i dostarczalna? Jeśli odpowiecie na to pytanie teraz, zyskacie nie tylko opcje platformowe, lecz także stabilniejszą podstawę dla modernizacji, usług, architektur REST i długoterminowej utrzymywalności.

Skontaktuj się z Net-Base Software GmbH, jeśli chcesz rzetelnie ocenić Windows 11 ARM64 w roadmapzie Delphi i wdrożyć go z jasną ścieżką techniczną.