© Андрей Колесов, Visual 2000
Авторский вариант. Статья была опубликована c незначительной литературной правкой в еженедельнике PC Week/RE (№ 32/97, с.45) PC Week/RE Online
Хотя статья была написана в 1997 году, вопросы, поднятые в ней, представляются довольно принципиальными, более того - их актуальность только возрастает.
Установка VB 5.0 и VB 4.0 на одном компьютере
Общая проблема модели Windows-приложений
Это - только ягодки
В нескольких откликах читателей на статью о 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 на одном компьютере по двум причинам:
Ошибки в бета 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, рисковать не стоит. К тому же все новые варианты компонентов заметно прибавили по размеру (что касается функций, то это еще требует дополнительного изучения).
На самом деле описанная выше проблема отнюдь не определяется особенностью VB - эта общий вопрос для всех современных Windows-приложений. Она является следствием реализации компонентной модели при создании программ. (Речь идет о понимании "компонентов" в широком плане, как любых автономных файлов, а не в конкретной архитектуры типа COM или CORBA).
Суть такой модели - использование одних и тех же копий общих компонентов для различных приложений. При этом решаются две очень важные задачи - минимизация объемов программ и повышение управляемости программной системой в целом (в частности, файл с ошибкой нужно заменить в одном месте, а не во всех программах). Первым примером такого глобального компонента является сама операционная система Windows, куда постепенно перетекают многие элементы прикладных программ, например в виде наборов WAPI. Одним из результатов этого стало то, что прикладная программа стала фактически приложением к Windows (вот такая версия смены терминов!), его функциональным расширением, потеряв автономность, которая была ей присуща во времена DOS.
Однако "плюсы" не бывают без "минусов" и последние довольно сильно проявляются по мере усложнения Windows-систем. Прежде всего, теоретическая предпосылка об обязательной совместимости версий компонентов "снизу-вверх" на практике реализуется с большим трудом, особенно когда они вообще создаются разными разработчиками (такое редко, но бывает). Тем более известно, что каждая новая версия исправляет старые ошибки, но добавляет новые, которые могут оказаться критичными для уже имеющихся программ.
Не очень приятным моментом является рост требований к ресурсам со стороны новых версий компонентов при том, что их новые функции для старых программ не нужны.
Разделение программных компонентов на общие и локальные вызывает трудности в решении двух вопросов:
В этой связи представляется, что одним из не очень удачных решений в Windows является автоматическое объявление OCX и многих DLL общими элементами и помещение их в один системный каталог SYSTEM. Более элегантным решением представлялась бы возможность выбора варианта установки компонентов данного приложения - в локальном или разделенном варианте. При этом никто не мешал бы создать механизм регистрации общих компонентов, в том числе и с одинаковыми именами, и даже находящимися в разных каталогах. (Подобный простой механизм работал в DOS, когда пользователь мог вручную поместить общие модули разных программ в общие каталоги, отмеченные командой PATH.)
Результатом всех этих проблем является то, что установка нового приложения на компьютер или удаление старого может довольно легко привести к неработоспособности имевшихся или оставшихся приложений. А разработчики довольно хорошо знакомы с подобной проблемой при дистрибуции собственных программ. Несмотря на созданные в Windows довольно сложные механизмы регистрации общих компонентов, а также процедуры "инсталляции/удаления" ("идет проверка компонентов системы" - такая заставка может присутствовать на экране в течение пары десятков секунд) и создания дистрибутивов, стопроцентной гарантии они не предоставляют.
Кроме того, еще одним следствием является появления обильного "мусора" после удаления программ (но это хоть не приводит к ошибкам). К сожалению, многие утилиты удаления не только забывают убрать компоненты своего приложения из системного каталога, но и из своей собственной директории.
Для иллюстрации сказанного хотелось бы привести такой пример из личного опыта, связанного с VB 5.0.
На самом деле в данном случае мы имеем дело с достаточно простым случаем распределенной компонентной вычислительной модели в рамках обычного локального ПК. Можно себе представить, что нас ожидает при ее переносе на уровень даже локальной сети, а уж тем более Internet. "Летающие" по сетям программные компоненты, возможно, будут видеться не в том розовом свете, как это представляется в идеале.