Учебник по созданию shareware программ
Microsoft Visual Basic
Microsoft Visual Basic
Разработка и распространение shareware-программ в системе Microsoft Visual Basic, при всей простоте самого языка программирования и удобстве среды разработки, сопряжена с некоторыми довольно серьезными трудностями.
Для работы любой программы, созданной в Visual Basic, требуется runtime-библиотека "весом" более мегабайта. Например, при использовании версии 5.0 требуется библиотека msvbvm50.dll, а версии 6.0 - библиотека msvbvm60.dll. Корпорация Microsoft относительно недавно стала поставлять эти библиотеки в составе операционных систем семейства Windows, и автор никогда не может быть полностью уверен, что у пользователя уже есть необходимая для работы программы библиотека. Приходится включать злосчастную DLL в дистрибутив своей программы, потому что предлагать вместо этого скачать ее со страницы разработчика слишком рискованно: многие пользователи будут разочарованы и просто не станут тратить лишнее время, предпочтя поискать продукт другого автора. Как следствие, архив с даже самой простой утилитой будет "весить" около полутора мегабайтов! Например, совсем недавно в конференции SwRus (см. разд. "Shareware в России" гл. 1) как раз шло массовое веселье по поводу обсуждения скромной утилиты, которая всего лишь показывала пользователю его IP-адрес. Увы, скромным в программе был только набор возможностей: объем ее дистрибутива был 1,4 Мбайта!
Другой недостаток shareware-программ, написанных на Visual Basic, — необходимость использования при работе над более-менее сложными проектами
ActiveX-компонентов, которые для этой системы разработки являются единственным способом серьезного увеличения функциональных возможностей программы. Активно продвигаемая корпорацией Microsoft технология на самом деле доставляет shareware-автору немало хлопот.
Несмотря на статус "дополнительной библиотеки" вроде DLL, ActiveX-компонент является, по сути дела, самостоятельным приложением, который, как и любой программный продукт, неминуемо содержит ошибки, проявляющиеся в самый неподходящий момент! Также вполне возможны ситуации, когда нормально функционирующий ActiveX отказывается работать при переходе на другую версию Windows. При этом найти ошибку автору компонента несколько сложнее, чем в случае отладки "обычного" приложения: когда ActiveX-компонент используется третьими разработчиками при написании их программ, возникают такие ситуации, которые автор компонента просто не может предвидеть и создать в процессе отладки. Более того, при подключении к проекту нескольких ActiveX-компонентов вполне может оказаться, что они конфликтуют между собой — в моей практике, по крайней мере, было несколько таких случаев. Что самое неприятное — исправить ошибку никак нельзя, т. к. компоненты поставляются без исходных текстов, только в скомпилированном виде. Иногда возникают трудности даже с отладкой программы из-за багов, возникающих где-то внутри двоичного файла ActiveX: можно довести себя до белого каления, пытаясь выяснить, почему программа не работает, хотя на соседнем компьютере такой же конфигурации оборудования и установленного программного обеспечения все, как говорится, Ok. Писать же автору компонента и просить исправить ошибку часто бывает бесполезно, т. к. он, как уже говорилось выше, может оказаться не в состоянии воссоздать ситуацию, возникшую у пользователя, и локализовать ошибку.
Кроме этого, включение в проект ActiveX-компонентов способно увеличить размеры дистрибутива программы вне всяких разумных пределов. Помимо наличия плохо оптимизированной внутренней структуры самих компонентов, некоторые автору непонятно зачем объединяют несколько ActiveX в один довольно объемный файл. Характерный пример — компонент Windows Common Controls из состава Visual Basic, включающий стандартные элементы управления Windows 95 (ToolBar, StatusBar, TabControl и др.). Поэтому при добавлении хотя бы одного из этих элементов, например кнопочной панели инструментов, объем дистрибутива сразу увеличивается на 650 Кбайт. А ведь еще нужно добавить специализированные DLL-библиотеки из состава Visual Basic для поддержки технологии OLE (основы ActiveX) — а это еще несколько сотен килобайтов!
Примечание
Примечание
Можно, конечно, обойтись без ActiveX-компонентов, программируя на чистом Windows API. Однако при этом теряется единственное преимущество Visual Basic, из-за которого его в основном используют, — высокая скорость и простота разработки.
Многие возлагали надежду на то, что корпорация Microsoft решит проблему необходимости использования громоздких DLL-библиотек и ActiveX-компонентов с помощью своей новой технологии .NET. Однако, по свидетельству бета-тестеров Visual Basic NET, размеры DLL-библиотек в этой системе увеличились еще больше и достигли "чудовищной" величины. А значит, несмотря на то, что Microsoft будет распространять NET-библиотеки в составе своей 64-разрядной операционной системы Windows XP, Visual Basic останется не очень привлекательным средством для разработки shareware-продуктов. Конечно, на рынке присутствуют программы, написанные на Visual Basic, но многие из них просто неконкурентоспособны из-за слишком большого размера дистрибутива.
К сожалению, особого смысла создавать с помощью Visual Basic ActiveX-компоненты для shareware-рынка нет, т. к. аудитория у них будет несколько ограничена. Причиной этого является то, что для работы такого ActiveX-компонента требуется runtime-библиотека из состава соответствующей версии Visual Basic. Поэтому его применение в проектах под Visual C++ и Borland Delphi нерационально. То же самое можно сказать о использовании такого ActiveX в проекте, созданном в другой версии Visual Basic: например, при добавлении компонента, созданного в версии 5.0, в проект, разрабатываемый в редакции 6.0, в дистрибутив готового продукта нужно будет включать и msvbvm50.dll, и msvbvm60.dll (суммарный объем — более 2,5 Мбайт).
Вот где позиции Visual Basic очень сильны — это в области создания дополнений для Microsoft Office: как известно, диалект VB - Visual Basic for Applications (VBA) — является языком программирования Office. В составе Office, начиная с версии 2000, наконец-то появилась полноценная интегрированная среда разработки, напоминающая обычный Visual Basic, позволяющая комфортно создавать и отлаживать приложения для Microsoft Office.
Поэтому, на мой взгляд, Visual Basic хорошо подходит в основном для разработки продуктов по конкретным заказам, (где имеется возможность протестировать программу на компьютерах заказчика, а ее окончательную версию записать на компакт-диск и принести лично или прислать по почте), а также дополнений к Microsoft Office. При использовании Visual Basic для разработки shareware-программ будьте готовы к тому, что у многих ваших конкурентов козырей будет больше, чем у вас — не случайно большинство продуктов на рынке shareware написаны все-таки на Visual C++, Borland Delphi или C++ Builder.
