7.3. Инсталляция приложения

      7.3.1. Гибель принтера. Последняя, третья история произошла с автором совсем недавно, в 1998 г. Решив в какой-то момент, что пришла пора взяться за ум и поаккуратнее оформлять свои публикации, я на своем персональном компьютере инсталлировал под Windows 95 одну из наиболее популярных издательских систем. Инсталляция не вызвала затруднений, система сразу успешно заработала, но через некоторое время выяснилось, что подключенный к компьютеру струйный принтер перестал воспринимать часть кириллических шрифтов.
      К счастью, не было никаких сомнений в том, что принтер погубила именно инсталляция. Поэтому первой попыткой исправления положения стала деинсталляция издательской системы. Я не очень-то рассчитывал на успех, и, увы, предчувствия оправдались — принтер не заработал.
      Затем, разумеется, я деинсталлировал и заново установил драйвер принтера. Не помогло и это. Далее последовали беспорядочно-бесплодные поиски каких-либо следов, оставленных сгубившими принтер событиями в реестре Windows 95 и в других системных файлах...
      После нескольких часов напряженного труда в голову пришла утешительная мысль о том, что я все равно собирался менять этот принтер на более совершенную модель. Кроме того, выяснилось, что если запускать печать по сети с соседнего компьютера, то принтер благополучно работает. Наконец, в запасе оставалось еще одно, последнее средство: «If you want to feel OK, install your Windows every day!».

      7.3.2. Проблема деинсталляции. За долгие годы знакомства c MS DOS, Windows 3.X и Windows 95 подобные истории происходили со мной неоднократно. Десятки историй доводилось слышать от друзей и коллег, которых также не миновала чаша сия. Каждый, кому выпало хоть раз искоренять глубоко засевшее в бесчисленных системных файлах приложение, не может без содрогания вспоминать о своих мучительных усилиях. Обиднее всего, что борьба эта, как правило, обречена на бесславное поражение: обычно так и не удается полностью выявить и изничтожить все крючья, которыми сложное приложение сцепилось с операционной системой.
      Проблема эта давно замечена. В результате многие приложения, инсталлируемые в Windows, предстают теперь перед взором удивленного пользователя в виде двух иконок: одна для постоянного использования, обслуживающая повседневное обращение к приложению, и другая — одноразовая, для его деинсталляции. Если же специальной процедуры деинсталляции в некотором приложении не предусмотрено, на помощь могут прийти универсальные деинсталляторы, невероятно сложные программы, за создание которых, похоже, вскоре начнут присуждать премии Тьюринга. Недавно сообщалось о масштабном судебном процессе между двумя крупными фирмами (Symantec и CyberMedia) из-за авторских прав на очередной деинсталлятор.

      7.3.3. Работает однородный набор. Если вспомнить о возможностях однородного набора, легко виден тривиальный выход из положения. Разработчикам операционной системы достаточно было чуть усложнить схему работы с файлами, введя файл специального типа — паспорт приложения. В этом файле приложение объявляет всю интересную для операционной системы информацию. Каждый компонент паспорта предваряется явным, понятным всем и каждому указанием о том, в которой из таблиц операционной системы ему надлежит оказаться. При своей перезагрузке, а также при появлении на постоянном диске новых файлов-паспортов операционная система анализирует их содержимое, выдает, где сочтет нужным, диагностические сообщения об обнаруженных ошибках и растаскивает полученные сведения о заявивших о себе таким образом приложениях по своим таблицам.
      Проблема решена. Приложение превратилось в модуль расширения (см. разд. 6.4). Для его удаления теперь достаточно всего лишь удалить файл-паспорт. Не так важно, что при этом будет делать операционная система: соберет ли все свои таблицы заново, или же прицельно исключит соответствующие их элементы, для чего ей нужно будет хранить изначальные сведения о происхождении каждого элемента каждой таблицы. Главное, что в любом случае приложение удаляется предельно просто и исчезает совершенно бесследно.
      Новую схему инсталляции имеет смысл оснастить некоторым сервисом для подготовленного пользователя. Хорошо бы позволить заглядывать в системные таблицы, построенные из материала файлов-паспортов, где о каждом элементе можно узнать, какие именно приложения потребовали его включения. Располагая подобным сервисом, пользователь оказывается в среде во всех отношениях значительно более благожелательной, чем существующая операционная среда MS DOS – Windows.

      7.3.4. Что помешало разработчикам Windows. Трудно вообразить, что разработчики Windows не видели приведенного выше решения. Что же помешало им применить его? Причин можно назвать несколько, но лишь одна из них представляется достаточно весомой, хотя и далеко не очевидной.
      По-видимому, разработчиками двигало желание приблизить создаваемые средства описания приложений к общеизвестным языкам программирования. Это стремление, во многом оправданное, имело и негативную сторону: средства описания унаследовали от языков их серьезный изъян — отсутствие поддержки однородных расширяемых наборов. Из-за относительной сложности языков класса Си или Паскаль печальные последствия небрежения однородными наборами не так заметны; в нашем же случае, на фоне простенького синтаксиса системных файлов эти последствия проявились довольно-таки рельефно. Собирающаяся в системных файлах информация имеет выраженную двумерную структуру: вертикальные слои-приложения и горизонтальные слои-списки однородных системных ресурсов. Каждому из двух измерений необходимо придать конструктивное оформление, однако сделать это, не выходя за рамки распространенных языковых средств, не удается.

      7.3.5. Системный текстовый файл. Не так важно, какой вид принимают системные файлы. Это может быть традиционный текст, доступный для просмотра любым редактором, применявшийся в MS DOS и в ранних версиях Windows. Или же какой-либо аналог таблицы базы данных, подобный реестру Windows 95. Главное, чтобы их формирование опиралось на первичные текстовые объекты — паспорта приложений, где размещались бы общепринятые и, в силу этого, понятные всем ассоциативные программные конструкции, которых на сегодняшний день в нашем распоряжении, увы, еще нет.
      Проанализируем, например, чуть подробнее, как могли бы выглядеть системные текстовые файлы и где коренится источник неприятностей, возникающих при деинсталляции.
      Отметим прежде всего, что для пользователя текстовое представление имеет определенное преимущество: ему удобно просматривать эти файлы посредством своего любимого универсального текстового редактора. Однако беда в том, что универсальные редакторы создаются с оглядкой на запросы существующих языков программирования, и вслед за языками в редакторах традиционно отсутствуют ассоциативные конструкции, обслуживающие расширяемые однородные наборы. Но это означает, что фирма Microsoft, положившись в ранних версиях операционной системы на системные текстовые файлы, фактически подписала приговор надежной организации добавления или исключения однородных элементов-приложений.
      Из-за отсутствия ассоциативных конструкций инсталляция нового приложения как правило требует редактирования текстов системных файлов. Здесь легко заметить сразу два источника неприятностей. Во-первых, любое редактирование находящегося в работе текста, и в особенности чужого текста, — процедура чрезвычайно деликатная. Далеко не каждое приложение успешно с ней справляется, и допущенные ошибки редактирования неумолимо делают свое черное дело: после небрежной инсталляции нередко не только не вызывается само новое приложение, но и перестают работать его соседи, информация о которых, непосредственно записанная в редактируемых текстовых файлах, весьма уязвима и легко может быть повреждена. Во-вторых, редактирование обезличивает вносимые дополнения, порождая отмеченные выше сложности деинсталляции.
      Напротив, если редактор поддерживает ассоциативные конструкции, перечисленные проблемы находят аккуратное решение. В том месте системного текстового файла, куда приложение должно было вписать, скажем, сведения о добавляемых им драйверах определенного класса, теперь располагается наборное гнездо, автоматически собирающее объявления драйверов данного класса из всех файлов-паспортов приложений, хранящихся на постоянном диске. Для этого в паспорте приложения объявление драйвера должно быть оформлено как объявление элемента соответствующего рассредоточенного набора.
      От редактора потребуется лишь обеспечить просмотр и выдачу системного файла в двух режимах: либо в форме исходного текста, либо с подставленными на место ассоциативных конструкций однородными объявлениями. Таким образом получает конструктивное воплощение изначальная двумерность информации: вертикальные слои-приложения отображаются в файлы-паспорта, а горизонтальные слои-списки однородных ресурсов — в совокупности объявлений драйверов, предъявляемые редактором в форме расширений наборных гнезд.

      7.3.6. Однородные конструкции — в практику. А ведь как легко можно было спроектировать рациональную схему инсталляции! С самого начала совершенно ясно, что состав инсталлированных приложений будет меняться достаточно динамично. Дальше работает простое правило: «Сколько выявишь однородности — столько и получишь расширяемости». Однородные наборы здесь вычленяются без заметных усилий: это — паспорта приложений и отдельные типы заказываемых приложением ресурсов. Теперь осталось только определить, какие компоненты паспорта являются обязательными, а какие — необязательными. Обязательные компоненты превращаются в односвязные компоненты многосвязного модуля-паспорта, необязательные — в размещаемые в том же паспорте объявления ресурсов-элементов рассредоточенных наборов. Проект готов.
      К сожалению, о таком проектировании пока остается лишь мечтать. Учебники программирования обычно не затрагивают тему непосредственной зависимости между однородностью и расширяемостью. Традиционный инструментарий не поддерживает однородные конструкции. А в результате безудержно катится вал сомнительных проектных решений, порождающих нелепицы, подобные деинсталляции в Windows.