Несколько лет назад на Хабре писали об отличном способе проапгрейдить Windows 7 или 8 до Windows 10 совершенно бесплатно. Все, что нужно — лицензионная версия предыдущей ОС и желание обновиться. В Microsoft заявляли, что способ проработает всего год и после этого обновление станет платным. Но нет — все работает до сих пор.

Многие пользователи, которые опробовали этот способ, заявляют, что он работает без проблем. У некоторых, правда, возникают затруднения разного рода, не связанные с лицензиями на ОС. Тем не менее, в большинстве случаев все получается.

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

 

Для начала — что такое WiX? Технология WiX (Windows Installer XML) представляет собой набор инструментов и спецификаций упрощающих процесс создания дистрибутивов на базе MSI (Microsoft Installer). Если объяснять проще то это обертка вокруг MSI с человеческим лицом.

На мой взгляд изучать проще всего на простых примерах. В данной статье я приведу пример простейшего инсталлятора.

В прошлый раз мы научились создавать простой инсталлятор. Прежде чем двинуться дальше, от простого к сложному, давайте научимся управлять этим самым сложным. А именно — научимся разбивать проект на части с тем, чтобы упростить сопровождение и внесение изменений.

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

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

UPD: Добавил картинку о трудностях локализации ))

Скачать Google Earth — не такая уж простая задача. Особенно, если вы хотите получить полный дистрибутив, и при этом избежать дополнительных «бонусов» от Google. По умолчанию Google выдаёт маленький веб-инсталлятор, который скачивает Google Earth, Google Chrome и Google Updater. Даже если в опциях вы снимите птичку ″Include Google Chrome, a fast new browser for Windows and Mac″, то всё равно получите веб-инсталлятор.

 

Театр начинается с вешалки, а программный продукт начинается с инсталлятора. Все мы хоть раз устанавливали программу и знаем, что часто по тому, как сделана программа установки, можно судить об отношении разработчиков ко всему программному продукту.
Также все наслышаны о таком «монстре», «корпорации зла», которая покупает Sun, судится с Google и т.д. Это Oracle Corporation, в которой работает более 100 тыс. сотрудников.
По роду моей деятельности мне пришлось столкнуться с флагманской СУБД данной компании – Oracle Database 11g Release 2.
До этого мое общение с этой СУБД замерло на версии 9i и теперь, хоть и избалованный другой известной СУБД, я решил насладиться инженерной мыслью Oracle Corporation.

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

В предыдущем посте мы уже вкратце рассказали о весьма изощренном трояне Duqu, ворующем конфиденциальную информацию компаний и самоуничтожающемся после завершения работы. На что мы получили 2 заявки
1. найти инсталляционный файл
2. найти уязвимость нулевого дня

Итак, концерт по заявкам:

Схема инфицирования Duqu

Введение

У предлагаемого вашему вниманию цикла статей есть несколько основных целей:

1. Создать полезное программное обеспечение – инсталлятор программ и обновлений.
2. Показать преимущества объектно-ориентированного подхода к разработке ПО и научить создавать легко расширяемые программные архитектуры.

В данном цикле статей я хочу поделиться историей создания программного обеспечения, позволяющего производить установку и обновление программных продуктов компании при помощи пакетов. Необходимость создания собственного инсталлятора(с отказом от использования готовых решений) вызвана специфичностью требований к инсталлятору. Я не буду углубляться в обоснование необходимости разработки, так как тема цикла статей другая.
Основными требованиями к разрабатываемой архитектуре будут:

1. Реализация механизма транзакций, причем транзакции могут включать в себя не только SQL-транзакции, но и файловые, а также транзакции, связанные с изменением любых других ресурсов ОС, таких как записи в реестре, изменения конфигурационных файлов и т.д.
2. Расширяемость операционной базы инсталлятора, то есть, добавление новых типов команд(операций), как с поддержкой транзакций, так и без нее.

Ссылка на первую часть

Транзакции.

Напомню, что я собирался реализовать механизм транзакций, позволяющий откатывать блоки операций при возникновении ошибки внутри блока, защищенного транзакцией. Сначала надо решить вопрос с ответственностью за сохранение состояния и за откат операции. Скажу сразу, что архитектура, которую я приведу ниже вырисовалась у меня не сразу, а только после нескольких попыток проектирования и реализации макета, пока у меня не получилось то, что получилось.
Для того, чтобы архитектура транзакций была легко наращиваемой, воспользуемся как и ранее наследованием. При этом возложим ответственность за сохранение состояние и откат к сохраненному состоянию на саму команду. Учтем при этом, что не все команды являются по сути транзакционными. Например, чтение из реестра не может быть частью транзакции, потому что оно ничего не изменяет в системе. А вот запись в реестр – это уже часть транзакции. И создание файла – это часть транзакции.
А поэтому объявим еще один абстрактный класс TransactionalCommand, унаследуем его от класса Command.

Ссылка на первую часть
Ссылка на вторую часть

Контентные и контейнерные команды

Некоторые команды подразумевают работу с файлами, изначально хранимыми на компьютере разработчика пакета. Понятно, что эти файлы нужно вместе с пакетом (а желательно, прямо внутри пакета) доставить к потребителю пакета. Попробуем для начала представить себе как это будет работать.
У нас есть экземпляр класса PackageBuilder, которому при конструировании мы указываем аргумент PackageBody, содержащий в себе, помимо всего прочего, команду Command, которая представляет собой корневой узел дерева команд пакета. Метод SaveResult() экземпляра класса PackageBuilder должен рекурсивно обойти все дерево, и для тех команд, которые используют контентные файлы, расположенные на компьютере разработчика, включить в тело пакета содержимое всех этих файлов. В тело пакета он также должен включить xml-файл, в который будет сериализован сам PackageBody с полным описанием пакета и выполняемых им команд.

Ссылка на первую часть
Ссылка на вторую часть
Ссылка на третью часть

Ввод данных

Любой инсталлятор должен давать пользователю возможность вводить некоторые стартовый параметры, например, путь к папке, куда будет инсталлирована программа, строка подключения к базе данных, и т.д. Причем, хотелось бы, чтобы это были не просто текстовые поля, а поля, дающие возможность удобного вода данных. Если это путь установки программы, то помимо текстового поля должна быть кнопка «Browse…», если это строка подключения к БД, то пусть рядом будет кнопка для выбора или создания источника данных и т.д.

Как и было обещано ранее, инсталлятор CyanogenMod покинул стадию закрытой беты появился в магазине Google Play — скачать его можно здесь. Окончательно радоваться пока рано — поддерживаются только семейства Google Nexus и Samsung Galaxy, а также HTC One (полный список устройств).

Смысл мода, вероятно, известен всем, однако, стоит повториться, что CyanogenMod представляет из себя «улучшенную версию Android, с множеством новых функций и продвинутыми приложениями, более безопасным мессенджером и улучшенной программой для фото- и видеосъёмки. Ценность мода ещё и в том, что он позволяет установить последние версии Android на старые устройства, которые забыты и заброшены производителями. CyanogenMod — это, буквально, Android с человеческим лицом» (via alizar).