WinStoreRegion
WinStoreRegion

Началось всё с довольно простой задачи. Мне понадобилось установить приложение из Microsoft Store, но для моего региона оно оказалось недоступно.

Гуглить способы обхода мне было лень, поэтому я отдал задачу ChatGPT вместе с установщиком. В результате регион Windows был временно изменён, приложение установилось.

Сам способ, конечно, не новый. Регион Windows можно поменять вручную в настройках, поставить приложение и вернуть обратно. Но после этого я подумал: если метод давно известный и с такой проблемой явно сталкиваюсь не только я, почему бы это не автоматизировать?

Так появился WinStoreRegion — небольшая утилита для Windows. На момент публикации актуальная версия — 0.1.0.


Что она делает

Изначально идея была совсем простой: сохранить текущий регион Windows, временно поставить другой, передать приложение Microsoft Store и потом вернуть всё обратно.

При этом сама программа ничего не скачивает из сторонних источников и не патчит Store. Регион меняется штатными средствами Windows, а установкой занимается Microsoft.

Первый вариант можно было бы на этом и закончить. Пользователь указывает Product ID приложения, выбирает регион и запускает установку.

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

Если программа завершится с ошибкой уже после переключения региона или в этот момент перезагрузится Windows, пользователь останется с новым значением.

Поэтому перед изменением региона WinStoreRegion сохраняет исходное состояние на диск. После возврата ещё раз читает настройку Windows и проверяет, что всё действительно вернулось обратно.

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

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

Как понять, какой регион выбрать

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

Допустим, приложение недоступно в России. А дальше что? Пользователь далеко не всегда знает, где оно вообще есть. Можно последовательно пробовать США, Великобританию, Германию и другие страны, но тогда автоматизация получается довольно условной.

Поэтому добавил поиск доступных рынков Microsoft Store.

Перед установкой WinStoreRegion может проверить, в каких регионах предлагается конкретный Product ID. Для быстрого поиска берётся около сорока наиболее очевидных рынков. Если этого недостаточно, можно запустить полный проход — там уже порядка 250 запросов.

В результате программа сама предлагает регионы, где приложение удалось найти.

Здесь есть небольшой нюанс: если от какого-то рынка не удалось получить ответ, программа не считает это автоматически отказом. Ответы разделены на «найдено», «не найдено» и «не удалось проверить».

Даже если приложение найдено во время такого поиска, перед установкой оно всё равно проверяется ещё раз уже после реальной смены региона Windows.

Мне это показалось правильнее, чем один раз получить ответ от каталога и дальше считать, что установка точно сработает.

Установка оказалась тоже не такой простой

Сначала предполагалось, что достаточно передать приложение штатному механизму Windows и дождаться результата.

На практике нашлись приложения, для которых этого недостаточно. Поэтому появился второй вариант: WinStoreRegion может скачать официальный установщик, который Microsoft сама отдаёт для приложения из Store.

Файл берётся у Microsoft по Product ID. До запуска проверяется цифровая подпись и подписант, считается SHA-256. После этого программа меняет регион и передаёт установщик пользователю.

Тут уже есть ограничение: Store открывает собственное окно, и дальше WinStoreRegion не может достоверно узнать, чем закончилась установка.

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

Наверное, это одна из вещей, которые в процессе разработки я стал делать специально: если программа не может что-то проверить, лучше так и написать, чем показать красивое зелёное «успешно».

Потом понадобились обновления

Когда первая версия установки заработала, возник ещё один вполне практический вопрос.

Хорошо, приложение поставили через другой регион. А что будет через месяц, когда выйдет обновление?

Microsoft Store в исходном регионе может это приложение вообще не обслуживать, поэтому ждать обычного автоматического обновления не всегда имеет смысл.

Так появилась отдельная вкладка проверки обновлений.

WinStoreRegion смотрит установленные приложения Store и пытается найти те, которые в текущем регионе не обслуживаются, но доступны в других. Для них можно увидеть установленную версию и то, что сейчас предлагает каталог.

Автоматическое обновление я пока не добавлял.

Во время тестов выяснилось, что номера версий из разных источников не всегда можно честно сравнивать. Например, версия bundle и версия пакета внутри него могут жить своей жизнью. Плюс я пока не проверил на достаточном количестве приложений, действительно ли повторный запуск установщика всегда обновляет существующий пакет.

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

Когда этот сценарий будет нормально проверен, можно будет автоматизировать и его.

Почему Rust

Написать такую программу можно было на C++, C# или вообще собрать большую часть логики на PowerShell.

Я выбрал Rust.

В основном потому, что давно хотел попробовать его именно для небольшого системного инструмента под Windows. Сейчас довольно много разработчиков, которые раньше для таких задач автоматически выбрали бы C++, смотрят в сторону Rust, и было интересно проверить это на чём-то реальном.

GUI при этом нативный Win32. Никакого Electron и браузера внутри программы нет.

Используются Windows API, COM/WinRT, Management.Deployment, реестр, WinHTTP и системные средства проверки цифровых подписей.

Проект разделён на GUI-приложение и отдельное ядро. В workspace запрещён собственный unsafe-код через unsafe_code = "deny".

В результате получился обычный portable exe размером примерно 1,3 МБ.

Права администратора для работы не нужны.

Сейчас в релизе собираются x64, ARM64 и 32-битный x86. При этом на реальном железе полноценно проверена пока только x64-сборка. ARM64 и x86 проходят сборку в CI, но устройства для нормального тестирования я ещё не нашёл.

Интерфейс тоже постепенно разросся

В самом начале я представлял программу буквально как окно с Product ID, регионом и кнопкой установки.

Сейчас там уже три основные вкладки: установка, обновления и журнал.

В журнал пишется, какое приложение запускалось, какой Product ID использовался, под каким регионом оно нашлось и чем закончилась операция.

Отдельно ведётся диагностический лог. Телеметрии нет, данные никуда не отправляются.

Интерфейс сейчас переведён на русский, английский и упрощённый китайский. Китайский пока машинный, и это прямо указано в проекте.

Локализация сделана через обычные TOML-файлы. Чтобы добавить новый язык, Rust знать не нужно. Сборка сама проверяет наличие всех строк, лишние ключи и подстановки в переводах.

Что получилось в итоге

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

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

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

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

Если кто-то сталкивался с другими особенностями регионов Microsoft Store или знает приложения, на которых такой сценарий ломается, — интересно будет проверить.

Исходники и готовые сборки: GitHub — kroxiksut/win-store-region

Лицензия — GPL-3.0

Комментарии (6)


  1. MrBotikkk
    23.08.2026 13:02

    geo_US.reg

    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Control Panel\International\Geo]
    "Nation"="244"
    "Name"="US"

    geo_RU.reg

    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Control Panel\International\Geo]
    "Nation"="203"
    "Name"="RU"


    1. krox Автор
      23.08.2026 13:02

      Да, сам регион так поменять можно. Но допустим, поставили US — а нужного приложения в американском Store тоже нет. Что дальше, вручную перебирать US, GB, DE, CA и т.д.?

      В WinStoreRegion смена региона — как раз самая простая часть. Утилита сначала может проверить, в каких рынках конкретный Product ID вообще доступен, предложить подходящие регионы, а после установки вернуть исходный регион. Плюс восстановить его при следующем запуске, если программа или Windows завершились между сменой и возвратом.


      1. MrBotikkk
        23.08.2026 13:02

        Ну и славно.

        Ставил помню, App Installer(winget) и windows-terminal на Windows Server 2022 или 2019. Помогла давняя фича:

        https://ru.store.rg-adguard.net/


        1. krox Автор
          23.08.2026 13:02

          У меня полностью опенсорс ГПЛ без какой-либо рекламы в отличии от данного ресурса и умею находить поддерживаемые регионы. Да и экзешник можно нужный подкинуть. Надеюсь кому-нибудь да пригодится


    1. MEGA_Nexus
      23.08.2026 13:02

      Для обычного пользователя Windows готовое приложение всё-таки проще, чем какие-то непонятные символы для правки реестра.


      1. krox Автор
        23.08.2026 13:02

        Особенно если этот пользователь далёк от айти не собирается входить )

        Тому же ребёнку или бабушке будет проще указать ссылку или экзешник перетащить, чем править реестр, а потом чинить/переставлять винду