Задумывались ли Вы, дорогой читатель, почему приложения, созданные с помощью Delphi или C++ Builder, имеют большой размер? Если Вы - «коренной» пользователь Дельфи (начали «обживаться» в этой среде еще со второй версии), то навеняка заметили, что с каждой следующей версией программы размер исполняемого файла неуклонимо растет. Возьмем, например, простейшее приложение - пустое окно, откомпилируем его на Delphi 5 и запишем размер входящего файла - 286 Кб. Теперь проделаем то же самое на Delphi 6 и запишем размер - 351 Кб. Сравните записанные результаты: разница составит аж 65 Кб. Конечено, теперь это не проблема, но что если Вы распотраняете приложение по Сети? Или, например, пишете программу вроде инсталлятора? (Какой смысл в инсталляторе, если он сам «весит» больше, чем распотраняемое приложение?) Примеров можно привести множество.
Причина проблемы...
Но почему размер приложения «пустого» окна настолько велик, если в том же Visual C++ или Ассемблере эта цифра не превышает и десятка килобайт? Ответ кроется в архитектуре приложения, создаваемого на Дельфи и С++ Builder. Ведь не секрет, что Дельфи и Builder использует Библиотеку Визуальных Компонентов (VCL - Visual Component Library), - она-то и прибавляет к исполняемому файлу столь впечатляющую цифру :-). А растет VCL от версии к версии за счет того, что всякий раз к форме или приложению добавляются новые свойства и события.
Решение проблемы...
Есть несколько способов решить эту проблему. Давайте подробнее разберем некоторые из них.
1. Отказаться от VCL и программировать с помощью API.
В этом случае Вы изначально редактируете один файл-проект, в котором подключаете только два модуля - Windows, Messages. Чтобы «построить» приложение таким образом, Вы должны хорошо знать функции API для работы с окнами, например такие, как CreateWindow. А во-вторых, Вам придется вручную обрабатывать сообщения для щелчка мышкой, нажатия кнопки на клавиатуре и т. д, и т. п. Еще один «минус» состоит в том, что вы не сможете увидеть само окно на стадии разработки, так как все будет создаваться динамически. Но хочу сказать, что приложение, построенное таким образом, займет поистине мизерный размер памяти: порядка 50 килобайт.
2. Отказаться от VCL и программировать с помощью диалогов.
Этот способ несколько отличается от предыдущего и сильно напоминает программирование на Visual C++: вы создаете диалог в редакторе ресурсов (можно использовать и Visual C++), а в файле проекта пишите код-обработчик сообщений. Использовать такой способ, по-моему, намного легче: диалог на стадии разработки вы видите в редакторе ресурсов, можете манипулировать компонентами, помещать новые. Все это в какой-то мере напоминает проектирование формы, но в отличие от последнего вы не можете создавать обработчики событий, и в Вашем распоряжении ограниченный набор компонентов. Пример приводить не буду, так как все предельно ясно описано в помощи к API (см. в Programs > Borland Delphi5 > Help > MS SDK Help Files > Win32 Programmer’s reference).
3. Оставить VCL и использовать запаковщик входящих файлов.
Этот способ наиболее легок и подходит для самых ленивых. Вы создаете свое приложение обычным путем, набиваете его какими хотите компонентами и компилируете. Затем вы закачиваете программу-запаковщик. В нашем случае это UPX executable packer, которую, при наличии отсутствия :-), можно скачать с сайта http://upx.sourceforge.net (размер программы вне архива - 87 Кб; программа «сжата» с помощью самой же себя). Так, UPX уже перед вами, лежит, допустим, в папке C:UPX - и что же дальше? Самый простой способ сжать приложения - набрать в командной строке (UPX - консольное приложение):
C:UPXupx.exe D:ProgramsTest est.exe
и нажать Enter. После этих действий промелькнет окно программы, и Ваш входящий файл будет запакован. В нашем случае, если он «весил» 386 Кб, теперь его величина окажется всего 122 Кб. Это же почти втрое меньше!
Да, совсем забыл сказать, что UPX сжимает любые приложения (т. е. созданные на любом языке программирования).
Читатель может поинтересоваться о возможных ошибках в запакованных EXE’шниках; отвечу, что лично я такого НИКОГДА не встречал, хоть авторы программы не дают НИКАКИХ ГАРАНТИЙ и советуют прочитать лицензионное соглашение.
Допустим, Ваше приложение состоит из нескольких входящих файлов, большая часть которых - библиотеки. Как быть дальше? Будьте спокойны, и в этом случае UPX Вас не подведет, благо она поддерживает такие типы входящих файлов, как ДОСовские *.exe, *.com, *.sys; Windows’овские *.exe, *.dll (PE); LINUX 386; WATCHCOM LE и некоторые другие, к сожалению, мне не известные форматы.
Помимо всего прочего, у программы масса параметров и опций - про некоторые я Вам сейчас поведаю.
Все параметры набираются в следующем виде:
UPX.EXE -параметры -опции -файл файл_для_записи
Параметры
Цифры от одного до девяти - степень упаковки файла. Чем меньше, тем хуже, но, естественно, быстрее.
-d - распаковать уже запакованный EXE’шник;
-t - тестировать уже запакованный EXE’шник;
-р - выдать больше помощи;
-l - информация об уже запакованном EXE’шнике;
-V - показать версия программы;
-L - показать лицензию программы;
Опции
-q - сокращенный вариант консоли;
-k - делать резервные копии приложения для запаковки;
Вы, впрочем, можете и не пользоваться параметрами, достаточно указать входящий файл. Для меня эта программа стала очень полезным подспорьем - надеюсь, Вы меня поймете!
P.S. Хотелось бы дать напоследок один маленький совет: если вы, например, используете всего-навсего одну функцию, допустим, из модуля ShellAPI, то можете его и не подключать: достаточно найти объявление функции или процедуры в этом модуле и узнать, в какой DLL’ке она содержится, затем добавить эту функцию под implementations в Вашей программе - и все готово! С облегчением Вас, дорогой товарищ!