Воткликах читателей на статью о Visual Basic 5.0 (PC Week/RE, № 22/ 97, с. 43) затрагивается проблема сосуществования VB 5.0 и VB 4.0 на одном компьютере. Кто-то столкнулся с ней на собственном опыте, кто-то читал об этом в Internet или зарубежной прессе.
Суть проблемы заключается в том, что эти две версии VB имеют довольно много общих программных компонентов с одинаковыми именами и функциями - ряд файлов OCX и DLL, которые хранятся в общем каталоге компьютера WINDOWS95SYSTEM. Соответственно при установке VB 5.0 автоматически производится замена старых компонентов на новые (правила здесь очень просты - на компьютере сохраняются файлы с более поздней датой создания).
В бета-версиях VB 5.0, которые распространялись в конце 1996 г., такая ситуация описывалась в обращении к программистам-тестерам. Там же говорилось, что хранить обе версии - 4.0 и 5.0 - на одном компьютере нежелательно по двум причинам:
1. Microsoft не гарантировала работоспособность новых компонентов, которые проходили стадию бета-тестирования.
2. Разработчик-тестер не мог передавать кому бы то ни было создаваемые им программы, так как в них попадали бета-компоненты 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-приложений. Возникшая проблема - следствие использования компонентной модели при создании программ в варианте, реализованном в Windows. (Речь идет о понимании “компонентов” в широком плане, как любых автономных файлов, а не в конкретной архитектуре типа COM или CORBA).
Суть такой модели - использование одних и тех же копий общих компонентов для различных приложений. При этом решаются две очень важные задачи - минимизация объемов программ и повышение управляемости программной системой в целом (в частности, файл с ошибкой нужно заменить в одном месте, а не во всех программах). Примером такого глобального компонента является сама операционная система Windows, куда постепенно перетекают многие элементы прикладных программ, в частности в виде наборов WAPI. Вследствие этого прикладная программа фактически превратилась в приложение к Windows и ее функциональное расширение, потеряв автономность, которая была ей присуща во времена DOS.
Однако плюсы не бывают без минусов, и последние довольно сильно проявляются по мере усложнения Windows-систем. Прежде всего, теоретическая предпосылка об обязательной совместимости версий компонентов “снизу вверх” на практике реализуется с большим трудом, особенно когда различные варианты одних компонентов создаются разными разработчиками. Тем более известно, что каждая новая версия исправляет старые ошибки, но добавляет новые, которые могут оказаться критичными для уже имеющихся программ.
Мало приятного в том, что растут требования к ресурсам со стороны новых версий компонентов, хотя их новые функции старым программам не нужны.
Разделение программных компонентов на общие и локальные затрудняет решение двух вопросов.
1. Какие компоненты входят в состав данного приложения?
2. Какие приложения реально используют данный компонент?
В этой связи следует заметить, что автоматическое объявление OCX и многих DLL общими элементами и помещение их в один системный каталог SYSTEM - не очень-то удачное решение Windows. Более элегантно смотрелась бы возможность выбора варианта установки компонентов данного приложения - в локальном или разделенном варианте. Тогда ничто не мешало бы создать механизм регистрации общих компонентов, в том числе и с одинаковыми именами, и даже находящимися в разных каталогах. (Подобный простой механизм работал в DOS, когда пользователь мог вручную поместить общие модули разных программ в общие каталоги, отмеченные командой PATH.)
В результате всего этого установка нового приложения на компьютер или удаление старого может довольно легко привести к неработоспособности имевшихся ранее или оставшихся приложений. Разработчики довольно хорошо знакомы с подобной проблемой при распространении собственных программ. Несмотря на созданные в Windows довольно сложные механизмы регистрации общих компонентов, а также процедуры “инсталляции/удаления” (“идет проверка компонентов системы” - такая заставка может присутствовать на экране в течение двух десятков секунд) и создания дистрибутивов, стопроцентной гарантии они не предоставляют.
Еще одно следствие - появление обильного “мусора” после удаления программ (но это хотя бы не приводит к ошибкам!). К сожалению, многие утилиты удаления забывают убрать компоненты своего приложения не только из системного каталога, но и из своего собственного каталога.
Чтобы проиллюстрировать сказанное, приведу пример из личного опыта.
В конце прошлого года после установки бета-версии VB 5.0 и обнаружения ошибки (при работе других программ!) мне пришлось немало помучиться, чтобы выяснить, какой OCX неисправен (выдавалось сообщение о его неверной регистрации), из какой программы он попал (разные его версии присутствовали в VB4, VB5/CCE и VB5) и как записать правильный.
После удаления VB 5.0 с диска обнаружилось, что VB 4.0 также перестал работать - оставив после себя немало “мусора”, программа инсталляции удалила ряд общих компонентов.
Запустив в начале мая на выполнение записанный незадолго до этого пакет Didger, я получил очень неприятное сообщение о том, что время его жизни истекло. Повторная инсталляция привела к такому же результату. А на другом компьютере все работало отлично. Оказалось, что Didger имеет общий компонент с VB5 (все тот же COMDLG32.OCX), который “умер” вместе со всей его бета-версией
1 мая. После удаления с диска этой версии оказалось, что мертвый OCX остался в системе - он был общим. Пришлось опять заниматься удалением-копированием вручную...
Это только цветочки
В действительности мы имеем дело с достаточно простым случаем распределенной компонентной вычислительной модели в рамках обычного локального ПК. Можно себе представить, что нас ожидает при ее переносе на уровень даже локальной сети, а уж тем более Internet. “Летающие” по сетям программные компоненты, возможно, будут видеться не в таком розовом свете, как нам казалось раньше.
Андрей Колесов
С Андреем Колесовым, обозревателем
PC Week/RE, можно связаться по адресу:
E-mail: akolesov@glasnet.ru.
