Создание инсталлятора

Созданную новую версию программы, в принципе, уже можно распростра­нять среди пользователей. Запаковать ЕХЕ-файл 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-формы с просьбой изменить ссылку на файл программы. Беда в том, что крупные архивы, как уже упоминалось (см. разд. "Периодичность выпуска" данной главы), могут обновить информа­цию о программе в своих базах данных спустя недели и даже месяцы после того, как получат соответствующие запросы, и все это время файл програм­мы не будет доступен для посетителей данных сайтов. И никто не знает, сколько зарегистрированных пользователей из-за этого недосчитается про­грамма. Учитывая сказанное выше, мне наиболее оптимальным представ­ляется вариант номер два: имя файла включает только название (или его аббревиатуру) программы, без номера версии. В таком случае название оста­ется более-менее понятным, а внешние ссылки на файл программы остают­ся рабочими при выходе новых версий программы. Правда, при поиске в файловых системах трудно будет найти конкретную версию данной про­граммы. Однако этим стоит пожертвовать ради того, чтобы внешние ссылки на файл программы сохраняли свою работоспособность после выхода ее но­вой версии: это окажется гораздо более выгодным в плане увеличения числа зарегистрированных пользователей.