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

© Андрей Колесов, Visual 2000

Авторский вариант. Статья была опубликована c незначительной литературной правкой в еженедельнике PC Week/RE (№ 32/97, с.45) PC Week/RE Online

Хотя статья была написана в 1997 году, вопросы, поднятые в ней, представляются довольно принципиальными, более того - их актуальность только возрастает.

Установка VB 5.0 и VB 4.0 на одном компьютере
Общая проблема модели Windows-приложений
Это - только ягодки

Установка VB 5.0 и VB 4.0 на одном компьютере

В нескольких откликах читателей на статью о Visual Basic 5.0 (PC Week/RE, N 22/97, стр. 43) затрагивается вопрос о проблеме сосуществования VB 5.0 и VB 4.0 на одном компьютере. Кто-то столкнулся с ней на собственном опыте, кто-то читал об этом в Internet или зарубежной прессе.

Суть проблемы заключается в том, что эти две версии VB имеют довольно много общих программных компонентов с одинаковыми именами и функциями - ряд файлов OCX и DLL, которые хранятся в общем каталоге компьютера WINDOW95\SYSTEM. Соответственно, при установке VB 5.0 автоматически производится замена старых компонентов на новые (правила здесь очень просты - на компьютере сохраняются файлы с более поздней датой создания).

В бета-версиях VB 5.0, которые распространялись в конце 1996 г., о такой ситуации прямо указывалось в обращении к программистам-тестерам. Там же говорилось о нежелательности хранения обеих версий 4.0 и 5.0 на одном компьютере по двум причинам:

• Так как речь шла о бета-версии, то Microsoft не гарантировала работоспособность новых компонентов.
• Разработчик-тестер не мог передавать кому бы то ни было создаваемые им программы, так как в них попадали бета-компоненты VB 5.0, на распространение которых он не имел прав.

Ошибки в бета VB 5.0 (в том числе и в бета-версии VB5/CCE, которая распространялась свободно) действительно были. Например, я тогда обнаружил их в ряде модулей OCX - COMDLG32, COMCTL32 и RICHTX32. Пришлось вручную восстанавливать варианты от VB 4.0, которые однако работали и с новой версией.

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

В окончательной версии VB 5.0 никаких предупреждений со стороны Microsoft о его разногласиях с VB 4.0 не содержится. Более того в документах Microsoft подчеркивается совместимость компонентов VB 5.0 с версией 4.0. (Один читатель указал на предупреждение не ставить две версии на один ПК, которое содержится в статье ID:Q161344, записанной на Web-странице Microsoft. Но, по-видимому, это относится ко времени бета-тестирования - статья датирована декабрем 1996 г.)

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

Общая проблема модели Windows-приложений

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

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

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

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

Разделение программных компонентов на общие и локальные вызывает трудности в решении двух вопросов:

• какие компоненты входят в состав данного приложения?
• какие приложения реально используют данный компонент?

В этой связи представляется, что одним из не очень удачных решений в Windows является автоматическое объявление OCX и многих DLL общими элементами и помещение их в один системный каталог SYSTEM. Более элегантным решением представлялась бы возможность выбора варианта установки компонентов данного приложения - в локальном или разделенном варианте. При этом никто не мешал бы создать механизм регистрации общих компонентов, в том числе и с одинаковыми именами, и даже находящимися в разных каталогах. (Подобный простой механизм работал в 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 остался в системе - он был общим. Пришлось опять заниматься удалением-копированием вручную...

Это - только ягодки

На самом деле в данном случае мы имеем дело с достаточно простым случаем распределенной компонентной вычислительной модели в рамках обычного локального ПК. Можно себе представить, что нас ожидает при ее переносе на уровень даже локальной сети, а уж тем более Internet. "Летающие" по сетям программные компоненты, возможно, будут видеться не в том розовом свете, как это представляется в идеале.