Windows 11 ARM64 для Delphi-додатків планувати заздалегідь

Windows 11 ARM64 у B2B-практиці вже не просто випадок для технічних ентузіастів. Нові покоління ноутбуків, довший час роботи від батареї, сценарії «Always-on» і зростаюче бажання мати легкі мобільні робочі місця приводять до того, що компанії закуповують ARM64-клієнти — іноді цілеспрямовано, іноді побічно через стандартні моделі в рамках контракту. Для команд із розвиненим індивідуальним ПЗ це чіткий сигнал: ARM64 має бути врахований на ранніх етапах технічного планування, інакше згодом це перетвориться на дороге дооснащення.

У випадку Delphi-застосунків центральне питання рідко зводиться до «чи зможе Delphi це скомпілювати?». На практиці розгортання ARM64 майже завжди спотикається об периферію: нативні DLL, компоненти друку/сканування, драйвери баз даних, движки звітності, COM-інтеграції, інсталяційні рутини, підписування коду або билд-пайплайни, які потайки підтримують лише x64. Саме тому варто розглядати Windows 11 ARM64 як вимогу до архітектури та експлуатації — а не як чисто платформенну опцію.

У цьому матеріалі показано типові технічні підводні камені для Delphi, як системно ідентифікувати ризики та які прагматичні шляхи міграції себе виправдали — від поетапної підготовки окремих модулів до чіткої цільової архітектури з сервісами й REST-серверами.

Чому Windows 11 ARM64 тепер тема архітектури

У багатьох компаніях «Windows» довгий час синонімізувався з x86/x64. Це припущення закладено в скриптах, інсталяторах, компонентах сторонніх виробників і іноді навіть у моделі даних (наприклад, шляхи, ключі реєстру, інтерфейси драйверів). Щойно з’являються ARM64-клієнти, стає видно, скільки неявного знання міститься в системі. І саме в цьому економічна суть: пізні доробки — це не «кілька прапорців компілятора», а прибирання припущень, що накопичувалися роками.

Практично ARM64 набуває значення насамперед у трьох ситуаціях:

• Клієнтське ПЗ з тривалим життєвим циклом: фахові програми, які використовують 8–15 років і поступово доповнюють. Нова клієнтська платформа посеред життєвого циклу ймовірніша, ніж повний ребілд.
• Змішані парки: виїзний/сервісний персонал, ноутбуки керівництва, сценарії близькі до BYOD або дочірні компанії, що закуповують іншу апаратну платформу.
• Тиск безпеки та відповідності: сучасне підписування коду, жорсткіші заходи захисту, принцип «least privilege», контрольовані механізми оновлення — при цьому інсталяційні та оновлювальні процеси все одно змінюють. Саме тоді ARM64 зручно інтегрувати як супутню вимогу.

Хороша новина: хто вже працює над Delphi Modernisierung, переходом на 64 біта, розпаралелюванням доступів до даних або сервіс-орієнтованою цільовою архітектурою, часто може «прив’язати» Windows 11 ARM64 до існуючих завдань — за умови, що це стоїть у беклозі раніше, ніж перша ARM-машина опиниться у підтримці.

Delphi на ARM64: що «легко», що «важко»?

Delphi-проєкти сильно відрізняються: від чистих VCL-десктоп-клієнтів до багатошарових систем із REST-серверами, Windows-сервісами, воркерами звітності, інтеграційними компонентами та фоновими задачами. Для Windows 11 ARM64 критично, які частини дійсно повинні запускатися нативно на клієнті, а які доцільно винести в сервіси.

Компилятор рідко є головною проблемою

Якщо власний код чистий (немає inline-асемблера, старих 32-бітних припущень, нестійких приведень вказівників, застарілих викликів API), компіляція під нову цільову платформу часто здійсненна. Проблеми виникають через:

• Компоненти сторонніх виробників з нативними частинами (DLL, BPL, C/C++-містки)
• Драйвери та підключення пристроїв (друк, сканування, підписні панелі, dongle)
• Доступ до бази даних через ODBC/OLE DB/клієнтські бібліотеки, які не підтримують ARM64
• Звітність та інтеграція з офісом (COM-автоматизація, старі фільтри експорту)
• Інсталятори/Оновлювачі, які тестують лише x64 або використовують жорстко задані шляхи

Отже, Windows 11 ARM64 насамперед — це «екосистемний тест»: наскільки добре ваш програмний пакет відокремлений від старих платформних припущень?

VCL, FMX і залежності UI

Багато B2B-фахових застосунків базуються на VCL і використовують десятиліттями нарощувані UI-компоненти. Це не є проблемою саме по собі — але UI часто концентрує залежності: PDF-друк, генератори штрихкоду, бібліотеки для зображень, браузерні контролі, COM-об’єкти. Для ARM64 справедливо правило: чим більше спеціалізованих компонентів, наближених до UI, тим важливішим стає ранній перелік сумісності.

У мультиплатформних стратегічних сценаріях (наприклад, Windows + macOS) часто з’являється FMX. Незалежно від фреймворка, надійна стратегія — відділити предметну логіку й інтеграції від UI. Це працює як для Delphi Multiplattform, так і для Windows 11 ARM64.

Типові технічні підводні камені (і як їх рано виявити)

На практиці більшість ARM64-проблем можна виявити на ранній стадії, якщо провести структуровану інвентаризацію і перевірку «ARM64 Readiness». Важливо дивитися не лише код Delphi, а все, що належить до продукту: інсталятори, драйвери, конфігурації, плагіни, сторонні інструменти, ланцюжок оновлень, скрипти підтримки.

1) Нативні DLL, BPL і змішані процесні ландшафти

Багато Delphi-застосунків завантажують додаткові DLL: криптографію, CAD-оглядачі, OCR, підписи, SDK для апаратури, спеціальні парсери. На x64 часто мовчазно припускають, що «є 64-бітна DLL». Для ARM64 це інакше: вам потрібні явні ARM64-бінарники або архітектура, яка виводить цю залежність із клієнта.

Практичний підхід:

• Складіть перелік усіх завантажуваних нативних модулів (включно з опосередкованими через компоненти).
• Класифікуйте: «ARM64 доступний», «лише x64», «лише 32-bit», «невідомо».
• Оцініть, чи модуль дійсно має бути локальним, чи може бути винесений у сервіс.

Частий висновок: один x64-only модуль блокує весь ARM64-клієнт. Це момент, коли окупається чиста шарова або Layer-3 Architektur: UI/клієнт залишається легким, інтеграції мігрують у контрольовані серверні/сервісні шари.

2) COM, Office-автоматизація і Shell-інтеграції

У багатьох компаніях експорт у Word/Excel, інтеграція з Outlook, контекстні меню Explorer або інтеграції DMS історично реалізовані через COM. COM не є автоматично «готовим до ARM64», особливо якщо COM-сервери або аддіни від сторонніх постачальників постачаються лише для x64. Також робота зі змішаними 32-/64-бітними процесами (Out-of-Proc vs. In-Proc) швидко ускладнюється.

Раннє прояснення:

• Які COM-об’єкти використовуються (список ProgIDs/CLSID)?
• In-Proc чи Out-of-Proc? Чи є реєстрації для ARM64?
• Чи можна замінити Office-автоматизацію серверними бібліотеками для експорту документів (наприклад, документ-орієнтовані формати)?

Часто це важіль модернізації: від UI-зв’язаної автоматизації — до відтворюваних експорт-сервісів (наприклад, PDF/Excel через бібліотеку), які можна використовувати як на Windows x64, так і на ARM64 або навіть на Linux-серверах.

3) Доступ до бази даних: ODBC, клієнтські бібліотеки, спадщина BDE

Доступ до даних — це типова точка, де виникають інтерфейси ARM64, оскільки тут важливі ландшафти драйверів і клієнтських бібліотек. Особливо критичні старі ODBC-настроювання, пропрієтарні клієнти баз даних або локальні бази з історичними шаром доступу.

Для Delphi-стеків це класика: якщо ще присутні Borland BDE, старі Paradox-структури або важко підтримувані ланцюжки драйверів, ARM64 стає каталізатором змін. BDE-Ablösung і перехід на BDE-Ablösung mit nativer Anbindung із чіткою стратегією DB-драйверів значно знижує ризики платформи.

Конкретні контрольні питання:

• Які СУБД використовуються (SQL Server, PostgreSQL, MariaDB, Firebird, локальні рушії)?
• Які драйвери застосовуються (ODBC, native client, BDE-Ablosung mit nativer Anbindung-драйвери, OLE DB)?
• Де зберігаються connection-strings і DSN (на користувача, на машину, в інсталяторі)?
• Чи є залежності від 32-бітних ODBC-драйверів або старих провайдерів?

Особливо для SQL Server/ODBC ARM64-клієнт може працювати — але лише за умови, що ланцюжок драйверів і процедура інсталяції налаштовані коректно. Це не те, що варто «дебажити в полі».

4) Звітність, друк, сканування, PDF та робочі процеси виводу

Вивід у фахових застосунках часто критичний для бізнесу: накладні, етикетки, рахунки, протоколи, показники лічильників, сертифікати, поштові етикетки. Багато таких робочих процесів залежать від компонентів звітності або спеціальних драйверів принтерів/сканерів.

На Windows 11 ARM64 типові проблеми:

• Драйвери спеціалізованих принтерів/етикеток доступні лише для x64
• Програмне забезпечення/SDK для сканерів без підтримки ARM64
• Старі звітні движки з нативними модулями прев’ю/експорту
• Генерація PDF через «віртуальні принтери» замість бібліотек

Надійний підхід — стандартизувати робочі процеси виводу: створення PDF/офісних форматів через бібліотеки, друк через стандартизовані інтерфейси, інкапсуляція доступу до спеціального обладнання. Там, де це неможливо, потрібна рання матриця пристроїв/драйверів для ARM64.

5) Інсталятори, оновлювачі, підписування коду та експлуатація

Багато ARM64-проєктів не зриваються через програму, а через доставку: інсталятор помилково визначає архітектуру, не інсталює драйвери, не реєструє COM, ставить неправильні шляхи або не проходить політики підписування коду. Також автоматичні оновлення (delta-updates, self-updater) часто залежать від архітектури.

Ключові питання для експлуатації:

• Як встановлюється ПЗ (MSI, Inno Setup, власний Updater)?
• Як інсталюються залежності (VC++ Runtimes, драйвери, сертифікати)?
• Як підписуються артефакти (EXE, DLL, інсталятор, пакети драйверів)?
• Як тестується: на реальному ARM64-обладнанні чи лише на припущеннях?

Для компаній це питання управління: поява Windows 11 ARM64 у клієнтському парку вимагає відтворюваного деплойменту — включно з відкатами, можливістю підтримки і чіткою версіонованістю.

Стратегія: Windows 11 ARM64 як «рання нефункціональна вимога»

Економічно обґрунтований підхід — розглядати ARM64 як нефункціональну вимогу (NFA) — подібно до продуктивності, безпеки або офлайн-можливостей. Це означає: не чекати спринту «коли загориться», а визначити її як керівну межу для архітектури та ланцюжка поставки.

ARM64-Readiness-Check: інвентар замість інтуїції

Наскільки такий чек має сенс: типовий обсяг перевірки охоплює:

• Інвентар залежностей: усі сторонні компоненти, DLL, драйвери, SDK, браузерні контроли, криптомодулі, звітність.
• Аналіз билд-/пайплайнів: цілі збірки, пакування, підписування, зберігання артефактів, нумерація версій, відтворюваність.
• Ланцюжок інсталяції/оновлення: логіка setup, prerequisites, шляхи в реєстрі/файловій системі, політики, права.
• Операційна модель: підтримка, логування, дампи збоїв, телеметрія (якщо є), план rollout.

Результат має бути не «ARM64: так/ні», а пріоритезований список: які блокери існують, які модулі уражені, які є альтернативи і який рівень інвестицій реалістичний.

Матриця рішень: нативно на ARM64 чи розв’язати залежність?

Для кожної проблемної залежності потрібне чітке рішення:

• Можна замінити на ARM64-нативне: оновлення, зміна постачальника, перехід на іншу бібліотеку.
• Залежність можна винести: наприклад, у Windows-сервіс, фоновий воркер або центральний REST-сервер.
• Залежність має залишатися локально: наприклад, коли апарат підключений безпосередньо до клієнта. Тоді потрібні обов’язкові списки затвердженого ARM64-обладнання/драйверів.

Для інтеграцій винесення часто є найчистішим шляхом: клієнт лишається UI + предметні діалоги, складна інтеграційна логіка працює в контрольованих сервісах. Це одночасно допомагає з централізованими оновленнями, моделлю прав і тестованістю.

Архітектурні патерни, що роблять ARM64-проєкти стійкими

Якщо Windows 11 ARM64 закладено на ранньому етапі, можна прийняти кілька архітектурних рішень так, щоб уникнути дорогих переробок пізніше.

1) Чітка шаруватість: UI, предметна логіка, інтеграції, доступ до даних

У дорослих Delphi-клієнтів часто «все в одному процесі»: UI, бізнес-правила, доступ до даних, підключення DMS, друк і експорт. Це придатно для підтримки, поки платформа стабільна. Але щойно з’являються варіанти платформи (ARM64, можливо macOS, можливо термінальні сервіси), цінність чіткої шаруватості зростає.

Практична мета:

• Шар UI: мінімальний, тестований, без прямих залежностей від драйверів/SDK.
• Предметна логіка: максимально платформонезалежна, чітко змодельована.
• Шар інтеграції: інкапсулює COM, формати файлів, DMS/ERP-коннектори, SDK пристроїв.
• Доступ до даних: консолідований (наприклад, FireDAC), чіткі межі транзакцій, без розпорошених SQL-фрагментів.

Це не «теорія», а реальна економія: якщо проблемною виявиться лише інтеграційна частина, не потрібно перебудовувати весь клієнт.

2) Сервіси і REST-сервери як стабілізатор

Багато B2B-систем виграють від того, що центральні функції виконуються як REST-сервер або як Windows-/Linux-сервіси: перевірка прав, документообіг, валідація даних, експорт/імпорт, інтеграції з ERP/DMS/CRM. Коли ці функції виконуються серверно, складність на клієнті значно знижується — а отже й площа атаки ARM64 зменшується.

Типові розподіли, що себе виправдали:

• Клієнт: діалоги, відображення, офлайн-логіка (якщо потрібно), мінімальні локальні інтеграції.
• REST-сервер: предметні операції, валідація, мульти-орендність, централізоване логування.
• Worker/Service: задачі за розкладом, опитування інтерфейсів, генерація звітів, пакетні експорти.

Це також узгоджується з сучасними моделями експлуатації: функція, що працює серверно, оновлюється один раз — замість оновлення на кожному ARM64-клієнті окремо.

3) Система збірки з кількома таргетами (x64 + ARM64) з самого початку

Якщо ARM64 — ціль, пайплайн збірки має це відображати. Не як «ми зробимо окрему збірку пізніше», а як стандарт: кожна реліз-кандидатна версія будується відтворювано для x64 (і, якщо передбачено, для ARM64), включно з підписуванням і пакуванням інсталятора.

Важливіше не інструменти, а дисципліна:

• Чітке найменування артефактів (архітектура в імені пака/структурі папок).
• Окремі конфігураційні значення на таргет (шляхи, prerequisites, пакети драйверів).
• Smoke-тести для кожної архітектури (запуск, логін, підключення до БД, друк/PDF).

Так ARM64 не стає «великою вибуховою зміною», а контролюваною додатковою ціллю.

Delphi-модернізація: ARM64 як можливість цілеспрямовано погасити технічний борг

Багато компаній використовують нові вимоги платформи як привід для «всього перекласти наново». Це ризиковано і часто невиправдано. Економічно вигідніше розглядати Windows 11 ARM64 як орієнтир для поступової модернізації: погасити технічний борг там, де він блокує ARM64 або ставить під загрозу доставку.

64-біт і Unicode: не відкладати старі проблеми

Якщо в кодовій базі залишилися 32-бітні припущення або загони з ранніх версій Delphi, вони вийдуть на поверхню при зміні платформи. Хоч ARM64 не означає автоматично «Unicode», багато проєктів, які серйозно беруться за ARM64, одночасно вирішують питання коректної підтримки Unicode, встановлення 64-бітних шляхів і очищення проблем з пам’яттю/вказівниками.

Мета — не ідеал, а надійний стандарт: код, який можна збирати під нові таргети без постійного відтворення тих самих класів помилок.

BDE-Ablösung і консолідований доступ до даних як енabler для ARM64

Де ще є історичні шари доступу (BDE, локальні Paradox-дані, змішані доступи), консолідація стає важелем із мультиефектом: код стає більш підтримуваним, деплоя — стабільнішим, стратегія драйверів — зрозумілішою. За допомогою FireDAC доступ у багатьох сценаріях можна уніфікувати, включно з централізованим керуванням параметрами, пулінгом та чіткою обробкою помилок.

Важливо: BDE-Ablösung — це не просто «замінити компонент». Вона зачіпає транзакційну логіку, типи даних, сортування, семантику фільтрів і частково модель даних. Тому її треба планувати — а не виконувати як аварійний захід, коли ARM64-клієнти раптово з’являться в полі.

Тестування і забезпечення якості: ARM64 керований лише тоді, коли він вимірюваний

Раннє закладення ARM64 означає також: необхідно тестувати — не повний тест кожної функції, а цілеспрямоване тестування ризикових ланцюгів. Найважливіший крок — мати реальне ARM64-тестове середовище. Емуляція інколи допомагає у вузьких випадках, але не замінює практики на реальному залозі, з реальними драйверами і політиками безпеки.

Мінімальний ARM64-smoke-тест: що справді треба покрити раніше

Прагматичний, але ефективний набір smoke-тестів для кожної реліз-кандидатної версії:

• Запуск програми, логін, базові UI-функції
• Підключення до БД (включно з автентифікацією, сертифікатами, DNS/проксі, якщо актуально)
• Один ключовий процес «end-to-end» (наприклад, створити замовлення, зберегти, роздрукувати/експортувати)
• Оновлювач/Інсталятор: чиста інсталяція та оновлення між версіями
• Логування/діалог помилок: чи придатні діагнози на ARM64?

Так ранньо виявляються типові блокери ARM64: відсутні DLL, неправильні драйвери, проблеми setup, неочікувані запити прав.

Діагностична спроможність: дампи, логи, прозорість версій

Коли ARM64 у флоті, з’являться кейси підтримки — щонайменше через нові конфігурації драйверів. Тому має сенс стандартизувати діагностику: чіткі build-ID, інформативні логи, відтворювані шляхи інсталяції й оновлення. Це не суто ARM64-питання, але ARM64 робить недоліки тут особливо накладними.

Розгортання і експлуатація: змішані парки без хаосу

Більшість компаній у середньостроковій перспективі працюватимуть зі змішаними клієнтськими парками: частина — x64, частина — ARM64. Ключ — управляти цим станом свідомо.

Пакетування: окремі інсталятори, чітке виявлення, однозначні шляхи завантаження

Найпрацездатніший підхід у практиці — інсталятори/пакети, які однозначно марковані: x64-пакет — для x64, ARM64-пакет — для ARM64. «Один інсталятор для всього» зручний, але швидко ускладнюється (логіка перевірок, prerequisites, шляхи драйверів, підписування, ремонтна інсталяція). Для контрольованого корпоративного rollout однозначність часто більш стійка.

Стратегія оновлень: без окремих шляхів для ARM64

ARM64 не повинен бути винятком в процесі оновлення. Мета: однакова частота релізів, однакові номери версій функціоналу, але окремі артефакти. Якщо ARM64 оновлюється лише «вручну», виникають розбіжності в парку, що згодом підвищують витрати на підтримку.

Документуйте інтеграції

Багато проблем з ARM64 пов’язані не з власним кодом, а з інтеграціями: ERP-коннектор, DMS-клієнт, сервіс підпису, ПЗ сканера, драйвери для етикеток. Оновлений реєстр інтеграцій з версіями і вказівками щодо архітектури корисний для будь-якої B2B-системи — і робить рішення по ARM64 прозорими.

Що компанії повинні робити зараз (без паніки)

Раннє врахування Windows 11 ARM64 не означає негайну перебудову всього. Йдеться про те, щоб рано відповісти на правильні питання і усунути блокери, доки зусилля залишаються планованими. Перевірена послідовність дій:

• 1) Інвентаризація (2–10 днів залежно від розміру системи): залежності, інсталятори, драйвери, доступ до даних, COM, звітність.
• 2) Цільове бачення і шлях: що має працювати нативно на клієнті? Що винести в сервіс/REST? Які компоненти замінюються?
• 3) Proof of Feasibility: робоча ARM64-збірка з інсталятором і end-to-end кейсом.
• 4) Поетапне зміцнення: решта функцій, тести, ланцюжок оновлень, діагностична спроможність.

Так не виникає окремого «ARM64-проєкту», що йде місяцями в ізоляції, а відбувається контрольоване розширення можливості доставки.

Висновок: Windows 11 ARM64 — не хайп, а ранній індикатор технічної зрілості

Windows 11 ARM64 для багатьох компаній стане реальністю — через закупівлю апаратури, вимоги мобільності або стандартизацію. Для Delphi-застосунків справжній виклик — не лише вихідний код, а ціла система залежностей, процеси інсталяції й оновлення, інтеграції й драйвери. Хто враховує ARM64 на ранньому етапі, може структуровано вирішити ці питання замість того, щоб виправляти їх пізніше в стресових умовах.

Наприкінці ARM64 — корисний тест: наскільки ваша програма відокремлена, тестована й готова до доставки? Відповівши на це зараз, ви отримаєте не лише додаткові платформні опції, а й стабільнішу базу для модернізації, сервісів, REST-архітектур і довготривалої підтримуваності.

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.