Глава из книги «Shareware: профессиональная разработка и продвижение программ». Станислав Жарков
Создание инсталлятора
Созданную новую версию программы, в принципе, уже можно распространять среди пользователей. Запаковать ЕХЕ-файл ZlP-архиватором, добавить в этот архив readme-файл и файл справки, и разместить получившийся ZIP-файл в Интернете. Однако для серьезной shareware-программы этого мало. Нужно создать к своему продукту специальную программу установки, или, как ее еще называют, инсталлятор ("install" — устанавливать)
Почему shareware-программе необходим инсталлятор? На это есть несколько причин.
· Большинство крупных архивов программного обеспечения и обозревателей компьютерных журналов даже не рассматривают программы, не имеющие инсталлятора. Если же они все-таки обратят внимание на такую программу, то о присуждении ей высоких оценок или наград, как правило, не может быть и речи.
· Программа установки, конечно же, помогает пользователю начать работу с shareware-продуктом, избавляет его от необходимости вручную копировать файлы и создавать ярлыки в меню Пуск.
· Инсталлятор — своеобразная "упаковка" программы, имеет большое значение для оповещения пользователя об условиях лицензионного соглашения.
· Инсталлятор служит еще одним свидетельством того, что данный продукт — серьезная разработка, а не поделка любителя.
Некоторые авторы программ, начав распространение своих продуктов на российском рынке и как freeware, привыкли к тому, что инсталлятор к ним делать не нужно. Некоторые из разработчиков даже с гордостью делают приписку к описанию своей программы: "Не требует инсталляции". Это с одной стороны, оправданно: пользователь может быть уверен, что процесс копирования программы на диск его компьютера будет под его контролем системные настройки будут отредактированы без его ведома или в папку WINDOWS/SYSTEM не будет записано никаких "левых" файлов. Правда, все это может быть сделано уже самой программой при первом запуске ее ЕХЕ-файла. С другой стороны, недоверие к инсталляторам со стороны пользователей в основном обусловлено низкой надежностью старых версий Windows (например, 3.х) и плохим качеством программ сторонних разработчиков, появившихся на рынке в то время, — например, механизм удаления уже установленной под Windows программы работал малоэффективно. Сейчас, по прошествии очень большого для индустрии информационных технологий периода времени, ситуация сильно изменилась, и большинство пользователей рассматривают инсталлятор как помощника в работе, а не обузу, придуманную авторами программ для засорения жестких дисков пользователей.
С увеличением объема продаж через Интернет, бумом shareware, сокращением доли "коробочных" продуктов на рынке и переход некоторой их части в разряд shareware, инсталлятор стал играть роль не только программы установки, но и "упаковки" программного продукта, что имеет большое значение в деле зашиты авторских прав.
Дело в том, что в то время, когда большинство платных продуктов были "коробочными", т. е. продавались в фирменной упаковке, лицензионное соглашение, в котором правообладатель разрешал использование программы, печаталось прямо на этой упаковке. Текст лицензионного соглашения обязательно начинался со слов: "Вскрывая упаковку данного программного продукта, Вы подтверждаете свое согласие с условиями настоящего лицензионного соглашения". Лицензионные соглашения даже стали называть "оберточными лицензиями", т, е. лицензиями, опубликованными на упаковке.
После того как все больше программ стало распространяться по компьютерным сетям, в том числе и по Интернету, термин "оберточная лицензия" стал терять смысл — ведь "обертки" как таковой уже не было! И тогда роль упаковки стал играть инсталлятор: перед началом процесса установки продукта он демонстрирует пользователю текст соглашения и требует поставить флажок или переключатель Согласен для продолжения установки. А слова "Вскрывая упаковку данного программного продукта..." заменились на "Устанавливая данный программный продукт..." Таким образом, лицензионное соглашение, оформленное в электронном виде, продолжают называть "оберточной лицензией".
Конечно, нельзя не упомянуть о том, что иногда без инсталлятора просто не обойтись — например, когда для нормальной работы устанавливаемой программы требуется скопировать в папку WINDOWS/SYSTEM и зарегистрировать в системе ActiveX- и DLL-библиотеки, типы файлов и т. п.
Самостоятельная подготовка инсталлятор - довольно простое дело. Существует огромное количество продуктов независимых разработчиков (как бесплатных, так и shareware и коммерческих), позволяющих создавать программы установки. Какую из них предпочесть? Давайте посмотрим, на какие параметры нужно обратить внимание при выборе программы создания инсталляторов.
Сначала, экономичность. Казалось бы, для любой программы главное — это функциональные возможности, но здесь они отходят на второй план. Первое, на что стоит обратить внимание при рассмотрении программы создания инсталляторов — объем файлов, которые она генерирует. Ведь функции и диалоговые окна инсталлятора также требуют определенного пространства на диске, в результате файл инсталлятора вместе с содержащимся в нем сжатыми файлами программного продукта окажется несколько больше, чем, например, объем ZlP-архива с теми же файлами внутри.
Эта разница между "обычным" архивом и инсталлятором существует и при использовании различных программ может оказаться очень значительной. Например, известнейший пакет InstallShield (облегченные версии которого, кстати, входят в комплекты поставки многих систем разработки приложений), "добавляет" к дистрибутиву программы более мегабайта! Конечно, использовать InstallShield можно разве что в том случае, если готовую программу планируется распространять не через Иптернет, где у более компактных программ есть больше шансов привлечь к себе внимание пользователей. Тем не менее, некоторые shareware-разработчики все равно применяют InstallShield. Например, я иногда спрашиваю авторов, присылающих мне заявки на публикацию своих программ в каталоге SoftList: "Почему Ваша программа, являясь вроде бы небольшой утилитой, имеет архив размером почти 2 Мбайта?" "Да не беспокойтесь, — слышу я в ответ, — сама программа занимает всего 500 Кбайт, а все остальное — инсталлятор!" Нет, программа установки, "съедающая" втрое больший объем, чем непосредственно "основной" продукт — слишком большая роскошь для shareware. Итак, как я уже упоминал, InstallShield, на мой взгляд, разумно использовать для "обертки" к программам, которые не планируется распространять по компьютерным сетям — например, написанных под конкретный заказ или рассчитанных на публикацию на CD-ROM и ему подобных носителях.
Другие программы по созданию инсталляторов гораздо более умеренны в своих аппетитах. Собственно, громоздкость InstallShield явилась своеобразным катализатором появления аналогичных, но более компактных продуктов: shareware-разработчики, которым для распространения своих продуктов через Интернет требовался более экономичный инсталлятор, писали собственные генераторы программ установки, а затем некоторые из них, в свою очередь, были оформлены как самостоятельные shareware-продукты.
Одним из самых популярных среди разработчиков shareware-программ является пакет Installer Wise (http://www.mindvision.com). Помимо широких возможностей, о которых вы прочтете ниже, он создает достаточно компактные программы установки: разница между ZIP-архивом с файлами программы и инсталлятором будет всего около 180 Кбайт. Createlnstall 2000 российской фирмы Gentee (http://www.gentee.com) еще более экономичен — после его работы дистрибутив программы увеличивается всего лишь на 40 Кбайт. Есть, конечно, еще немало программ для генерации инсталляторов, но большинство из них создают относительно компактные установочные программы — в пределах 200 Кбайт. Более "прожорливые" аналоги практически не имеют шансов выжить на рынке shareware (тот же InstallShield, например, в основном применяется при оформлении больших коммерческих продуктов), а их появление в дистрибутивах shareware-программ обусловлено в основном неопытностью автора соответствующей программы.
Вторым по значению фактором выбора программы для создания инсталляторов является набор функциональных возможностей, который она предоставляет разработчику. Естественно, по этому параметру разные продукты в этой категории различаются, и порой очень сильно. Являются ли возможности той или иной программы достаточными — зависит в основном от особенностей этой программы.
Для многих программ вполне подходит несложный процесс установки, состоящий из небольшого числа стадий: показ лицензионного соглашения, предложение выбрать папку для установки, выбор группы в секции Программы меню Пуск и непосредственно сам процесс копирования файлов и создания ярлыков в Главном меню. В этом случае подойдет практически любая программа для генерации инсталляторов, в том числе и из категории бесплатных продуктов. Правда, среди последних действительно хорошую программу придется поискать: многие программы из этой группы имеют раздражающие недостатки вроде неудобного интерфейса или отсутствия возможности переопределить внешний вид инсталлятора.
Если же в процессе установки требуется еще и регистрировать DLL-библиотеки и ActiveX, предоставлять пользователю выбор языка интерфейса или устанавливаемых компонентов программы, выводить определяемые автором программы диалоговые окна и обрабатывать результат действий пользователя, изменять ассоциации файлов, делать записи в реестре, перегружать компьютер по окончании установки и т. п., требуется более продвинутый генератор инсталляции. Это уже упомянутые мной Installer Wise, Create Install и др.
И наконец, немаловажным вопросом при выборе программы создания инсталляторов является удобство работы с ней. Часть программ этого типа (к счастью, небольшая), например уже упоминавшийся выше InstallShield, a также InnoSetup (http://www.doniain.com), для описания инсталлятора (вид диалоговых окон, обработка событий и т. д.) используют специальные скриптовые языки, вследствие чего освоение такого продукта замедляется. Для преодоления этой проблемы другими авторами написаны специальные визуальные конструкторы, генерирующие текст скриптов по параметрам, указанным пользователем в диалоговом режиме — например, ISTool (http://www.bhenden.org/istool), создающий скрипты для InnoSetup.
Впрочем, являются ли скрипты недостатком или нет — зависит от взглядов и предпочтений самого shareware-разработчика. Некоторым авторам программ больше нравятся как раз работать со скриптами, к тому же в этом случае часто имеется возможность более тонко настроить параметры инсталлятора, чем при использовании диалоговых окон.
Основная часть программ для создания инсталляторов работают с пользователем в диалоговом режиме, позволяя визуально конструировать будущий инсталлятор: выбирать стадии процесса установки, описывать вид диалоговых окон, определять другие параметры — имена устанавливаемых файлов. регистрируемые расширения файлов, названия и пути к создаваемым ярлыкам и т. д..
Работать с такими программами, конечно, гораздо проще, чем с теми, которые используют скрипты.
Каким же должен быть "правильный" инсталлятор? Вместе с большинством программ для их создания поставляются примеры готовых проектов установочных программ, кроме того, в качестве наглядного примера можно посмотреть инсталляторы известных и популярных продуктов. Но я бы хотел обратить внимание на некоторые важные детали, которыми пренебрегают некоторые разработчики. Демонстрация текста лицензионного соглашения
Как уже говорилось выше, согласие с условиями лицензионного соглашения — это условие, при котором инсталляция программы может быть продолжена. В этом — суть лицензионного соглашения как "оберточной" лицензии. Значит в инсталлятор нужно не забыть включить окно с текстом License Agreement, чтобы пользователь мог продолжить установку, только нажав кнопку Согласен или установив соответствующий флажок (переключатель).
Папка для установки по умолчанию
Мне до сих пор попадаются программы, инсталляторы которых предлагают создать папку программы для копирования файлов не в папке C:\Program Files, а в корневом каталоге диска С:. Конечно, в большинстве случаев можно выбрать для установки любую другую папку, в том числе и Program Files, но, во-первых, это раздражает, т. к. приходится совершать лишние операции, а во-вторых, приходится все равно устанавливать такую программу в каталоге С:\, т. к, никогда нельзя быть уверенным в том, что программа будет нормально работать в папке Program Files — например, из-за проблем с длинными именами файлов. Кто-то может удивиться тому, что в наше время, когда на рынке господствуют 32-разрядные операционные системы, какие-то программы "не понимают" длинные имена файлов, но на самом деле такие программы встречаются, и я бы не сказал, что очень редко.
Создание ярлыков в Главном меню
Я уже говорил "Не трогайте системные файлы и настройки" о том, что группа с ярлыками для установленной программы должна находиться исключительно в папке Программы Главного меню, а не в его первом уровне или где-то еще. Если же вы считаете, что ярлык к вашей программе пригодится пользователю и на Рабочем столе или, например, в первом уровне Главного меню, то инсталлятор программы должен создавать такие ярлыки только с разрешения пользователя.
Если ярлык программы помещается не в собственную группу в меню Программы, а в одну из стандартных групп — например, Автозагрузка или Стандартные, то нужно учитывать, что в локализованных версиях Windows их названия различаются, и не повторять ошибок разработчиков пакета утилит Microsoft PowerToys, в процессе установки которых даже под русской версией Windows ярлыки создаются в группах "Accessories" и "Startup", которые, конечно, в данной локализации Windows игнорируются.
Помимо установки, программа должна иметь возможность деинсталляции, т. е. удаления себя из системы. Программа, производящая эту операцию —
деинсталлятор, — как правило, генерируется той же программой, которая использовалась для создания инсталляторов. Хотя большинство программ для генерации инсталляторов предоставляют разработчику самому решить, нужен ли его программе деинсталлятор, на самом деле он фактически является обязательным для любого серьезного программного продукта.
Деинсталляция — это не просто удаление файлов с компьютера, которое, в общем-то, может произвести любой пользователь вручную. Деинсталляция подразумевает удаление всех следов пребывания программы в системе (записей в реестре и других системных файлах, DLL-библиотек в папке WINDOWS/SYSTEM и т. п). Если же вся эта информация остается в системе, то она по мере установки на компьютер все новых и новых приложений накапливается, что отрицательно сказывается на стабильности работы операционной системы.
Да и удаление файлов деинсталлятором не такой уж и простой процесс. Дело в том, что по умолчанию деинсталлятор настраивается так, чтобы удалить только те файлы, которые были установлены ранее. Если при удалении - файлов программы деинсталлятор обнаруживает в ее папке файлы, которые не были туда установлены инсталлятором, то он пропускает их, а иногда (это зависит от того, какой программой был создан деинсталлятор) вообще прекращает свою работу, чтобы не удалить важные файлы, например документы, созданные пользователем. Но на практике не все "новые" файлы могут действительно являться документами пользователя: вполне возможно, что это файлы, созданные операционной системой в связи с работой данной программы на этом компьютере.
Например, если справочная система продукта выполнена в формате WinHelp, то обычно программа установки копирует на диск компьютера файлы с расширением hip и cnt (основной файл и файл с оглавлением Справки). Но стоит пользователю хоть один раз посмотреть справочную систему, как на диске будет создан файл с расширением gid, а если пользователь проведет расширенный поиск— создаются файлы FTS и FTG (см. табл. 7.1). Поэтому файлы с этим расширением также нужно включить в настройки программы деинсталлятора.
То же самое относится и к ключам в системном реестре с настройками программы. Часто эти ключи создаются не инсталлятором, а самой программой, в процессе работы пользователя с ней. В результате эти записи не удаляются деинсталлятором и остаются в реестре, увеличивая его объем и ухудшая скорость работы Windows. Вследствие этого нужно настроить деинсталлятор на удаление всех ключей, которые могут быть созданы программой в процессе ее использования.
Как известно, деинсталлятор приложения для Windows может быть запущен двумя способами: посредством выбора соответствующего пункта в группе с ярлыками программы в меню Пуск и при помощи апплета "Установка и удаление программ" Панели управления Windows. Некоторые программы генерации инсталляторов, например уже упоминавшийся InstallWise, предоставляют пользователю возможность при удалении программы воспользоваться любым из этих способов на свой выбор: соответствующие пункты присутствуют как в меню Пуск, так и в апплете "Установка и удаление программ" Панели управления. Однако некоторые shareware-продукты можно удалить только одним способом. Нельзя сказать, что это удачный ход, с точки зрения удобства работы с программой. Можно испытать сильно, раздражение, например, последовательно вызвав Панель управления, апплет "Установка и удаление программ", прокрутить длинный список и не найти ту программу, которая вам требуется, прокрутить этот список более медленно, тщательно вчитываясь в названия продуктов, чтобы не пропустить интересующую программу, задуматься, как же все-таки удалить эту злосчастную программу и т. д.
Наконец, когда инсталлятор и деинсталлятор созданы, нужно обязательно протестировать их работу: насколько хорошо продукт устанавливается на компьютер и удаляется с него. Кто-то из читателей сочтет это замечание не нужным — ведь необходимость тестирования любой программы кажется само собой разумеющейся вещью, однако мне время от времени встречаются программные продукты, после инсталляции которых не работают даже ярлыки в меню Пуск, не говоря уже о более серьезных ошибках при проектировании программ установки. При этом нужно постараться найти возможность протестировать работу инсталлятора и деинсталлятора на компьютерах с различными версиями Windows, в том числе и с разными локализациями.
Подготовка дистрибутива
Итак, инсталлятор программного продукта готов: файл setup.exe лежит в папке вашего shareware-проекта. В принципе, этот файл уже является дистрибутивом программы, и его можно смело распространять через Интернет. Многие авторы так и делают: переименовывают файл setup.exe так, чтобы его название было созвучно названию программы, и размещают его на Web-сернере.
Это распространенный, но не совсем правильный подход к выбору варианта оформления дистрибутива. Лучше всего — упаковать ЕХЕ-файл инсталлятора ZIP-архиватором. Помимо файла setup.exe, в архив нужно включить еще и файл readme.txt, содержащий наиболее важную информацию о программе и се текущей версии, а также файл file_id.diz, в который записывается название программы, ее версия и короткое (10—20 слов) описание.
Главный недостаток распространения "голого" файла setup.exe, без его "оборачивания" архиватором, состоит в том, что пользователь может узнать, какую именно программу содержит дистрибутив, только установив ее. Хотя авторы обычно дают файлу дистрибутива имя, производное от названия программы, оно нередко совершенно ничего не говорит пользователю, т. к. выглядит как аббревиатура и номер версии — например, ср32е45.ехе: попробуйте догадайтесь, что за этим малопонятным набором букв скрывается Netscape Communicator версии 4.5 для Windows 9.X/NT/2000.
Если же инсталлятор упакован архиватором, а в архиве находится и файл readme.txt, то пользователь может узнать, какая именно программа представлена данным дистрибутивом без ее непосредственной установки, а так же получить много дополнительной информации о ней (что нового появилось в этой версии, какие существуют системные требования и т. п).
Некоторые читатели, возможно, спросят: "А зачем в архив нужно еще включать и файл file_id.diz? Ведь много информации уже есть в readme.txt?" Это действительно гак, однако file_id.diz более удобен для чтения, если пользователю всего лишь нужно узнать название программы и ее версию. Но самое главное — многие архиваторы, файловые менеджеры, каталогизаторы автоматически извлекают из архивов файлы file_id.diz (традиция снабжать дистрибутивы файлами file_id.diz идет еще со времен DOS) и показывают (или обрабатывают другим образом) их содержимое. В результате пользователь получает описания упакованных файлов из таких архивов без необходимости открывать их вручную и самостоятельно читать файлы readme.txt. Не случайно текст в файле file_id.diz принято записывать небольшими по длине строками, чтобы описание помещалось в информационные окна соответствующих программ.
По свидетельству тех shareware-разработчиков, которые размещают на своих Web-сайтах программы сразу в двух вариантах — ехе и zip, оба варианта скачивают примерно равное количество пользователей. Тем не менее, с ZIP-архивами работать удобнее, что подтверждают письма от посетителей архива SoftList: в некоторых из них содержатся довольно эмоциональные просьбы публиковать на сайте только программы, дистрибутивы которых оформлены в виде ZIP-файлов, и даже обязать авторов программ распространять свои программы только упакованными в архив. Конечно, выполнить такие просьбы по разным причинам невозможно, но сам по себе факт наличия подобных просьб со стороны пользователей показателен, тем более, что просьб искоренить формат ZIP в области распространения дистрибутивен программ не поступало.
Читатели, наверное, обратили внимание на то, что, говоря об использовании архиватора, я все время упоминаю об одном формате — ZIP. Ведь существует множество других архивных форматов, некоторые из которых более эффективны, чем ZIP — например, широко распространенный в России RAR Евгения Рошаля (http://www.rarsoft.com). Дело в том, что ZIP является стандартом де-факто для распространения файлов в Интернете, чего о других архивных форматах не скажешь. Конечно, существуют исключения, обусловленные, в частности, спецификой платформы, для которой предназначен файл: например, программы для Linux традиционно упаковываются в архивы tar.gz. Но когда речь идет о распространении через Интернет программного обеспечения для Windows, здесь выбора нет: только ZIP, и никакой другой архиватор.
Большое значение для распространения программ среди зарубежных пользователей имеет и тот факт, что существует большое количество бесплатных ZIP-архиваторов, а вот тот же RAR (как его версия для Windows— WinRAR) — shareware-продукт, за использование которого (в данном случае — всего лишь для того, чтобы распаковать чужую программу) нужно платить. И, хотя в комплект поставки RAR входит бесплатная утилита UnRar, которая предназначена только для распаковки файлов, большинство пользователей о ней ничего не знают, т. к. автором RAR она не особо рекламируется. Получается, что автор shareware-продукта, упакованной RAR (или другим небесплатным архиватором), вынуждает пользователя заплатить деньги только за право разархивировать программу. Один из российских shareware-разработчиков рассказывал, что в то время, когда он пользовался архиватором RAR для упаковки дистрибутива своих программ, он как-то даже получил письмо с упреком. "Чтобы запустить Вашу программу, я должен зарегистрировать RAR!" — писал пользователь.
Примечание
Надеюсь, мои слова будут поняты правильно: критикуется, конечно же, не то, что за пользование архиватора требуется платить, а то, что в данном случае пользователя вынуждают платить за программу, которая ему фактически не нужна.
Пожалуй, единственный тип программ, дистрибутивам которых противопоказана упаковка любым архиватором и которые должны распространяться только в виде исполняемого файла ("голый" инсталлятор или самораспаковывающийся архив), — это... ZIP-архиваторы. Очень часто пользователь скачивает из Интернета дистрибутив, одной из таких программ как раз для того, чтобы разархивировать другие ZIP-файлы, и поэтому ему, скорее всего, будет просто нечем распаковать дистрибутив, сжатый ZIP-архивом.
Наконец последний вопрос, который мне хотелось бы рассмотреть в данном разделе, — это вопрос о том, какое имя должен иметь готовый файл дистрибутива, т. е. файл, который пользователи будут качать из Интернета. Есть три возможных варианта: оставить ему стандартное имя вроде setup.zip, дать имя на основе названия программы (предположим, abc.zip) и добавить ко второму варианту номер версии — например, abc20.zip будет означать версию 2.0.
Первый вариант, конечно, отпадает: имя файла setup.zip ничего не скажет пользователю о названии программы, когда он скачает этот файл, а через некоторое время (например, наводя порядок на жестком диске) решит выяснить, что же он содержит.
Последний, третий по счету вариант представляется идеальным: в имени файла содержится указание не только на название программы, но и на номер ее версии. Пользователь, едва взглянув на имя файла, может сделать вывод о назначении этого дистрибутива. Кроме того, при таком методе наименования файлов соответствующий дистрибутив — нужной программы и нужной версии — легко найти на специализированных файловых поисковых системах наподобие www.filesearch.ru.
Однако, при всех достоинствах, этот способ имеет большой недостаток. После выпуска очередной версии программы ссылки на ее файл быстро расползаются по всему Интернету: автор регистрирует программу в различных online-архивах, а некоторые архивы сами добавляют эту программу в свои базы данных. Но после того, как в свет выходит новая версия программы, имя файла меняется: ведь версия программы тоже изменилась. В результате все ссылки, которые стоят на файл программы на страницах интернет-каталогов программного обеспечения, компьютерных обозрений и других информационных ресурсов, перестают работать, и соответственно посетители не могут скачать программу по этим ссылкам. С помощью небольшой настройки Web-сервера эту проблему можно решить, но не все авторы shareware-программ имеют возможность произвести такую настройку. Чтобы хоть как-то поправить положение, разработчику приходится писать письма администраторам соответствующих архивов или заполнять Web-формы с просьбой изменить ссылку на файл программы. Беда в том, что крупные архивы, как уже упоминалось (см. разд. "Периодичность выпуска" данной главы), могут обновить информацию о программе в своих базах данных спустя недели и даже месяцы после того, как получат соответствующие запросы, и все это время файл программы не будет доступен для посетителей данных сайтов. И никто не знает, сколько зарегистрированных пользователей из-за этого недосчитается программа. Учитывая сказанное выше, мне наиболее оптимальным представляется вариант номер два: имя файла включает только название (или его аббревиатуру) программы, без номера версии. В таком случае название остается более-менее понятным, а внешние ссылки на файл программы остаются рабочими при выходе новых версий программы. Правда, при поиске в файловых системах трудно будет найти конкретную версию данной программы. Однако этим стоит пожертвовать ради того, чтобы внешние ссылки на файл программы сохраняли свою работоспособность после выхода ее новой версии: это окажется гораздо более выгодным в плане увеличения числа зарегистрированных пользователей.
Реквізити гаманців WebMoney
Z536361860574
R373015687019
U879214523453
E188856618791