Приветствую вас, уважаемые подписчики!

Автор: Николай Куртов

Редактор журнала СофтТерра

Софт Терра: Технологии Microsoft для разработчиков

Неслучайно именно эта статья была выбрана мной для начала рубрики, посвященной технологиям Microsoft для разработчиков. Слова OLE и COM (Component Object Model) на устах программистов вот уже 5 лет, тем не менее, парадигма компонентного подхода остается базовым и неизменным моментом в создании приложений. Я помню, насколько широкие горизонты я для себя открыл, осознав идею объектного подхода – с тех пор строю свои программы из компонентов-кирпичиков, объединяя их в более абстрактные модели – сервисы. Программирование давно стало сплавом творчества и строительства, оставляя в прошлом сугубо научно-шаманскую окраску ремесла. И если такой переход уже сделан, то сейчас можно обозначить новый виток – ломание барьеров API и переход к более обобщенному подходу в проектировании, выход на новый уровень абстракции. Немало этому способствовал интернет и его грандиозное творение – XML. Сегодня ключ к успеху приложения сплавляется из способности его создателей обеспечить максимальную совместимость со стандартами и в то же время масштабируемость. Придумано такое количество различных технологий для связи приложений и повторного использования кода, что сегодня прикладные программы не могут жить без такой "поддержки". Под термином "автоматизация" я понимаю настоящее оживление приложений, придание им способности взаимодействовать с внешней средой, предоставление пользователю максимального эффекта в работе с приложениями. Не равняясь на такие гранды технической документации, как MSDN, я, тем не менее, этой статьей хочу указать на путь, по которому сегодня проектируются современные приложения.

Автоматизация (Automation) была изначально создана как способ для приложений (таких как Word или Excel) предоставлять свою функциональность другим приложениям, включая скрипт-языки. Основная идея заключалась в том, чтобы обеспечить наиболее удобный режим доступа к внутренним объектам, свойствам и методам приложения, не нуждаясь при этом в многочисленных "хедерах" и библиотеках.

Вообще, я бы выделил два вида автоматизации – внешняя и внутренняя. Внешняя автоматизация – это работа сторонних приложений с объектной моделью вашей программы, а внутреняя – это когда сама программа предоставляет пользователю возможность работы со своей объектной структурой через скрипты. Комбинирование первого и второго вида представляется наиболее масштабируемым решением и именно о нем сегодня пойдет речь.

Для начала обратим внимание на самое дно – интерфейсы COM. Если термин "интерфейс" в этом контексте вам ничего не говорит, то представьте себе абстрактный класс без реализации – это и есть интерфейс. Реальные объекты наследуются от интерфейсов. Компоненты, наследующиеся от интерфейса IUnknown, называются COM-объектами. Этот интерфейс содержит методы подсчета ссылок и получения других интерфейсов объекта.

Автоматизация базируется на интерфейсе IDispatch, наследующегося от IUnknown. IDispatch позволяет запускать методы и обращаться к свойствам вашего объекта через их символьные имена. Интерфейс имеет немного методов, которые являются тем не менее довольно сложными в реализации. К счастью, существует множество шаблонных классов, предлагающих функциональность интерфейса IDispatch, поэтому для создания объекта, готового к автоматизации, необходимо весего лишь несколько раз щелкнуть мышкой в ClassWizard Visual C++.

Что касается способа доступа и динамического создания ваших внутренних dispatch объектов, то тут тут тоже все довольно просто – данные об объекте хранятся в реестре под специальным кодовым именем, которое называется ProgId. Например, progid программы Excel – Excel.Application. Cоздать в любой процедуре на VBScript достаточно легко – надо только вызвать функцию CreateObject, в которую передать нужный ProgID. Функция вернет указатель на созданный объект.

В MFC существует специальный класс, под названием CCmdTarget. Наследуя свои классы от cCmdtarget, вы можете обеспечить для них необходимую функциональность в dispatch виде – как раз как ее понимают скрипты. При созднании нового класса в ClassWizard (View>ClassWizard>Add Class>New), наследуемого от cСmdtarget, просто щелкните на кнопке Automation или Creatable by ID, чтобы обеспечить возможность создания экземпляра объекта по его ProgID. Замечу, что для программ, реализующих внутреннюю автоматизацию, это не нужно. Для приложений, реализующих внешнуюю и смешанную автоматизацию, это необходимо для "корневых" объектов.

После создания такого объекта, ClassWizard создает интерфейс ITestAutomatedClass (это dispatch интерфейс, т.е. наследуется от IDispatch), который реализуется моим CTestAutomatedClass. Теперь к этому интерфейсу я могу добавить методы или свойства, которые автоматически будут реализованы в CTestAutomatedClass. Я добавил свойство Age.

COM-объекты, коим и является наш CTestAutomatedClass, можно создавать только динамически. Это связано с тем, что объект может использоваться несколькими приложениями одновременно, а значит, удаление объекта из памяти не может выполнить ни одно из них. Разумно предположить, что объект сам должен отвечать за свое удаление. Такой механизм реализован при помощи механизма ссылок (reference count). Когда приложение получает указатель на объект, он увеличивает свой внутренний счетчик ссылок, а когда приложение освобождает объект – счетчик ссылок уменьшается. При достижении счетчиком нуля, объект удаляет сам себя. Если наш объект был создан по ProgID другим приложением, то программа CTestApp (другими словами, Automation-Server) не завершится до тех пор, пока счетчик ссылок CTestAutomatedClass не станет равным нулю.

Создаваемые через ProgID COM-объекты, обычно являются Proxy-компонентами. Реально они не содержат никакой функциональности, но имеют доступ к приложению и его внутренним, не доступным извне, функциям. Хотя можно организовать все таким образом, чтобы всегда создавался только один COM-объект, а все остальные вызовы на создание возвращали указатели на него.

Метод интерфейса CCmdTarget GetIDispatch(), позволяет получить указатель на реализованный интерфейс IDispatch. В параметрах можно указать, нужно ли увеличивать счетчик ссылок или нет.

В следующей статье, посвященной использованию функциональности WebBrowser Control, я обращусь к практическому применению dispatch-объектов программы в скриптах. А в дальнейшем, мы поговорим о внедрении процессора скриптов в собственные приложения.

Q. Как сделать так, чтобы программа сама себя могла стереть, т.е. свой *.exe файл?

(LowFeaR )

A₁ Удалить программу в тот момент, когда она запущена, не представляется возможным (во всяком случае такая возможность мне не знакома), остается удаление после завершения ее выполнения. Идея следующая: при выходе из программы создать BAT-файл, который ждет до тех пор, пока файл можно будет удалить (программа завершит работу), удаляет файл программы и себя, и запустить его:

void MyDlg::OnDestroy() {

 CDialog::OnDestroy();

 const char *AppName=AfxGetApp()->m_pszExeName;

 FILE *f=fopen("selfdel.bat","w+");

 fprintf(f, ":dc\n"

             "del %s.exe\n"

             "if exist %s.exe goto dc\n"

             "del selfdel.bat", AppName, AppName);

 fclose(f);

 WinExec("selfdel.bat",FALSE);

}

Преимущества:

-файл удаляется сразу в тот момент, когда это становится возможно

Недостатки:

-если запустить два экземпляра приложения, то после завершения работы первого мы получаем цикл активного ожидания до тех пор пока не завершится второй экземпляр (это незаметно в W95/98, но в NT в окне Task Manager можно заметить полную загрузку процессора). Также пользователь все это время будет удивляться наличию невесть откуда взявшегося файла sefdel.bat. 

Майкрософт же предлагает свой способ решения проблемы, причем его реализация отличается для WinNT и Win95/98. Удаление (переименование, замещение, и т.д.) файла происходит во время следующей перезагрузки системы. 

Win95/98: В процессе перезагрузки системы запускается утилита wininit.exe, которая осуществляет заданные действия над файлами, указанные в секции [rename] файла wininit.ini. При этом т.к. wininit.exe запускается еще до того как запущена система поддержки длинных имен файлов, все имена должны быть указаны в формате DOS (8.3). 

Последовательность действий для удаления или переименования файла:

1. Проверить наличие файла WININIT.INI в директории Windows

2. Если WININIT.INI существует, открываем его и добавляем новые строки в секцию [rename]. Если файла нет, создаем его и секцию [rename] в нем. 3.Добавляем строки следующего формата в секцию [rename]:

DestinationFileName=SourceFileName

Оба пути DestinationFileName и SourceFileName не должны содержать длинных имен. Приемник и источник должны находится на одном диске. Для удаления файла вместо DestinationFileName использовать NUL.

WinNT:

Здесь все сделано по-человечески. Для удаления файла следует использовать функцию MoveFileEx():

MoveFileEx(szSrcFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT);

где szSrcFile – имя файла или директории

Преимущества:

-"Лицензированный" метод Майкрософт

Недостатки:

-Чрезмерно утяжеленная процедура редактирования wininit.ini, проблемы при работе с длинными именами Win95/98,

-Удаление происходит только в момент перезагрузки.

(Bad Sector )

A₂ Программа не может удалить свой exe-файл, пока она работает. Это фундаментальное правило при работе под Windows. Поэтому всё, что остаётся – это поручить удаление другому процессу перед тем как завершить свой. 

Самый простой вариант – создать на лету и запустить bat-файл, который дождётся завершения нашего процесса, а затем удалит его exe-файл. Более сложные варианты подразумевают создание в чужом процессе (например, в Task Manager) рабочего потока, который опять же дождётся завершения нашего процесса и убьёт файл. 

Вот пример функции, которая создаёт bat-файл и запускает его, чтобы убить наш exe-файл. Лучше всего вызывать её непосредственно перед завершением нашего процесса. 

void DelSelf() {

 // Получаем свой путь

 char szExePath[MAX_PATH];

 GetModuleFileName(NULL, szExePath, MAX_PATH);

 // Создаём bat-файл

 static char szBat[] = ":Loop\r\n"

  "del %1\r\n"

  "if exist %1 goto Loop\r\n"

  "del %0";

 HANDLE hFile = CreateFile("__delself.bat", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0);

 DWORD temp;

 WriteFile(hFile, (LPVOID)szBat, strlen(szBat), &temp, NULL);

 CloseHandle(hFile);

 // Запускаем его

 STARTUPINFO si;

 ZeroMemory(&si, sizeof(si));

 si.cb = sizeof(si);

 si.wShowWindow = SW_HIDE;

 si.dwFlags = STARTF_USESHOWWINDOW;

 PROCESS_INFORMATION pi;

 char szCommand[MAX_PATH+15] = "__delself.bat ";

 strcat(szCommand, szExePath);

 CreateProcess(NULL, szCommand, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &si, &pi);

 return;

}

 Замечу, что это только пример, который можно улучшать в различных направлениях. Можно, скажем, получать имя bat-файла через GetTempFileName, чтобы гарантировать его уникальность. Или понизить приоритет создаваемого из bat-файла процесса до минимума, чтобы он кушал поменьше ресурсов в процессе циклической проверки существования exe-файла.

(Александр Шаргин (rudankort@mail.ru) )

Q. Есть у меня файлы с расширением .pdb (Microsoft C/C++ program database 2.00) (их MS VC++ делает, в папке Debug проекта создаются), можно ли с их помощью восстановить исходники программы (размер у них такой, что туда не только прога влезет, но и комментарии к ней в HTML (FrontPage Style) формате :)

( Andrey Shtukaturov )

Пока все. До скорого! 

(Алекс Jenter jenter@mail.ru) (Красноярск, 2001.)