ASProtect взломщики отдыхают

ASProtect: взломщики отдыхают

В конце разд. "Реализация защиты и ее взлом" этой главы приведен "скорбный" список из дюжины продуктов для организации защиты shareware-программ, которые были взломаны. Но все-таки есть в этой категории продукт, защита которого пока остается нерушимой. Его не раз рекомендовали как отличное средство организации защиты и в российской конференции SwRus, и в зарубежных, например, news:comp.shareware.authors. Называется он ASProtect (http://www.aspack.com) и написан нашим соотечественником Алексеем Солодовниковым. От одного опытного специалиста в области компьютерной безопасности мне приходилось как-то слышать такие слова: "Во времена ASProtect можно с защитой уже особо и не париться".

Действительно, ASProtect обеспечивает комплексную защиту shareware -программ:

упаковку и шифрацию кода, данных, таблиц импорта и ресурсов файлов программы; генерацию очень длинных и сложных ключей (как статических, так и динамических); "черные списки" для блокировки украденных ключей; обработку ограничения работы программы по времени; П распознавание активности отладчика; специальные API-функции для взаимодействия ASProtect с защищаемой программой.

Механизм защиты ASProtect основан на принципе "конверта", в который как бы помещается приложение. Сначала код, данные, таблицы импорта и ресурсы файлов программы шифруются и упаковываются с использованием оригинального алгоритма ASPack, при этом двоичный код анализируется на предмет наличия в нем API-функций ASProtect, и код, отвечающий за защиту, присоединяется к концу исходного файла. Размер этого кода — около 40 Кбайт, но за счет упаковки приложения по алгоритму ASPack объем файла программы сокращается более чем на 50%.

После запуска ЕХЕ-файла программы управление передается к тому самому, в 40 Кбайт, модулю защиты. Он проверяет целостность файла, активность отладчика (при его обнаружении работа защищенной программы прекращается), наличие регистрационного кода, обрабатывает ограничение работы по времени и, наконец, расшифровывает и распаковывает данные основного приложения и передает ему управление.

Наличие API-функций, с помощью которых ASProtect взаимодействует с защищаемым приложением, многократно повышает сложность взлома защиты. С освоением этого API нет никаких сложностей: функции имеют простой синтаксис, и, кроме того, в документации к программе приводятся примеры внедрения защиты на C++, Delphi и Visual Basic.

Регистрационные коды, генерируемые ASProtect, имеют минимальную длину 137 символов. В программе есть диалоговое окно Украденные ключи. Если автор программы обнаружит, что какой-либо из выданных ключей попал в руки злоумышленников, то он может поместить его в список, еще раз запустить процедуру защиты ЕХЕ-файла — и программа перестанет воспринимать этот ключ.

Если запустить поиск по слову ASProtect, например, в http://www.yandex.ru, то можно найти много страничек, где рассказывается о том, как взломать защиту ASProtect. Но все это относится только к ранним версиям пакета, в механизме защиты которых существовали "дыры". К версии 1.2 все ошибки были исправлены, и с тех пор, несмотря на многочисленные попытки, защита ASProtect так никем и не была сломана.

Примечание
Примечание

Отдельные случаи взлома программ, защищенных ASProtect 1.2, известны. Однако, как оказалось, авторы этих программ при реализации защиты не использовали одну из важнейших функций ASProtect— шифрование кода. А без шифрования кода взломать защищенную ASProtect программу не может только начинающий крякер.

ASProtect, естественно, не является бесплатным продуктом, и его цена относительно высока для начинающего шароварщика — 99$. Но в то же время это одно из самых выгодных вложений на этапе начала собственного shareware-проекта.

Демоверсия

Демо-версия

Демо-версия — самый простой для реализации, но одновременно самый неудобный вид защиты. Из программы просто удаляются некоторые фрагменты кода, в результате чего функциональные возможности программы сильно ограничиваются. Такая "урезанная" версия затем выкладывается на Web-сайт, а оплатившим регистрацию пользователям высылается "полная" версия по электронной или обычной почте либо сообщается "скрытый" от посторонних адрес, по которому ее можно скачать.

Достоинство этого варианта в том, что "взломать" саму программу невозможно — ведь программная защита как таковая в ЕХЕ-файле отсутствует. С другой стороны, зарегистрированная версия программы может легко стать доступной всем, а не только тем, кто ее оплатил. Например, кто-нибудь из купивших программу может выложить ее где-нибудь в Интернете или, если зарегистрированная версия не высылается по почте, а скачивается с Web-сервера — опубликовать "секретный" адрес для всеобщего пользования. Самое обидное, что у автора нет никаких шансов узнать, кто именно из пользователей сделал ему такую гадость (если только виновник сам не укажет себя).

Разработчику же распространение программы в виде демо-версии доставляет много хлопот. Например, рассылка зарегистрированных версий по электронной, не говоря уже об обычной, почте сопряжена с большими накладными расходами. Если же пользователи должны загружать "полную" версию с Web-сервера, то автор программы должен постоянно быть готовым к тому, что экземпляр полнофункциональной версии появится в свободном доступе где-нибудь в Сети, а убрать ее оттуда окажется очень непросто. Если разработчик захочет защититься от скачивания "полной" версии незарегистрированными пользователями с помощью опубликованного кем-то "секретного" адреса, ему следует поместить файл с дистрибутивом программы в специальный защищенный паролем каталог на своем сервере. Далее необходимо постоянно добавлять в настройки имена новых пользователей, имеющих право доступа к этому каталогу, а также удалять имена пользователей, опубликовавших свои логины и пароли в Интернете.

Демо-версии не так удобны и для пользователей. Например, для получения полной версии нужно обязательно иметь доступ в сеть Интернет (рассылка "полных" версий обычной почтой встречается очень редко), а это не всегда возможно, ведь дистрибутив программы может быть переписан у знакомых или куплен на CD-ROM со сборником shareware-программ. Кроме того, доступ этот должен быть довольно быстрым, чтобы перекачать из почтового ящика большой файл (кстати, многие почтовые серверы настроены таким образом, что не принимают большие файлы).

Как видите, недостатки этого вида защиты более весомы, чем достоинства, поэтому в shareware демо-версии используются очень мало. Их можно распространять разве что дополнительно к ограниченным по времени или функционально версиям -- включать на CD-ROM, раздавать на выставках — т. е. применять исключительно в рекламных целях.

Функционально ограниченная версия

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

Какие именно функции закрыть — решает, конечно, сам автор программы. Можно, например, запретить сохранение настроек. Графические редакторы обычно при сохранении изображения добавляют в него штамп "Сделано в зарегистрированной версии"; системы управления базами данных работают с ограниченным числом записей или таблиц программы поиска в Интернете, опрашивают только одну-две поисковых системы вместо "полного комплекта" и т. д. Главное — не перестараться с ограничением функций и не превратить свою программу в маломощную поделку, иначе пользователь может просто не оценить полезные свойства программы и решить, что регистрация ему не требуется. Нужно стараться не выкидывать какие-то функции, а ограничивать их мощь, чтобы пользователь попробовал их и хотел бы использовать в полную силу. Это своеобразная "приманка" в охоте за регистрация-ми пользователя. А вот если какие-то функции программы в незарегистрированной версии не доступны полностью и о них только рассказывается в справочной системе, то это является не таким сильным стимулом для пользователей.

Как и в случае с "time-limited''-версией, функциональные ограничения незарегистрированной версии могут быть сняты без оплаты программы, при помощи взлома защиты.

Помимо этих трех основных видов стимулирования пользователей к оплате регистрации, применяется еще и так называемый nag-screen (см. Рисунок 6.1), что в дословном переводе означает "экран ворчания". Это — диалоговое окно, которое появляется чаще всего при запуске программы (а иногда — в момент осуществления ключевых функций, при завершении работы или вообще случайным образом), и сообщающее, что данная версия программы является ознакомительной и что для использования программы требуется регистрация.

Nag-screen ("экран ворчания"; из-за неблагозвучности русского перевода этот термин употребляют в оригинальном виде) — очень эффективный способ стимуляции пользователей, т. к. он является мощным источником раздражения, о чем я уже напоминал в разд. "Не делайте из программы культа" гл. 4. Интересный факт: один из самых популярных мировых архивов бесплатных программ называется NoNags (http://www.nonags.com) чем не прозрачный намек на особую "любовь" пользователей к nag-screen. Некоторые специалисты советуют, от греха подальше, не включать в программы nag-screen, чтобы "не превращать заказчиков в своих врагов". Но, по другому распространенному мнению, если при проектировании защиты программы чувствовать меру и не делать "экраны ворчания" слишком навязчивыми и агрессивными, то можно значительно повысить число своих пользователей.

Nag-screen можно использовать как совместно с каким-либо другим видом защиты (например, в моей программе Actual Startup nag-screen присутствует совместно с тридцатидневным испытательным сроком), так и в качестве единственного "стимулятора" регистрации, как например, в WinZip (см. Рисунок 6.1).

Хакеры и крякеры

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

Сначала нужно сказать о том, что настоящие хакеры, которые являются высококлассными специалистами в области компьютерной безопасности, взломом защит программных продуктов не занимаются. Ведь по сравнению с проникновением в компьютерные сети и кражей ценной информации взлом программ, большинство из которых можно купить всего за 20-30$ -слишком мелкое и неприбыльное дело: ведь денег за это не платят! Для взлома защиты программы не нужно того опыта и знаний, которыми обладает квалифицированный хакер, для него это пустяки, на которые не следует отвлекаться.

Примечание
Примечание

Известны немногочисленные случаи, когда взломщикам все-таки поступали заказы от коммерческих предприятий на слом защит очень дорогих — стоимостью в тысячи долларов — программных продуктов. Но цена такого заказа — всего лишь около пятидесяти долларов; что, учитывая небольшой спрос на такой "коммерческий взлом", никак нельзя назвать прибыльным бизнесом.

Взломом защит компьютерных программ занимаются так называемые крякеры. Термин этот произошел от английского "crack", что в данном случае означает (цитата из конференции newsralt.cracks) "любой метод, применяемый для преодоления защиты компьютерной программы, чтобы сделать возможным ее неограниченное использование без платежей ее автору". Вообще говоря, если следовать правильной английской транскрипции, то следовало бы говорить не "крякер", а "крэкер", но последнее по звучанию уж слишком похоже на название печенья "крекер", да и термин "крэк" давно закреплен за одним из видов сильнодействующего наркотика, поэтому вместо этого говорят "кряк".

Что же представляет из себя типичный крякер? Чаще всего это подросток, учащийся в школе, в лучшем случае — на первых курсах ВУЗа. В этом возрасте человеку присущи, помимо всего прочего, два свойства: во-первых, желание самоутвердиться, показать всем, что он "круче", чем более взрослые люди и, во-вторых, отсутствие заботы о заработке денег и содержании семьи. Этим и объясняются действия крякеров, занимающихся делом, которое не приносит им никаких денег. Стремясь самоутвердиться, они идут на все, лишь бы громко заявить: "Именно я сломал эту крутую прогу!" Они взламывают даже FAR, который для жителей бывшего СССР бесплатен, лишь бы доказать свое мнимое превосходство над известным разработчиком. Или, например, не будучи в состоянии вскрыть защиту какой-то программы, покупают по украденному номеру кредитки регистрационный номер, а затем пишут программку, которая "прописывает" в нужное место ЕХЕ-файла этот номер, что не является взломом и не свидетельствует о "победе" крякера. Тем не менее, эта программка выкладывается в Сеть под видом кряка, и ее автор восторженно кричит в news- и Web-конференциях: "Сломал, сломал!" А некоторые даже честно покупают регистрационный код за свои кровные и публикуют его в Интернете, заявляя, что самостоятельно подобрали его и, следовательно, защита в этой программе никудышная. Shareware-авторы шутят, что даже если делать отдельные демо- и полные версии программ, то крякеры, стремясь во что бы то ни стало заявить о взломе, напишут гигантский файл, который будет конвертировать одно в другое, и гордо назовут это "кряком!"

Правда, есть небольшое количество крякеров, которые стараются действовать честно, соблюдая даже некий "кодекс чести". Видимо, это те, кто уже вышел из юношеского возраста, получил хорошую профессию и работу и занимается взломом программ из "спортивного" интереса, изучая на практике различные механизмы защиты. Они с уважением относятся к труду авторов программ и не боятся признавать свои поражения. Так, например, известный крякер Saltine, не сумев-в течение многих недель взломать защиту программы Advanced Disk Catalog (http://www.elcomsoft.com), заявил, что видит единственный способ преодолеть защиту программы — прописать правильный код в тело ЕХЕ-файла (описанный выше нечестный метод псевдовзлома), но не будет этого делать, т. к. это не по-джентльменски. Позже он законно приобрел регистрационный код к Advanced Disk Catalog, но не стал его раздавать всем желающим.

Как бороться с крякерами? Некоторые shareware-разработчики вообще не уверены, что это нужно делать. По наблюдениям многих из них, появление в Интернете кряков к программам не очень сильно сказывается на динамике продаж. Исключение составляют Россия и страны с традиционно низким уровнем жизни: количество регистрации от пользователей из этих государств после появления кряков падает в несколько раз. Если продукт не ориентирован полностью на Россию, то это не принесет больших убытков: число пользователей из этих стран и так невелико. А вот если автор продает бухгалтерскую или банковскую программу — кряки могут нанести серьезный урон бизнесу. Но большинство shareware-авторов не может сказать, что наличие кряков им очень сильно мешает — скорее, отсутствие кряков помогает.

Примечание
Примечание

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

Что касается борьбы с крякерами, то самый надежный метод — это сильная защита от взлома. Договориться с крякерами нельзя: можно убедить одного, но договориться со всеми или группой -- невозможно. Закрывать Web-сайты, на которых размещены кряки, тоже бесполезно: их слишком много, да и провайдеры не всегда реагируют на письма с жалобами. Так что лучше всего не зависеть от крякеров или провайдеров, а полагаться только на свои силы, улучшая стойкость защиты собственных shareware-программ.

Кодогенератор к WinZip

Рисунок 6.3. Кодогенератор к WinZip

Нужно сказать, что защита большинства программ взламывается всего за 10—15 минут. Для этого нужно лишь несколько инструментов: дизассемблер, отладчик, еще несколько утилит и хотя бы базовое знание ассемблера (впрочем, без последнего часто можно обойтись).

Вариантов того, как крякер "подбирается" к защите и ломает ее, может быть много. Рассмотрим основные из них.

Чаще всего крякер стремится подобрать к программе регистрационный код, чтобы зарегистрировать на ее себя и опубликовать пароль в Интернете. Тогда сбудется "голубая мечта" крякера - мировая известность: любители "халявы" станут использовать этот пароль при разблокировании своих копий программы, и в диалоговых окнах О программе (About) в графе Registered by будет стоять имя крякера.

Обычно процесс регистрации программы организован так. Пользователь попадает в диалоговое окно Регистрация, нажав соответствующую кнопку в nag-screen или вызвав соответствующий пункт меню. Он вводит в текстовое поле ключ и нажимает кнопку ОК, после чего программа проверяет соответствие введенного ключа некоторым условиям. Эта верификация может быть очень сложной и запутанной, но в конце концов она приходит к закономерному результату, а именно операции сравнения введенного ключа с некоторым образцом или записи в регистр памяти результата верификации.

Дело в том, что все операции, программируемые при помощи языков высокого уровня (C++, Delphi, Basic), используют вызовы функций API Windows или обращения к runtime-библиотекам. Все эти функции легко отслеживаются отладчиком. Если же программа использует динамические ключи, то перед сравнением введенного регистрационного номера она по также введенному имени пользователя генерирует "правильный" ключ, который замечательно виден при помощи отладчика. Однажды я почувствовал всю эффективность этого метода на себе. Когда я впервые написал подобную защиту к одной из своих программ, то отослал эту программу знакомому программисту, который иногда, ради развлечения, взламывал различные shareware-продукты. Он перезвонил через десять минут и сообщил правильный регистрационный код, а заодно рассказал, что код ему в отладчик "выложила" сама моя программа.

Если же автор программы хорошо потрудился над защитой и пароль подобрать невозможно, то крякер с помощью дизассемблера и отладчика находит в программе место, где определяется, зарегистрирована ли программа или нет, модифицирует значение, возвращаемое проверочной функцией (например, безусловный переход меняется на условный). После этого пишется маленькая программа, которая делает то же самое, но не в памяти, а в самом ЕХЕ-файле (это и есть патч).

Кроме того, можно сделать и так: "вырезать" из ЕХЕ-файла программы код, который отвечает за генерацию ключей, и вставить его в маленькую программку, которая будет создавать правильные ключи для всех желающих, т. е. будет кодогенератором.

Если в программе применяется ограничение по времени, то это открывает крякерам дополнительную лазейку в защите. Заключается она в том, что время первого запуска (или количество запусков) хранится во внешнем файле (INI или системном реестре). С помощью бесплатных программ File Monitor и Registry Monitor, которые можно скачать с сайта www.sysinternals.com, легко выяснить, к каким ключам в реестре и каким файлам обращается программа, какие данные туда пишет и какие читает. А дальше не составит никакого труда найти соответствующие вызовы в программе при помощи отладчика и дизассемблера.

Естественно, такая ситуация авторов shareware-программ не устраивает. Они стремятся усилить защиту, но, увы, некоторые из них выбирают не совсем правильный путь.

Кому-то кажется хорошим вариантом привязка к компьютеру. Из программы очень легко получить какие-то данные о системе (например, серийный номер жесткого диска), и поэтому в воображении программиста быстро вырисовывается такая схема: пользователь высылает автору эти данные, который, после подтверждения оплаты, вычисляет на их основе регистрационный код и высылает его пользователю. В программе закодирован тот же самый алгоритм, происходит сверка и — готово. Если же код попадет в чужие руки, то на других компьютерах он работать не будет.

Тем не менее этот способ обычно доставляет больше неудобств зарегистрированным пользователям, чем крякерам, т. к. сломать такую защиту очень легко: здесь работает тот же фокус с патчами, "препарирующими" проверочные функции. А вот честному пользователю придется изрядно помучиться, если он поменяет компьютер...

Та же ситуация возникает с аппаратными ключами, подключаемыми к параллельному порту компьютера (типа HASP). Ведь проверка все равно осуществляется в программе, а следовательно, и эта защита может быть легко взломана. Так и есть - "патчи" существуют ко многим системам защиты при помощи аппаратных ключей. При этом эти ключи доставляют много хлопот как разработчикам (высокая стоимость — нужно обеспечить доставку ключей заказчикам), так и пользователям. Например, при подключении к параллельному порту аппаратного ключа экономического Project Expert 7.0 подключаемый к этому же порту имеющийся в нашем офисе сканер Hewlett-Packard перестает нормально работать.

Существует достаточно много программных продуктов, которые позволяют авторам реализовать защиту для своих программ. Это - IntelliSecure R2, TimeLock, ShareLock, CrypKey, StopCopy, Unlocker, RSAgent32, Software Licensing System, ZipLock, BuyOnet, UnBox, Vbox. Но, к сожалению, все они давно уже вскрыты (см. http://www.fravia.org), и воспользоваться ими — все равно, что приложить к программе подробную инструкцию по ее взлому.

Напоминание о регистрации архиватора WinZip

Рисунок 6.1. Напоминание о регистрации архиватора WinZip

Однако нужно вспомнить, что деньги возникли когда-то как средство обмена одной материальной ценности на другую. Сейчас их можно потратить и на удовлетворение духовных потребностей — например, сходить в театр, -но суть от этого не меняется. Потратив деньги, мы что-нибудь получаем взамен. Исключение — меценатство.

Но что получит человек взамен, если ему предлагают потратить 20$, заплатив за shareware-программу, в которой нет никаких ограничений, никакой защиты? Ничего. Кто-то скажет: "Программу". Но программа у пользователя уже есть. Вот и выходит, что автор просит у него деньги, взамен ничего не давая.

Shareware с ознакомительной версией, в которой есть ограничения, в этом смысле более корректно. Пользователь покупает за свои деньги именно программу, точнее возможность нормально ее использовать. А вот фактически бесплатная программа, имеющая статус shareware, ставит пользователя в двусмысленное положение. Здесь могут работать только меценатские мотивы, желание материально поддержать разработчика программы. Но меценаты — прослойка достаточно обеспеченных людей, и деньги они тратят, как правило, на социальные и прочие общественно полезные проекты. Разработка программ к ним не относится.

Что касается WinZip... Да, незарегистрированная версия программы не имеет никаких ограничений, кроме напоминания о необходимости регистрации. Даже это напоминание можно убрать совершенно бесплатно — генератор, который создает коды для "регистрации", написан уже очень давно, а разработчики WinZip не меняют механизм проверки кодов при выходе новых версий. И, тем не менее, только через одного из дистрибьюторов WinZip продается на сумму более чем сто тысяч долларов в месяц.

Но при этом нужно помнить, что WinZip, как говорится, "попал в струю" -тогда, в начале 1996 года, Windows 95 и Интернет набрали уже большую популярность, но средств удобной работы с файлами и архивирования не было — альтернативой Norton Commander и pkzip был Проводник Windows, только крайне неудобный. И тут, когда существовала неудовлетворенная потребность работать с архивами не из командной строки, а из графического интерфейса пользователя (прежде всего у десятков миллионов "чайников", только что купивших Windows 95), появился WinZip во всей красе. Пусть не самый удобный, но зато понятный и, самое главное — это было настоящее GUI application for Windows 95! Конечно же, WinZip распространился очень широко.

Но это исключение из правил, такое же исключение, как бесплатный мультимедиа-плейер WinAmp, который, даже будучи несколько лет назад shareware-программой ценой в десять долларов, не имел никаких ограничений. Эти программы были пионерами и распространились чрезвычайно широко. Здесь (в этом случае) сработала такая маркетинговая схема: сначала вы имеете небольшое количество регистрации, но затем, после того как продукт распространится максимально широко, даже небольшой, по сравнению с числом пользователей, процент продаж приносит вам очень много денег.

Но, появись эти программы сегодня, когда рынок насыщен ZIP-архиваторами и мультимедиа-плейерами — вряд ли они стали бы такими же популярными и прибыльными, как тогда. Поэтому не нужно полагаться на такую схему. Дайте пользователю почувствовать, что взамен своих денег он получил что-то вполне определенное.

Напоминание в текстовом редакторе

Рисунок 6.2. Напоминание в текстовом редакторе UltraEdit-32, что она будет работать еще 42 дня

В чем же считать "испытательный срок" - в днях или запусках? Чаще всего отсчет ведется в днях. Тридцать дней — стандартная продолжительность этого срока, указанная в Уставе Ассоциации профессионалов shareware. Если же выбрать для отсчета запуски, то может получиться ситуация, когда пользователь еще не успел изучить работу с программой, а количество запусков уже превысило лимит незарегистрированной версии и программа отказывается работать — ведь невозможно предугадать, с какой интенсивностью программа будет использоваться. Мне как-то попалась "звонилка" (утилита для дозвона к интернет-провайдеру), "испытательный срок" которой исчислялся всего пятнадцатью запусками. Программа работала не очень корректно, из-за чего приходилось ее постоянно перезапускать, и когда милосердно отпущенные мне 15 запусков прошли, я так и не успел с ней разобраться. Естественно, о регистрации, которую настойчиво стала требовать программа, не могло быть и речи.

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

Ограниченная по времени версия

Ограниченная по времени (time-limited) версия — более распространенный вариант, хотя и более сложный для реализации. Незарегистрированная версия после установки на компьютере пользователя работает какой-то период времени, исчисляемый либо в днях (обычно 30 дней), либо в запусках (Рисунок 6.2). По истечении этого срока программа прекращает работать, выводя после запуска сообщение об окончании "trial period" и необходимости зарегистрироваться.

Реализация защиты и ее взлом

Как видно из разд. "Виды защиты" этой главы, сегодня для shareware-рынка актуальны два типа защиты программ: ограничение по времени работы и ограничение по функциям. О демо-версиях говорить особенно не нужно, т. к. это очень простой и одновременно очень непопулярный вариант реализации защиты shareware-программ.

При ограничении по времени программа хранит в каком-нибудь файле дату первого запуска и при очередном запуске проверяет, сколько дней осталось до окончания ознакомительного срока. Если ограничение по времени исчисляется в количестве запусков, то программа при первом запуске записывает в файл начальное значение счетчика и при каждом последующем запуске это значение увеличивается па единицу и проверяется, не превышен ли лимит на число запусков, установленный автором. В случае положительного результата (ознакомительный срок закончен) программа перестает работать.

Что касается ограничения по функциям, то здесь тоже не нужно много объяснять. При старте программа проверяет, зарегистрирована ли она, и в зависимости от этого решает, разблокировать ли недоступные для незарегистрированных пользователей функции или нет.

В обоих случаях — при временном и функциональном ограничении — программа разблокируется посредством ввода регистрационного ключа. Эти ключи бывают двух видов: статические, которые заранее определены автором программы, и динамические, т. е. генерируемые в зависимости от каких-то исходных данных — чаще всего имени пользователя.

Как только программа появляется на shareware-рынке, она почти сразу привлекает внимание взломщиков, которые, немного потрудясь, выпускают к программе кряки.

Кряки делятся на две основные группы: патчи и кодогенераторы. Патч (patch) — это небольшая программка, которая модифицирует один или несколько файлов исходной программы таким образом, чтобы отключить защиту. Кодогенератор (keygen) — также небольшая программа, которая генерирует регистрационные ключи, введя которые можно разблокировать ту или иную shareware-программу (Рисунок 6.3). Иногда крякеры публикуют в Интернете не кодогенератор, а просто подобранный регистрационный номер (serial number, reg. code или просто serial code).

Усиление защиты

А теперь — несколько рекомендаций и советов, которые могут помочь повысить стойкость защиты shareware-программы перед атаками крякеров. Часть из них приводится на сайте www.fravia.org, на котором опубликовано много статей о взломе компьютерных программ и систем защиты, часть — рассказана опытными разработчиками shareware-программ, которые противостоят крякерам не один год.

Рекомендуется зашифровывать код, который отвечает за функции защиты, с помощью сильных средств шифрования с открытым ключом. При этом лучше использовать знакомые алгоритмы вроде RCA. Из теории шифрования следует, что методы шифровки с неизвестным алгоритмом потенциально ненадежны. Только шифрование по известному алгоритму наподобие того же RCA имеет математически доказуемую стойкость. Очень хороший шаг — упаковать- ЕХЕ-файл программы "интеллектуальным" упаковщиком наподобие AsPack (http://www.aspack.com). Применение такого упаковщика может очень сильно защитить программу, значительно затрудняя анализ структуры кода крякером. Храните важную информацию (например, дату первого запуска, количество запусков) в файле, к которому и так происходит много обращений. В этом случае чтение секретной информации "затеряется" на фоне остальных обращений, и это будет не очень легко обнаружить при использовании вышеупомянутой утилиты File Monitor. Сохраняйте пароли в каком-либо "необычном" месте, например в полях свойств базы данных. Сохраняйте пароль в нескольких местах одновременно. Не предупреждайте сразу пользователя о том, что защита нарушена. Лучше сделать это через два-три дня. Крякер, как правило, не будет использовать ее столько времени: получив удовлетворительный результат, он удалит программу и примется за следующую. Развитие предыдущего совета: пусть регистрационный код удовлетворяет нескольким условиям, которые проверяются не сразу, а с интервалом в несколько дней. Таким образом, крякер подбирает код, который удовлетворяет первому условию и "успокаивается" на этом. Главное — поместить фрагменты кода, которые отвечают за проверку разных условий, в разные части программы, чтобы крякер при взломе "первого рубежа" не догадался о втором. Совет, выполнение которого будет особенно эффективным в сочетании с советами 6 и 7 — не сообщать о том, что введен неправильный код, "открытым текстом". Лучше выводить сообщение о критической ошибке и просьбу связаться с разработчиком. Пользователи будут думать, что это ошибка в программе, и будут писать автору об этом. И тут уже будет ясно, кто пользуется программой законно (например, просто ошибся при вводе кода), а кто установил кряк. Последним можно предлагать оплатить регистрацию, чтобы избавиться от досадной "ошибки". Делайте небольшую (продолжительностью 1—2 секунды) при возврате результата в ответ на введенный пользователем пароль. Это сделает невозможным подбор правильного регистрационного кода путем прямого перебора вариантов при помощи специально написанной программы. Делайте свои регистрационные коды очень длинными и сложными, чтобы простой перебор вариантов занял у крякера несколько тысяч лет (если, конечно, у него нет дома суперкомпьютера). Вычисляйте системную дату не при помощи стандартных функций, а определяйте ее по дате изменения файлов system.dat, system.а0 и bootlog.txt. Не нужно давать осмысленные имена важным файлам и функциям, например, IsValidSerialNum. Если вы используете статические ключи, то делайте их похожими на программный код или названия функций (например, "73AF" или "GetWindowText"). Это действительно очень эффективно и сбивает с толку многих крякеров. Не используйте жестко "прошитые" в программу строки текста для уведомления пользователя о том, что пароль правильный (или неправильный). Это первое, на что смотрит крякер. Генерируйте эти строки динамически или используйте хотя бы самое простое шифрование. Используйте "перекрестные" проверки CRC-кодов ваших ЕХЕ- и DLL-файлов. И, наконец, никогда и никому не рассказывайте, как устроена ваша защита.

Замечание 1
Замечание 1

Любая защита, которую даже теоретически нельзя сломать, все-таки ломается, если к злоумышленнику попадает правильный регистрационный ключ (например, в результате покупки по украденному номеру кредитной карточки). Здесь — полная аналогия с бытом: любой самый совершенный замок откроется, если иметь ключ. Поэтому нужно не терять бдительности и помнить, что самая нерушимая защита — еще не решение проблемы кряков.

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

Виды защиты

Существует три основных типа защиты shareware-программ: демо-версия, ограниченная по времени версия и функционально ограниченная версия.

Зачем нужна защита

Наличие защиты в shareware-программах обусловлено самим принципом shareware: "Попробуй, прежде чем купить". Разработчик предоставляет свою программу для тестирования, а если программа понравится, то пользователь может оплатить регистрацию. Если бы распространение копий программы строго контролировалось, а все пользователи были известны, что называется, "в лицо", с получением денег за программу не было бы почти никаких проблем. Но shareware-программы скачиваются по Интернету огромным числом людей, находящихся от автора на большом расстоянии. Для того чтобы стимулировать пользователей оплачивать регистрацию, программисты включают в программу всевозможные ограничения, отличающие незарегистрированную версию от зарегистрированной.

В самом начале развития shareware-индустрии, во времена расцвета PC-Talk и PC-File (см. разд. "История shareware" гл. 1), условно-бесплатные программы не имели никаких ограничений. В документации автор просто указывал, что пользователи, если программа им понравится, могут прислать ему определенную сумму денег.

С появлением множества других shareware программ эта схема быстро потеряла свою эффективность. Многие разработчики на своем опыте убедились, что при отсутствии защиты программу покупают очень мало, зато при вставке в программу хотя бы экрана, напоминающего о необходимости регистрации продукта, число зарегистрированных пользователей резко увеличивается. Защиту не заменит даже то, что вместо денег за регистрацию требуется прислать всего лишь заполненную анкету: пользователей, действительно сделавших это, будут единицы. У пользователя должен быть реальный стимул зарегистрировать программу, одного лишь сообщения о ее статусе shareware в лицензионном соглашении недостаточно.

Несмотря на это, начинающие шароварщики до сих пор пытаются начать продавать свою программу без защиты, лишь с напоминанием о необходимости зарегистрироваться, указанным не в самом заметном месте — в справочной системе, файле readme.txt или диалоговом окне О программе. Многих вдохновляет пример WinZip, который распространяется в виде полнофункциональной версии и всего лишь напоминает о необходимости зарегистрироваться (Рисунок 6.1).

Adobe Acrobat

Adobe Acrobat (Рисунок 7.5) был разработан компанией Adobe как более эффективная альтернатива HTML. Как известно, основное достоинство HTML -независимость платформы: HTML-документ можно прочитать на компьютере с любой операционной системой, главное, чтобы было установлено средство просмотра HTML-файлов. Однако при этом документ выглядит на разных компьютерах по-разному: это зависит от установленных на компьютере пользователя шрифтов и других системных настроек, а также названия и версии средства просмотра HTML. Как известно, страница, отлично отображаемая в Internet Explorer, может вообще не показываться в Netscape Navigator, и наоборот. А уж многочисленные мелкие, но раздражающие искажения, которые возникают при просмотре страниц в разных браузерах, давно стали предметом горячих споров в интернет-конференциях.

Документация на Webсайте

Документация на Web-сайте

Некоторые разработчики слишком буквально понимают термин "online help", который на самом деле обозначает справочную систему в электронном, а не печатном, виде. Поэтому при нажатии клавиши <F1> или вызова меню Help в их программе, запускается установленный в системе интернет-браузер и загружает... раздел "Справка" с Web-сайта разработчика программы!

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

Интернете часто приводит к тому, что пользователь не может получить к ней доступ тогда, когда ему требуется помощь. Например, пользователь может скачать программу дома, а использовать ее на работе, где по каким-либо причинам выход в Интернет может отсутствовать, и наоборот. И даже если доступ в Интернет на компьютере имеется, то домашнему пользователю для выяснения каких-то деталей относительно работы с программой нужно дозваниваться до интернет-провайдера, что при частых обращениях к справочной системе очень раздражает. Кроме того, скорость доступа к справочной системе, размещенной в Сети, не сравнима со скоростью чтения файла Справки с жесткого диска компьютера. И наконец, не нужно забывать, что за пользование Интернетом провайдеры берут деньги, а значит, доступ к справочной системе программы тоже будет платным!

HTML Help

HTML Help (Рисунок 7.3) — новый формат файлов для документации, разработанный Microsoft как замена "старичку" WinHelp. Первой операционной системой, в которую был включен HTML Help, стала Windows 98.

Как писать документацию

Прежде чем писать документацию, нужно определить ее будущую структуру, т. е. из каких разделов она будет состоять.

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

Для решения первой задачи, т. е. помощи пользователям в преодолении различных проблем с освоением и работой с программой, следует включить в документацию раздел Introduction (Введение), в котором рассказать о назначении программы, а также гораздо более объемный раздел Description (Описание), в котором дать описание меню, диалоговых окон и прочих элементов программы.

Считается, что для составления текста справочных систем применяются два подхода: либо вы рассказываете для чего что-то предназначено, либо о том, как что-то сделать (wanting to know vs. wanting to do). Однако, на мой взгляд, при определении структуры и содержания Справки эти два подхода нужно объединить и добавить в документацию раздел How to... (Как сделать...). Дело в том, что все вопросы, с которыми пользователи обращаются к справочной системе, можно разделить на две группы: "Что означает этот элемент (меню, кнопка, флажок и т. п.)?" и "Как мне сделать то-то (отфильтровать данные, переформатировать текст, настроить параметры и т. п.)". Если же в документации будет только описание элементов программы, то на вопросы категории "Как мне сделать то-то?" найти ответ для не очень опытных пользователей будет гораздо сложнее.

Кроме того, нужно создать в Справке раздел Technical Support (Техническая поддержка), где указать адреса e-mail, по которым пользователи могут задать свои вопросы, а также привести ссылки на источники дополнительной информации о программе, если они имеются: форум на Web-сайте, список ответов на часто задаваемые вопросы (FAQ) и т. п.

Для отражения в документации принадлежности программы к shareware-программы следует создать раздел Registration (Регистрация), где завести подразделы, в которых рассказать о цене программы, дать ссылки на Web-сайты компаний-регистраторов, указать преимущества статуса зарегистрированного пользователя (например, бесплатные обновления, отсутствие ограничений функциональности программы) и другую информацию по этой теме.

Если у вас имеется несколько shareware-продуктов, то удачным шагом будет создание еще одного раздела: Our products (Наши продукты), где будет дана информация о ваших других программах и ссылки на их Web-страницы и файлы для загрузки. Эта информация будет полезна для тех пользователей, которые получили дистрибутив программы не с Web-сайта разработчика (а, например, скачали его с сервера интернет-архива или купили в составе сборника shareware-программ на CD-ROM) и ничего не знают о других продуктах этого же автора. Очень часто бывает, что люди начинают интересоваться ими, скачивают, тестируют и — оплачивают регистрацию.

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

Для российских программистов, составляющих справочную систему, большая проблема — английский язык. Одно дело меню и небольшие информационные сообщения в интерфейсе программы, здесь больших сложностей нет (хотя в некоторых российских программах даже в меню и диалоговых окнах встречаются ошибки). Но вот документация... Здесь требуется более глубокое знание языка. Грамматические и орфографические ошибки очень сильно портят впечатление обо всем продукте, и это приводит не только к отрицательным обзорам в журналах и на Web-сайтах, но и существенно снижает объем продаж. Качественный английский язык документации -одно из самых главных требований к серьезному shareware-продукту.

Самый простой вариант, на котором останавливается большинство авторов, — это перевод текста на английский язык знакомым или нанятым за плату переводчиком. Лучше всего будет после этого разместить на Web-сайте программ объявление с предложением для пользователей из Великобритании или США проверить имеющийся у вас перевод документации в обмен на бесплатную регистрацию копии вашей программы. Человек, для которого английский язык является родным, сможет наиболее эффективно довести качество перевода до хорошего уровня.

Некоторые начинающие разработчики, стараясь сильно не занимать себя проблемой написания качественной справочной системы на хорошем английском языке, проступают так: находят аналогичный продукт и почти полностью копируют его документацию, заменяя разве что название программы и ссылки на сайт разработчика. Хотя идея получить с минимальными затратами времени и сил профессиональную англоязычную справочную систему очень заманчива, делать этого ни в коем случае нельзя. Это обычное нарушение авторских прав, иными словами — плагиат. Рано или поздно это все равно раскроется, восстановить потерянную репутацию в глазах пользователей, обозревателей, работников shareware-сервисов будет очень трудно.

Один из российских разработчиков shareware рассказывал такую историю. Некий иностранный программист, продававший конкурирующую программу (утилита для общения в локальной сети), украл у него полностью всю документацию, включив ее в дистрибутив своего продукта. Однако он забыл исправить адреса, на которые указывали ссылки в Справке: текст на них был изменен, но вели они по-прежнему на оригинальный Web-сайт. Пострадавший от плагиата смотрел на это сквозь пальцы, т. к. его программа продавалась очень хорошо, и мелкий конкурент его не особенно волновал. Но однажды он получил письмо от пользователя, который интересовался, почему ссылка из документации программы, которую он недавно приобрел, ведет на совсем другой сайт, где продается вроде бы похожий продукт. "Это что, новая версия?" - спрашивал удивленный пользователь. Наш соотечественник объяснил ему ситуацию и предложил этому человеку, т. к. он уже купил программу плагиатора, скидку (в 20%) при переходе на свой продукт. Пользователь согласился: воров никто не уважает.

Контекстная справка

Пользователи обычно не любят запускать справочную систему из меню Help (Справка), т. к. в этом случае приходится самостоятельно искать нужный раздел Справки. Зато они вполне готовы нажать клавишу <F1> в каком-либо диалоговом окне или воспользоваться кнопкой с вопросом ("What's This?" "Что это такое?"), чтобы получить пояснение именно по текущей ситуации.

Разработка контекстной системы помощи — это вопрос, затрагивающий и тему построения интерфейсов. Есть, например, даже такой принцип: "Предлагайте помощь". Для того чтобы пользователь программы при работе с ней чувствовал себя человеком и видел, что автор хочет сделать его работу наиболее простой и понятной, нужно позаботиться о том, чтобы программа всегда могла бы пояснить пользователю порядок действий в текущий момент.

Конечно, не нужно предлагать помощь также навязчиво, как известная скрепка-помощник из Microsoft Office (Рисунок 7.6). Созданный для придания "ящику" большей интеллектуальности и, так сказать, человечности, Помощник заслужил неоднозначные отзывы. У некоторых пользователей, которые не смогли понять, как отключить Помощника, скачущая по экрану скрепка даже вызывала истерику.

NetHelp — аналог HTML Help от компании Netscape

Рисунок 7.4. NetHelp — аналог HTML Help от компании Netscape

Существует также несколько аналогичных форматов HTML Help, также использующих язык HTML для описания структуры справочной системы: NetHelp от компании Netscape (Рисунок 7.4), WebHelp от Oracle и, наконец, JavaHelp от Sun. Однако эти форматы не получили сколько-нибудь широкого распространения и используются в основном в продуктах соответствующих фирм-разработчиков.

Один из самых крупных интернетархивов

Рисунок 7.1. Один из самых крупных интернет-архивов ПО — Tucows — не принимает программы без документации

Печатная документация

Документация, отпечатанная типографским способом, столь привычная для коммерческих программных продуктов, для shareware — явление очень редкое. Если она все-таки имеется, то обычно продается отдельно и за довольно большие деньги, порой превышающие стоимость самой программы.

Перспектива

Здесь, конечно же, все козыри у HTML Help, который создан как замена WinHelp и усиленно продвигается Microsoft. Нет сомнений, что в будущем имеющие недостатки HTML Help будут устранены, а функциональные возможности — еще больше расширены. Более того, я думаю, что HTML Help изменит существующий подход к созданию документации и, возможно, серьезно поменяет вид и структуру справочных систем. Очень важно и то, что хорошо составленная и грамотно оформленная документация в формате HTML Help производит благоприятное впечатление на обозревателей компьютерных журналов и архивов. Какой же формат выбрать? Каждый, конечно же, решает сам. Лично я пока остановился на WinHelp. Меня привлекает его надежность (независимость от установленного в системе интернет-браузера и стопроцентная его поддержка во всех версиях существующих Windows), высокая скорость работы, хорошие возможности для создания файлов Справки (пока я не чувствую потребности в Dynamic HTML или JavaScript). To, что WinHelp - уже "старичок" по сравнению с модным HTML Help, на мой взгляд, даже плюс: пользователи уже привыкли к нему и работают с такими справочными системами без проблем.

На самом деле не нужно бояться сделать неправильный выбор и предпочесть "не тот" формат документации. Большинство современных программ по разработке справочных систем (см. разд. "Средства создания документации" данной главы) позволяют сохранять файлы как в формате WinHelp, так и HTML Help (а некоторые поддерживают еще большее число форматов). Поэтому в будущем можно без особых трудностей перейти с одного формата на другой. При желании можно даже поставлять в дистрибутиве программы документацию в обоих вариантах: WinHelp и HTML Help, позволяя пользователю самому выбрать предпочтительный формат. Программ с таким оригинальным решением проблемы выбора формата документации я пока не встречал, но, если бы это случилось, то лично на меня, в том числе и как на пользователя, это произвело бы большое впечатление.

Помощник из Microsoft Office

Рисунок 7.6. Помощник из Microsoft Office

Лучше сосредоточить свои усилия в другом направлении. Например, все диалоговые окна программы должны содержать кнопку Help (Справка). Это касается не только диалогов, в которых непосредственно осуществляется и ввод данных (например, окон Настройка), но и информационных диалогов, например, диагностических или сообщений об ошибках.

Так как при появлении на экране диалога у пользователя чаще всего появляется вопрос "Почему?", то вполне стандартным приемом является дополнение текста диалога подсказкой: "For help, press F1" (Для справки, нажмите F1). Использование такого предложения помощи полезно не только в диалогах, но и в обычных окнах, где оно выводится в строку состояния сразу после старта программы. И даже если пользователю в настоящий момент справка не нужна, такое ненавязчивое предложение помощи как бы сигнализирует, что программа, в случае необходимости, может дать пояснения.

Нужно помнить, что контекстная помощь — это не только разделы в файле Справки, которые вызываются из соответствующих частей программы. К контекстной помощи также относятся подсказки, появляющиеся в строке состояния, когда пользователь ведет мышью по пунктам меню. Не нужно забывать и про всплывающие подсказки к кнопкам на панелях инструментов и секциям строки состояния.

С контекстной справкой связан интересный случай, который еще раз напомнил не только составителям документации, но и проектировщикам интерфейсов о том, что с пользователями нужно обращаться максимально вежливо и учтиво. Как рассказал один из посетителей Web-сайта iarchitect.com, однажды справочная система инженерного пакета AutoCAD Mechanical от фирмы Autodesk показала вот такое сообщение.

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

Пример документации в формате Adobe Acrobat

Рисунок 7.5. Пример документации в формате Adobe Acrobat

Adobe Acrobat, пo замыслу разработчиков, и предназначен для решения этой проблемы: документы в этом формате можно просмотреть не только в любой операционной системе (существуют версии этого продукта для Windows, MacOS и Unix), но именно в том виде, как задумывал его автор. При этом пользователю доступны гораздо большие возможности, чем предоставляют WinHelp или HTML Help: можно распечатать весь документ целиком, масштабировать не только текст, но и графику, поворачивать страницы на 90 градусов и др.

Adobe Acrobat (расширение файлов — pdf) очень популярен как формат для хранения документации к различному компьютерному "железу": материнским платам, видеокартам, акустическим системам и т. п. Среди разработчиков программного обеспечения (особенно шароварщиков) он не очень распространен, хотя некоторые крупные компании (например, McAfee, Symantec) используют его для подготовки справочных систем к своим продуктам.

На мой взгляд, минусы Adobe Acrobat, которые препятствуют его использованию в качестве средства организации Справки для shareware-программ, следующие:

отсутствие функций Windows API, с помощью которых можно вызывать отдельные разделы документации в формате Adobe Acrobat, обеспечивая, таким образом, контекстную Справку к различным элементам программы; недостаточная распространенность программы Adobe Acrobat Reader, которая требуется для просмотра PDF-файлов. Несмотря на то, что Reader — бесплатный продукт, он установлен далеко не на каждом компьютере, и было бы неэтично заставлять пользователя скачивать его дистрибутив (около 10 Мбайт) лишь для того, чтобы просмотреть справочную систему небольшой shareware-программы. А вот поставщики комплектующих для компьютеров, прикладывая к своим изделиям диск CD-ROM с документацией в формате Acrobat, без проблем могут включить на этот же диск и инсталлятор Acrobat Reader. Что касается поддержки HTML Help, то браузер Internet Explorer уже давно поставляется вместе с Windows, а о WinHelp и говорить не нужно: файл winhelp.exe прочно обосновался в дистрибутиве системы; довольно высокая стоимость пакета для создания PDF-файлов, которое называется так же, как и сам формат — Adobe Acrobat, а также средств для конвертации PDF независимых разработчиков. А вот для создания справочных систем в форматах WinHelp и HTML Help можно обойтись бесплатными продуктами.

Пример справочной системы в формате HTML Help

Рисунок 7.3. Пример справочной системы в формате HTML Help

HTML Help отражает новую политику Microsoft: во-первых, полная интеграция приложений с Интернетом, во-вторых, использование HTML как основного формата файлов: в процессе подготовки справочной системы разработчик должен сохранять текст в формате HTML, а для просмотра получившегося после компиляции СНМ-файла требуется, чтобы на компьютере пользователя был установлен интернет-браузер Microsoft Internet Explorer 3.02 или выше. Впрочем, некоторые специалисты восприняли появление HTML Help скептически: разработка нового формата, по их мнению, была обусловлена не заботой о пользователях, а желанием Microsoft добиться перелома в так называемой "войне браузеров" и добиться преимущества над основным конкурентом своего Internet Explorer — Netscape Navigator (в то время большая часть рынка интернет-браузеров принадлежала "Навигатору").

В HTML Help устранены недостатки предшественника: можно распечатать не только текущий раздел, но и все его подразделы; вся справочная система находится не в пяти, а всего одном файле с расширением chm. Правда, исчезла полнотекстовая индексация файла, и возможности поиска в Справке несколько снизились.

Примечание
Примечание

Некоторые авторы прикладывают в качестве документации к своим программам просто несколько HTML-файлов, без компиляции их в СНМ-файл формата HTML Help. Это, конечно, не может являться полноценной заменой HTML Help: скорее, это некоторый промежуточный вариант между текстовым файлом readme.txt и "настоящей" Справкой.

Пример справочной системы в формате WinHelp

Рисунок 7.2. Пример справочной системы в формате WinHelp

У WinHelp очень мало недостатков. Один из самых серьезных — невозможность печати всего справочного файла целиком, в результате чего приходится посылать на принтер каждый раздел отдельно. Другой минус — то, что каждый экземпляр справочной системы может состоять из пяти файлов (табл. 7.1): не слишком изящный способ организации документации.

Таблица 7.1. Файлы справочной системы в формате WinHelp


	Тип файла	Назначение
	HLP CNT GID FTS FTG	Основной текст справочной системы Оглавление справочной системы Конфигурационный файл Полнотекстовый индекс Группы для полнотекстового индекса

В целом формат WinHelp достаточно удобен и универсален, и поэтому, несмотря на появление нового формата — HTML Help, активно продвигаемого Microsoft, WinHelp по-прежнему очень популярен среди разработчиков справочных систем.

Скорость работы

Как уже упоминалось, для чтения СНМ-файлов формата HTML Help используется браузер Internet Explorer, который вызывает много нареканий за высокие требования к системным ресурсам и относительно медленную работу. Действительно, при вызове Справки в формате HTML Help, особенно имеющей довольно большой объем, задержки в работе по сравнению с WinHelp хорошо заметны.

Средства создания документации

Сделать справочную систему не так уж сложно. Для создания справочных файлов в формате WiuHelp можно использовать Microsoft Word, а также бесплатный компилятор Help Workshop, который можно скачать с сайта Microsoft или взять из дистрибутивов многих средств разработки приложений (Visual C++, Visual Basic, Delphi) или специализированных продуктов для создания справочных файлов. Для подготовки Справки в формате HTML Help требуется любая программа для редактирования HTML (от простейшего Блокнота до навороченного FrontPage 2000) и, опять же, компилятор.

Однако разрабатывать справочные системы традиционными средствами не очень удобно. В частности, в этом случае не так уж легко отслеживать структуру готовящегося файла Справки и синхронизировать ее с RTF и HTML-файлами. Кроме того, при написании WinHelp-документации в редакторе Microsoft Word нужно запоминать различные спецсимволы и стили выделения текста, которыми описывается структура и форматирование файла Справки. А это, надо сказать, посложнее, чем синтаксис HTML.

Конечно, продуктов независимых разработчиков, которые существенно облегчают задачу создания справочных систем, существует очень много, от самых простых до целых интегрированных сред разработки. Самые простые не представляют большого интереса, т. к. они обладают довольно слабыми возможностями и при этом неудобны для использования; единственное их достоинство — бесплатность или очень низкая цена. Лучше обратить внимание на продукты более высокого класса, которые позволяют очень эффективно решать задачу создания справочных систем.

Продуктов в этой группе также немало. Самые известные из них — AnetHelp-Tool (http://www.anetsoft.com), Help & Manual (http://www.ec-software.com), Windows Help Designer (http://www.winhelp.gr), HelpMagician Pro (http:// www.helpmagician.com), RoboHelp Office (http://www.bluesky.com). Интерфейс всех этих программ организован примерно одинаково. Слева находится окно, в котором в древовидной форме отображается структура файла справки; справа - окно WYSIWYG-редактора в стиле Microsoft Word.

С помощью окна слева можно легко переходить от одного раздела справки к другому, создавать новые разделы, переименовывать и удалять их. Встроенный редактор обычно обеспечивает все необходимые функции по обработке содержания справочной системы: добавление перекрестных ссылок, форматирование текста и абзацев, вставку таблиц и списков, добавление специальных символов и командных кнопок, вставку изображений, звуков, анимации и других объектов. Конечно, обязательны функции поиска/замены текста, проверки орфографии (английской), импорта и экспорта файлов различных форматов (TEXT, RTF, HTML). Также эти программы умеют сохранять проекты как в форматах WinHelp, так и HTML Help, так что проблема выбора формата Справки стоит не так остро. Многие продукты имеют функции анализа проектов различных систем программирования (Visual C++, Delphi, Visual Basic) и автоматической генерации разделов Справки ко всем диалоговым окнам, пунктам меню и элементам управления, а также исходного кода на соответствующем языке программирования для вызова этих разделов.

Конечно, у каждой программы имеются уникальные возможности, которые могут повлиять на выбор в пользу одной из них. Так, AnetHelpTool позволяет редактировать файлы Справки в двух режимах — Runtime и Design: в первом режиме можно просматривать документ практически в том же виде, как он будет выглядеть в WinHelp после компиляции, а во втором — редактировать текст и графику. Кроме того, этот продукт поддерживает множество форматов справки: WinHelp, HTML Help, JavaHelp, Web-сайт, документацию для печати. Windows Help Designer довольно компактен, к тому же хранит проект не в файле специфического формата, а в RTF, так что при необходимости можно подправить файл Справки в Microsoft Word, не прибегая к утомительной процедуре импорта-экспорта. HelpMagician Pro отличается мощным редактором с поддержкой стилей, а также вызывающим ностальгию интерфейсом в стиле Windows 3.1. RoboHelp Office — это не просто программа для создания справочной системы, а мощный интегрированный пакет с просто потрясающими возможностями, состоящий из двух отдельных программ — RoboHelp Classic (поддержка WinHelp) и RoboHelp HTML (поддержка HTML Help, Oracle Help, WebHelp, Java Help), а также пятнадцати утилит. Из них особого внимания заслуживает известная программа What's This? Help Composer, которая сканирует готовый ЕХЕ-файл приложения, написанного на Visual C++, а также проект Visual Basic (к сожалению, Delphi не поддерживается) распознает все содержащиеся в программе диалоги и позволяет указать для них подсказки. После этого текст подсказок записывается обратно в ЕХЕ-файл (!) — вот такое простое до гениальности решение.

Как видите, у разработчика существует большой выбор средств для создания справочных систем. Остается посмотреть их и выбрать, то, которое придется по душе.

Текстовый файл

Чисто теоретически, документация может быть выполнена в виде обычного текстового файла — например, readme.txt. Однако для серьезной shareware-программы один текстовый файл — явно недостаточно. В крайнем случае, readme.txt может быть временной заменой справочной системы на этапе, когда программа существует в виде бета-версии. У готового же к продажам продукта документация должна быть оформлена в одном из форматов, специально предназначенных для справочной системы.

В то же время файл readme.txt тоже должен входить в дистрибутив программы, служа важным дополнением "основной" документации. Readme.txt обычно содержит краткую информацию о продукте: номер версии, дата выпуска, имя разработчика, адрес домашней страницы, важные заметки о текущем выпуске (новые возможности, необходимость установки каких-либо компонентов и т. п.). Особенности, из-за которых формат ASCII не подходит для создания полноценных справочных систем — отсутствие возможностей для удобной навигации по страницам и поиска,. — здесь являются достоинством. Благодаря им, пользователь может быстро получить доступ к важной информации, не путаясь в многочисленных страницах традиционной справочной системы.

Виды документации

Возможности

Конечно, по функциональности справочной системы HTML Help значительно опережает своего предшественника. К услугам разработчика все то, что поддерживает браузер Microsoft Internet Explorer: не только "обычный" HTML, но и Dynamic HTML, таблицы стилей (CSS), JavaScript и т. д. С помощью этих инструментов можно реализовать такие функции, которые WinHelp и не снились.

Однако за все нужно платить, и "красоты" HTML Help — не исключение. Дело в том, что, включив в оформление документации все эти "навороты", автор не может быть уверен, что на компьютере пользователя справочная система отобразится корректно. Вид Справки может быть самый различный: от небольших искажений до полной нечитабельности. Это зависит от многих факторов, например, от версий браузера, установленных у автора и у пользователя. Например, если у пользователя более старая версия, чем у автора, то многие элементы справочной системы могут быть невидимыми. Другой вариант — персональные настройки браузера, например, запрет выполнения JavaScript или установленный специфический шрифт. Более того, не редки случаи, когда на компьютере вообще не установлен Internet Explorer, и просмотр файла HTML Help невозможен. Например, один из российских shareware-программистов рассказывал, что ему пришлось отказаться от формата HTML Help в пользу WinHelp из-за того, что ему стали приходить письма от пользователей примерно такого содержания: "В фирме, в которой я работаю, корпоративная политика состоит в отказе от Internet Explorer, и со всех компьютеров этот браузер удален и установлен Netscape Navigator.

Вследствие этого я не могу просмотреть Справку к Вашей программе. Вышлите, пожалуйста, мне ее текст в каком-нибудь другом формате". В то же время большинство разработчиков не пользуются и 10% всех возможностей Internet Explorer, предпочитая привычные средства подготовки документов: перекрестные ссылки, форматированный текст, таблицы, списки, графические изображения. А со всем этим превосходно справляется и WinHelp. Кроме того, у последнего перед HTML Help есть даже некоторые преимущества именно в области создания справочных систем. Например, во всплывающих (popup) окнах WinHelp допускает форматированный текст, а HTML Help - нет (см. http://msdn.microsoft.com/library/en-us/htmlhelp/html /hwHTMLHelpFrequentlyAskedQuestions.asp?frame=true#6). Интересно, что в этой ситуации специалисты Microsoft советуют продолжать пользоваться WinHelp.

WinHelp

WinHelp (Рисунок 7.2) — настоящий долгожитель среди форматов справочных систем. Программа winhelp.exe, обеспечивавшая работу HLP-файлов, входила в состав еще шестнадцатиразрядных версий Windows. Несмотря на свой почтенный возраст, WinHelp — довольно эффективный формат для организации документации: он позволяет хранить в HLP-файлах форматированный текст (включая таблицы, списки и тому подобные элементы), графику, видео, анимацию, звук, проводить поиск, индексировать справочный файл для более эффективного поиска.

WinHelp или HTML Help?

Как видно из предыдущего раздела, сегодня существует два реальных варианта для реализации справочной системы: WinHelp и HTML Help. Какой же из них предпочесть?

Зачем нужна документация

Многие разработчики считают, что справочная система для их продуктов совершенно не нужна. Это и не удивительно: автор досконально знает свое творение, и оно кажется ему абсолютно простым для понимания и освоения. Если быть откровенным, то у программистов существует прямо-таки природное отвращение к написанию документации: это занятие представляется им на редкость нудным и скучным. Многие из них согласны проводить целые дни и ночи напролет, как говорится, "в глубокой отладке", но ни в коем случае не описывать все эти меню, диалоговые окна и т: п.

Между тем документация — это одно из основных отличий программы "для себя" от серьезного продукта, который можно успешно продавать на shareware-рынке, С помощью Справки пользователи могут быстро найти ответы на возникающие у них вопросы по работе с программой, что произведет на них благоприятное впечатление и поможет сделать выбор в пользу оплаты регистрации продукта. А многие компьютерные журналы и online-архивы программного обеспечения даже не рассматривают программы, не имеющие справочной системы (Рисунок 7.1), не говоря уже о получении положительных отзывов и наград ("звезд", "коров" и т. п.) от обозревателей. И наконец, хорошо составленная справочная система избавляет разработчика от необходимости отвечать на одни и те же вопросы пользователей.

Что касается того, что "моей программе Справка не нужна — там и так все понятно"... Практика показывает, что у большинства пользователей рано или поздно возникают затруднения при освоении программ. К тому же уровень квалификации у всех разный: не каждый может разобраться, например, в специфическом формате файлов или механизме записи макросов.

Borland Delphi позволяет определять

Рисунок 8.1. Borland Delphi позволяет определять сложные номера версий для создаваемых программ

Некоторые из читателей, возможно, подумают: "Как это все запутанно". И будут совершенно правы! Для многих пользователей даже такие простые номера версий, как 3.1 или 6.0, сложны для запоминания, не говоря уже о номерах типа 5.00.2614.3500 (Рисунок 8.2). Действительно, можете ли вы вспомнить полный номер версии браузера Internet Explorer, установленного у вас?

В 1994 году, готовя к выпуску новую, 32-разрядную версию Windows, в корпорации Microsoft решили отказаться от традиционной нумерации версий, назвав свою новую разработку не Windows 4.0, a Windows 95. Нет, "обычный" номер все равно остался (чтобы убедиться в этом, достаточно в командной строке дать команду ver), однако он стал предназначаться для сведения опытных пользователей и специалистов. "В массы" продукт продвигался как Windows 95 — именно из-за того, что, по мнению Microsoft, традиционные номера версий не понятны большинству пользователей и запутывают их. Этот шаг оказался удачным, и корпорация Microsoft при наименовании своих продуктов продолжает пользоваться правилом, которое, перефразируя старый флотский принцип, звучит так: "Каждая версия Windows или любого другого продукта должна иметь имя собственное" - пускай даже это имя собственное выбрано в честь года выпуска программы. Windows 95 OSR, Windows 98, Windows Millennium, Windows 2000, Windows XP — в официальных названиях операционных систем линейки Microsoft Windows не встретишь традиционных "4.1" или "5.0".

Демонстрация текста лицензионного соглашения

Как уже говорилось выше, согласие с условиями лицензионного соглашения — это условие, при котором инсталляция программы может быть продолжена. В этом — суть лицензионного соглашения как "оберточной" лицензии. Значит в инсталлятор нужно не забыть включить окно с текстом License Agreement, чтобы пользователь мог продолжить установку, только нажав кнопку Согласен или установив соответствующий флажок (переключатель).

Номера версий

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

Среди разработчиков программных продуктов (не только shareware) уже очень долго существует соглашение о порядке нумерации версий программ. Вы наверняка слышали о нем:

номер версии состоит из двух частей, разделенных точкой; цифры до точки обозначают номер основной версии (так называемой "мажорной версии" (major version); 1—2 цифры после точки обозначают номер вспомогательной версии (так называемой "минорной версии" (minor version)).

Изменение номера основной версии происходит при внесении в программу серьезных изменений, например, при смене интерфейса, включении новых функций, значительно повышающих возможности продукта. Если в программу были внесены небольшие изменения, то меняется первая цифра после точки; если сделанные изменения совсем уж незначительны, то меняется вторая цифра после точки.

Многие разработчики используют более сложные номера версий, учитывающие и так называемые релизы (release) и билды (build). Первый термин обозначает номер "промежуточной" версии, содержащей исправления ошибок; второй — номер перекомпиляции проекта (Рисунок 8.1).

Окно программыинсталлятора

Рисунок 8.3. Окно программы-инсталлятора

Некоторые авторы программ, начав распространение своих продуктов на российском рынке и как freeware, привыкли к тому, что инсталлятор к ним делать не нужно. Некоторые из разработчиков даже с гордостью делают приписку к описанию своей программы: "Не требует инсталляции". Это, с одной стороны, оправданно: пользователь может быть уверен, что процесс копирования программы на диск его компьютера будет под его контролем, системные настройки не будут отредактированы без его ведома или в папку WINDOWS/SYSTEM не будет записано никаких "левых" файлов. Правда, все это может быть сделано уже самой программой при первом запуске ее ЕХЕ-файла. С другой стороны, недоверие к инсталляторам со стороны пользователей в основном обусловлено низкой надежностью старых версий Windows (например, 3.x) и плохим качеством программ сторонних разработчиков, появившихся на рынке в то время, — например, механизм удаления уже установленной под Windows программы работал малоэффективно. Сейчас, по прошествии очень большого для индустрии информационных технологий периода времени, ситуация сильно изменилась, и большинство пользователей рассматривают инсталлятор как помощника в работе, а не обузу, придуманную авторами программ для засорения жестких дисков пользователей.

С увеличением объема продаж через Интернет, бумом shareware, сокращением доли "коробочных" продуктов на рынке и переход некоторой их части в разряд shareware, инсталлятор стал играть роль не только программы установки, но и "упаковки" программного продукта, что имеет большое значение в деле защиты авторских прав.

Дело в том, что в то время, когда большинство платных продуктов были "коробочными", т. е. продавались в фирменной упаковке, лицензионное соглашение, в котором правообладатель разрешал использование программы, печаталось прямо на этой упаковке. Текст лицензионного соглашения обязательно начинался со слов: "Вскрывая упаковку данного программного продукта, Вы подтверждаете свое согласие с условиями настоящего лицензионного соглашения". Лицензионные соглашения даже стали называть "оберточными лицензиями", т. е. лицензиями, опубликованными на упаковке.

После того как все больше программ стало распространяться по компьютерным сетям, в том числе и по Интернету, термин "оберточная лицензия" стал терять смысл — ведь "обертки" как таковой 'уже не было! И тогда роль упаковки стал играть инсталлятор: перед началом процесса установки продукта он демонстрирует пользователю текст соглашения и требует поставить флажок или переключатель Согласен для продолжения установки (Рисунок 8.4). А слова "Вскрывая упаковку данного программного продукта..." заменились на "Устанавливая данный программный продукт..." Таким образом, лицензионное соглашение, оформленное в электронном виде, продолжают называть "оберточной лицензией".

Конечно, нельзя не упомянуть о том, что иногда без инсталлятора просто не обойтись — например, когда для нормальной работы устанавливаемой программы требуется скопировать в папку WINDOWS/SYSTEM и зарегистрировать в системе ActiveX- и DLL-библиотеки, типы файлов и т. п.

Папка для установки по умолчанию

Мне до сих пор попадаются программы, инсталляторы которых предлагают создать папку программы для копирования файлов не в папке C:\Program Files, а в корневом каталоге диска С:. Конечно, в большинстве случаев можно выбрать для установки любую другую папку, в том числе и Program Files, но, во-первых, это раздражает, т. к. приходится совершать лишние операции, а во-вторых, приходится все равно устанавливать такую программу в каталоге С:\, т. к. никогда нельзя быть уверенным в том, что программа будет нормально работать в папке Program Files — например, из-за проблем с длинными именами файлов. Кто-то может удивиться тому, что в наше время, когда на рынке господствуют 32-разрядные операционные системы, какие-то программы "не понимают" длинные имена файлов, но на самом деле такие программы встречаются, и я бы не сказал, что очень редко.

Периодичность выпуска

Первая версия вашей программы должна появиться как можно быстрее. Это требование обусловлено природой shareware-рынка, динамично развивающегося, заполненного множеством ожесточенно конкурирующих между собой продуктов. Если слишком долго тянуть с выпуском первой версии, программы, то, когда она все-таки выйдет в свет, вполне может оказаться, Что конкуренты ушли далеко вперед, и такая программа уже никому не нужна. В конце концов, это же не рынок freeware, где пользователи согласны работать с продуктом только потому, что он бесплатен.

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

Да, очень важно, чтобы первая версия появилась быстро, но при этом не была функционально слишком слабой. Иначе пользователи, попробовав новую программу в деле, будут сильно разочарованы и потеряют интерес к последующим версиям продукта, которые, возможно, будут не такими уж плохими. Избежать этого поможет, в частности, постепенное изменение позиционирования продукта на рынке параллельно с развитием функциональных возможностей, а не первоначальный "замах" на более высокий уровень.

Например, компактный Web-редактор, в котором есть черты некоторых более продвинутых продуктов, встретит гораздо больше симпатий, чем "аналог FrontPage", где пользователь сразу же обнаружит отсутствие некоторых нужных функций и досадные ошибки, которые не позволят новой программе выглядеть достойно по сравнению с конкурентами.

Конечно, выпуском одной версии история развития вашей программы не ограничится (по крайней мере, я на это надеюсь). Программа будет совершенствоваться, будут выходить новые версии. Немаловажный вопрос — как часто должны появляться новые версии продукта?

Частые обновления программы имеют несколько плюсов:

почти о всех online-архивах списки программ сортируются по дате поступлений (т. е. новые программы всегда расположены в начале списка), кроме того, новые программы попадают на страницу "Что нового?" (имеющую относительно остальных страниц очень высокую посещаемость), а в некоторых архивах — даже страницу; выход новой версии всегда привлекает внимание к продукту. Например, многие интернет-обозрения, посвященные компьютерам и программам для них, охотно публикуют анонсы новых shareware-программ. Появляется повод, например, разослать в редакции online- и offline-изданий пресс-релизы с сообщением о выпуске новой версии продукта; частые появления новых версий программы свидетельствуют о том, что продукт активно развивается. Например, в news-конференциях пользователей программного обеспечения я не раз читал, как среди достоинств той или иной программы упоминается "frequently updated"; с появлением новой версии устаревают все крякерские патчи к данной программе (если таковые, конечно, имеются). Кроме того, если в программе изменен алгоритм генерации регистрационных ключей, то все опубликованные в Интернете ключи также перестают работать в новой версии.

В то же время иногда частые обновления программы могут не иметь положительного эффекта или даже приносить вред. Так, слишком частый выход новых версий (раз в одну-две недели или чаще) отрицательно сказывается на имидже программы: пользователи начинают полагать, что эта программа - "buggy", т. е. имеет множество ошибок, для исправления которых и выпускаются, собственно, все эти обновления. Еще один пример — публикация новых версий в интернет-архивах, чтобы обеспечить более выгодную позицию в их списках программ. Крупные каталоги программного обеспечения, способные привлечь к продукту внимание большой аудитории, обновляют свои базы данных очень неспешно: может пройти несколько недель и даже месяцев, прежде чем информация о новой версии появится на страницах архива. С другой стороны, многие мелкие архивы, работающие более оперативно, приводят гораздо меньше пользователей, чем рассчитывал автор программы, готовя новую версию. Наконец, нужно учитывать и то, что при слишком частых обновлениях программы пользователи вовсе не будут скачивать и устанавливать каждую появляющуюся новую версию. Если в имеющемся у них варианте программы нет явных ошибок, откровенно мешающих нормальной работе, то, скорее всего, многие пользователи будут проводить обновления после выхода нескольких новых версий. Так что получается, что иногда все те затраты времени, сил и средств, сделанные автором для быстрого выпуска новой версии программы, не приведут к ожидаемому результату.

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

По мере того как программа совершенствуется, набирает популярность, новые версии могут выходить все реже и реже. В частых обновлениях уже нет необходимости: число пользователей уже достаточно велико, а новые узнают о программе не со страниц "Что нового?" интернет-каталогов, а из других источников (например, по рекомендациям друзей и знакомых); большинство возможностей, характерных для таких программ, уже реализовано; основная часть ошибок исправлена. В этом случае появление обновлений или их длительное отсутствие не очень сильно влияют на динамику продаж. Но, естественно, выпуск новых версий программы хотя бы раз в полгода демонстрирует пользователям, что данный проект по-прежнему работает и развивается.

Подготовка дистрибутива

Итак, инсталлятор программного продукта готов: файл setup.exe лежит в папке вашего shareware-проекта. В принципе, этот файл уже является дистрибутивом программы, и его можно смело распространять через Интернет. Многие авторы так и делают: переименовывают файл setup.exe так, чтобы его название было созвучно названию программы, и размещают его на Web-сервере.

Это распространенный, но не совсем правильный подход к выбору варианта оформления дистрибутива. Лучше всего — упаковать ЕХЕ-файл инсталлятора ZIP-архиватором. Помимо файла setup.exe, в архив нужно включить еще и файл readme.txt, содержащий наиболее важную информацию о программе и ее текущей версии, а также файл file_id.diz, в который записывается название программы, ее версия и короткое (10—20 слов) описание.

Пример файла file_id diz

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

Пример программыдеинсталлятора

Рисунок 8.5. Пример программы-деинсталлятора

Деинсталляция — это не просто удаление файлов с компьютера, которое, в общем-то, может произвести любой пользователь вручную. Деинсталляция подразумевает удаление всех следов пребывания программы в системе (записей в реестре и других системных файлах, DLL-библиотек в папке WINDOWS/SYSTEM и т. п). Если же вся эта информация остается в системе, то она по мере установки на компьютер все новых и новых приложений накапливается, что отрицательно сказывается на стабильности работы операционной системы.

Да и удаление файлов деинсталлятором не такой уж и простой процесс. Дело в том, что по умолчанию деинсталлятор настраивается так, чтобы удалить только те файлы, которые были установлены ранее. Если при удалении файлов программы деинсталлятор обнаруживает в ее папке файлы, которые не были туда установлены инсталлятором, то он пропускает их, а иногда (это зависит от того, какой программой был создан деинсталлятор) вообще прекращает свою работу, чтобы не удалить важные файлы, например документы, созданные пользователем. Но на практике не все "новые" файлы могут действительно являться документами пользователя: вполне возможно, что это файлы, созданные операционной системой в связи с работой данной программы на этом компьютере.

Например, если справочная система продукта выполнена в формате WinHelp, то обычно программа установки копирует на диск компьютера файлы с расширением hlp и cnt (основной файл и файл с оглавлением Справки). Но стоит пользователю хоть один раз посмотреть справочную систему, как на диске будет создан файл с расширением gid, а если пользователь проведет расширенный поиск — создаются файлы FTS и FTG (см. табл. 7.1). Поэтому файлы с этим расширением также нужно включить в настройки программы-деинсталлятора.

То же самое относится и к ключам в системном реестре с настройками программы. Часто эти ключи создаются не инсталлятором, а самой программой, в процессе работы пользователя с ней. В результате эти записи не удаляются деинсталлятором и остаются в реестре, увеличивая его объем и ухудшая скорость работы Windows. Вследствие этого нужно настроить деин-сталлятор на удаление всех ключей, которые могут быть созданы программой в процессе ее использования.

Как известно, деинсталлятор приложения для Windows может быть запущен двумя способами: посредством выбора соответствующего пункта в группе с ярлыками программы в меню Пуск и при помощи апплета "Установка и удаление программ" Панели управления Windows. Некоторые программы генерации инсталляторов, например уже упоминавшийся InstallWise, предоставляют пользователю возможность при удалении программы воспользоваться любым из этих способов на свой выбор: соответствующие пункты присутствуют как в меню Пуск, так и в апплете "Установка и удаление программ" Панели управления. Однако некоторые shareware-продукты можно удалить только одним способом. Нельзя сказать, что это удачный ход с точки зрения удобства работы с программой. Можно испытать сильное раздражение, например, последовательно вызвав Панель управления, апплет "Установка и удаление программ", прокрутить длинный список и не найти ту программу, которая вам требуется, прокрутить этот список более медленно, тщательно вчитываясь в названия продуктов, чтобы не пропустить интересующую программу, задуматься, как же все-таки удалить эту злосчастную программу и т. д.

Наконец, когда инсталлятор и деинсталлятор созданы, нужно обязательно протестировать их работу: насколько хорошо продукт устанавливается на компьютер и удаляется с него. Кто-то из читателей сочтет это замечание не нужным — ведь необходимость тестирования любой программы кажется само собой разумеющейся вещью, однако мне время от времени встречаются программные продукты, после инсталляции которых не работают даже ярлыки в меню Пуск, не говоря уже о более серьезных ошибках при проектировании программ установки. При этом нужно постараться найти возможность протестировать работу инсталлятора и деинсталлятора на компьютерах с различными версиями Windows, в том числе и с разными локализациями.

Содержимое "правильного" дистрибутива

Рисунок 8.6. Содержимое "правильного" дистрибутива

Главный недостаток распространения "голого" файла setup.exe, без его "оборачивания" архиватором, состоит в том, что пользователь может узнать, какую именно программу содержит дистрибутив, только установив ее. Хотя авторы обычно дают файлу дистрибутива имя, производное от названия программы, оно нередко совершенно ничего не говорит пользователю, т. к. выглядит как аббревиатура и номер версии — например, cp32e45.exe: попробуйте догадайтесь, что за этим малопонятным набором букв скрывается 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 принято записывать небольшими по длине строками, чтобы описание помещалось в информационные окна соответствующих программ.

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

Созданную новую версию программы, в принципе, уже можно распространять среди пользователей. Запаковать ЕХЕ-файл ZIP-архиватором, добавить в этот архив readme-файл и файл справки, и разместить получившийся ZIP-файл в Интернете. Однако для серьезной shareware-программы этого мало. Нужно создать к своему продукту специальную программу установки, или, как ее еще называют, инсталлятор ("install" - устанавливать) (Рисунок 8.3).

Почему shareware-программе необходим инсталлятор? На это есть несколько причин.

Большинство крупных архивов программного обеспечения и обозревателей компьютерных журналов даже не рассматривают программы, не имеющие инсталлятора. Если же они все-таки обратят внимание на такую программу, то о присуждении ей "высоких оценок или наград, как правило, не может быть и речи. Программа установки, конечно же, помогает пользователю начать работу с shareware-продуктом, избавляет его от необходимости вручную копировать файлы и создавать ярлыки в меню Пуск. Инсталлятор — своеобразная "упаковка" программы, имеет большое значение для оповещения пользователя об условиях лицензионного соглашения. Инсталлятор служит еще одним свидетельством того, что данный продукт — серьезная разработка, а не поделка любителя.

Создание ярлыков в Главном меню

Я уже говорил в разд. "Не трогайте системные файлы и настройки" гл. 4 о том, что группа с ярлыками для установленной программы должна находиться исключительно в папке Программы Главного меню, а не в его первом уровне или где-то еще. Если же вы считаете, что ярлык к вашей программе пригодится пользователю и на Рабочем столе или, например, в первом уровне Главного меню, то инсталлятор программы должен создавать такие ярлыки только с разрешения пользователя.

Если ярлык программы помещается не в собственную группу в меню Программы, а в одну из стандартных групп — например, Автозагрузка или Стандартные, то нужно учитывать, что в локализованных версиях Windows их названия различаются, и не повторять ошибок разработчиков пакета утилит Microsoft PowerToys, в процессе установки которых даже под русской версией Windows ярлыки создаются в группах "Accessories" и "Startup", которые, конечно, в данной локализации Windows игнорируются.

Помимо установки, программа должна иметь возможность деинсталляции, т. е. удаления себя из системы. Программа, производящая эту операцию - деинсталлятор (Рисунок 8.5), — как правило, генерируете» той же программой, которая использовалась для создания инсталляторов. Хотя большинство программ для генерации инсталляторов предоставляют разработчику самому решить, нужен ли его программе деинсталлятор, на самом деле он фактически является обязательным для любого серьезного программного продукта.

Текст "оберточной лицензии" в окне инсталлятора

Рисунок 8.4. Текст "оберточной лицензии" в окне инсталлятора

Самостоятельная подготовка инсталлятора — довольно простое дело. Существует огромное количество продуктов независимых разработчиков (как бесплатных, так и shareware и коммерческих), позволяющих создавать программы установки. Какую из них предпочесть? Давайте посмотрим, на какие параметры нужно обратить внимание при выборе программы создания инсталляторов.

Сначала, экономичность. Казалось бы, для любой программы главное — это функциональные возможности, но здесь они отходят на второй план. Первое, на что стоит обратить внимание при рассмотрении программы создания инсталляторов — объем файлов, которые она генерирует. Ведь функции и диалоговые окна инсталлятора также требуют определенного пространства на диске, в результате файл инсталлятора вместе с содержащимся в нем сжатыми файлами программного продукта окажется несколько больше, чем, например, объем ZIP-архива с теми же файлами внутри.

Эта разница между "обычным" архивом и инсталлятором существует и при использовании различных программ может оказаться очень значительной. Например, известнейший пакет InstallShield (облегченные версии которого, кстати, входят в комплекты поставки многих систем разработки приложений), "добавляет" к дистрибутиву программы более мегабайта! Конечно, использовать InstallShield можно разве что в том случае, если готовую программу планируется распространять не через Интернет, где у более компактных программ есть больше шансов привлечь к себе внимание пользователей. Тем не менее, некоторые shareware-разработчики все равно применяют InstallShield. Например, я иногда спрашиваю авторов, присылающих мне заявки на публикацию своих программ в каталоге SoftList: "Почему Ваша программа, являясь вроде бы небольшой утилитой, имеет архив размером почти 2 Мбайта?" "Да не беспокойтесь, — слышу я в ответ, — сама программа занимает всего 500 Кбайт, а все остальное — инсталлятор!" Нет, программа установки, "съедающая" втрое больший объем, чем непосредственно "основной" продукт — слишком большая роскошь для shareware. Итак, как я уже упоминал, InstallShield, на мой взгляд, разумно использовать для "обертки" к программам, которые не планируется распространять по компьютерным сетям — например, написанных под конкретный заказ или рассчитанных на публикацию на CD-ROM и ему подобных носителях.

Другие программы по созданию инсталляторов гораздо более умеренны в своих аппетитах. Собственно, громоздкость InstallShield явилась своеобразным катализатором появления аналогичных, но более компактных продуктов: shareware-разработчики, которым для распространения своих продуктов через Интернет требовался более экономичный инсталлятор, писали собственные генераторы программ установки, а затем некоторые из них, в свою очередь, были оформлены как самостоятельные shareware-продукты.

Одним из самых популярных среди разработчиков shareware-программ является пакет Installer Wise (http://www.mindvision.com). Помимо широких возможностей, о которых вы прочтете ниже, он создает достаточно компактные программы установки: разница между ZIP-архивом с файлами программы и инсталлятором будет всего около 180 Кбайт. CreateInstall 2000 российской фирмы Gentee (http://www.gentee.com) еще более экономичен — после его работы дистрибутив программы увеличивается всего лишь на 40 Кбайт. Есть, конечно, еще немало программ для генерации инсталляторов, но большинство из них создают относительно компактные установочные программы- в пределах 200 Кбайт. Более "прожорливые" аналоги практически не имеют шансов выжить на рынке shareware (тот же InstallShield, например, в основном применяется при оформлении больших коммерческих продуктов), а их появление в дистрибутивах shareware-программ обусловлено в основном неопытностью автора соответствующей программы.

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

Для многих программ -вполне подходит несложный процесс установки, состоящий из небольшого числа стадий: показ лицензионного соглашения, предложение выбрать папку для установки, выбор группы в секции Программы меню Пуск и непосредственно сам процесс копирования файлов и создания ярлыков в Главном меню. В этом случае подойдет практически любая программа для генерации инсталляторов, в том числе и из категории бесплатных продуктов. Правда, среди последних действительно хорошую программу придется поискать: многие программы из этой группы имеют раздражающие недостатки вроде неудобного интерфейса или отсутствия возможности переопределить внешний вид инсталлятора.

Если же в процессе установки требуется еще и регистрировать DLL-библиотеки и ActiveX, предоставлять пользователю выбор языка интерфейса или устанавливаемых компонентов программы, выводить определяемые автором программы диалоговые окна и обрабатывать результат действий пользователя, изменять ассоциации файлов, делать записи в реестре, перегружать компьютер по окончании установки и т. п., требуется более продвинутый генератор инсталляций. Это уже упомянутые мной Installer Wise, Create Install и др.

И наконец, немаловажным вопросом при выборе программы создания инсталляторов является удобство работы с ней. Часть программ этого типа (к счастью, небольшая), например уже упоминавшийся выше InstallShield, a также InnoSetup (http://www.domain.com), для описания инсталлятора (вид диалоговых окон, обработка событий и т. д.) используют специальные скриптовые языки (Рисунок 8.6), вследствие чего освоение такого продукта замедляется. Для преодоления этой проблемы другими авторами написаны специальные визуальные конструкторы, генерирующие текст скриптов по параметрам, указанным пользователем в диалоговом режиме — например, ISTool (http://www.bhenden.org/istool), создающий скрипты для InnoSetup.

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

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

Работать с такими программами, конечно, гораздо проще, чем с теми, которые используют скрипты.

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

В сложных номерах версий не так уж легко ориентироваться

Рисунок 8.2. В сложных номерах версий не так уж легко ориентироваться

Примеру Microsoft последовали другие корпорации, производящие программное обеспечение, а за ними — и некоторые shareware-разработчики программ. Особенно много было программ с индексом "98", т. к. именно в 1998 году в западных странах случился "бум" Интернета, вызвавший, в том числе, и стремительное развитие shareware-рынка. Но одновременно авторы, применившие новомодный прием, оказались в двусмысленном положении. Крупные компании, выпускавшие большие программные пакеты, обновляли свои продукты раз в один-два года, и вполне могли использовать номер соответствующего года в качестве номера версии. А для shareware-программ такой принцип нумерации версий оказался неудобен, т. к. большинство продуктов на этом рынке обновляется несколько раз в год. Для того чтобы пользователи могли отличать одну версию от другой, разработчику все равно приходилось применять традиционную систему номеров версий: 1.0, 1.01, 1.1 (например, Zet Picture Viewer 98 1.0). Но при наступлении нового года цифры "98" в названии устаревали, и приходилось менять их па "99" или "2000". После этого у пользователей возникал закономерный вопрос: "Что это — только новая версия или полностью новый продукт?" Таким образом, одновременное использование двух систем нумерации версий одного shareware-продукта еще более запутывает потребителей.

Не менее интересен и вопрос политики изменения номеров версий по мере развития shareware-продукта.

Еще со времен появления первых программ для персональных компьютеров существует пользовательский стереотип, который очень распространен и сегодня: только с версии 2.0 программа становится достойна внимания. Такое мнение выработалось в результате разочарований, которые испытывали пользователи, попробовав многочисленные программы, стремительно заполнившие рынок программного обеспечения, в том числе и shareware.

Вследствие этого я всегда рекомендую разработчикам программ как можно скорее преодолеть "барьер номера 2.0" и выпустить версию 2.0 своего продукта. Очень многие авторы программ, по моим наблюдениям, как-то даже боятся увеличивать номера версий своих программ. Типичная ситуация -они начинают отсчет номера версии не от 1.0, а от 0.00, в то время как номер версии меньше единицы традиционно воспринимается пользователями как указание на очень предварительную и "сырую" версию программы. Например, download-менеджер FlashGet (http://www.amazesoft.com) достаточно долго имел номер версии, меньший, чем 1.0 (0.8, 0.9 и т.д.), но при этом был качественным продуктом с обширными возможностями, развитым интерфейсом и объемной документацией.

Еще один пример — разработчик, постоянно создавая новые версии с достаточно большим количеством изменений и дополнений, меняет только вторую цифру после точки, выпуская версии 1.01, 1.02, 1.03 и т. д. В результате программа, пережив выпуск уже нескольких десятков версий, имеет номер типа 1.21. А теперь представьте ситуацию: пользователь (или, например, редактор журнала, собирающий информацию для обзора shareware-продуктов), заходит на сайт online-архива программ и видит в списке два конкурирующих продукта: один, имеющий номер версии 1.21, и второй, обозначенный как 2.5. При сходстве остальных параметров этих программ (тип лицензии, размер, описание возможностей) предпочтение в большинстве случаев будет отдано второму варианту.

"Боязнь" разработчиков программ к существенному изменению номера версии обусловлена в основном тем, что они опасаются негативной реакции пользователей. На мой взгляд, это оправдано только в одном случае: автор предоставляет зарегистрированным пользователям бесплатно не все последующие версии, а только лишь minor updates, т. е. те обновления, номера версий которых изменяются в пределах цифр после точки. Например, если пользователь приобрел версию 1.2, то версии 1.3, 1.45, 1.6 и т. п. он получит бесплатно, а за версию 2.0 должен будет заплатить еще какую-то дополнительную сумму. По этой схеме распространяется, в частности, текстовый редактор UltraEdit (http://www.utlraedit.com). В этом случае при выходе версий 2.0, 3.0 и т. п. автор программы должен следить, чтобы эти версии по своим возможностям действительно сильно отличались от предыдущих, иначе пользователи будут очень недовольны тем, что их вынуждают платить за незначительные исправления.

Если же зарегистрированные пользователи получают все последующие обновления бесплатно, то не нужно опасаться смены номера версии. Конечно, выпускать версию 2.0, внеся в версию 1.0 лишь небольшие изменения, не стоит. Однако и тянуть с выходом версии 2.0 (или еще хуже, 1.0), выпуская один minor update за другим, тоже не нужно. Лично я практически отказался от использования в номере версии второй цифры после точки, чтобы сделать нумерацию версий простой для запоминания пользователями, а заодно увеличить скорость перехода на более солидные номера версий.

Среди известных программных продуктов много примеров довольно смелого обращения с номерами версий. Например, Dbase II появилась "с нуля": Dbase I не существовало (все из-за предубеждений пользователей относительно версий l.xx, которым якобы нельзя доверять); Microsoft Word с версии 2.0 перескочил сразу на 6.0, чтобы "унифицировать", свой номер с остальными программами пакета Microsoft Office; Netscape Navigator четвертой версии стал "шестым", чтобы хотя бы по этому параметру опередить почти вытеснившего его с рынка конкурента — Microsoft Internet Explorer. Как видите, крупные разработчики программного обеспечения в данном случае в первую очередь учитывали собственные маркетинговые интересы и не особенно комплексовали относительно предположительной реакции пользователей, что очень поучительно и для авторов shareware-программ.