Рассуждая в канале Telegram о разработчиках, не стремящихся улучшать пользовательский опыт, я приводил пример создателя qBittorrent. Магазинной версии нет, а обычная часто обновляется, что вынуждает нас регулярно обслуживать ее вручную. Сначала скачивать с сайта, потом next-next-next. Это настолько уныло, что в какой-то момент я вопреки своим принципам отключил проверку обновлений qBittorrent.
В дискуссии пара человек отметили, что можно автоматизировать обновление с помощью winget – встроенного в Windows менеджера пакетов. Это звучало заманчиво, но кажется они сами не пробовали. Мне изначально было лень ковыряться — даже навскидку видно, что там одной командной не обойтись.
Но все-таки с установкой приложений winget неплохо справляется. И я решил посмотреть, как обстоят дела с обновлением.
[+] Сегодня в программе
- Основы winget
- Задача и первичный анализ
- Тонкости решения задачи
- Нюанс 1 – необходимо завершение запущенного приложения
- Нюанс 2 – нужен запуск приложения с обычными правами
- Нюанс 3 – захочется скрыть консольное окно
- Резюме: winget непригоден для массового автоматического обновления
- P.S. Исключение приложений из массового обновления
Основы winget
Обновление возможно, когда приложение есть в репозитории winget и установлено у вас. Причем с помощью установщика (в том числе посредством winget), а не каким-то портативным способом. Список установленных приложений, которые winget может автоматически обновлять, покажет команда:
winget list
Она не поддается дрессировке, поэтому просто смотрите в столбце Source на репозиторий winget.
Name Id Version Available Source ----------------------------------------------------------------------------------------------------------------------- Ace Stream Media 3.1.32 AceStream 3.1.32 Bitvise SSH Client 8.53 (remove only) Bitvise.SSH.Client 8.53 9.25 winget Ubuntu on Windows Canonical.Ubuntu 2004.2022.1.0 winget CrystalDiskInfo 8.17.5 CrystalDewWorld.CrystalDiskInfo 8.17.5 winget Emby Server Emby Server 4.5 Progress Telerik Fiddler Classic Telerik.Fiddler.Classic 5.0.20211.51073 winget GPS Track Editor GpsTrackEditor 1.15 (build 141) IrfanView 4.57 (64-bit) IrfanSkiljan.IrfanView 4.57 4.60 winget TreeSize Free JAMSoftware.TreeSizeFree_37s2tpab2h9zg 4.6.1.0 MKVToolNix 54.0.0 (64-bit) MoritzBunkus.MKVToolNix 54.0.0 72.0.0 winget Microsoft Edge Microsoft.Edge 107.0.1418.42 winget
Если приложение не установлено, найдите и установите:
winget search qbit winget install --id qBittorrent.qBittorrent
Обновление конкретного приложения:
winget upgrade --id qBittorrent.qBittorrent --silent
Обновление всех приложений, для которых есть новые версии:
winget upgrade all
В теории все просто!
Задача и первичный анализ
С помощью планировщика заданий нужно регулярно и незаметно обновлять qBittorrent. После обновления запускать приложение с обычными правами.
В простой формулировке кроется пара подводных камней:
- Работающее приложение нужно перезапускать после обновления. Поскольку приложения следует устанавливать в Program Files, скрипт для обновления будет выполняться с правами администратора. И тогда неочевидно, как из него запустить приложение с обычными правами.
- Перфекционистам надо скрывать окна PowerShell при запуске из планировщика. А в этом случае не работает параметр
-WindowStyle hidden.
Дальше я покажу приемы, которые вы сможете применять к большинству приложений.
Тонкости решения задачи
Два подвоха я выявил уже при анализе задачи, но тестирование сразу выявило более существенную проблему.
Нюанс 1 – необходимо завершение запущенного приложения
Для теста я установил старую версию qBittorrent и проверил версию исполняемого файла.
[PS <26> C:\…\Scripts] winget install --id qBittorrent.qBittorrent -v 4.4.2 Found qBittorrent [qBittorrent.qBittorrent] Version 4.4.2 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.4.2/qbittorrent_4.4.2_x64_setup.exe/download ... 28.8 MB / 28.8 MB Successfully verified installer hash Starting package install... Successfully installed [PS <27> C:\…\Scripts] (Get-Item "C:\Program Files\qBittorrent\qbittorrent.exe").VersionInfo.FileVersionRaw Major Minor Build Revision ----- ----- ----- -------- 4 4 2 0
Затем я попробовал обновить qBittorrent. И сходу наступил на грабли, когда приложение было запущено. В этом случае winget рапортует об успешном завершении и показывает новую версию приложения. Но по факту обновления не происходит, и версия исполняемого файла остается прежней!
[PS <28> C:\…\Scripts] winget list --id qBittorrent.qBittorrent Name Id Version Available Source ------------------------------------------------------------------ qBittorrent 4.4.2 qBittorrent.qBittorrent 4.4.2 4.4.3.1 winget [PS <29> C:\…\Scripts] winget upgrade --id qBittorrent.qBittorrent --silent Found qBittorrent [qBittorrent.qBittorrent] Version 4.4.3.1 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.4.3.1/qbittorrent_4.4.3.1_x64_setup.exe/download ... 28.5 MB / 28.5 MB Successfully verified installer hash Starting package install... Successfully installed [PS <30> C:\…\Scripts] winget list --id qBittorrent.qBittorrent Name Id Version Source ----------------------------------------------------------- qBittorrent 4.4.3.1 qBittorrent.qBittorrent 4.4.3.1 winget [PS <31> C:\…\Scripts] (Get-Item "C:\Program Files\qBittorrent\qbittorrent.exe").VersionInfo.FileVersionRaw Major Minor Build Revision ----- ----- ----- -------- 4 4 2 0
Более того, теперь winget считает пакет актуальным. Это — общая проблема приложений Win32. Такая ситуация возникает, если в манифесте не прописано поведение при обновлении (Upgrade, UpgradeBehavior). Но манифест все равно зависит от возможностей установщика.
Для начала разработчик должен предусмотреть в установщике сценарий, когда автоматически обновляется запущенное приложение. Так, при ручном обновлении qBittorrent определяет, что приложение работает. Однако дальше предлагает пользователю самостоятельно это устранить. Отдельно доставляет предложение пропустить исполняемый файл.
Трудно сказать, что мешало разработчику внедрить завершение приложения при согласии пользователя. Но это легко скриптуется. Вместо убийства процесса код ниже сначала пытается закрыть программу.
$qbt = Get-Process qbittorrent -ErrorAction SilentlyContinue
if ($qbt) {
$qbt.CloseMainWindow()
Start-Sleep -Milliseconds 100
if (!$qbt.HasExited) {
$qbt | Stop-Process -Force
}
}
winget upgrade --id qBittorrent.qBittorrent --silent
Все равно это решение очень грубое. Сначала завершается приложение, и только потом выполняется проверка новой версии. Конечно, логичнее сначала проверить наличие обновления. Но для этого придется парсить вывод winget. А он текстовый, никаких привычных по PowerShell объектов там нет. То еще удовольствие…
Таким образом, для каждого приложения необходимо протестировать сценарий «приложение запущено в момент обновления» и предусмотреть обходной путь в скрипте.
Нюанс 2 – нужен запуск приложения с обычными правами
Нельзя просто взять и сделать это из скрипта, запущенного с правами администратора. В теории грамотный алгоритм должен быть таким:
- Код запускается с обычными правами.
- Создается дочерний процесс и запрашивает для себя повышение. По окончании работы он передает результат родительскому процессу.
- Родительский процесс продолжает сценарий с обычными правами.
Примерно так работают толковые установщики программ. Но у нас не программа, а скрипты и планировщик, поэтому обойдемся неочевидным, но вполне эффективным обходным путем.
В качестве посредника привлекается оболочка, а точнее — приложение explorer. Оно может принимать в качестве параметра полный путь к программе. При таком запуске повышения прав программы не происходит!
В итоге скрипт венчает запуск qBittorrent с помощью explorer.
$qbt = Get-Process qbittorrent -ErrorAction SilentlyContinue
if ($qbt) {
$qbt.CloseMainWindow()
Start-Sleep -Milliseconds 100
if (!$qbt.HasExited) {
$qbt | Stop-Process -Force
}
}
winget upgrade --id qBittorrent.qBittorrent --silent
explorer "C:\Program Files\qBittorrent\qbittorrent.exe"
Нюанс 3 – захочется скрыть консольное окно
Это для перфекционистов. При запуске powershell.exe из планировщика на миг будет появляться консольное окно. В канале Telegram я уже показывал несколько решений: вызов PS1 из скрипта VBS и nircmd exec hide. Во втором посте также фигурировала настройка запланированного задания «Выполнять для всех пользователей». Однако для запуска интерактивного приложения это не подходит. О чем я совсем недавно рассказывал в статье про запуск невидимых приложений.
Если VBS и nircmd не устраивают, можете создать еще одно простое запланированное задание исключительно для запуска приложения. И вызывать его в конце скрипта, который выполняет обновление.
Резюме: winget непригоден для массового автоматического обновления
С одним приложением разобрались, но хочется-то обновлять все! Впрочем, уже понятно, что придется анализировать ход обновления для каждого приложения и при необходимости завершать его. Это для очень терпеливых людей.
Более того, на момент написания статьи в winget не было предусмотрено исключений из массового обновления! Был выбор только между winget upgrade --id id1 и winget upgrade --all. Нужно было что-то вроде winget upgrade -all -skipid id1, id2. Это реализовали летом 2023 года в рамках команды pin, см. P.S. ниже.
Философия репозитория winget тоже не способствует достижению дзена. Если установщик не умеет обновлять свое приложение в полностью автоматическом режиме, вам приходится опираться только на локальные костыли.
У chocolatey более гибкий подход – там в пакете может быть скрипт, который делает всю грязную работу.
Сам я не слишком доверяю чужим скриптам, и уж тем более их тихому запуску с правами админа, какой бы чудесной модерация репозитория ни была. Но по крайней мере они решают задачу.
Наконец, winget – пока еще относительно примитивное средство командной строки. Если он обзаведется сопутствующим модулем PowerShell, управление пакетами заметно упростится.
Это не решит фундаментальных недостатков winget. Но по крайней мере какие-то из их проще будет обходить скриптами. Пример набора костылей PowerShell из комментариев к статье: Winget-AutoUpdate.
Вердикт: с помощью winget можно реализовать автоматическое обновление нескольких приложений, но это решение не масштабируется.
В комментариях напишите, как вы автоматизируете обновление приложений в домашних условиях.
P.S. Исключение приложений из массового обновления
Этот упомянутый в статье недостаток устранили, что я разобрал в канале Telegram.
Ранее пользовался Chocoatey, даже поддерживаю пару пакетов в их репозитории, но мне очень сильно не нравится в choco, что при установке пакета, могут ставиться дополнительные утилиты, часто с аналогичной функциональностью, которые необходимы для «тихой» установки.
Сейчас почти всё ставлю при помощи winget. Обновляю «руками» при помощи
Сделал себе парочку списков софта, что сильно облегчает установку на новые машины
Но до удобства любого линукс-пакетного менеджера, конечно, вообще не дотягивает.
Это одновременно и плюс, и минус :) Для меня минус перевешивает, я не пользуюсь чоко. А свое репо лень, нет столько ПО, чтобы заморачиваться.
Использую https://github.com/Romanitho/Winget-AutoUpdate
Да, есть проблемы с приложениями, которые установщик не умеет закрывать, но есть и список приложений-исключений.
Спасибо, мне попадалось и даже было в заметках, но в статью не вошло. Это, кстати, отличный пример коллекции костылей на PowerShell, закрывающих многочисленные недостатки winget (втч вызванные относительной молодостью).
Если речь именно про домашние условия, то стараюсь использовать магазины приложения, чтобы они через магазин сами обновлялся, либо те, которые автоматически сами обновляются. Есть ещё одно приложение, потолок не отвечает данным критериям, но частота его использования ленит меня заниматься автоматизацией. Вообще мне кажется это решение для работы скорее, где у тебя реально много машин, а дома проще некст нажать, чем щаморачиваться.
Да, я тоже ставлю магазинную версию, если она есть. Но разработчик qbt отрицает магазин, о чем есть записи в гитхабе :) И нет, next-next-next не проще (легче отключить обновления).
Приходится использовать и Chocolatey, и winget. Для qBittorrent, например, лучше подходит choco, он корректно закрывает qBittorrent и даже сообщает, что он не стартанёт автоматически после апгрейда. Недостаток choco состоит в том, что он хранит локально свою базу установленных через него приложений и их версий. Если приложение обновилось само, choco этого не замечает, считает, что установлена всё ещё старая версия, будет пытаться обновить.
Похоже автор пакета не допилил автозапуск. Может как раз потому, что не знал как запустить с правами обычного пользователя :)
Спасибо. Да, это интересный нюанс, что внутреннее обновление приложения конфликтует с менеджером пакетов. Мне в свое время это тоже не понравилось.
Никак не автоматизирую.
Вся «автоматизация» сводится к команде winget upgrade и запуску обновления для каждой программы.
У winget много косяков с отдельными программами. Например, если новая версия программы может сосуществовать со старой, он будет продолжать пытаться обновить старую, не глядя на то, что новая уже установлена. У меня такое было с Windows SDK и ещё с чем-то.
Ещё у Logitech есть две разные программы Logitech Gaming Software — для старых и для новых устройств. Они имеют одно название и разные номера версий. Обновить одну другой невозможно, и работать новая со старыми устройствами не будет. winget видит новую версию как обновление старой и пытается установить ненужный софт.
Знаю, что можно сделать файл с исключениями, но пока лень.
С выводом автора согласен, для прайм-тайма winget не готов.
Мне кажется я именно исключение Logitech даже видел в чьих-то скриптах/примерах, когда смотрел разные реализации исключений :)
Кстати интересно что упомянут в статье также choco, но не упомянут scoop. Я именно вторым пользуюсь. Да, он не решает проблемы запущенного софта, но и честно пишет ошибку при обновлении (конкретно указывая что приложение запущено).
Кстати для любителей именно winget есть wingetUI ещё — https://github.com/martinet101/WingetUI
Зато он упомянут в комментариях :)
В описании пишут также про поддержку scoop. А так, этих UI много разных, начиная от магазина Windows (msstore) и заканчивая веб-версиями. Но пост про автоматизацию, а там UI не нужен.
А я немного поадвокатирую «опенсорсных разработчиков, которым интереснее кодить, чем делать удобную программу». Обвинение, по-моему, довольно серьёзное и требует обоснования.
Во-первых строках письма давайте отделим комаров от туристов — неудобна программа сама по себе или неудобна её установка в операционной системе Windows? Вроде бы программу вы отметили как отличную, значит к ней самой претензий у вас нет, разработчик накодил как надо. Получается, что претензия-то к удобству установки, причём именно в конкретной ОС.
Разработчикам действительно обычно неинтересно углубляться в мейнтейнеризм и, как по мне, это совершенно нормально. Моральный долг разработчика в части опакечивания — выложить инструкции по сборке и запуску программы, чтобы мейнтейнер конкретных ОС/дистрибутива знал, что ему надо сделать, чтобы собрать пакет, не углубляясь в код. То, что разработчик ещё и опакечивает во что-то сам — исключительно его добрая воля, а не обязанность. Чаще всего просто он сам же пользуется этим пакетом для личных нужд, ну и заодно его выкладывает для широкой аудитории.
Но стоит сделать людям добро как они сразу садятся на шею: и теперь разработчики, которые не предоставили пакет, удобный для использования в конкретных ОС/дистрибутиве, почему-то становятся врагами пользовательского опыта, хотя граница их ответственности за него — опыт общения с собственно приложением, а не обвязкой операционной системы для его установки. И разработчик эту зону своей ответственности прекрасно блюдёт (по вашим же словам, напомню).
Сделал ли автор qBittorrent кандидатский минимум разработчика в части опакечивания? Сделал — https://github.com/qbittorrent/qBittorrent/wiki#compilation . До кучи ещё и предоставил несколько готовых к употреблению вариантов для конечных пользователей, что хороший плюс, но это уже свободная программа, обязательную он и без этого откатал.
С пакетом в winget какая-то петрушка? Так вот его мейнтенерам и надо адресовать свои претензии, что пакет не торт. Не покурили документацию, не сделали сборку, упаковку и установочные скрипты, а просто взяли готовую программу для ручной установки и сымитировали из него свой пакет. Разработчик тут при чём?
Установка и особенно обновление приложения — неотъемлемая часть пользовательского опыта по взаимодействию с приложением. А все эти опенсорсные аргументы «кодируй сам» — в топку.
И пакет тут вообще ни при чем. Я же пишу, что разработчик не предусмотрел в установщике автоматизацию обновления.
Интересно, что в статье есть листинги команд и вывода winget и ps-скриптов, если скриншот установщика Nullsoft, но нет ни одного скриншота самого приложения. И это неудивительно, т.к. процесс установки самой устанавливаемой программы не касается.
Работа с установкой/обновлением/удалением пакетов — неотъемлемая часть пользовательского опыта, да, но взаимодействия с пакетным менеджером, каким бы он ни был (хоть бы даже в лице пользователя, вручную раскидывающего файлы). При установке приложение даже не запускается, оно на этом этапе является данными для другой программы.
Пакетить же приложение под КАЖДУЮ операционную систему, чтобы не напрягать бедных-несчастных мейнтейнеров — ну это, извините, уже снобизм. Или вендоцентризм — типа остальные ОС/дистрибутивы пускай как-то сами, но уж для Windows разработчик просто обязан сделать как условный «я» считаю нужным, иначе будем считать, что он пишет неудобную программу.
ОС/дистрибутивов десятки, может быть даже сотни, не знаю, не задавался целью посчитать. Для одной только Windows в этой статье несколько способов установки упомянуто. Это большой объём работы даже для коммерческих команд и они ограниченное количество вариантов пакетов выкладывают (даже при закрытых исходниках), а вы от человека, делающего программу, которая во всех смыслах free, и бесплатно отдающего её вам в уже скомпилированном виде, требуете (пусть и неявно, в форме «не сделал — значит бука») дополнительной работы, которую при этом делать обязан вовсе не он.
Ассоциативно вспомнились срачики Windows vs Linux, в которых я по молодости любил время от времени участвовать, когда сторонники первой рассказывали, как в линуксе плохо с драйверами и поддержкой устройств, а вот в винде-то как замечательно, а им контраргументировали, что драйверы-то пишут в основном не микрософт, а производители железа, а если они для линукса не написали, то почему в этом линукс-то виноват? Видимо привычка воспринимать мир так, что винде все обязаны, проявляется и в данном случае.
Тут ситуация, конечно, не совсем зеркальная с драйверам (кроссплатформенные приложения таки доступны и на винде тоже, в то время как драйверы между системами не перетащишь), но тем не менее: в моём дистрибутиве пакет qBittorrent есть и сколько влезет можно без всего этого цирка одиночными командами ставить/обновлять/удалять (я другим клиентом пользуюсь, просто поиском проверил наличие такого пакета). А откуда он там взялся, неужто автор программы собрал пакет для моего арчика и заботливо в репозиторий загрузил? Нет, просто мейнтейнер дистрибутива некий Felix Yan сделал эту работу, т.к. это его задача, а не разработчика. Но условные «вы» можете и дальше считать, что плохой именно разработчик, сделавший неудобную программу. Это очень взрослая позиция.
Это не привычка воспринимать мир. Это гайдлайны и лучшие практики разработки под Windows. И да, обязаны, если взялись.
В Windows разработчик должен предоставить установщик, чтобы обеспечить нормальную регистрацию программы (например, ассоциацию с типами файлов). Это его обязанность в соответствии с гайдлайнами создания ПО для Windows.
Я не знаю, что там гайдлайны предписывают по поводу обновления. Но раз он выкатил установщик, то он становится частью UX. И вот этот UX не предусматривает закрытия приложения. Вручную и автоматически тоже. В этом корень проблемы. Зрите в корень.
Ну вот, о чём я и говорил.
Разработчик не просто написал на сайте: парни, я тут прогу клёвую написал, если вы хотите её использовать под виндой, то компилять её вот так, а потом рассуйте эти файлы вот туда вот так.
Нет, разработчик помимо этого собрал исходный код в исполняемый, упаковал это в пакет для ручной установки и на сайте выложил. Добрую волю автор проявил, иначе уважаемый Вадим не смог бы приложением воспользоваться (хотя не знаю вашей квалификации в данном вопросе, может и собрали бы). Он скорее всего не особо-то заморачивался с настройками установщика Nullsoft, всё по умолчаниям запилил, но зато условный жаждущий торрентов Вася теперь может программу поставить, не зная программистско-админского матана.
Но оказывается нет же, это не добрая воля была, чтоб условному Васе помочь программу установить. Это было подписание кабального договора и теперь автор обязан соблюдать гайдлайны и лучшие практики, которые ему предписали. А почему должен? Ему денег за это заплатил кто-то и надо отрабатывать? Или он социалистическое обязательство дал мегапакеты под винду ваять? Ребят, он просто приложение создал и развивает для всех людей, которым оно может быть полезным. И приложение, судя по всему, действительно хорошее.
А микрософт минимизирует расходы и сваливает дистрибутивоспецифичные вещи на разработчиков, вместо того, чтобы заняться этим самим. Сделали микрософт это для каких-то избранных программ (как минимум для своих же продуктов) — молодцы. Не сделали — это разработчики редиски, неудобные программы делают, а мы-то тут при чём.
Это попытка представить максиму виндового подхода «разработчики должны вот это вот всё, если уж посмели написать программу, работающую в нашей системе» как императив мира программного обеспечения в целом. Но нет, в целом так не принято, и эти нехорошие опенсорс-разработчики знают другой мир, где есть иной и вполне разумный подход.
Вот в этом корень-то проблемы. За десятилетия (!) развития в централизованно (!) разрабатываемой системе не могут сделать нормальный единый централизованный же менеджмент пакетов (именно это, а не гламурные окошечки и панельки с иконками, есть одна из первейших вещей в ОС/дистрибутиве). Вместо гайдлайнов и лучших практик для разрабов лучше бы этим занялись и потом там сами пакеты собирали, но гораздо проще (и намного, намного дешевле!) найти виноватых вовне.
У меня winget ваще не работает. Вынь10. Выдает список установленных программ, а колонки source нет там.
Обновляю проги обычно руками, по необходимости.
Возможно, всего один источник (winget). См.
Добавить msstore можно так https://www.thomasmaurer.ch/2021/01/install-apps-from-the-microsoft-store-using-winget/
Не понимаю зачем вы притащили с лора эти пропахшие нафталином красноглазые тезисы. Про майкрософт, третирующую разработчиков и тп.
Эта запись вполне техническая же. А блог целиком и полностью про грамотные подходы. Вполне очевидно, что грамотная разработка ПО должна вестись в соответствии с требованиями, гайдлайнами и лучшими практиками той операционной системы, для которой приложение создаётся. А не какой-то другой, своими фантазиями или религиозными соображениями.
В Windows существует понятие жизненный цикл приложения, который включает установку, обновление и удаление. Все три аспекта должны учитываться при создании приложения. В своей статье я показываю, как игнорирование разработчиком одной детали при обновлении приложения препятствует автоматизации обновления. В том числе с помощью менеджера пакетов от Microsoft.
Я также достаточно прозрачно намекаю, по какой причине в этом пакетном менеджере невозможно исправить недостатки установщика. Это небезопасно!
В каком-то другом менеджере пакетов пропихивание пользователю левых утилит или скриптов для исправления косяков разработчиков считается нормальным. А здесь нет.
А он есть. Магазин называется. Если бы разработчик сделал магазинное приложение или хотя бы бридж, никаких проблем и вопросов не было бы. Но он отрицает магазин, и как раз по религиозным соображениям. Ветку на гитхабе найдите самостоятельно.
Так что сворачивайте свой устав, слезайте с трибуны и подышите воздухом — прогуляйтесь до ближайшей аптеки за визином.
Аминь.
Не знаю чью сторону занять, вашу или вашего оппонента. Вы в чем-то оба правы, а истина посередине. Которую вижу в том, что это Open Source. Видите проблему, как минимум создайте issue, как максимум предложите патч. Скорее всего билд создается автоматически, средствами CI/CD и просто пропущена какая-то опция создания установщика. Хуже, если такой опции нет и для этого нужно создавать инсталятор руками, через GUI. В этом случае, претензии к разработчику вообще не корректны.
Кто пакует приложение в установщик, к тому и претензии. В этом случае — это все тот же разработчик приложения. Кому еще за это претензии предъявлять-то. С претензиями к майкрософту за это вы можете пройти в ту же аптеку.
Спасибо, посмеялся. Вспомнил тут одно приложение для торговли финансовыми бумагами. Там в манифест не заложили требование полных прав, а папка по умолчанию — Program Files. Ну и отлуп при первом же Next. Дефект закрыт с причиной Won’t Fix и предложением запускать установщик от имени администратора.
На qbt такое заводить — зря время тратить. Вы хотите целовать этому классному парню ноги за то что он вас софтом осчастливил — вперед и с песнями. И это мне еще лень искать ваши комментарии о бесполезности отзывов в фидбэкхаб (недавно их перечитывал).
В общем, дискуссия не подразумевала религиозных войн, которые регулярно пытается сюда протащить strafer. Посему она завершена.