Работают ли бизнес-приложения на Windows на Arm — реальность x64-эмуляции (Prism) и нативных DLL/COM

«Со следующего месяца переходим на новый ПК, что-то вроде Copilot+ PC — заработает ли на нём наша бизнес-система?» По мере того как корпоративное внедрение ПК на Snapdragon набирает обороты, всё больше компаний-разработчиков и ИТ-отделов сталкиваются с этим вопросом. В маркетинговых материалах написано «существующие приложения тоже работают через эмуляцию». Но собственное бизнес-приложение вызывает через P/Invoke нативную DLL от вендора за интерфейсом на C#, формирует отчёты через COM-компонент, да ещё и содержит драйвер для специализированного оборудования. Честно говоря, «заработает ли?» — вопрос, на который сходу не ответишь.

Ответ вкратце: «само приложение обычно заработает. Опасность — во всём, что к нему подвешено». Эмуляция Windows 11 довольно точно справляется с пользовательским кодом x86/x64, но при этом чётко очерчена зона «вне юрисдикции эмуляции» — драйверы, расширения оболочки, смешение архитектур внутри процесса, — и именно в этой зоне бизнес-приложения традиционно чувствовали себя как дома.

В этой статье разбираем, как устроена эмуляция Windows на Arm и где проходят её границы, фундаментальное правило о невозможности смешивать x64 и Arm64 внутри процесса, характерную для .NET-приложений проблему сочетаний, а также практический порядок проверки «заработает ли наше приложение на Arm-машине» — всё это с опорой на то, что можно перепроверить по Microsoft Learn.

1. Сначала вывод

• Чисто управляемое (.NET) приложение или обычное десктопное x86/x64-приложение почти наверняка заработает благодаря эмуляции Arm-версии Windows 11. Эмуляция встроена в ОС — изменение приложения или дополнительные компоненты не требуются.¹
• Эмуляция заботится только о коде пользовательского режима. Драйверы уровня ядра не эмулируются и обязательно требуют нативной сборки под Arm64. Драйверы UMDF и принтеров тоже должны соответствовать архитектуре ОС.²³
• Расширения оболочки, IME, средства специальных возможностей — любые «DLL, загружаемые в чужой процесс» — тоже нужно пересобрать под Arm64, как и саму систему. Эмуляция здесь не спасает.⁴
• Внутри одного процесса x64 и Arm64 сосуществовать не могут. Процесс x64/Arm64EC может загружать только бинарники x64 и Arm64EC, процесс Arm64 — только бинарники Arm64. Из x64-exe нельзя вызвать Arm64-DLL, и наоборот тоже нельзя.⁵
• Способы обойти это ограничение в пределах одного файла — это Arm64EC (нативный Arm64-код, способный сосуществовать с x64 в одном процессе) и Arm64X (бинарник, объединяющий Arm64- и Arm64EC-код в одном PE-файле и загружаемый в процесс любого из этих типов). Именно для этого нужен Arm64X, когда COM-сервер вне процесса или плагин вызывается из обеих архитектур.⁵⁶
• .NET официально поддерживает Arm64, и нативную публикацию можно выполнить через RID win-arm64. С другой стороны, запустите AnyCPU-приложение на Arm64-runtime — и процесс будет работать как Arm64, поэтому если приложение вызывает через P/Invoke нативную DLL, доступную только для x64, её загрузка завершится ошибкой — это стоит держать в уме как проблему сочетания.⁷⁸⁵
• Помимо физического железа (Copilot+ PC и т. п.), тестовое окружение можно развернуть на Arm64-VM в Azure или через ISO Windows 11 Arm64, пригодный для Hyper-V на Arm-машине или для Mac на Apple Silicon. Учтите, что на Hyper-V, работающем на x64-машине, Arm64-VM создать нельзя.⁹¹⁰

2. Что такое Windows на Arm — ПК на Snapdragon и Prism

Windows на Arm — это Windows, работающая на процессоре Arm64. С 2024 года большинство «Copilot+ PC» — новой категории ПК на Windows 11 с NPU, способным выполнять более 40 триллионов операций в секунду (40+ TOPS), — используют Arm-чипы серии Snapdragon X, и разработчики уже не могут это игнорировать.¹¹¹²

Совместимость с существующими приложениями обеспечивает встроенная в ОС эмуляция. Кратко о том, как она устроена.¹

• Эмулятор выполняет JIT-компиляцию блоков инструкций x86/x64 в инструкции Arm64, кэшируя результат преобразования по модулям, чтобы ускорить последующие запуски.
• Windows 11 умеет эмулировать и x86, и x64. Windows 10 на Arm эмулирует только x86, поэтому любой разговор о x64-бизнес-приложениях по сути подразумевает Windows 11.
• В Windows 11 24H2 появился новый эмулятор Prism, который повысил производительность по сравнению с предыдущим и снизил нагрузку на CPU. Prism оптимизирован под чипы Qualcomm Snapdragon.
• 32-битные (x86) приложения работают поверх того же слоя WOW64, что и в x64-версии Windows, и получают перенаправление файловой системы и реестра. У x64-приложений слоя WOW64 нет — поскольку системные бинарники скомпилированы в формате Arm64X (о нём ниже), x64-приложения обращаются ко всей ОС (и к файловой системе, и к реестру) без перенаправления.¹

Информация о процессоре, видимая приложению под эмуляцией, — это информация об «эмулируемом виртуальном процессоре». Ради совместимости даже GetNativeSystemInfo возвращает эмулированное значение, поэтому чтобы узнать, действительно ли хост — Arm64, используйте IsWow64Process2 или GetMachineTypeAttributes.¹³

Отметим также, что для приложений, у которых возникают проблемы под эмуляцией, в Windows предусмотрен способ изменить настройки эмуляции (пресеты «по умолчанию/безопасный/строгий/очень строгий» и отдельные детальные параметры) через правый клик по exe-файлу → «Свойства» → вкладка «Совместимость». Это компромисс, снижающий производительность ради совместимости, но стоит держать его в уме как запасной вариант для случаев «раньше на старой Windows на Arm это работало».¹⁴

3. Что работает под эмуляцией, а что нет

Ответ на вопрос «заработает ли?» определяется не самим приложением, а типом зависимости. Сведём это в таблицу решений.

Переводя на язык бизнес-приложений, тревожные сигналы выглядят так:

• VPN-клиенты, агенты управления активами, средства защиты — по сути, набор драйверов уровня ядра. Нужно уточнить у вендора наличие версии с поддержкой Arm64.
• Авторизация через USB-донглы, специализированное оборудование (измерительные приборы, платёжные терминалы и т. п.) — наличие Arm64-драйвера устройства становится решающим фактором.
• Инструменты «добавляют функцию в Explorer» — расширения оболочки загружаются в Arm64-версию Explorer, поэтому пока они остаются x64, они просто не будут работать.
• Даже если само приложение не подпадает под эти категории, случай, когда установщик содержит драйвер (например, вывод в PDF через драйвер виртуального принтера), сталкивается с той же проблемой.

4. Смешение архитектур внутри процесса невозможно — реальность P/Invoke и COM

Ещё с 32-битной эпохи существовало железное правило: «64-битный процесс не может загрузить 32-битную DLL».¹⁶ В Windows на Arm действует структурно то же правило. Официально совместимость загрузки сведена в такую таблицу.⁵

Здесь появляются два механизма, ключевых для проектирования готовности к Arm.

• Arm64EC (Emulation Compatible) — это ABI нативного Arm64-кода, следующее соглашению о вызовах, использованию стека и раскладке данных x64, благодаря чему такой код может сосуществовать в одном процессе с x64-кодом, работающим под эмуляцией. Когда x64-приложение работает в Windows 11 на Arm, бо́льшая часть кода ОС, загружаемого в этот процесс, уже скомпилирована как Arm64EC и выполняется с нативной скоростью незаметно для приложения. Это позволяет вести поэтапную миграцию: постепенно переводить в Arm64EC собственный код, повышая производительность, оставляя зависимые DLL по-прежнему в x64.⁵
• Arm64X — это формат бинарника, объединяющий традиционный Arm64-код и Arm64EC-код в одном PE-файле. В зависимости от того, x64 или Arm64 загружающий процесс, он ведёт себя как x64-DLL или как Arm64-DLL соответственно, что делает его удобным для DLL, которую потенциально могут вызывать процессы обеих архитектур. Официальная документация называет ситуации, требующие Arm64X: «64-битный COM-сервер, вызываемый как из x64-, так и из Arm64-приложений», «плагин, загружаемый и в x64-, и в Arm64-приложения», «единый бинарник, инжектируемый в процессы x64/Arm64».⁶

Конкретизируем реальные последствия для бизнес-приложений.

Случай 1: x64-exe + нативная x64-DLL (P/Invoke). Если весь процесс целиком остаётся x64, он полностью работает внутри эмуляции. Нельзя «ускорить только часть», подмешав туда Arm64-DLL — это попросту невозможно (как показано в таблице выше).

Случай 2: COM-сервер внутри процесса. COM-сервер in-proc — это просто DLL, поэтому таблица выше применяется напрямую. x64-клиент может использовать только x64- (или Arm64EC/Arm64X-) COM-DLL, и в момент, когда приложение станет нативным под Arm64, x64-COM-DLL перестанет загружаться. Если нужна поддержка обоих вариантов, либо делайте DLL в формате Arm64X, либо применяйте проверенный ещё с эпохи 32/64 бит приём — разделение на отдельные процессы с COM/IPC вне процесса (разнести на разные процессы и связать межпроцессным взаимодействием). Пересечение границы архитектур на границе процессов — исторически базовый подход.¹⁶⁶

Случай 3: вы сами хостите плагин или являетесь плагином. Надстройки Excel, плагины бизнес-пакетов, промежуточное ПО для печати и любая другая форма, где «ваша DLL загружается в чужой процесс», должны соответствовать архитектуре хост-процесса. И наоборот, если ваше приложение само хостит плагины, нужно продумать зону влияния: перевод собственного приложения на нативный Arm64 «выкосит» все сторонние x64-плагины.

Кстати, узнать, к какой архитектуре относится конкретный бинарник, можно из командной строки разработчика.⁵

link /dump /headers MyLibrary.dll | findstr machine
# 8664 machine (x64)            → x64
# 8664 machine (x64) (ARM64X)   → включает Arm64EC
# AA64 machine (ARM64)          → Arm64
# AA64 machine (ARM64) (ARM64X) → Arm64X

5. Случай .NET-приложений — ловушка AnyCPU и определение архитектуры

.NET (семейство Core) официально поддерживает Windows Arm64, и Arm64-версии Windows 11/10 прямо указаны как поддерживаемые ОС для .NET 8/9/10. Для публикации достаточно указать win-arm64 в качестве RID.¹⁷⁷

<!-- csproj: публикация для нативного Arm64 -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

Для приложения, состоящего только из управляемого кода, на этом перевод на нативный Arm64 практически завершён. JIT просто генерирует код Arm64, и правки исходников, как правило, не требуются. Для приложений на .NET Framework нативную поддержку Arm64 добавила версия 4.8.1 (для Arm64-машин под Windows 11; runtime 4.8.1 не поддерживает нативные Arm64-приложения на Arm-машинах с Windows 10). Приложение на Framework, оставшееся в сборке x64, считается работающим через эмуляцию.¹⁸¹⁹

Проблема — в сочетании, возникающем при вызове нативной DLL через P/Invoke. На Arm-машине давнее ощущение «это .NET-приложение, значит AnyCPU запустится где угодно» подводит.

• При запуске под Arm64-версией SDK/runtime .NET приложение по умолчанию работает как Arm64-процесс.⁸
• Процесс Arm64 не может загрузить x64-DLL (см. таблицу в разделе 4). То есть собственный AnyCPU-код остаётся нетронутым, но загрузка нативной x64-DLL, подключённой через DllImport, завершается ошибкой.⁵
• И наоборот, приложение, опубликованное как win-x64, работает целиком как x64-процесс и функционирует внутри эмуляции (вместе с нативной x64-DLL). В этом случае вы не получаете производительность нативного Arm64, но зато это конфигурация с максимальной совместимостью.¹²

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

using System.Runtime.InteropServices;

// Архитектура самого процесса (X64, если работает под x64-эмуляцией)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// Реальная архитектура ОС (Arm64 на Arm-машине)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

Стоит учесть: OSArchitecture начал возвращать «реальную архитектуру ОС, снимая эмуляцию» только начиная с .NET 7. До этого он возвращал X64 даже под эмуляцией, поэтому код на .NET 6 и старше, определяющий по этому API «это Arm-машина?», будет работать не так, как ожидается.²⁰²¹

Сведём воедино контрольные точки, специфичные для .NET.

• Нативные ресурсы в NuGet-пакетах: пакет, содержащий только runtimes/win-x64/native, при публикации под win-arm64 не даёт ничего взамен. Проверяйте содержимое пакета (или его репозиторий) на наличие ресурсов для win-arm64. Механизм RID как раз и существует для этой «маршрутизации платформо-специфичных ресурсов».⁷
• Состав SDK на машине разработки: на Arm-машине версия .NET для Arm64 обычно устанавливается в C:\Program Files\dotnet\, а SDK для x64 — в C:\Program Files\dotnet\x64\, и они могут сосуществовать. То, под какой архитектурой реально выполняется dotnet run, зависит от того, куда указывают PATH или DOTNET_ROOT, — учитывайте это при тестировании.¹⁷
• Как читать исключение: несовпадение архитектуры в управляемой сборке проявляется как BadImageFormatException (в официальном справочнике прямо указано, что условием возникновения служит «загрузка компонента, предназначенного для другой платформы»).²²

6. Чек-лист готовности собственного приложения к Arm

На практике эффективно проверять в три этапа.

Для этапов 2 и 3 есть следующие варианты тестового окружения.

• Реальное устройство: машина на Snapdragon вроде Copilot+ PC. Наличие хотя бы одного такого устройства даёт наибольшую уверенность, включая расследование проблем.¹²
• VM в Azure: в портале Azure можно отфильтровать образы по Arm64 и создать Arm64-VM с Windows 11 (рекомендуемый размер, например D2ps_v5, на базе Ampere Altra). Преимущество в том, что тестирование можно начать, не имея под рукой ни одной Arm-машины.⁹
• Локальная VM: официально распространяется ISO Windows 11 Arm64, и VM можно создать на Hyper-V на Arm-машине или на Mac с Arm-based Apple Silicon. Учтите, что на Hyper-V, работающем на x64-машине, создать Arm64-VM нельзя.¹⁰

Состояние поддержки сторонних продуктов можно проверить на сайте статуса, который публикует Microsoft (Works on Windows on Arm), а по проблемам совместимости бизнес-приложений (LOB) для корпоративных тарифов без дополнительной платы предоставляет поддержку программа App Assure. Наличие официального канала помощи до того, как всё упрётся в тупик «не работает», — полезный аргумент и при объяснении ситуации ИТ-отделу.¹²¹⁵

7. Практичное решение на сегодня — выбор между тремя вариантами

Готовность к Arm — это не только «полностью перевести на нативный код». Для многих бизнес-приложений практичнее поэтапный, ситуативный подход.

Если объём кода на C++ велик, между (а) и (в) есть промежуточный вариант — Arm64EC. Он позволяет постепенно переводить в нативный код только собственный код, оставляя зависимые x64-DLL как есть, и служит официальным маршрутом для случаев «огромное x64-приложение нельзя перевести одним махом».⁵²³

Со стороны инструментов разработки существует нативная под Arm64 версия Visual Studio, а на Arm-машине доступен набор компилятора, способный собирать под Arm64, x64 и x86 одновременно. CI-сборки тоже можно получать кросс-компиляцией на существующей x64-машине сборки, что упрощает конфигурацию, где «только запуск тестов» переносится на реальное Arm-устройство или VM.²⁴²³

8. Итог

• Arm-версия Windows 11 умеет запускать x86/x64-приложения через встроенную в ОС эмуляцию, и начиная с 24H2 производительность дополнительно улучшена благодаря Prism. x64-эмуляция появилась начиная с Windows 11, а Windows 10 на Arm поддерживает только x86.
• Юрисдикция эмуляции — только пользовательский режим. Драйверы уровня ядра/UMDF/принтеров, а также «DLL, загружаемые в чужой процесс», вроде расширений оболочки, IME и средств специальных возможностей, обязательно требуют нативной сборки под Arm64. Работоспособность бизнес-приложения определяется не самим приложением, а этими окружающими зависимостями.
• Внутри процесса x64 и Arm64 сосуществовать не могут. Процесс x64/Arm64EC может загружать x64 и Arm64EC, процесс Arm64 — только Arm64. И COM-серверы внутри процесса, и плагины подчиняются этому же правилу: Arm64X — стандартный ответ для двойной поддержки, а COM/IPC вне процесса — стандартный ответ для пересечения границы процесса.
• .NET умеет публиковать нативно под win-arm64, но AnyCPU-приложение, работающее на Arm64-runtime, выполняется как процесс Arm64, поэтому оно завершится ошибкой, если вызывает через P/Invoke только x64-версию нативной DLL. Для диагностики используйте RuntimeInformation.ProcessArchitecture / OSArchitecture (последнее — начиная с .NET 7).
• Порядок проверки — три этапа: «инвентаризация зависимостей → проверка на реальном устройстве в исходном виде под эмуляцией → при необходимости перевод на нативный Arm64». Тестовое окружение можно развернуть через Arm64-VM в Azure или ISO Arm64, а корпоративным клиентам доступна поддержка App Assure.
• На сегодня практичное решение — ситуативное сочетание: «если работает под эмуляцией — оставить как есть», «уточнить у вендоров драйверов и DLL статус поддержки», «перевести на нативный Arm64, если того требуют условия (для C++ возможна и поэтапная миграция через Arm64EC)».

Похожие статьи

• Вызов нативной DLL из C#: обёртка C++/CLI против P/Invoke
• Безопасный вызов Win32 API из C# — практическое руководство по P/Invoke (DllImport / LibraryImport / CsWin32)
• Как вызвать C# Native AOT DLL из C/C++
• Распространение Windows-приложения одним файлом — единый бинарник и пределы зависимости от ОС
• Практический пример COM-моста: вызов 64-битной DLL из 32-битного приложения

Смежные области консультаций

В Komura Software LLC мы занимаемся исследованием готовности существующих бизнес-приложений к Windows на Arm, проектированием миграции архитектуры приложений с нативными DLL и COM-интеграцией, а также анализом первопричин сбоев, возникающих только на Arm-машинах.

• Разработка приложений для Windows
• Техническая консультация и ревью архитектуры
• Расследование сбоев и анализ первопричин
• Контакты

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Заработает ли обычное x64-бизнес-приложение на Windows на Arm?

В большинстве случаев да. В Windows 11 на Arm встроена эмуляция, запускающая x86/x64-приложения без изменений, а начиная с Windows 11 24H2 новый эмулятор Prism дополнительно улучшил производительность. Однако эмуляция покрывает только пользовательский режим — драйверы уровня ядра, а также расширения оболочки и IME, которые загружаются в другие процессы вроде Explorer, обязательно требуют нативной сборки под Arm64. Стоит думать об этом не как о вопросе к самому приложению, а как о вопросе к тому, что к нему подвешено.

Может ли x64-exe вызвать Arm64-DLL?

Нет. Смешивать x64- и Arm64-бинарники в пределах одного процесса нельзя: процесс x64 (или Arm64EC) может загружать только бинарники x64 и Arm64EC, а процесс Arm64 — только бинарники Arm64. Обратное направление (Arm64-exe вызывает x64-DLL) точно так же невозможно. Если действительно нужна одна-единственная DLL, поддерживающая оба варианта, вариантами остаются Arm64X — формат, позволяющий Arm64- и Arm64EC-коду сосуществовать в одном файле, — либо разделение на отдельные процессы, связанные через IPC.

Что нужно, чтобы подготовить .NET-приложение к Arm64?

.NET 6 и новее официально поддерживают Windows Arm64, и нативный исполняемый файл под Arm64 можно получить, просто опубликовав приложение с RID (идентификатором среды выполнения) win-arm64. Для чисто управляемого кода на этом работа практически заканчивается, но если приложение вызывает нативную DLL через P/Invoke или использует NuGet-пакет с нативными ресурсами, нужно проверить наличие Arm64-версии для каждого из них. Для приложений на .NET Framework нативное выполнение на Arm64 в Windows 11 поддерживает версия 4.8.1.

Какое ПО не работает на Windows на Arm?

На первом месте — ПО с драйверами уровня ядра. Драйверы не эмулируются, поэтому VPN-клиенты, средства защиты, виртуальные устройства и авторизация через USB-донглы не заработают без Arm64-драйвера. Далее идут расширения оболочки, IME и средства специальных возможностей, загружающие DLL в процессы самой ОС, приложения, запрещающие динамическую генерацию кода, а также игры, зависящие от устаревшего OpenGL или античит-драйверов. Работоспособность периферии тоже определяется наличием Arm64-драйвера.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.