Раннее планирование Windows 11 ARM64 для Delphi-приложений

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

Bei Delphi-Anwendungen ist die zentrale Frage dabei selten „kann Delphi das kompilieren?“. На практике развёртывания ARM64 почти всегда терпят неудачу из‑за периферии: нативных DLL, компонентов печати/сканирования, драйверов баз данных, движков отчётности, COM‑интеграций, установочных процедур, подписывания кода или конвейеров сборки, которые молча поддерживают только x64. Именно поэтому имеет смысл рассматривать Windows 11 ARM64 как требование к архитектуре и эксплуатации — а не как чисто платформенную возможность.

В этой статье показано, какие технические подводные камни типично возникают в Delphi, как системно идентифицировать риски и какие прагматичные пути миграции себя оправдали — от поэтапной подготовки отдельных модулей до ясной целевой архитектуры с сервисами и REST-серверами.

Warum Windows 11 ARM64 jetzt ein Architekturthema ist

Во многих компаниях «Windows» долгое время было синонимом x86/x64. Это предположение заложено в скриптах, инсталляторах, компонентах третьих сторон и иногда даже в модели данных (например пути, ключи реестра, интерфейсы драйверов). Как только появляются ARM64‑клиенты, становится видно, сколько неявных допущений укоренилось в системе. И именно в этом заключается экономический смысл: поздние доработки — это не просто «пара флагов компилятора», а чистка допущений, которые накапливались годами.

Практически ARM64 становится особенно релевантным в трёх ситуациях:

• Клиентское ПО с долгим жизненным циклом: отраслевые приложения, используемые в течение 8–15 лет и развиваемые итеративно. Замена платформы клиента посреди жизненного цикла вероятнее, чем полный ребилд.
• Смешанные флоты: выездные/сервисные устройства, ноутбуки менеджмента, сценарии близкие к BYOD или дочерние предприятия, закупающие другую технику.
• Давление по безопасности и соответствию: современное подписывание кода, жёсткая хардениг, принцип наименьших привилегий, контролируемые механизмы обновления — при этом процессы установки и обновления уже подвергаются изменениям. Именно тогда интеграция ARM64 как сопутствующего требования выгодна.

Хорошая новость: если вы уже занимаетесь Delphi Modernisierung, переходом на 64‑бит, декуплированием доступа к данным или целевой сервисно‑ориентированной архитектурой, то Windows 11 ARM64 часто можно «включить» в эти процессы — при условии, что это поставлено в бэклог рано, а не решается впервые при появлении первой ARM‑машины в службе поддержки.

Delphi auf ARM64: Was ist „easy“, was ist „hard“?

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

Der Compiler ist selten das Hauptproblem

Если собственный код аккуратен (нет inline‑ассемблера, нет устаревших 32‑битных допущений, нет хрупких приведений указателей, нет устаревших вызовов API), компиляция под новую целевую платформу обычно возможна. Проблемы возникают из‑за:

• Компонентов третьих сторон с нативными частями (DLL, BPL, мосты C/C++)
• Драйверов и привязки устройств (печать, сканирование, планшеты подписания, донглы)
• Доступа к БД через ODBC/OLE DB/клиентские библиотеки, которые не поддерживают ARM64
• Отчётности и интеграции с Office (COM‑автоматизация, старые фильтры экспорта)
• Инсталляторов/апдейтеров, которые тестируют только x64 или используют жёстко заданные пути

Таким образом Windows 11 ARM64 прежде всего — это «тест экосистемы»: насколько ваше программное обеспечение отвязано от старых платформенных предпосылок?

VCL, FMX und UI-Abhängigkeiten

Многие B2B‑приложения основаны на VCL и используют наработанные годами UI‑компоненты. Это само по себе не проблема — но UI часто концентрирует зависимости: PDF‑принтеры, генераторы штрихкодов, библиотеки работы с изображениями, браузерные контролы, COM‑объекты. Для ARM64 действует правило: чем больше специализированных компонентов на уровне UI вы используете, тем важнее заранее составить список совместимости.

При мультиплатформенных стратегиях (например Windows + macOS) часто появляется FMX. Независимо от фреймворка устойчивой стратегией является отделение предметной логики и интеграций от UI. Это выгодно и для Delphi Multiplattform, и для Windows 11 ARM64.

Typische technische Stolpersteine (und wie man sie früh erkennt)

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

1) Native DLLs, BPLs und gemischte Prozesslandschaften

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

Практический подход:

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

Частая находка: один единственный модуль, работающий только на x64, блокирует весь ARM64‑клиент. Это тот момент, когда экономически оправданной становится чистая многослойная или Layer-3 Architektur: UI/клиент остаётся лёгким, интеграции переносятся в контролируемые серверные/сервисные слои.

2) COM, Office-Automation und Shell-Integrationen

Во многих компаниях экспорт в Word/Excel, интеграция с Outlook, контекстные меню Проводника или DMS‑интеграции исторически построены на COM. COM не обязательно «ARM64‑ready», особенно если сторонние COM‑серверы или надстройки поставляются только в x64. Управление смешанными 32‑/64‑битными сценариями (Out‑of‑Proc vs. In‑Proc) быстро становится сложным.

Ранняя проверка:

• Какие COM‑объекты используются (список ProgID/CLSID)?
• In‑Proc или Out‑of‑Proc? Есть ли ARM64‑регистрации?
• Можно ли заменить экспорт серверными библиотеками (например, документ‑ориентированными форматами) вместо Office‑автоматизации?

Часто это рычаг модернизации: от UI‑связанной автоматизации к воспроизводимым экспорт‑сервисам (например PDF/Excel через библиотеку), которые можно использовать и на Windows x64, и на ARM64 или даже на Linux‑серверах.

3) Datenbankzugriff: ODBC, Client-Libraries, Legacy-BDE

Доступ к данным — частое место столкновения с ARM64, так как здесь важны экосистемы драйверов и клиентских библиотек. Особенно критичны старые ODBC‑настройки, проприетарные клиентские драйверы или локальные базы с историческими слоями доступа.

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

Конкретные пункты проверки:

• Какие СУБД используются (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) Reporting, Druck, Scan, PDF und Output-Workflows

Вывод данных в отраслевых приложениях часто критичен для бизнеса: накладные, этикетки, счета, протоколы, показания счётчиков, сертификаты, транспортные этикетки. Множество таких рабочих процессов завязано на компоненты отчётности или на специфические драйверы принтеров/сканеров.

На Windows 11 ARM64 типичные подводные камни:

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

Надёжный путь — стандартизировать рабочие процессы вывода: генерировать PDF/Office‑форматы через библиотеки, печать через стандартизированные интерфейсы, по возможности инкапсулировать доступ к специальному оборудованию. Где это невозможно, нужна ранняя матрица устройств/драйверов для ARM64.

5) Installer, Updater, Code-Signing und Betrieb

Многие ARM64‑проекты ломаются не из‑за самого приложения, а из‑за доставки: установщик неверно определяет архитектуру, не ставит драйверы, не регистрирует COM, прописывает неправильные пути или сталкивается с политиками подписи кода. Автоматические обновления (дельта‑апдейты, self‑updaters) часто сильно завязаны на архитектуру.

Ключевые вопросы для эксплуатации:

• Как идёт установка (MSI, Inno Setup, собственный апдейтер)?
• Как устанавливаются зависимости (VC++ Runtimes, драйверы, сертификаты)?
• Как подписывается ПО (EXE, DLL, инсталлятор, пакеты драйверов)?
• Как тестируется: на реальном ARM64‑оборудовании или только на допущениях?

Для компаний это вопрос управления: если Windows 11 ARM64 появляется в клиентской парке, развёртывание должно быть воспроизводимым — включая откат, поддержку и ясную версионирование.

Strategie: Windows 11 ARM64 als „frühe Nicht-Funktionale Anforderung“

Экономически оправданный подход — рассматривать ARM64 как нефункциональное требование (NFA), аналогично производительности, безопасности или офлайн‑возможностям. Это значит: не решать «когда загорится», а определить руководящие рамки для архитектуры и цепочки поставки заранее.

ARM64-Readiness-Check: Inventar statt Bauchgefühl

Надёжная проверка обычно включает:

• Инвентарь зависимостей: все компоненты третьих сторон, DLL, драйверы, SDK, браузерные контролы, криптомодули, отчётность.
• Анализ сборки/пайплайна: цели сборки, упаковка, подпись, хранилище артефактов, номера версий, воспроизводимость.
• Цепочка инсталляции/обновления: логика Setup, пререквизиты, ключи реестра/пути в ФС, политики, права.
• Модель эксплуатации: поддержка, логирование, дампы аварий, телеметрия (если есть), план развёртывания.

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

Entscheidungsmatrix: Nativ auf ARM64 oder entkoppeln?

Для каждой проблемной зависимости нужна ясная стратегия:

• Возможна нативная замена под ARM64: апгрейд, смена вендора, переход на другую библиотеку.
• Зависимость можно вынести: например в Windows‑сервис, фоновый воркер или на централизованный REST-Server.
• Зависимость должна оставаться локальной: например когда оборудование напрямую подключено к клиенту. В этом случае требуются утверждённые ARM64‑аппаратные платформы и драйверы.

Для интеграций вынесение часто оказывается самым чистым решением: клиент остаётся UI + предметный диалог, а сложная интеграционная логика выполняется в контролируемых сервисах. Это помогает не только с ARM64, но и с централизованными обновлениями, правовой моделью и тестируемостью.

Architektur-Pattern, die ARM64-Projekte stabil machen

Если Windows 11 ARM64 заложен ранним, можно принять архитектурные решения так, чтобы позднее не приходилось дорого всё переделывать.

1) Klare Schichten: UI, Fachlogik, Integration, Datenzugriff

У выросших Delphi‑клиентов часто «всё в одном процессе»: UI, бизнес‑правила, доступ к данным, подключение DMS, печать и экспорт. Это можно поддерживать, пока платформа стабильна. Как только появляются платформенные варианты (ARM64, возможно macOS, возможно терминальные серверы), ценность чёткой слоистости возрастает.

Практическая цель:

• UI‑слой: минимален, тестируем, без прямых зависимостей от драйверов/SDK.
• Бизнес‑логика: максимально платформонейтральна, чисто смоделирована.
• Интеграционный слой: инкапсулирует COM, форматы файлов, DMS/ERP‑коннекторы, SDK устройств.
• Доступ к данным: консолидирован (например FireDAC), с чёткими транзакционными границами, без разбросанных SQL‑фрагментов.

Это не «академизм», а реальная экономия: если проблемна только интеграционная прослойка, не придётся заново писать весь клиент.

2) Services und REST-Server als Stabilitätsanker

Многие B2B‑системы выигрывают от того, что центральные функции выносятся в REST-Server или в Windows‑/Linux‑сервисы: проверка прав, документные рабочие процессы, валидация данных, экспорт/импорт, интерфейсы к ERP/DMS/CRM. Когда эти функции выполняются на сервере, сложность на клиенте существенно снижается — и вместе с ней поверхность риска для ARM64.

Типичные разделения, которые показали себя работоспособными:

• Клиент: диалоги, отображение, офлайн‑логика (если нужна), минимальные локальные интеграции.
• REST-Server: предметные операции, валидация, мульти‑тенантность, централизованное логирование.
• Worker/Service: задания по расписанию, опрос интерфейсов, генерация отчётов, пакетные экспорты.

Это также соответствует современным моделям эксплуатации: функция, выполняющаяся на сервере, обновляется один раз — вместо обновления на каждом ARM64‑клиенте.

3) Ein Build-System, mehrere Targets (x64 + ARM64) von Anfang an

Если ARM64 — цель, сборочная конвейеризация должна это отражать. Не как «сделаем отдельный билд позже», а как стандарт: каждая релиз‑кандидатная версия собирается воспроизводимо для x64 (и, при необходимости, для ARM64), включая подпись и упаковку инсталлятора.

Важнее не инструменты, а последовательность:

• Артефакты явно именовать (архитектура в имени пакета/структуре папок).
• Отделять конфигурации по таргетам (пути, пререквизиты, пакеты драйверов).
• Определить smoke‑тесты для каждой архитектуры (запуск, логин, подключение к БД, печать/PDF).

Так ARM64 перестаёт быть «большим взрывом» и становится контролируемым дополнительным таргетом.

Delphi-Modernisierung: ARM64 als Gelegenheit, technische Schulden gezielt abzubauen

Многие компании используют новые платформенные требования как повод «всё переделать». Это рискованно и часто неоправданно. Гораздо экономичнее использовать Windows 11 ARM64 как ориентиир для поэтапной модернизации: погашать технический долг там, где он блокирует ARM64 или угрожает поставке.

64-Bit und Unicode: alte Baustellen nicht verschleppen

Если в кодовой базе ещё присутствуют 32‑битные допущения или наследие ранних версий Delphi, они проявятся при смене платформы. Хотя ARM64 не равняется автоматически «Unicode», многие проекты, которые серьёзно подходят к ARM64, заодно приводят Unicode в порядок, устанавливают 64‑битные пути и устраняют проблемы со памятью/указателями.

Цель — не идеал, а надёжный стандарт: код, который можно собирать под новые таргеты, не воспроизводя постоянно одни и те же классы ошибок.

BDE-Ablösung und konsolidierter Datenzugriff als ARM64-Enabler

Где ещё есть исторические слои доступа (BDE, локальные Paradox‑данные, смешанные доступы), консолидация становится рычагом с мультиплицирующим эффектом: более поддерживаемый код, стабильные развёртывания, ясная драйверная стратегия. С помощью FireDAC в многих сценариях можно унифицировать доступ, включая централизованное управление параметрами, стратегии пуллинга и аккуратную обработку ошибок.

Важно: замена BDE — это не просто «подменить компонент». Это затрагивает транзакционную логику, типы данных, сортировки, семантику фильтров и частично модель данных. Поэтому её следует планировать, а не делать в экстренном порядке, когда ARM64‑клиенты внезапно появляются в поле.

Test und Qualitätssicherung: ARM64 ist nur dann planbar, wenn es messbar wird

Раннее планирование ARM64 также означает: нужно тестировать — не обязательно всефункционально, но целенаправленно тестировать критические цепочки риска. Самый важный шаг — иметь реальную ARM64‑тестовую среду. Эмуляция в отдельных случаях помогает, но не заменяет практики на реальном оборудовании, с реальными драйверами и реальными политиками безопасности.

Minimaler ARM64-Smoke-Test: was wirklich früh abgedeckt sein sollte

Практичный, но эффективный набор smoke‑тестов для каждого релиз‑кандидата:

• Запуск программы, вход в систему, базовые UI‑функции
• Подключение к БД (включая аутентификацию, сертификаты, DNS/Proxy, если релевантно)
• Один ключевой «end‑to‑end» процесс (например создание заказа, сохранение, печать/экспорт)
• Апдейтер/инсталлятор: новая установка и обновление через одну версию
• Логирование/диалоги ошибок: являются ли диагностики также полезными на ARM64?

Это помогает выявить типичные ARM64‑блокеры на ранней стадии: отсутствующие DLL, неверные драйверы, проблемы инсталляции, неожиданные запросы прав.

Diagnosefähigkeit: Crash-Dumps, Logs, Versionstransparenz

Когда ARM64 появляется в парке, будут обращения в поддержку — хотя бы из‑за новых конфигураций драйверов. Поэтому стоит стандартизировать диагностику: чёткие Build‑ID, информативные логи, воспроизводимые пути установки и обновления. Это не уникально для ARM64, но ARM64 быстро делает такие пробелы дорогостоящими.

Rollout und Betrieb: gemischte Flotten ohne Chaos

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

Paketierung: getrennte Installer, klare Erkennung, eindeutige Downloadwege

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

Update-Strategie: keine Sonderpfade für ARM64

ARM64 не должен быть спец‑пути в процессе обновления. Цель — одинаковая частота релизов, одинаковая номерная схема версий, но разделённые артефакты. Если ARM64 обновляется только вручную, возникают расхождения в парке и в будущем это повышает затраты на поддержку.

Integrationen sauber dokumentieren

Многие проблемы с ARM64 не в собственном коде, а в интеграциях: ERP‑коннекторы, DMS‑клиенты, сервисы подписания, сканерное ПО, драйверы этикеточных принтеров. Ведённый список интеграций с версиями и указаниями по архитектуре полезен для B2B‑систем и делает решения по ARM64 прозрачными.

Was Unternehmen jetzt konkret tun sollten (ohne Aktionismus)

Раннее планирование Windows 11 ARM64 не означает немедленно всё перестраивать. Речь о том, чтобы заранее ответить на правильные вопросы и устранить блокеры, пока объём работ остаётся планируемым. Проверенная последовательность действий:

• 1) Инвентаризация (2–10 дней в зависимости от размера системы): зависимости, инсталляторы, драйверы, доступ к данным, COM, отчётность.
• 2) Целевое состояние и путь: что должно быть нативно на клиенте? Что переводится в сервис/REST? Какие компоненты заменяются?
• 3) Proof of Feasibility: работоспособный ARM64‑билд с инсталлятором и одним end‑to‑end‑кейсом.
• 4) Поэтапное упрочнение: оставшиеся функции, тесты, цепочка обновлений, диагностические возможности.

Так не возникает отдельного «ARM64‑проекта», работающего месяцами в изоляции, а происходит контролируемое расширение поставляемости.

Fazit: Windows 11 ARM64 ist kein Hype, sondern ein Frühindikator für technische Reife

Windows 11 ARM64 становится для многих компаний реальностью — из‑за закупок оборудования, требований мобильности или стандартизации. Для Delphi‑приложений основная проблема — не только исходный код, а целая система зависимостей, установочных и обновляющих процессов, интеграций и драйверов. Кто планирует ARM64 заранее, может структурировано прояснить эти моменты, вместо того чтобы «латать» их в условиях дефицита времени.

В конечном счёте ARM64 — полезный тест: насколько отвязано, тестируемо и поставляемо ваше приложение? Ответив на этот вопрос сейчас, вы получите не только дополнительные платформенные опции, но и более устойчивую основу для модернизации, сервисов, REST‑архитектур и долгосрочной сопроводы.

Свяжитесь с Net-Base Software GmbH, wenn Sie Windows 11 ARM64 in Ihrer Delphi-Roadmap belastbar bewerten und mit einem klaren technischen Pfad umsetzen möchten.