Средства разработки приложений


Общая проблема модели Windows-приложений - часть 2


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

Результатом всех этих проблем является то, что установка нового приложения на компьютер или удаление старого может довольно легко привести к неработоспособности имевшихся или оставшихся приложений. А разработчики довольно хорошо знакомы с подобной проблемой при дистрибуции собственных программ. Несмотря на созданные в Windows довольно сложные механизмы регистрации общих компонентов, а также процедуры "инсталляции/удаления" ("идет проверка компонентов системы" - такая заставка может присутствовать на экране в течение пары десятков секунд) и создания дистрибутивов, стопроцентной гарантии они не предоставляют.

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

Для иллюстрации сказанного хотелось бы привести такой пример из личного опыта, связанного с VB 5.0.

  1. После установки бета-версии VB 5.0 в конце прошлого года и обнаружив ошибки (при работе других программ!) пришлось немало помучиться, чтобы сначала обнаружить, какой OCX неисправен (выдавалось сообщение о его неверной регистрации), из какой программы он попал (разные версии присутствовали в VB4, VB5/CCE и VB5) и как записать правильный.
  2. После удаления VB 5.0 с диска обнаружилось, что VB 4.0 также перестал работать - оставив после себя немало мусора, программа инсталляции удалила ряд общих компонентов.
  3. Запустив в начале мая на выполнение записанный незадолго до этого пакет (в моем случае Didger), я получил очень неприятное сообщение о том, что "время его жизни истекло".Повторная инсталляция привела к такому же результату. На другом же компьютере все работало отлично. Оказалось, что Didger имеет общий компонент с VB5 (все тот же COMDLG32.OCX), который "умер" вместе со всей его бета-версией 1 мая. После удаления с диска этой версии, оказалось, что мертвый OCX остался в системе - он был общим. Пришлось опять заниматься удалением-копированием вручную...



Начало  Назад  Вперед



Книжный магазин