Читать книгу Delphi. Трюки и эффекты - Александр Чиртик - Страница 16

Для начала создадим новый проект Windows-приложения (Pro j ectl. exe). По умолчанию оно создает и показывает одну пустую форму (объявлена в модуле Unitl. pas). Ничего менять не будем, просто скомпилируем и посмотрим размер ЕХЕ-файла. Больше 300 Кбайт – не многовато ли для такого простого приложения?

Кстати, простейшее оконное приложение, написанное на Visual C++ 6.0 (в Release-конфигурации, то есть без отладочной информации в ЕХЕ-файле) без использования MFC, имеет размер 28 Кбайт, с использованием библиотеки MFC (правда, окно диалоговое) – 20 Кбайт. Простейшее оконное приложение на Visual Basic 6.0 занимает всего 16 Кбайт.

Из-за чего такая разница? Посмотрим, какие библиотеки используются приложениями, написанными на этих языках программирования. Это можно сделать, например, с помощью программы Dependency Walker, входящей в комплект Microsoft Visual Studio (рис. 2.1).

Рис. 2.1. Библиотеки, используемые приложениями

Как видим, приложение на Delphi (правый верхний угол окна на рис. 2.1) использует приличный набор функци й, помещенных в стандартные библиотеки операционной системы Windows. Кроме библиотек операционной системы, приложение на Delphi ничего не использует.

Приложение WinAPI. ехе (левое верхнее окно на рис. 2.1) является примером чистого Windows API приложения в том смысле, что в нем не задействованы библиотеки-оболочки над API-функциями, каким-либо образом облегчающие программирование. Собственно, столько реально и «весит» простейшее оконное приложение.

С приложением MFC. ехе уже интереснее: размер самого ЕХЕ-файла уменьшился за счет того, что часть кода работы с API-функциями переместилась в библиотеки. С приложением на Visual Basic (правое нижнее окно) еще интереснее – оно фактически представляет собой вызовы функций одной библиотеки, в которой и реализована вся поддержка программирования на этом языке (при детальном рассмотрении этой библиотеки в ней можно найти объявления встроенных функций Visual Basic).

К чему это все? А к тому, что приложения на других языках программирования (в данном случае речь идет о продуктах Microsoft) совсем не менее «тяжеловесны», чем приложения, написанные на Borland Delphi, если при их написании программист пользуется не только API-функциями. Особенно примечателен в этом случае пример исполняемого файла Visual Basic, который хотя и имеет малый размер, но требует наличия библиотеки, размер которой около 1,32 Мбайт. Программа на Visual C++ с использованием, например, MFC, в которой реализованы классы оболочки над функциями Windows API (правда, не только они), требуетналичия нескольких DLL. Для Microsoft это не проблема, так как операционная система Windows выпускается именно этой компанией, а следовательно, обеспечить переносимость (здесь – работоспособность без установки) приложений, написанных с использованием ее же сред разработки, очень просто: достаточно добавить нужные библиотеки в состав ОС.

Что же в таком случае осталось сделать Borland? Дабы не лишать программиста возможности пользоваться библиотеками с реализацией самых полезных классов (VCL и не только), код с реализацией этих самых классов приходится компоновать в один файл с самой программой. Вот и получается, что реализация этих самых классов в ЕХЕ-файле может занимать места гораздо больше, чем реализация собственно приложения. Так в нашем случае и получилось.

Примечание

Кстати, проект на Visual C++ также можно статически скомпоновать с библиотекой MFC (то есть включить код реализации классов в сам ЕХЕ-файл). Таким способом можно добиться независимости приложения от различных библиотек, кроме тех, что гарантированно поставляются с Windows. Но при этом размер ЕХЕ-файла рассмотренного выше приложения (в Release-конфигурации) возрастает до 192 Кбайт.

Теперь обратимся к нашему проекту на Delphi. Посмотрим, что записано в файлах Unitl.pas и Projectl. dpr. Текст файла Unitl.pas приводится ниже (листинг 2.1).

Листинг 2.1. Содержимое Unitl.pas

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics,

Controls, Forms,

Dialogs;

type

TForm1 = class(TForm)

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

{$R *.dfm}

end.

Обратите внимание на секцию uses. Здесь можно увидеть подключение девяти модулей, объявление собственно класса формы TForml, а также строку, указывающую компилятору на использование файла ресурсов. Все модули, кроме первых двух, – это уже труды компании Borland, облегчающие жизнь простым программистам. Модуль такого же рода используется и в файле Pro j ectl. dpr (листинг 2.2).

Листинг 2.2. Содержимое файла Project1.dpr

program Project1;

uses

Forms,

Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin

Application.Initialize;

Application.CreateForm(TForm1, Form1);

Application.Run;

end.

Теперь обратим внимание на модули Windows и Messages. В первом определены константы, структуры данных, необходимые для работы с функциями Windows API, и, конечно же, объявлены импортируемые из системных библиотек API-функции. В модуле Messages можно найти определения констант и структур для работы с Windows-сообщениями (об этом в подразд. «Реакция на события элементов управления» разд. 2.3).

Собственно, этих двух модулей должно хватить для того, чтобы реализовать оконное приложение, правда, использующее только стандартные функции WindowsAPI, стандартные элементы управления. В листинге 2.3 приведен пример элементарного Windows-приложения. Главное, на что сейчас стоит обратить внимание, – это размер приложения: всего 15 Кбайт.

Листинг 2.3. Элементарное приложение

program WinAPI;

uses

Windows, Messages;

{$R *.res}

begin

MessageBox(0, 'This is a test', 'Little application', MB_OK);

end.

Зачастую неоправданно полностью отказываться от классов, реализованных Borland. Но для чистоты эксперимента в этой главе рассмотрим радикальные примеры, построенные на использовании только Windows API.