Директ Коммандер на Linux: Всё

В первой статье я запустил Директ Коммандер на Linux и сделал вывод: официальный установщик под Wine сломан везде, чинить его бессмысленно, программу надо доставать из него архиватором. Во второй выкинул из схемы Bottles и разобрал, почему не работает автообновление.

Вывод из первой статьи оказался неверным. Установщик чинится одной настройкой Wine, а вместе с ним начинает работать и автообновление. Ответ полгода лежал в багтрекере Wine, и нашёл я его благодаря модератору WineHQ.

Как я вообще туда попал

После второй статьи я оформил результаты тестов в AppDB WineHQ, это база совместимости Windows-программ с Wine. До меня там висела запись про Коммандер 3.68 с рейтингом Garbage: человек упёрся в тот же зацикленный установщик и честно написал, что не работает. Я добавил версию 3.154.2 с рейтингом Gold и обходом через распаковку.

Запись одобрили, а модератор приписал к письму стандартную просьбу: заведите баг в Bugzilla, если его ещё нет, и привяжите к записи. Правила Bugzilla требуют сначала поискать дубликаты, а для этого надо понимать, что искать. Я полез смотреть, как вообще устроена проверка «приложение уже запущено» в установщиках на electron-builder. Оказалось, она идёт через PowerShell. А в трекере Bottles нашлась жалоба на другой установщик с той же петлёй, и там виноватой оказалась заглушка PowerShell в Wine. Я вбил в поиск Bugzilla powershell и на втором экране увидел:

Bug 59670. Installers think app is already running (powershell is a stub)

Заведён в апреле 2026 года, подтверждён, к нему привязаны лаунчеры Feather, Lunar Client и Loudplay. Симптом мой один в один, а в комментариях готовый обход.

Что на самом деле происходит

Установщик Коммандера собран на electron-builder. Перед копированием файлов он проверяет, не запущена ли программа, и делает это в два этапа.

Сначала выясняет, доступен ли PowerShell. Запускает его дважды: проверяет, что существует командлет Get-CimInstance (код выхода 0 значит есть), и что политика выполнения не Restricted (код 1 значит запрещено).

Если PowerShell доступен, установщик ищет процессы, чей путь начинается с папки установки, через Get-CimInstance Win32_Process. Код 0 означает «нашёл, программа запущена». Если PowerShell недоступен, идёт запасной путь через tasklist и findstr.

В Wine powershell.exe это заглушка. Она пишет в лог fixme:powershell:wmain stub и возвращает 0 на любую команду, даже на exit 1. Дальше всё складывается само:

• Get-CimInstance существует? 0, да;

• политика Restricted? 0, нет, всё разрешено;

• программа запущена? 0, да.

Установщик пытается закрыть несуществующий процесс, проверяет снова, снова получает 0 и показывает то самое окно «Не удалось закрыть Direct Commander. Повтор». Повтор ничего не меняет, заглушка отвечает одинаково.

Отсюда и «ломается везде». Bottles, CrossOver, любые раннеры, любые версии Windows в префиксе: заглушка PowerShell у всех одна, и CrossOver, судя по результату, её не исправлял. Я перебирал всё, кроме того, что действительно было общим.

Обход в одну строку

Заглушку достаточно отключить:

WINEDLLOVERRIDES=powershell.exe=d wine "Direct Commander-3.158.1-ia32.exe"

=d запрещает Wine загружать встроенный powershell.exe. Установщик не может его запустить, получает ненулевой код, решает, что PowerShell нет, и уходит на tasklist. А tasklist в Wine отвечает правду: такого процесса нет. Дальше обычная установка.

Проверил на своём Mint 22.3 с Wine 11.0: установщик доходит до конца, программа запускается, кампании качаются, баллы тратятся. Для чистоты эксперимента повторил в пустом контейнере с Wine 9.0 из репозитория Ubuntu, в тихом режиме:

без обхода:  wine installer.exe /S                        → код 2, ничего не установлено
с обходом:   WINEDLLOVERRIDES=powershell.exe=d wine ... /S → код 0, 13 секунд

Код 2 установщик возвращает, когда пользователь отказался закрывать программу. В тихом режиме диалог не показывается, и установщик сразу сдаётся.

Автообновление тоже починилось

Во второй статье я разбирал красную плашку «обновление будет установлено автоматически». Апдейтер качал установщик и при закрытии программы запускал его с флагами --updated /S. Установщик упирался в ту же проверку и молча умирал.

Раз причина та же, обход должен сработать и тут. Апдейтер запускает установщик дочерним процессом, а переменные окружения наследуются. Значит, достаточно запустить сам Коммандер с WINEDLLOVERRIDES=powershell.exe=d.

Запустил, закрыл. Лог:

[Updater] Auto install update on quit
[Updater] Install: isSilent: true, isForceRunAfter: false
[Updater] Executing: ...\pending\Direct Commander-3.158.1-ia32.exe with args: --updated,/S

Те же три строки, что и раньше, только теперь установщик дошёл до конца, всё установилось фоном.

Как обойтись без своего лаунчера

У схемы с переменной окружения есть слабое место. Флаг надо передавать при каждом запуске, иначе обновление снова молча не встанет. Ярлык, который Wine создаёт для установленной программы, ничего про флаг не знает. Поэтому сначала я запретил Wine делать ярлыки (winemenubuilder.exe=d) и сделал свой: маленький скрипт запуска с флагом и пункт в меню.

Работало, но выглядело как костыль. А переопределения DLL в Wine можно записать прямо в реестр префикса. Тогда они действуют на всё, что в этом префиксе запускается:

export WINEPREFIX=~/.wine-dc
wine reg add 'HKCU\Software\Wine\DllOverrides' /v powershell.exe /d '' /f

Пустое значение означает «отключено». Команда выполняется один раз, после неё установщик запускается обычным wine установщик.exe, без всяких флагов.

Проверил в чистом префиксе на своей машине: обычная установка с окнами, путь по умолчанию. Установщик дошёл до конца, Wine сам сделал ярлык «Direct Commander» в меню и на рабочем столе, со значками всех размеров. Программа запустилась из меню, в «О программе» 3.158.1. Апдейтер работает в том же префиксе, значит, читает ту же настройку, и как запускать программу, уже неважно.

Нашлись две мелочи. Установщик кладёт на рабочий стол ещё и виндовый Direct Commander.lnk: Wine связывает рабочий стол Windows с настоящим, и ярлык ложится туда как есть. На Linux он не нужен. А после удаления программы ярлыки, которые сделал Wine, остаются в меню и на рабочем столе: сам Wine их не убирает.

Что поменялось в репозитории

install-wine.sh стал короче вдвое. Он больше ничего не распаковывает и своих ярлыков не делает: берёт установщик из загрузок, записывает настройку в реестр префикса, запускает установщик в тихом режиме и убирает лишний виндовый ярлык .lnk.

uninstall.sh вызывает штатный деинсталлятор, а потом убирает ярлыки и значки, которые сделал Wine. Только те, что ведут в этот префикс: проверка сравнивает путь целиком, вместе с закрывающей кавычкой, подстроку в grep учёл.

Оба скрипта рассчитаны на установку с нуля и за старыми схемами не убирают. Тем, кто ставил по прошлым статьям, сначала нужно удалить старую установку руками. Если ставили через обычный Wine, данные остаются в том же префиксе:

git pull
rm -rf ~/.wine-dc/drive_c/"Program Files (x86)"/DirectCommander
rm -f ~/bin/direct-commander ~/.local/share/applications/direct-commander.desktop ~/.local/share/icons/direct-commander.png

Если через Bottles, данные надо перенести из бутылки в новый префикс до первого запуска:

cp -a ~/.var/app/com.usebottles.bottles/data/bottles/bottles/Direct/drive_c/users/*/AppData/Roaming/direct-commander ~/direct-commander-backup
rm -f ~/bin/direct-commander ~/.local/share/applications/direct-commander.desktop ~/.local/share/icons/direct-commander.png

./install-wine.sh
D=~/.wine-dc/drive_c/users/"$USER"/AppData/Roaming/direct-commander
rm -rf "$D" && cp -a ~/direct-commander-backup "$D"

Кампании и настройки переедут, а авторизацию, возможно, придётся пройти заново: токены хранятся зашифрованными и в другом префиксе могут не расшифроваться. Скрипт для Bottles остался в репозитории с пометкой legacy.

Перед публикацией прошёл путь нового пользователя на своей машине: убрал префикс целиком, скачал установщик с сайта и поставил скриптом с нуля. Проверил обе версии, 64- и 32-битную. Ярлык от Wine, вход в аккаунт и загрузка кампаний работают в обеих. Заодно проверил автообновление: поставил старую версию 3.154.2, и встроенное обновление по кнопке «Установить» подняло программу до 3.158.1.

В багтрекер Wine дописал, что Коммандер тоже затронут, а баг привязал к записи в AppDB. Следующий, кто будет искать, найдёт ответ сразу.

Что я вынес

Если ломается везде одинаково, ищи общее. Я сделал из «ломается в Bottles, CrossOver и на всех раннерах» вывод, что чинить бесполезно. Правильный вывод был другой: у всех этих сборок есть общая часть, и сломана именно она.

Трекеры раньше перебора настроек. Я перебирал настройки, раннеры и сборки и написал две статьи вокруг обхода. А ответ с апреля лежал в Bugzilla, в комментарии из одной строки. Когда стало понятно, что искать, поиск занял минуту.

Рабочий обход ещё не значит простой. Переменная окружения решила задачу, но потребовала своего лаунчера. Та же настройка в реестре префикса убрала и его.

Модераторские шаблоны иногда полезны. Письмо из AppDB было стандартным: «заведите баг, если его ещё нет». Если бы я его пропустил, до сих пор распаковывал бы установщик архиватором.

Если повторяли инструкцию из первых статей и всё работает, переделывать не обязательно. Но со штатной установкой Коммандер обновляется сам, а переход занимает пару команд.

Скрипты и README: github.com/cpa-jedi/direct-commander-linux
Баг в Wine: bugs.winehq.org/show_bug.cgi?id=59670
Запись в AppDB: Direct Commander 3.154.2

Пишу про то, как Директ устроен изнутри, про LLM в работе аналитика и контекстолога тут t.me/cpa_jedi_notes.