Определение версии системы

Весьма часто приложению требуется определять, в какой версии Windows оно выпол няется. Причин тому несколько Например, программа может использовать функции защиты, заложенные в Windows API, но в полной мерс эти функции реализованы лишь в Windows 2000.

Насколько я помню, функция GetVersion есть в API всех версий Windows:

DWORD GetVersion();

С этой простой функцией связана целая история. Сначала ее разработали для 16 разрядной Windows, и она должна была я старшем слове возвращать номер версии MS-DOS, а в младшем — номер версии Windows. Соответственно в каждом слове старший байт сообщал основной номер версии, младший — дополнительный но мер версии

Увы, программист, писавший ее код, слегка ошибся, и получилось так, что номера версии Windows поменялись местами: в старший байт попадал дополнительный но мер, а в младший - основной. Поскольку многие программисты уже начали пользо ваться этой функцией, Microsoft пришлось оставить все, как есть, и изменить доку ментацию с учетом ошибки.

Из-за всей этой неразберихи вокруг GetVersion в Windows API включили новую функцию — GetVersionEx:

BOOL GetVersionEx(POSVERSIONINFO pVersionInformation);

Перед обращением к GetVersionEx профамма должна создать структуру OSVER SIONINFOEX, показанную ниже, и передать ее адрес этой функции

typedef struct {
DWORD dwOSVersionInfoSize;
DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber;
DWORD dwPlatformId;
TCHAR szCSDVersion[128];
WORD wServicePackMajor;
WORD wServicePackMinor;
WORD wSuiteMask;
BYTE wProductType;
BYTE wReserved;
} OSVERSIONINFOEX, *POSVERSIONINFOEX;

Эта структура — новинка Windows 2000 В остальных версиях Windows использу ется структура OSVERSIONINFO, в которой нет последних пяти элементов, присутству ющих в структуре OSVERSIONINFOEX

Обратите внимание, что каждому компоненту номера версии операционной сис темы соответствует свой элемент структуры это сделано специально — чтобы про граммисты не возились с выборкой данных ш всяких там старших-младших байтов слов (и не путались в них), тeпepь программе гораздо проще сравнивать ожидаемый номер версии операционной системы с действительным Назначение каждою элемен та структуры OSVERSIONTNFOFX описано в таблице 4-2

Элемент	Описание
dwOSVersionInfoSjze	Размер структуры, перед обращением к функции GetVertsionEx дол жен быть заполнен вызовом sizeof(OSVERSIONINFO) или Sizeof(OSVERSIONINFOEX)
dwMajorVersion	Основной номер версии операционной системы
dwMinorVersion	Дополнительный номер версии операционной системы
dwBuildNumber	Версия сборки данной системы
dwPlatformId	Идентификатор платформы, поддерживаемой данной системой, его возможные шачепия VFR_PLATFORM_WIN32s (Win32s), VER_PLATFORM_WIN32_WINDOWS (Windows 95/98), VER_PLATFORM_WIN32_NT (Windows NT или Windows 2000), VER_PLATFORM_WIN32_CEHH (Windows CE)
szCSDVersion	Этот элемент содержит текст — дополнительную информацию об установленной операционной системе
wServicePackMajor	Основной номер версии последнего установленного пакета исправ лений (service pack)
wServicePackMinor	Дополнительный номер версии последнего установленного пакета исправлений

Таблица 4-2. Элементы структуры OSVERSIONINFOEX

Элемент	Описание
wSuiteMask	Сообщает, какие программные пакеты (suites) доступны в системе; его возможные значения VER_SUITE_SMALLBUSINESS, VER_SUITE_ENTERPRISE, VER_SUITE_BACKOFFICE, VER_SUITE_COMMUNICATIONS, VER_SUITE_TERMINAL, VER_SUITE_SMALLBUSINESS_RESTRICTED, VER_SUITE_EMBEDDEDNT, VER_SUITE_DATACENTER
wProductType	Сообщает, какой именно вариант операционной системы установлен; его возможные значения: VER_NT_WORKSTATION, VER_NT_SERVER, VER_NT_DOMAIN_CONTROLLER
wReserved	Зарезервирован на будущее

В Windows 2000 появилась новая функция, VerifyVersionInfo, которая сравнивает версию установленной операционной системы с тем, что требует Ваше приложение:

BOOL VerifyVersionInfo(
POSVERSIONINFOEX pVersionInformation;
DWORD dwTypeMask;
DWORDLONG dwlConditionMask);

Чтобы использовать эту функцию, соэдайте структуру OSVERSIONINFOEX, запи шите в се элемент dwOSVersionInfoSize размер структуры, а потом инициализируйте любые другие элементы, важные для Вашей программы, При вызове VerifyVersionInfo параметр dwTypeMask указывает, какие элементы структуры Вы инициализировали.


Этот параметр принимает любые комбинации следующих флагов: VER_MINORVER SION, VER_MAJORVERSION, VER_BUILDNUMBER, VER_PLATFORMID, VER_SERVICEPACK MINOR, VER_SERVICEPACKMAJOR, VER_SUITENAME и VER_PRODUCT_TYPE, Последний параметр, dwlConditionMask, является 64-разрядным значением, которое управляет тем, как именно функция сравнивает информацию о версии системы с нужными Вам дан ными.

Параметр dwlConditionMask устанавливает правила сравнения через сложный на бор битовых комбинаций. Для создания требуемой комбинации используйте макрос VER_SET_CONDITION:

VER_SET_CONDITION(
DWORDLONG dwlConditionMask, ULONG dwTy0eBiLMask, ULONG dwConditionMask);

Первый параметр, dwlConditionMask, идентифицирует переменную, битами кото рой Вы манипулируете. Вы не передаете адрес этой переменной, потому что VER_SET_ CONDITION — макрос, а не функция. Параметр dwTypeBitMask указывает один элемент в структуре OSVERSIONINFOEX, который Вы хотите сравнить со своими данными. (Для сравнения нескольких элементов придется обращаться к VER_SETCONDITION не сколько раз подряд.) Флаги, передаваемые в этом параметре, идентичны передавае мым в параметре dwTypeMask функции VerifyVersionInfo.

Последний параметр макроса VER_SET_CONDITION, dwConditionMask, сообщает, как Вы хотите проводить сравнение. Он принимает одно из следующих значений. VER_EQUAL, VER_GREATER, VER_GREATER_EQUAL, VER_LESS или VER_LESS_EQUAL, Вы можете использовать эти значения в сравнениях по VER_PRODUCT_TYPE. Например, значение VER_NT_WORKSTATION меньше, чем VER_NT_SERVER. Но в сравнениях по VER_SUITENAME вместо этих значений применяется VER_AND (должны быть установ лены все программные пакеты) или VER_OR (должен быть установлен хотя бы один из программных пакетов).

Подготовив набор условий, Вы вызываете VerifyVersionlnfo и получаете ненулевое значение, если система отвечает требованиям Вашего приложения, или 0, если она не удовлетворяет этим требованиям или если Вы неправильно вызвали функцию Чтобы определить, почему VenfyVersionlnfo вернула 0, вызовше GetLastError. Если та вернет ERROR_OLD_WIN_VERSION, значит, Вы правильно вызвали функцию Venfy VersionInfo, но система не соответствует предъявленным требованиям.

Вот как проверить, установлена ли Windows 2000;

// готовим структуру OSVERSIONINFOEX, сообщая, что нам нужна Windows 2000
OSVERSIONINFOEX osver = { 0 };
osver.dwOSVersionInfoSize = sizeof(osver);
osver.dwMdjorVersion = 5;
osver.dwMinorVersion = 0;
osver.dwPlatformId = VER_PLATFORM_WIN32_NT;

// формируем маску условии

DWORDLONG dwlConditionMask = 0;
// всегда инициализируйте это элемент так
VER_SET_CONDITION(dwlConditionMask, VER_MAJORVERSION, VER_EQUAL);
VER_SET_CONDITION(dwlConditionMask, VER_MINORVERSION, VER_EQUAL); VER_SET_CONDITION(dwlConditionMask, VER_PLATFORMID, VER_EQUAL);

// проверяем версию
if (VenfyVersionInfo(&osver, VER_MAJORVERSION | VER_MINORVERSION | VER_PLATFORMID,
dwlConditionMask)) {

// хост-система точно соответствует Windows 2000

} else {
// хост-система не является Windows 2000 }

показана карта адресного пространства

В таблице 1 3- 4 показана карта адресного пространства при выполнении все той же программы VMMap, но уже под управлением Windows 98. Для экономии места диапазон виртуальных адресов между 0x80018000 и 0x85620000 не приведен.

Базовый адрес	Тип	Размер	Блоки	Атрибут(ы) защиты	Описание
00000000	Free	4194304
00400000	Private	131072	6	----	C:\CD\X86\DEBUG\14_VMMAP.EXE
00400000	Private	8192		-R-- ---
00402000	Private	8192		-RW- ---
00404000	Private	73728		-R-- ---
00416000	Private	8192		-RW- ---
00418000	Private	8192		-R-- ---
0041А000	Reserve	24576
00420000	Private	1114112	4	-
00420000	Private	20480		-RW- ---
00425000	Reserve	1028096		-
00520000	Private	4096		-RW- ---
00521000	Reserve	61440
00530000	Private	65536	2	-RW- ---
00530000	Private	4096		-RW- ---
00531000	Reserve	61440		-RW- ---
00540000	Private	1179648	6		Стек потока
00540000	Reserve	942080		--
00626000	Private	4096		-RW- ---
00627000	Reserve	24576		-- -
00620000	Private	4096		— --
0062Е000	Private	139261		-RW- ---
00650000	Reserve	65536
00660000	Private	1114112	4	- _
00660000	Private	20480		-RW- ---
00665000	Reserve	1028096		--- --
00760000	Private	4096		-RW- ---
00761000	Reserve	61440
00770000	Private	10485/6	2	-RW- ---
00770000	Private	32768		-RW- ---
00778000	Reserve	1015808		-RW- ---
00870000	Free	2004418560
78000000	Private	262144	3	----	С \WINDOWS\SYSTEM\MSVCRT.DLL
78000000	Private	188416		-R-- ---
7802E000	Private	57344		-RW- ---
7803С000	Private	16384		-R-- -
78040000	Free	133955584
80000000	Private	4096	1	---
80000000	Reserve	4096		-- ---
80001000	Private	4096	1
80001000	Private	4096		-RW- ---
80002000	Private	4096	1	----
80002000	Private	4096		-RW- ---
80003000	Private	4096	1
80003000	Private	4096		-RW- ---
80004000	Private	65536	2
80004000	Private	32768		-RW- ---
8000С000	Reserve	32768		---- ---
80014000	Private	4096	1
80014000	Private	4096		-RW- ---
80015000	Private	4096	1	----
80015000	Private	4096		-RW- ---
80016000	Private	4096	1	----
80016000	Private	4096		-RW- ---
80017000	Private	4096	1
80017000	Private	4096		-RW- ---
85620000	Free	9773056
85F72000	Private	151552	1	----
8bF72000	Private	151552		-RW- ---
85F97000	Private	327680	1	----
85F97000	Private	327680		-RW- ---
85FE7000	Free	22052864
874EF000	Private	4194304	1	----
874EF000	Reserve	4194304
878EF000	Free	679219200
B00B0000	Private	880640	3
B00B0000	Private	233472		-RW- ---
В00Е9000	Private	20480		-RW- ---
В00ЕЕ000	Private	626688		-R- ---
В0187000	Free	177311744
ВААА0000	Private	315392	7	----
ВАAА0000	Private	4096		-R- ---
ВААA1000	Private	4096		-RW- ---
ВАAА2000	Private	241664		-R- ---
BAADD000	Private	4096		-RW- ---
BAADE000	Private	4096		-R- ---
BAAOF000	Private	32788		-RW- ---
ВААЕ7000	Private	24576		-R- ---
BAAED000	Free	86978560
BFDE0000	Private	20480	1
BFOE0000	Private	20480		-R- ---
BFDE5000	Free	45056
BFDF0000	Private	65536	3	----
BFDF0000	Private	40960		-R- ---
BFDFA000	Private	4096		-RW- ---
BFDFB000	Private	20480		-R- ---
BFE00000	Free	131072
BFE20000	Private	16384	3	---
BFE20000	Private	8192		-R- ---
BFE22000	Private	4096		-RW- ---
BFE23000	Private	4096		-R- ---
BFE24000	Free	245760
BFE60000	Private	24576	3	----
BFE60000	Private	8192		-R-- ---
BFE62000	Private	4096		-RW- ---
BFE63000	Private	12288		-R-- ---
BFE66000	Free	40960
BFE70000	Private	24I376	3	----
BFE70000	Private	8192		-R-- ---
BFE72000	Private	4096		-RW- ---
BFE73000	Private	12288		-R-- ---
BFE76000	Free	40960
BFE80000	Private	65536	3	----	С:\WINDOWS\SYSTEM\ADVAPI32.DLL
BFE80000	Private	49152		-R-- ---
BFE8C000	Private	4096		-RW- ——
BFE8D000	Private	12288		-R-- ---
BFE90000	Private	573440	3
BFE90000	Private	425984		-R-- ---
BFEF8000	Private	4096		-RW- ---
BFEF9000	Private	143360		-R-- ---
BFF1C000	Free	16384
BFF20000	Private	155648	5	----	С:\WINDOWS\SYSTEM\GDI32.DLL
BFF20000	Private	126976		-R-- ---
BFF3F000	Private	8192		-RW- ---
BFF41000	Private	4096		-R-- ---
BFF42000	Private	1096		-RW- ---
BFF43000	Private	12288		-R-- ---
BFF46000	Free	40960
BFF50000	Private	69632	3		С:\WINDOWS\SYSTEM\USER32.DLL
BFF50000	Private	53248		-R-- ---
BFF5D000	Private	4096		-RW- —
BFF5E000	Private	12288		-R-- ---
BFF61000	Free	61440
BFF70000	Private	585728	5	----	С:\WINDOWS\SYSTEM\KERNEL32.DLL
BFF70000	Private	352256		-R-- ---
BFFC6000	Reserve	12288		---- --
BFFC9000	Private	16384		-RW- ---
BFFCD000	Private	90112		-R-- ---
BFFE3000	Reserve	114688		---- ---
BFFFF000	Free	4006

<
Таблица 13-4. Образец карты адресного пространства процесса (с указанием блоков внутри регионов) в Windows 98

Главное отличие двух карт адресного пространства в том, что под управлением Windows 98 информации получзешь значительно меньше Например, о регионах и блоках можно узнать лишь, свободные они, резервные или закрытые Распознать тип физической памяти Mapped или Image нельзя, Windows 98 не позволяет получить дополнительную информацию, по которой можно было бы судить, что с регионом связан проецируемый в память файл или образ исполняемого файла.

Наверное, Вы заметили, что размер большинства регионов кратен 64 Кб (это значение определяется гранулярностью выделения памяти) Если размеры блоков, составляющих регион, не дают в сумме величины, кратной 64 Кб, то в конце региона часто появляется резервный блок адресного пространства. Его размер выбирается системой так, чтобы довести общий объем региона до величины, кратной 64 Кб Например, регион, который начинается с ядреса 0x00530000, включает в себя два блока: четырехкилобайтовый блок переданной памяти и резервный блок, занимающий 60 Кб адресного пространства.

Заметьте также, что на последней карте не встречаются атрибуты защиты, разрешающие исполнение или копирование при записи, поcкoлькy Windowы 98 не поддерживает их. Кроме того, она не поддерживает и флаги атрибутов защиты (PAGE_GUARD, PAGE_WRITECOMBINE и PAGE_NOCACHE) Из-за этого программе VMMap приходится использовать более сложный метод, чтобы опредслить, не выделен ли данный регион под стек потока.

И последнее. В Windows 98 (в отличие от Windows 2000) можно исследовать регион адресного пространства 0x80000000-0xBFFFFFFF. Это раздел, в котором находится адресное пространство, общее для всех 32-разрядных приложений По карте видно, что в него загружены четыре системные DLL., и поэтому они доступны любому процессу

Особенности проецирования файлов на разных платформах

Механизм проецирования файлов в Windows 2000 и Windows 98 реализован по-раз ному Вы должны знать об этих отличиях, поскольку они могут повлиять на код про грамм и целостность используемых ими данных

В Windows 98 представление всегда проецируется на раздел адресного простран ства, расположенный в диапазоне от 0x80000000 до 0xBFFFFFFF. Значит, после успеш ного вызова функция MapViewOfFile вернет какой-нибудь адрес из этого диапазона. Но вспомните: данные в этом разделе доступны всем процессам. Если один из про цессов отображает сюда представление объекта "проекция файла, то принадлежащие этому объекту данные физически доступны всем процессам, и уже неважно: проеци руют ли они сами представление того же объекта. Если другой процесс вызывает MapViewOJFile, используя тот же объект "проекция файла", Windows 98 возвращает адрес памяти, идентичный тому, что она сообщила первому процессу. Поэтому два процесса обращаются к одним и тсм же данным и представления их объектов коге рентны.

В Windows 98 один процесс может вызвать MapViewOJFile и, воспользовавшись какой-либо формой межпроцессной связи, передать возвращенный ею адрес памяти потоку другого процесса. Как только этот поток получит нужный адрес, ему уже нич то не помешает получить доступ к тому же представлению объекта "проекция фай ла". Но прибегать к такой возможности не следует по двум причинам:

приложение не будет работать в Windows 2000 (и я только что рассказал — почему);

если первый процесс вызовет UnmapViewOfFile, регион адресного простран ства освободится. А значит, при попытке потока второго процесса обратиться к участку памяти, где когда-то находилось представление, возникнет наруше ние доступа.

Чтобы второй процесс получил доступ к представлению проецируемого файла, его поток тоже должен вызвать MapViewOfFile Тогда система увеличит счетчик числа пользователей объекта "проекция файла". И если первый процесс обратится к Unmap ViewOfFile, регион адресного пространства, занятый представлением, не будет осво божден, пока второй процесс тоже не вызовет UnmapViewOfFile. А вызвав MapView OfFile, второй процесс получит тот же адрес, что и первый.
Таким образом, необхо димость в передаче адреса от первого процесса второму отпадает.

В Windows 2000 механизм проецирования файлов реализован удачнее, чем в Win dows 98, потому что Windows 2000 для доступа к файловым данным в адресном про странстве требует вызова MapViewOfFile. При обращении к этой функции система резервирует для проецируемого файла закрытый регион адресного пространства, и никакой другой процесс нс получает к нему доступ автоматически. Чтобы посторон ний процесс мог обратиться к данным того же объекта "проекция файла", сго поток тоже должен вызвать MapViewOfFile, и система отведет регион для представления объекта в адресном пространстве второго процесса.

Адрес, полученный при вызове MapViewOfFile первым процессом, скорее всего не совпадет с тем, что получит при ее вызове второй процесс, - даже несмотря на то что оба процесса проецируют представление одного и того же объекта. И хотя в Windows 98 адреса, получаемые процессами при вызове MapViewOfFile, совпадают,

лучше не полагаться на эту особенность — иначе приложение не станет работать в Windows 2000!

Рассмотрим еще одно различие механизмов проецирования файлов у Windows 2000 и Windows 98. Взгляните на текст программы, проецирующей два представления един ственного объекта "проекция файла".

#include <Windows.h>

int WINAPI WinMain(HINSTANCE hinstExe, HINSTANCE, PTSTR pszCmdLine, int nCmdShow)
{

// открываем существующий файл; он должен быть больше 64 Кб
HANDLE hFile = CreateFile(pszCmdLine, GENERIC_READ | GENERlC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

// создаем объект "проекция файла", связанный с файлом данных
HANDLE hFileMapping = CreateFileMapping(hFile, NULL, PAGE_READWRITE, 0, 0, NULL);

// проецируем представление всего файла на наше адресное пространство
PBYTE pbFilc = (PBYTE)MapViewOfFile(hFileMapping, FILE_MAP_WRITE, 0, 0, 0);

// проецируем второе представление файла, начиная со смещения 64 Кб

PBYTE pbFile2 = (PBYTE)MapViewOfFile(hFileMapping, FILE_MAP_WRITE, 0, 65536, 0);



if ((pbFile + 65536) == pbFilft2))
{

// если адреса перекрываются, оба предсгавления проецируются на один
// регион, и мы работаем в Windows 98
MessageBox(NULL, "We are running under Windows 98", NULL, MB_OK);

}
else
{

// если адреса не перекрываются, каждое представление размещается в
// своем регионе адресного пространства, и мы работаем в Windows 2000
MessageBox(NULL, "We are running under Windows 2000", NULL, MB_OK),

}

UnmapViewOfFile(pbFile2);
UnmapViewOfFile(pbFile);
CloseHandle(hFileMapping);
CloseHandle(hFile};

return(0);

}

Когда приложение в Windows 98 отображает на адресное пространство представ ление объекта "проекция файла", ему отводится регион, достаточно большой для раз мещения всего объекта Это происходит, даже если Вы просите MapViewOfFile спрое цировать лишь малую часть такого объекта. Поэтому спроецировать объект размером 1 Гб не удастся, даже если указать, что представление должно быть не более 64 Кб.

При вызове каким-либо процессом функции MapViewOfFile ему возвращается ад рес в пределах региона, зарезервированного для целого объекта "проекция файла". Так что в покязанной выше программе первый вызов этой функции дает базовый адрес региона, содержащего весь спроецированный файл, а второй — адрес, смещенный "вглубь" того же региона на 64 Кб.

Wmdows 2000 и здесь ведет себя совершенно иначе Два вызова функции МарView OfFile (как в показанном выше коде) приведут к тому, что будут зарезервированы два

региона адресного пространства. Объем первого будет равен размеру объекта "про екция файла", объем второго — размеру объекта минус 64 Кб. Хотя регионы - раз ные, система гарантирует когерентность данных, так как оба представления созданы на основе одного объекта "проекция файла" А в Windows 98 такие представления когерентны потому, что они расположены в одном участке памяти

Остановка глобальной раскрутки

Глобальную раскрутку, осуществляемую системой, можно остановить, если в блок finally включить оператор return. Взгляните:

void FuncMonkey()
{

__try
{

FuncFish();

}

__except (EXCEPTION_EXECUTE_HANDLER)
{

MessageBeep(0);

}

MessageBox(...);

}

void FuncFish()
{

FuncPheasant();

MessageBox(...);

}

void FuncPheasant()
{

__try
{

strcpy(NULL, NULL);

}

__finally
{

return;

}

}

При вызове strcpy в блоке try функции FuncPheasant из-за нарушения доступа к памяти генерируется исключение Как только это происходит, система начинает про сматривать код, пытаясь найти фильтр, способный обработать данное исключение. Обнаружив, что фильтр в FuncMonkey готов обработать его, система приступает к глобальной раскрутке Она начинается с выполнения кода в блоке finally функции FuncPheasant. Ho этот блок содержит оператор return. Он заставляет систему прекра тить раскрутку, и FuncPheasant фактически завершается возвратом в FuncFish, кото рая выводит сообщение на экран Затем FuncFish возвращает управление FuncMonkey, и та вызывает MessageBox.

Заметьте: код блока except в FuncMonkey никогда не вызовет MessageBeep. Опера тор return в блоке finally функции FuncPheasant заставит систему вообще прекратить раскрутку, и поэтому выполнение продолжичся так, будто ничего не произошло.

Microsoft намеренно вложила в SEH такую логику Иногда всдь нужно прекратить раскрутку и продолжить выполнение программы. Хотя в большинстве случаев так все же не делают А значит, будьте внимательны и избслайте операторов return в блоках finally.

Освобождение блока

Для этого служит функция HeapFreeю

BOOL HeapFree( HANDLE hHeap, DWORD fdwFlags, PVOID pvMem);

Она освобождает блок памяти и при успешном вызове возвращает TRUE. Параметр fdwFlags принимает два значения 0 или HEAP_NO_SFRIALIZE. Обращение к этой функции может привести к тому, что диспетчер, управляющий кучами, вернет часть физической памяти системе, но это не обязательно.

Отказ от объекта-мьютекса

Объект-мьютекс отличается от остальных объектов ядра тем, что занявшему его по току передаются права на владение им. Прочие объекты могут быть либо свободны, либо заняты — вот, собственно, и все. А объекты-мьютексы способны еще и запоми нать, какому потоку они принадлежат. Если какой-то посторонний поток попытается освободить мьютекс вызовом функции ReleaseMutex, то она, проверив идентифика торы потоков и обнаружив их несовпадение, ничего делать не станет, а просто вер нет FALSE. Тут же вызвав GetLastError, Вы получите значение ERROR_NOT_OWNER.

Отсюда возникает вопрос а что будет, если поток, которому принадлежит мью текс, завершится, не успев его освободить? В таком случае система считает, что про изошел отказ от мьютекса, и автоматически переводит его в свободное состояние (сбрасывая при этом все его счетчики в исходное состояние). Если этот мьютекс ждут другие потоки, система, как обычно, "по-честному" выбирает один из потоков и по зволяет ему захватить мьютекс. Тогда Wait-функция возвращает потоку WAIT_ABANDO NED вместо WAIT_OBJECT_0, и тот узнает, что мьютскс освобожден некорректно. Дан ная ситуация, конечно, не самая лучшая. Выяснить, что сделал с защищенными дан ными завершенный поток — бывший владелец объекта-мьютекса, увы. невозможно.

В реальности программы никогда специально не проверяют возвращаемое зна чение на WAIT_ABANDONED, потому что такое завершение потоков происходит очень редко. (Вот, кстати, еще один яркий пример, доказывающий, что Вы не должны пользо ваться функцией TerminateThread.)

Отключение вывода сообщений об исключении

Иногда нужно, чтобы окно с сообщением об исключении нс появлялось на экране, — например, в готовом программном продукте. Ведь если такое окно появится, пользо ватель может случайно перейти в режим отладки Вашей программы. Стоит ему толь ко щелкнуть кнопку Cancel, и он шагнет на незнакомую и страшную территорию попадет в отладчик. Поэтому предусмотрено несколько способов, позволяющих из бежать появления этого окна на экране.

Отладка по запросу

Windows позволяет подключать отладчик к любому процессу в любой момент време ни — эта функциональность называется отладкой по запросу (just-in-time debugging). В этом разделе я расскажу, кяк она работает Щелкнув кнопку Cancel, Вы сообщаете функции UnhandledExceptionFilter о том, что хотиге начать отладку процесса.

Для активизации отладчика UnhandledExceptionFilter просматривает раздел реестра.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Если Вы установили Visual Studio, то содержащийся в этом разделе параметр Debug ger имеет следующее значение:

"C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\msrtev Rxe" -p %ld -e %ld

WINDOWS 98
В Windows 98 соответствующие значения хранятся не в реестре, а в файле Win.ini.

Строка, приведенная выше, сообщает системе, какой отладчик надо запустить (в данном случае — MSDev.exe). Естественно, Вы можете изменить это значение, указав другой отладчик. UnhandiedExceptionFilter передает отладчику два параметра в коман дной строке Первый — это идентификатор процесса, который нужно отладить, а второй — наследуемое событие со сбросом вручную, которое создается функцией UnhandiedExceptionFilter в занятом состоянии. Отладчик должен распознавать ключи -p и -e как идентификатор процесса и описатель события

Сформировав командную строку из идентификатора процесса и описателя собы тия, UnhandledExceptionFiltet запускает отладчик вызовом CreateProcess. Отладчик про

веряет аргументы в командной строке и, обнаружив ключ -p, подключается к соот ветствующему процессу вызовом DebugActiveProcess-

BOOL DebugActiveProcess(DWORD dwProcessID);

После этого система начинает уведомлять отладчик о состоянии отлаживаемого процесса, сообщая, например, сколько в нем потоков и кякие DLL спроецированы на его адресное пространство. На сбор этих данных отладчику нужно какое-то время, в течение которого поток UnhandledExceptionFilter должен находиться в режиме ожи дания. Для этого функция вызывает WaitForSingleObject и передает описатель создан ного ею события со сбросом вручную.
Как Вы помните, оно было создано в занятом состоянии, поэтому поток отлаживаемого процесса немедленно приостанавливается и ждет освобождения этого события

Закончив инициализацию, отладчик вновь проверяет командную строку — на этот раз он ищет ключ -e. Найдя его, отладчик считывает оиисатель события и вызывает SetEvent. Он может напрямую использовать этот наследуемый описатель, поскольку процесс отладчика является дочерним по отношению к отлаживаемому процессу, который и породил его, вызвав UnhandledExceptionFilter.

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

Кстати, совсем не обязательно дожидаться исключения, чгобы начать отладку. Отладчик можно подключить в любой момент командой "MSDEV -p PID", где PID — идентификатор отлаживаемого процесса. Task Manager в Windows 2000 еще больше упрощает эту задачу. Открыв вкладку Process, Вы можете щелкнуть строку с нужным процессом правой кнопкой мыши и выбрать из контекстного меню команду Debug. В ответ Task Managcr обратится к только что рассмотренному разделу реестра и вы зовет CreatуProcess, передав ей идентификатор выбранного процесса Но вместо опи сателя события Task Manager передаст 0.

Отложенная загрузка DLL

Microsoft Visual С++ 60 поддерживает отложенную загрузку DLL — новую, просто фантастическую функциональность, которая значительно упрощает работу с библиотеками. DLL отложенной загрузки (delay-load DLL) — это неявно связываемая DLL, которая нс загружается до тех пор, пока Ваш код не обратится к какому-нибудь экспортируемому из нее идентификатору. Такие DLL могут быть полезны в следующих ситуациях.

Если Ваше приложение использует несколько DLL, его инициализация может занимать длительное время, потому что загрузчику приходится проецировать их па адресное пространство процесса. Один из способов снять остроту этой проблемы — распределить загрузку DLL в ходе выполнения приложения. DLL отложенной загрузки позволяют легко решить эту задачу. Если приложение использует какую-то новую функцию и Вы пытаетесь запустить его в более старой версии операционной системы, в которой нет такой функции, загрузчик сообщает об ошибке и не дает запустить приложение. Вам нужно как-то обойти этот механизм и уже в период выполнения, выяснив, что приложение работает в старой версии системы, не вызывать новую функцию. Например, Baшa программа в Windows 2000 должна использовать функции PSAPI, я в Windows 98 — ToolHclp-функции (вроде Process32Next) При инициализации программа должна вызвать GetVersionEx, чтобы определить версию текущей операционной системы, и после этого обращаться к соответствующим функциям. Попытка запуска этой программы в Windows 98 приведет к тому, что загрузчик сообщит об ошибке, поскольку в этой системе нет модуля PSAPI.dll. Так вот, и эта проблема легко решается за счет DLL отложенной загрузки.

Я довольно долго экспериментировал с DLL отложенной загрузки в Visual C++ 6.0 и должен скязать, что Microsoft прекрасно справилась со своей задачей. DLL отложенной загрузки открывают массу дополнительных возможностей и корректно работают как в Windows 98, так и в Windows 2000.

Давайте начнем с простого: попробуем воспользоваться механизмом поддержки DLL отложенной загрузки. Для этого создайте, как обычно, свою DLL.
Точно так же создайте и ЕХЕ-модуль, по потом Вы должны поменять пару ключей компоновщика и повторить сборку исполняемого файла. Вот эти ключи:

/Lib:DelayImp.lib /DelayLoad:MyDll.dll

Первый ключ заставляет компоновщик внедрить в ЕХЕ-модуль специальную функцию, _delayLoadHelper, а второй — выполнить следующие операции:

удалить MyDll.dll из раздела импорта исполняемого модуля, чтобы при инициализации процесса загрузчик операционной системы не пытался неявно связывать эту библиотеку с ЕХЕ-модулем; встроить в ЕХЕ-файл новый раздел отложенного импорта (.didat) со списком функций, импортируемых из MyDll.dll; привести вызовы функций из DLL отложенной загрузки к вызовам _delayLoadHelper.

При выполнении приложения вызов функции из DLL отложенной загрузки (далее для краткости — DLL-функции) фактически переадресуется к _delayLoadHelper. Последняя, просмотрев раздел отложенного импорта, знает, что нужно вызывать LoadLibrary, а затем GetProcAddress. Получив адрес DLL-функции, delayLoadHelper делает так, чтобы в дальнейшем эта DLL-функция вызывалась напрямую. Обратите внимание, что каждая функция в DLL настраивается индивидуально при первом ее вызове Ключ /DelayLoad компоновщика указывается для каждой DLL, загрузку которой требуется отложить.

Вот собственно, и все. Как видите, ничего сложного здесь нет. Однако следует учесть некоторые тонкости. Загружая Ваш ЕХЕ-файл, загрузчик операционной системы обычно пытается подключить требуемые DLL и при неудяче сообщает об ошибке. Но при инициализации процесса наличие DLL отложенной загрузки не проверяется. И если функция _delayLoadHelper уже в период выполнения не найдет нужную DLL, она возбудит программное исключение. Вы можете перехватить его, используя SEH, и как-то обработать. Если же Вы этого не сделаете, Ваш процесс будет закрыт. (О структурной обработке исключений см. главы 23, 24 и 25.)

Еще одна проблема может возникнуть, когда _delayLoadHelper, найдя Вашу DLL, не обнаружит в ней вызываемую функцию (например, загрузчик нашел старую версию DLL).


В этом случае _delayLoadHelper так же возбудит программное исключение, и все пойдет по уже описанной схеме В программе-примере, которая представлена в следующем разделе, я покажу, как написать SEH-код, обрабатывающий подобные ошибки. В ней же Вы увидите и массу другого кода, не имеющего никакого отношения к SEH и обработке ошибок Он использует дополнительные возможности (о них — чуть позже), предоставляемые механизмом поддержки DLL отложенной загрузки. Если эта более "продвинутая" функциональность Вас не интересует, просто удалите дополнительный код.

Разработчики Visual C++ определили два кода программных исключений: VcppException(ERROR_SEVERTY_ERROR, ERROR_MOD_NOT_FOUND) и VcppException(ERROR_SEVERTIY_ERKOR, ERROR_PROC NOT_FOUND) Они уведомляют соответственно об отсутствии DLL и DLL-фупкции. Моя функция фильтра исключений DelayLoadDllExceptionFilter реагирует на оба кода. При возникновении любого другого исключения она, как и положено корректно написанному фильтру, возвращает EXCEPTION_CONTINUE_SEARCH. (Программа не должна "глотать" исключения, которые не умеет обрабатывать.) Однако, если генерируется один из приведенных выше кодов, функция __delayLoadHelper предоставляет указатель на структуру DelayLoadInfo, содержащую некоторую дополнительную информацию. Она определена в заголовочном файле DelayImp.h, поставляемом с Visual C++.

typedef struct DelayloadInfo
{

DWORD cb; // размер структуры
PCImgDelayDescr pidd; // "сырые" данные (все, что пока не обработано)
FARPROC * ppfn; // указатель на адрес функции, которую надо загрузить
LPCSTR szDll; // имя DLL
DelayLoadProc dlp; // имя или порядковый номер процедуры
HMODULE hmodCur; // nInstance загруженной библислеки
FARPROC pfnCur; // функция, которая будет вызвана на самом деле
DWORD dwLastError;// код ошибки

} DelayLoadInfo, * PDelayLoadInfo;

Экземпляр этой структуры данных создается и инициализируется функцией _delayLoadHelper, а ее элементы заполняются по мере выполнения задачи, связанной с динамической загрузкой DLL.


Внутри Вашего SEH- фильтра элемет szDll указывает на имя загружаемой DLL, а элемент dlp — на имя нужной DLL-функции. Поскольку искать функцию можно как по порядковому номеру, так и по имени, dlp представляет собой следующее

typedef struct DelayLoadProc
{

BOOL fImportByName;
union
{

LPCSTR bzProcName;
DWORD dwOrdinal;

};

} DealyLoadProc;

Если DLL загружается, но требуемой функции в ней нет, Вы можете проверить злемент hmodCur, в котором содержится адрес проекции этой DLL, и элемент dwLastError, в который помещается код ошибки, вызвавшей исключение. Однако для фильтра исключения код ошибки, видимо, не понадобится, поскольку код исключения и так информирует о том, что произошло. Элемент pfnCur содержит адрес DLL-функции, и фильтр исключения устанавливает его в NULL, так как само исключение говорит о том, что _delayLoadHelper нс смогла найти этот адрес

Что касается остальных элементов, то сЬ служит для определения версии системы, pidd указывает на раздел, встроенный в модуль и содержащий список DLL отложенной загрузки, а ppfh — это адрес, по которому вызывается функция, если она найдена в DLL. Последние два параметра используются внутри _delayLoadHelper и рассчитаны на очень "продвинутое" применение — крайне маловероятно, что они Вам когда-нибудь понадобятся.

Итак, самое главное о том, как использовать DLL отложенной загрузки, я рассказал Но это лишь видимая часть айсберга — их возможности гораздо шире. В частности, Вы можете еще и выгружать эти DLL Допустим, что для распечатки документа Вашему приложению нужна специальная DLL. Такая DLL — подходящий кандидат на

отложенную загрузку, поскольку она требуется только на время печати документа. Когда пользователь выбирает команду Print, приложение обращается к соответствующей функции Вашей DLL, и та автоматически загружается. Все отлично, но, напечатав документ, пользователь вряд ли станет сразу же печатать что-то еще, а значит, Вы можете выгрузить свою DI.I, и освободить системные ресурсы. Потом, когда пользователь решит напечатать другой документ, DLL вновь будет загружена в адресное пространство Вашего процесса.



Чтобы DLL отложенной загрузки можно было выгружать, Вы должны сделать две вещи. Во-первых, при сборке исполняемого файла задать ключ /Delay:unload компоновщика. А во-вторых, немного изменить исходный код и поместить в точке выгрузки DLL вызов функции _FUnloadDelayLoadedDLL:

BOOL __FUnloadDelayLoadedDLL(PCSTR szDll);

Ключ /Delay:unload заставляет компоновщик создать в файле дополнительный раздел В нем хранится информация, необходимая для сброса ужe вызывавшихся DLLфункций, чтобы к пим снова можно было обратиться чсрсз _delayLoadHelper. Вызывая _FUnloadDelayLoadedDLL, Вы передаете имя выгружаемой DLL После зтого она просматривает раздел выгрузки (unload section) и сбрасывает адреса всех DLL-функций. И, наконец, __FUnloadDelayLoadedDLL вызывает FreeLibrary, чтобы выгрузить эту DLL

Обратите внимание на несколько важных моментов Во-первых, ни при каких условиях не вызывайте сами FreeLibrary для выгрузки DLL, иначе сброса адреса DLLфункции не произойдет, и впоследствии любое обращение к ней приведет к нарушению доступа. Во-вторых, при вызове _FUnloadDelayLoadedDLL в имени DLL нельзя указывать путь, а регистры всех букв должны бьть точно такими же, как и при передаче компоновщику в ключе /DelayLoad, в ином случае вызов __FUnloadDelayLoadedDLL закончится неудачно. В-третьих, если Вы вообще не собираетесь выгружать DLL отложенной загрузки, не задавайте ключ /Delay:unload — тогда Вы уменьшите размер своего исполняемого файла И, наконец, если Вы вызовете __FUnloadDelayLoadedDLL из модуля, собранного без ключа /Delay:unload, ничего страшного не случится: __FUnloadDelayLoadedDll, проигнорирует1 вьиов и просто вернет FALSE.

Другая особенность DLL отложенной загрузки в том, что вызываемые Вами функции по умолчанию связываются с адресами памяти, по которым они, как считает система, будут находиться в адресном пространстве процесса (О связывании мы поговорим чуть позжс ) Поскольку связываемые разделы DLL отложенной загрузки увеличивают размер исполняемого файла, Вы можете запретить их создание, указав ключ /Delay:nobind компоновщика.


Однако связывание, как правило, предпочтительно, позтому при сборке большинства приложений этот ключ использовать не следует.

И последняя особенность DLL отложенной загрузки. Она, кстати, наглядно демонстрирует характерное для Microsoft внимание к деталям Функция _delayLoadHelper может вызывать предоставленные Вами функции-ловушки (hook functions), и они будут получать уведомления о том, как идет выполнение _delayLoadHelper, а также уведомления об ошибках. Кроме того, они позволяют изменять порядок загрузки DLL и формирования виртуального адреса DLL-функций.

Чтобы получать уведомления или изменить поведение _delayLoadHelper, нужно внести два изменения в свой исходный код Во-первых, Вы должны написать функцию-ловушку по образу и подобию DliHook, код которой показан на рис. 20-6 Моя функция DliHook не влияет на характер работы _delayLoadHelper. Если Вы хотите изменить поведение _delayLoadHelper, начните с DliHook и модифицируйте ее код так, как Вам требуется. Потом передайте ее адрес функции _delayLoadHelper.

В статически подключаемой библиотеке DelayImp.lib определены двс глобальные переменные типа PfriDliHouk: __pfnDliNotifyHook и __pfnDliFailureHook:

typedef FARPROC (WINAPI *pfnDliHook)( unsigned dliNotify, PDelayLoadInfo pdli);

Как видите, это тип данных, соответствующий функции, и он совпадает с прототипом моей DliHook. В DelayImp.lib эти две переменные инициализируются значением NULL, которое сообщает __delayLoadHelper, что никаких функций-ловушек вызывать не требуется. Чтобы Ваша функция-ловушка все же вызывалась, Вы должны присвоить ее адрес одной из этих переменных. В своей программе я пpocтo добавил на глобальном уровне две строки:

PfnDliHook __pfnDliNotifyHook = DliHook;
PfnDliHook __pfnDliFailureHook = DliHook;

Так что __delayLoadHelper фактически работает с двумя функциями обратного вызова: одна вызывается для уведомлений, другая — для сообщений об ошибках. Поскольку их прототипы идентичны, а первый параметр, dliNotify, сообщает о причине вызова функции, я всегда упрощаю себе жизнь, создавая одну функцию и настраивая на нее обе переменные.

Механизм отложенной загрузки DLL, введенный в Visual C++ 6.0, — вещь весьма интересная, и я знаю многих разработчиков, которые давно мечтали о нсм. Он будет полезен в очень большом числе приложений (особенно от Microsoft).

Ожидаемые таймеры

Ожидаемые таймеры (waitahle timers) ~ это объекты ядра, которые самостоятельно переходят в свободное состояние в определенное время или через регулярные про межутки времени. Чтобы создать ожидаемый таймер, достаточно вызвать функцию CreateWaitableTimer.

HANDLE CreateWaitableTimer( PSECURITY_ATTRIBUTES psa, BOOL fManualReset, PCTSTR pszName);

О параметрахр psa и pszName я уже рассказывал в главе 3. Разумеется, любой про цесс может получить свой ("процессо-зависимый") описатель существующего объек та "ожидаемый таймер", вызвав OpenWaitableTimer.

HANDLE OpenWaitableTirrer( DWORD dwDesiredAccess, BOOL bInheritHandle, PCTSTR pszName);

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

Объекты "ожидаемый таймер" всегда создаются в занятом состоянии. Чтобы со общить таймеру, в какой момент он должен перейти в свободное состояние, вызови те функцию SetWaitableTimer.

BOOL SetWaitableTimer( HANDLE hTimer, const LARGE_INTEGER *pDueTime, LONG lPeriod, PTIMERAPCROUTINE pfnCompletionRoutine, PVOID pvArgToCotnpletionRoutine, BOOI fResume);

Эта функция принимает несколько параметров, в которых легко запутаться Оче видно, что hTimer определяет нужный таймер. Следующие два параметра (pDиеТiте и lPeriod) используются совместно, первый из них задает, когда таймер должен сра ботать в первый раз, второй определяет, насколько часто это должно происходить в дальнейшем. Попробуем для примера установить таймер так, чтобы в первый раз он сработал 1 января 2002 года в 1:00 PM, а потом срабатывал каждые 6 часов.

// объявляем свои локальные переменные

HANDLE hTimer;
SYSTEMTIME st;
FILETIME ftLocal, ftUTC;
LARGE_INTEGER liUTC;

// создаем таймер с автосбросом
hTimer = CreateWaitableTimer(NULL, FALSE, NULL);

// таймер должен сработать в первый раз 1 января 2002 года в 1:00 PM
// но местному времени

st.wYear = 2002; // год
st.wMonth = 1; // январь
st.wOayOfWeek = 0; // игнорируется
st.wDay = 1, // первое число месяца
st.wHour = 13; // 1 PM
st.wMinute = 0; // 0 минут
st.wSecond = 0, // 0 секунд
st.wMilliseconds = 0; // 0 миллисекунд

SystemTimeToFileTime(&st, &ftLocal);

// преобразуем местное время в UTC-время
LocalFileTimeToFilelime(&ttLocal, &ftUTC);

// преобразуем FILETIME в LARGE_INTEGER из-за различий в выравнивании данных
liUTC.LowPart = ftUTC dwLowDateTime;
liUTC.HighPart = ftUTC dwHighDateTime;

// устанавливаем таймер
SetWaitablcTimer(hTimer, &liUTC, 6 * 60 * 60 * 1000, NULL, NULL, FALSE);

...

Этот фрагмент кода сначала инициализирует структуру SYSTEMTIME, определяя время первого срабатывания таймера (его перехода в свободное состояние). Я уста новил это время как местное. Второй параметр представляется как const LARGE_IN TEGER * и поэтому нс позволяет напрямую использовать структуру SYSTEMTIME. Од нако двоичные форматы структур FILETIME и LARGE_INTEGER идентичны: обе содер жат по два 32-битных значения. Таким образом, мы можем преобразовать структуру SYSTEMTIME в FILETIME. Другая проблема заключается в том, что функция SetWaitable Timer ждет передачи времени в формате UTC (Coordinated Universal Time). Нужное преобразование легко исуществляется вызовом LocalFileTimeToFileTime

Поскольку двоичные форматы структур FILETIMF, и IARGE_INTEGER идентичны, у Вас может появиться искушение передать в SetWaitableTimer адрес структуры FILETIME напрямую;

// устанавливаем таймер
SetWaitableTimer(hTirner, (PLARGE^INTEGER) &ftUTC, 6 * 60 * 60 * 1000, NULL, NULL, FALSE);

В сущности, разбираясь с этой функцией, я так и поступил. По это большая ошиб ка! Хотя двоичные форматы структур FILETIME и LARGE_INTEGER совпадают, вырав нивание этих структур осуществляется по-разному. Адрес любой структуры FILETIME должен начинаться на 32-битной границе, а адрес любой структуры IARGE_INTEGER — на 64-битной.


Вызов SetWaitableTimer с передачей ей структуры FILETIME может cpa

ботать корректно, но может и не сработать — все зависит от того, попадет ли начало структуры FlLETIME на 64-битную границу. В то же время компилятор гарантирует, что структура LARGE_INTEGER всегда будет начинаться на 64-битной границе, и по этому правильнее скопировать элементы FILETIME в элементы LARGE_INTEGER, а за тем передать в SetWaitableTtmer адрес именно структуры LARGE_INTEGER.

NOTE:
Процессоры x86 всегда "молча" обрабатываю ссылки на невыровненные дан ные. Поэтому передача в SetWaitableTimer адреса структуры FILETIME будет сра батывать, если приложение выполняется на машине с процессором x86 Од нако другие процессоры (например, Alpha) в таких случаях, как правило, ге нерируют исключение EXCEPTION_DATATYPE_MISALIGNMENT, которое приво дит к завершению Вашего процесса Ошибки, связанные с выравниванием дан ных, — самый серьезный источник проблем при переносе на другие процес сорные платформы программного кода, корректно работавшего на процессо рах x86 Так что, обратив внимание на проблемы выравнивания данных сей час, Вы сэкономите себе месяцы труда при переносе программы на другие платформы в будущем! Подробнее о выравнивании данных см. главу 13.

Чтобы разобраться в том, как заставить таймер срабатывать каждые 6 часов (на чиная с 1:00 PM 1 января 2002 года), рассмотрим параметр lPeriod функции SetWaitable Timer. Этот параметр определяет последующую частоту срабатывания таймера (в мс). Чтобы установить 6 часов, я передаю значение, равное 21 600 000 мс (т e. 6 часов * 60 минут • 60 секунд • 1000 миллисекунд).

О последних трех параметрах функции SetWaitableTimer мы поговорим ближе к концу этого раздела, а сейчас продолжим обсуждение второго и третьего парамет ров Вместо того чтобы устанавливать время первого срабатывания таймера в абсо лютных единицах, Вы можете задать его в относительных единицах (в интервалах по 100 нс), при этом число должно быть отрицательным. (Одна секунда равна десяти миллионам интервалов по 100 нс.)



Следующий код демонстрирует, как установить таймер на первое срабатывание через 5 секунд после вызова SetWaitableTimer.

//объявляем свои локальные переменные
HANDLF hTimer;
LARGE_INTEGER li;

// создаем таймер с автосбросом
hTimer = CreateWaitableTimer(NULL, FALSE, NULL);

// таймер должен сработать через 5 секунд после вызова SetWaitableTimer;
// задаем время в интервалах по 100 нс
const int nTimerUnitsPerSecond = 10000000;

// делаем полученное значение отрицательным, чтобы SetWaitableTimer
// знала: нам нужно относительное, а не абсолютное время li.
QuadPart = -(5 * nTimerUnitsPerSecond);

// устанавливаем таймер (он срабатывает сначала через 5 секунд,
// а потом через каждые 6 часов)
SetWaitableTimer(hTimer, &li, 6 * 60 * 60 * 1000, NULL, NULL, FALSE);

...

Обычно нужно, чтобы таймер сработал только раз — через определенное (абсо лютное или относительное) время перешел в свободное состояние и уже больше никогда не срабатывал Для этого достаточно передать 0 в параметре lPeriod Затем можно либо вызвать CloseHandle, чтобы закрыть таймер, либо перенастроить таймер повторным вызовом SetWattableTimer с другими параметрами

И о последнем параметре функции SetWaitableTimer — lResume. Он полезен на компьютерах с поддержкой режима сна. Обычно в нем передают FALSE, и в приведен ных ранее фрагментах кода я тоже делал так. Но если Вы, скажем, пишете програм му-планировщик, которая позволяет устанавливать таймеры для напоминания о зап ланированных встречах, то должны передавать в этом параметре TRUE Когда таймер сработает, машина выйдет из режима сна (если она находилась в нем), и пробудятся потоки, ожидавшие этот таймер. Далее программа сможет проиграть какой-нибудь WAV-файл и вывести окно с напоминанием о предстоящей встрече. Если же Вы пере дадите FALSE в параметре fResume, объект-таЙмер перейдет в свободное состояние, но ожидавшие его потоки не получат процессорное время, пока компьютер не выйдет из режима сна

Рассмотрение ожидаемых таймеров было бы неполным, пропусти мы функцию CancelWaitable Timer.

BOOL CancelWaitableTimer(HANDLE hTimer);

Эта очень простая функция принимает описатель таймера и отменяет его (тай мер), после чего тот уже никогда не сработает, — если только Вы не переустановите его повторным вызовом SetWaitableTimer. Кстати, если Вам понадобится перенастро ить таймер, то вызывать CancelWattableTimer перед повторным обращением к SetWai tableTimer не требуется; каждый вызов SetWaitableTimer автоматически отменяет пре дыдущие настройки перед установкой новых

Ожидаемые таймеры и АРС-очередь

Теперь Вы знаете, как создавать и настраивать таймер. Вы также научились приоста навливать потоки на таймере, передавая его описатель в WaitForSingleObjects или Wait ForMultipleObjects. Однако у Вас есть возможность создать очередь асинхронных вы зовов процедур (asynchronous procedure call, APC) для потока, вызывающего SetWai tableTimer в момент, когда таймер свободен.

Обычно при обращении к функции SetWaitableTtmer Вы передаете NULL в пара метрах pfnCompletionRoutine и pvArgToCompletionRoutine. В этом случае объект-таймер переходит в свободное состояние в заданное время. Чтобы таймер в этот момент поместил в очередь вызов АРС-функции, нужно реализовать данную функцию и пе редать ее адрес в SetWaitableTimer. АРС-функция должна выглядеть примерно так

VOID APIENTRY TimerAPCRoutine(PVOID pvArgToCompleUonRoutine, DWORD dwTimerLowValue, DWORD dwTimerHighValue)
{

// здесь делаем то, что нужно
}

Я назвал эту функцию TimerAPCRoutine, по Вы можете назвать ее как угодно. Она вызывается из того потока, который обратился к SetWaitableTimer в момент срабаты вания таймера, — но только если вызывающий поток находится в "тревожном" (aler table) состоянии, т. e. ожидает этого в вызове одной из функций SleepEx, WaitForSingle ObjectEx, WaitForMultipleObjectsEx,MsgWaitForMultipleObjectsEx или SignalObjectAndWait Если же поток этого не ожидает в любой из перечисленных функций, система не

поставит в очередь АРС-функцию таймера. Тем самым система не даст АРС-очереди потока переполниться уведомлениями от таймера, которые могли бы впустую израс ходовать колоссальный объем памяти.

Если в момент срабатывания таймера Ваш поток находится в одной из перечис ленных ранее функций, система заставляет его вызвать процедуру обратного вызова Первый ее параметр совпадает с параметром pvArgToCompletionRoutine, передаваемым в функцию SetWaitableTimer, Это позволяет передавать в TimerAPCRoutine какие-либо данные (обычно указатель на определенную Вами структуру) Остальные два парамет ра, dwTimerLowValue и dwTimerHighValue, задают время срабатывания таймера.
Код, приведенный ниже, демонстрирует, как принять эту информацию и показать ее поль зователю.

VOID APIENTRY TimerAPCRoutine(PVOID pvArgToCompletionRoutine, DWORD dwTimerLowValue, DWORD dwT:merHighValue)
{

FILETIME ftUTC, ftLocal;
SYSTEMTIME st;
TCHAR szBuf[256];

// записываем время в структуру
FILETIME ftUTC.dwlowDateTime = dwTimerLowValue;
ftUTC.dwHighDateFime = dwTimerHighValue;

// преобразуем UTC-время в местное
FileTimeToLocalFileTime(&ftUTC, &ftLocal);

// преобразуем структуру FILETIME в структуру SYSTEMTIME,
// как того требуют функции GetDateFormat и GetTimeFormat
FileTimetoSystemTime(&ftLocal, &st);

// формируем строку с датой и временем, в которой
// сработал таймер
GetDateFormat(LOCALE_USER_DEFAULT, DATE_LONGDATE, &st, NULL, szBuf, sizeof(szBuf) / sizeof(TCHAR));
_tcscat(szBuf, __TEXT(' '));
GetTimeFormat(LOCALE_USER_DEFAULT, 0, &st, NULL, _tcschr(szBuf, 0), si/eof(szBuf) / sizeor(TCHAR) - _tcslen(sz8uf));

// показываем время пользователю
MessageBox(NULL, szBuf, "Timer went off at ... ", MB_OK); }

Функция "тревожного ожидания" возвращает управление только после обработ ки вссх элементов АРС-очереди. Поэтому Вы должны позаботиться о том, чтобы Ваша функция TimerAPCRoutine заканчивала свою работу до того, как таймер вновь подаeт сигнал (перейдет в свободное состояние). Иначе говоря, элементы не должны ставить ся в АРС-очередь быстрее, чем они могут быть обработаны.

Следующий фрагмент кода показывает, как правильно пользоваться таймерами и APC:

void SomeFunc() {

//создаем таймер (его тип не имеет значения)
HANDLE hTimer = CreateWaitableTimer(NULL, TRUE, NULL);

// настраиваем таймер на срабатывание через 5 секунд
LARGE_INTEGER li = { 0 };

SetWaitableTimer(hTimer, &li, 5000, TimerAPCRoutine, NULL, FALSE);
// ждем срабатывания таймура в "тревожном" состоянии
SleepEx(INFINITE, TRUE);

CloseHandle(hTimer);
}

И последнее. Взгляните ни эют фрагмент кода:

HANDLE hTimer - CreateWaitableTimer(NULL, FAISE, NULL);
SetWaitableTimer(hTimer, ..., TimerAPCRoutine, );
WaitForSingleObjectEx(hTimer, INFINITE, TRUE);

Никогда ие пнигите такой код, потому что вызов WaitForSingleObjectEx на деле за ставляет дважды ожидать таймер — по описателю hTimer и в "тревожном" состоянии Когда таймер перейдет в свободное состояние, поток пробудится, что выведет eго из "тревожного" состояния, и вызова АРС-функции не последует. Правда, АРС-функции редко используются совместно с ожидаемыми таймерами, так как всегда можно дож даться перехода таймера в свободное состояние, а затем сделать то, что нужно.

Параметр cbStack

Этот параметр определяет, какую часть адресного пространства поток сможет использовать под свой стек. Каждому потоку выделяется отдельный стек Функция Create Process, запуская приложение, вызывает CreateThread, и та инициализирует первичный поток процесса. При этом CreateProcess заносит в параметр cbStack значение, хранящееся в самом исполняемом файле. Управлять этим значением позволяет ключ /STACK компоновщика:

/STACK.[reserve] [,commit]

Аргумент reserve определяет объем адресного пространства, который система должна зарезервировать под стек потока (по умолчанию — 1 Мб). Аргумент commit задает объем физической памяти, который изначально передается области, зарезервированной под стек (по умолчанию — 1 страница). По мере исполнения кода в потоке Вам, весьма вероятно, понадобится отвести под стек больше одной страницы памяти. При переполнении стека возникнет исключение. (О стеке потока и исключениях, связанных с его переполнением, см. главу 16, а об общих принципах обработки исключений — главу 23.) Перехватив это исключение, система передаст зарезервированному пространству еще одну страницу (или столько, сколько указано в аргументе commit) Такой механизм позволяет динамически увеличивать размер стека лишь по необходимости.

Если Вы, обращаясь к CreateThread, передаете в параметре cbStack ненулевое значение, функция резервирует всю указанную Вами память. Ее объем определяется либо значением параметра cbStack, либо значением, заданным в ключе /STACK компоновщика (выбирается большее из них). Но передается стеку лишь тот объем памяти, который соответствует значению в cbStack. Если же Вы передаете в параметре cbStack нулевое значение, CreateThread создает стек для нового потока, используя информацию, встроенную компоновщиком в ЕХЕ-файл.

Значение аргумента reserve устанавливает верхний предел для стека, и это ограничение позволяет прекращать деятельность функций с бесконечной рекурсией. Допустим, Вы пишете функцию, которая рекурсивно вызывает сама себя. Предположим также, что в функции есть "жучок", приводящий к бесконечной рекурсии. Всякий раз, когда функция вызывает сама себя, в стске создается новый стековый фрейм. Если бы система не позволяла ограничивать максимальный размер стека, рекурсивная функция так и вызывала бы сама себя до бесконечности, а стек поглотил бы все адресное пространство процесса. Задавая же определенный предел, Вы, во-первых, предотвращаете разрастание стека до гигантских объемов и, во-вторых, гораздо быстрее узнаете о наличии ошибки в своей программе. (Программа-пример Summation в главе 16 продемонстрирует, как перехватывать и обрабатывать переполнение стека в приложениях.)

Параметр fdwCreate

Параметр fdwCreate определяет флаги, влияющие на то, как именно создается новый процесс Флаги комбинируются булевым оператором OR.

Флаг DEBUG_PROCESS даст возможность родительскому процессу проводить отладку дочернего, а также всех процессов, которые последним могут быть порождены Если этот флаг установлен, система уведомляет родительский про цесс (он теперь получает статус отладчика) о возникновении определенных событий в любом из дочерних процессов (а они получают статус отлаживае мых).

Флаг DEBUG_ONLY_THIS_PROCESS аналогичен флагу DEBUG_PROCESS с тем исключением, что заставляет систему уведомлять родительский процесс о воз никновении специфических событий только в одном дочернем процессе — его прямом потомке. Тогда, если дочерний процесс создаст ряд дополнительных, отладчик уже нс уведомляется о событиях, "происходящих" в них.

Флаг CREATE_SUSPENDED позволяет создать процесс и в то же время приоста новить его первичный поток Это позволяет родительскому процессу модифи цировать содержимое памяти в адресном пространстве дочернего, изменять приоритет его первичного потока или включать этот процесс в задание (job) до того, как он получит шанс на выполнение. Внеся нужные изменения в до черний процесс, родительский разрешает выполнение его кода вызовом фун кции ResumeThread (см. главу 7).

Флаг DFTACHED_PROCESS блокирует доступ процессу, инициированному кон сольной программой, к сопданному родительским процессом консольному окну и сообщает системе, что вывод следует перенаправить в новое окно CUI процесс, создаваемый другим CUI-процессом, по умолчанию использует кон сольное окно родительского процесса (Вы, очевидно, заметили, что при за пуске компилятора С из командного процессора новое консольное окно не создается, весь его вывод "подписывается" в нижнюю часть существующего консольного окна ) Таким образом, этот флаг заставляет новый процесс пере направлять свой вывод в новое консольное окно

Флаг CREATE_NEW_CONSOLE приводит к созданию нового консольного окна для нового процесса.
Этот параметр определяет дополнительные флаги, управляющие созданием потока. Он принимает одно из двух значений. 0 (исполнение потока начинается немедленно) или CREATE_SUSPENDED. В последнем случае система создает поток, инициализирует его и приостанавливает до последующих указаний.
Флаг CREATE_SUSPENDED позволяет программе изменить какие-либо свойства потока перед тем, как он начнет выполнять код. Правда, необходимость в этом возникает довольно редко Одно из применений этого флага демонстрирует программa - пример JobLab из главы 5.

Параметр pdwThreadlD

Последний параметр функции CreateTbread - это адрес переменной типа DWORD, в которой функция возвращает идентификатор, приписанный системой новому потоку. (Идентификаторы процессов и но'юков рассматривались в главе 4.)

NOTE:
В Windows 2000 и Windows NT 4 в этом параметре можно передавать NULL (обычно так и делается). Тем самым Вы сообщаете функции, что Вас не инте ресует идентификатор потока Ilo в Windows 95/98 это приведет к ошибке, так как функция попытается записать идентификатор потока no нулевому адресу, что недопустимо. И поток не будет создан.

Такое несоответствие между операционными системами может создать разработчикам приложений массу проблем. Допустим, Вы пишете и тестируете программу в Windows 2000 (которая создает поток, даже если Вы передаете NULL в pdwThreadID). Но вот Вы запускаете приложение в Windows 98, и функция CreateThread, естественно, дает ошибку. Вывод один: тщательно тестируйте свое приложение во всех операционных системах, в которых оно будет работать.

Параметр ppiProclnfo

Параметр ppiProcInfo указывает на структуру PROCESS_INFORMATION, которую Вы должны предварительно создать; ее элементы инициализируются самой функцией CreateProcess. Структура представляет собой следующее:

typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_TNFORMATION;

Как я уже говорил, создание нового процесса влечет за собой создание объектов ядра "процесс" и "поток". В момент создания система присваивает счетчику каждого объекта начальное значение — единицу. Далее функция CreateProcess (перед самым возвратом управлении) открывает объекты "процесс" и "поток" и заносит их описатели, специфичные для данного процесса, в элементы hProcess и hTbread структуры PROCESS_INFORMATION. Когда CreateProcess открывает эти объекты, счетчики каждого из них увеличиваются до 2.

Это означает, что, перед тем как система сможет высвободить из памяти объект "процесс", процесс должен быть завершен (счетчик уменьшен до 1), а родительский процесс обязан вызвать функцию CloseHandle (и тем самым обнулить счстчик). То же самое относится и к объекту "поток" поток должен быть завершен, а родительский процесс должен закрыть описатель объекта "поток". Подробнее об освобождении объектов "поток" см. раздел "Дочерние процессы" в этой главе.

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

Почему-то многие разработчики считают, будто закрытие описателя процесса или потока заставляет систему уничтожить этот процесс или поток. Это абсолютно неправильно.
Закрывая описатель, Вы просто сообщаете системе, что статистические данные для этого процесса или потока Вас больше не интересуют, но процесс или поток продолжает исполняться системой до тех пор, пока он сам не завершит себя.
Созданному объекту ядра "процесс" присваивается уникальный идентификатор; ни у каких других объектов этого типа в системе не может быть одинаковых идентификаторов. Это же касается и объектов ядра "поток". Причем идентификаторы процесса и потока тоже разные, и их значения никогда не бывают нулевыми. Завершая свою работу, CreateProcess заносит значения идентификаторов в элементы divProcessId и dwThreadld структуры PROCESS_INFORMATION. Эти идентификаторы просто облегчают определение процессов и потоков в системе; их используют, как правило, лишь специализированные утилиты вроде Task Manager.
Подчеркну ещс один чрезвычайно важный момент система способна повторно использовать идентификаторы процессов и потоков. Например, при создании процесса система формирует объект "процесс", присваивая ему идентификатор со значением, допустим, 122. Создавая новый объект "процесс", система уже не присвоит ему данный идентификатор. Но после выгрузки из памяти первого объекта следующему создаваемому объекту "процесс" может быть присвоен тот же идентификатор — 122.
Эту особенность нужно учитывать при написании кода, избегая ссылок на неверный объект "процесс" (или "поток"). Действительно, затребовать и сохранить идентификатор процесса несложно, но задумайтесь, что получится, если в следующий момент этот процесс будет завершен, а новый получит тот же идентификатор: сохраненный ранее идентификатор уже связан совсем с другим процессом.
Иногда программе приходится определять свой родительский процесс. Однако родственные связи между процессами существуют лишь на стадии создания дочернего процесса. Непосредственно перед началом исполнения кода в дочернем процессе Windows перестает учитывать его родственные связи.


В предыдущих версиях Windows не было функций, которые позволяли бы программе обращаться с запросом к ее родительскому процессу. Но ToolHelp-функции, появившиеся в современных версиях Windows, сделали это возможным. С этой целью Вы должны использовать структуру PROCESSENTRY32: ее элемент th32ParentProcessID возвращает идентификатор "родителя" данного процесса. Тем не менее, если Вашей программе нужно взаимодействовать с родительским процессом, от идентификаторов лучше отказаться. Почему — я уже говорил. Для определения родительского процесса существуют более надежные механизмы: объекты ядра, описатели окон и т.д.
Единственный способ добиться того, чтобы идентификатор процесса или потока не использовался повторно, — не допускать разрушения объекта ядра "процесс" или "поток". Если Вы только что создали новый процесс или поток, то можете просто не закрывать описатели на зти объекты — вот и все. А по окончании операций с идентификатором, вызовите функцию CloseHandle и освободите соответствующие объекты ядра. Однако для дочернего процесса этот способ не годится, если только он не унаследовал описатели объектов ядра от родительского процесса.

Параметр psa

Параметр psa является указателем на структуру SECURITY_ATTRIBUTES. Если Вы хотите, чтобы объектуядра "поток" были присвоены атрибуты защиты по умолчанию (что чаще всего и бывает), передайте в этом параметре NULL. A чтобы дочерние процессы смогли наследовать описатель этого объекта, определите структуру SECURITY_ATTRIBUTES и инициализируйте ее элемент hlnheritHandle значением TRUE (см. главу 3)

Параметр psiStartlnfo

Этот параметр указывает на структуру STARTUPINFO:

typedef struct _STARTUPINFO {
DWORD cb;
PSTH lpReserved;
PSTR lpDesktop;
PSTR lpTitle;
DWORD dwX;
DWORD dwY;

DWORD dwXSize;
DWORD dwYSize;
DWORD dwXCountChars;
DWORD dwYCountChars;
DWORD dwFillAttribute;
DWORD dwFlags;
WORD wShowWindOw;
WORD cbReserved2;
PBYTE lpReserved2;
HANDLE hStdInput;
HANDLE hStdOutput;
HANDLE hStdError;
} STARTUPINFO, *LPSTARTUPINFO;

Элементы структуры STARTUPINFO используются Windows-функциями при созда нии нового процесса. Надо сказать, что большинство приложений порождает процес сы с атрибутами по умолчанию Но и в этом случае Вы должны инициализировать все элементы структуры STARTUPINFO хотя бы нулевыми значениями, а в элемент сb — заносить размер этой структуры:

STARTUPINFO si = { sizeof(si) }; CreateProcess(.. , &si, ...};

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

Когда Вам понадобится изменить какие-то элементы структуры, делайте это пе ред вызовом CreateProcess. Все элементы зтой структуры подробно рассматриваются в таблице 4-3- Но заметьте, что некоторые элементы имеют смысл, только если до чернее приложение создает перекрываемое (overlapped) окно, а другие — если это приложение осуществляет ввод-вывод на консоль

Элемент		Окно или консоль		Описание
cb		То и другое		Содержит количество байтов, занимаемых структу рой STARTUPINFO. Служит для контроля версий — на тот случай, если Microsoft расширит эту структуру в будущем Программа должна инициализировать cb как sizeof(STARTUPINFO)
lpReserved		То и другое		Зарезервирован Инициализируйте как NULL.
IpDesktop		То и другое		Идентифицирует имя рабочего стола, на котором за пускается приложение Если указанный рабочий стол существует, новый процесс сразу же связывается с ним. В ином случае система сначала создает рабочий стол с атрибутами по умолчанию, присваивает ему имя, указанное в данном элементе структуры, и свя зываем его с новым процессом. Если IpDesktop равен NULL (что чаще всего и бывает), процесс связывается с текущим рабочим столом.
IpTitle		Консоль		Определяет заголовок консольного окна. Если IpTitle — NULL, в заголовок выводится имя исполняе мого файла.

<
Таблица 4-3. Элементы структуры STARTUPINFO

Элемент	Окно или консоль	Описание
dwX dwY	То и другое	Указывают х- и j'-координаты ( в пикселах) окна приложения Эти координаты используются, только если дочерний процесс создаст свое первое перекры ваемое окно с идентификатором CW_USEDEFAULT в параметре х функции CreateWindow. В приложениях, создающих консольные окна, данные элементы опре деляют верхний левый угол консольною окна.
dwXSize dwYSize	То и другое	Определяют ширину и высоту (в пикселах) окна приложения. Эти значения используются, только если дочерний процесс создает свое первое перекрывае мое окно с идентификатором CW_USEUEFAULT в параметре nWtdth функции CreateWindow В приложениях, создающих консольные окна, данные элементы определяют ширину и высоту консольного окна
dwXCountChars dwYCountChars	Консоль	Определяют ширину и высоту (в символах) консольных окон дочернего процесса
dwFillAttnbute	Консоль	Задает цвет текста и фона в консольных окнах дочернего процесса
dwFlags	То и другое	См ниже и следующую таблицу
wSbowWtndow	Окно	Определяет, как именно должно выглядеть первое перекрываемое окно дочернего процесса, если приложение при первом вызове функции ShowWindow передает в параметре nCmdSbow идентификаюр SW_SHOWDEFAULT. В этот элеменn можно записать любой из идентификаторов типа SW_*, обычно используемых при вызове SbowWindoiv.
cbReserved2	То и друюс	Зарезервирован Инициализируйте как 0.
lpReserved2	То и друюс	Зарезервирован. Инициализируйте как NULL.
hStdlnput hStdOutlput bStdError	Консоль	Определяют описатели буферов для консольного ввода-вывода. По умолчанию bStdlnpitt идентифицирует буфер клавиатуры, a bStdOutput и bStdError — буфер консольного окна

Теперь, как я и обещал, обсудим элемент dwFlags. Оп содержит набор флагов, по зволяющих управлять созданием дочернего процесса. Большая часть флагов просто сообщает функции CreateProcess, содержат ли прочие элементы структуры START UPINFO полезную информацию или некоторые из них можно игнорировать.


Список допустимых флагов приведен в следующей таблице.

Флаг	Описание
STARTF_USESIZE	Заставляет использовать элементы divSize и dwYSize
STARTF_USESHOWWINDOW	Заставляет использовать элемент wShowWindow
STARTF_USEPOSITION	Заставляет использовать элементы dwX и dwY
STARTF_USECOTUNTCHARS	Заставляет использовать элементы dwXCountChars и dwYCountCbars
STARTF_USEFILLATTRIBUTE	Заставляет использовать элемент dwFillAttnbute
STARTF_USESTDHANDLES	Заставляет использовать элементы hStdlnput, hStdOutput и bStdError

Флаг	Описание
STARTF_RUN_FULLSCREEN	Приводит к тому, что консольное приложение на компью тере с процессором типа х86 запускается в полноэкран ном режиме

Два дополнительных флага — STARTF_FORCEONFEEDBACK и STARTF_FORCEOFF FEEDBACK — позволяют контролировать форму курсора мыши в момент запуска но вого процесса. Поскольку Windows поддерживает истинную вытесняющую многоза дачность, можно запустить одно приложение и, пока оно инициализируется, пора ботать с другой программой. Для визуальной обратной связи с пользователем функ ция CreateProcess временно изменяет форму системного курсора мыши:
Курсор такой формы подсказывает: можно либо подождать чего-нибудь, что вот вот случится, либо продолжить работу в системе. Если же Вы укажете флаг STARTF_ FORCEOFFFEEDBACK, CreateProcess не станет добавлять "песочные часы" к стандарт ной стрелке.
Флаг START_FFORCEONFEEDBACK заставляет CreateProcess отслеживать инициали зацию нового процесса и в зависимости от результата проверки изменять форму кур сора. Когда функция CreateProcess вызывается с этим флагом, курсор преобразуется в "песочные часы" Если спустя две секунды от нового процесса не поступает GUI-вы зов, она восстанавливает исходную форму курсора
Если же в течение двух секунд процесс все же делает GUI-вызов, CreateProcess ждет, когда приложение откроет свое окно. Это должно произойти в течение пяти секунд после GUI-вызова Если окно не появилось, CreateProcess восстанавливает курсор, а появилось — сохраняет его в виде "песочных часов" еще на пять секунд Как только приложение вызовет функцию GetMessage, сообщая тeм самым, что оно закончило инициализацию, CreateProcess немедленно сменит курсор на стандартный и прекра тит мониторинг нового процесса.


В заключение раздела — несколько слов об элементе wShowWindow структуры STARTUPINFO. Этот элемент инициализируется значением, которое Вы передаете в (w)WinMain через ее последний параметр, nCmdShoiv. Он позволяет указать, в каком виде должно появиться главное окно Вашею приложения В качестве значения ис пользуется один из идентификаторов, обычно передаваемых в ShowWindow (чаще всего SW_SHOWNORMAL или SW_SHOWMINNOACTIVE, но иногда и SW_SHOW DEFAULT).
После запуска программы из Explorer ее функция (w)WinMain вызывается с SW_SHOWNORMAL в параметре nCmdShow Если же Вы создаете для нее ярлык, то можете указать в его свойствах, в каком виде должно появляться ее главное окно. На рис. 4-3 показано окно свойств для ярлыка Notepad. Обратите внимание на список Run, в котором выбирается начальное состояние окна Notepad.
Когда Вы активизируете этот ярлык из Explorer, последний создает и инициализирует структуру STARTUPINFO, a затем вызывает CreateProcess. Это приводит к запуску Notepad, а его функция (w)WinMam получает SW_SIHOWMINNOACTIVE в параметре nCmdSbow.
Таким образом, пользователь может легко выбирать, в каком окне запускать программу — нормальном, свернутом или развернутом.

Рис. 4-3. Окно свойств для ярлыка Notepad
Наконец, чтобы получить копию структуры STARTUPINFO, инициализированной родительским процессом, приложение может вызвать:
VOID GetStartupInfo(PSTARTUPINFO pStartupInfo);
Анализируя эту структуру, дочерний процесс может изменять свое поведение в зависимости oт значений ее элементов:
NOTE
Хотя в документации на Windows об этом четко не сказано, перед вызовом GetStartupInfo нужно инициализировать элемент cb структуры STARTUPINFO:
STARTUPINFO si = { sizeof(si) }, GetStartupInfo(&si)

Параметр pszCurDir

Он позволяет родительскому процессу установить текущие диск и каталог для дочер него процесса. Если его значение — NULL, рабочий каталог нового процесса будет тем же, что и у приложения, его породившего. А если он отличен от NULL, то должен ука зывать на строку (с нулевым символом в конце), содержащую нужный диск и каталог. Заметьте, что в путь надо включать и букву диска.

Параметр pvEnvironment

Параметр pvEnvironment указывает на блок памяти, хранящий строки переменных окружения, которыми будет пользоваться новый процесс. Обычно вместо этого па раметра передается NULL, в результате чего дочерний процесс наследует строки пе рсмснных окружения от родительского процесса. В качестве альтернативы можно вызвать функцию GetEnvironmentStrings

PVOID GetEnvironmentStrings();

Она позволяет узнать адрес блока памяти со строками переменных окружения, используемых вызывающим процессом. Полученный адрес можно занести в параметр pvEnvironment функции CreateProcess. (Именно это и делает CreateProcess, если Вы передаете ей NULL вместо pvEnvironment.) Если этот блок памяти Вам больше не ну жен, освободите его, вызнав функцию FreeEnvironmentStrings:

BOOL FreeEnvironmentStrings(PTSTR pszEnvLronmenLBlock);

Параметры pfnStartAddr и pvParam

Параметр pfnStartAddr определяет адрес функции потока, с которой должен будет начять работу создаваемый поток, а параметр pvParam идентичен параметру рvРаrаm функции потока. CreateTbread лишь передает этот параметр по эстафете той функции, с которой начинается выполнение создаваемого потока. Таким образом, данный параметр позволяет передавать функции потока какое-либо инициализирующее значение. Оно может быть или просто числовым значением, или указателем на структуру данных с дополнительной информацией.

Вполне допустимо и даже полезно создавать несколько потоков, у которых в качестве входной точки используется адрес одной и той же функции. Например, можно реализовать Web-сервер, который обрабатывает каждый клиентский запрос в отдельном потоке. При создании каждому потоку передается свое значение рvParam.

Учтите, что Windows — операционная система с вытесняющей многозадачностью, а следовательно, новый поток и поток, вызвавший CreateThread, могут выполняться одновременно. В связи с этим возможны проблемы. Остерегайтесь, например, такого кода.

DWORD WINAPI FirstThread(PVOID pvParam)
{
// инициализируем переменную, которая содержится в стеке

int x = 0;
DWORD dwThreadID;

// создаем новый поток
HANDLE hThread = CreateThread(NULL, 0, SecondThread, (PVOID) &x, 0, &dwThreadId);

// мы больше не слылаемся на новый поток,
// поэтому закрываем свой описатель этого потока
CloseHandle(hThread);

// Наш поток закончил работу.
// ОШИБКА, его стек будет разрушен, но SecondThread // может попытаться обратиться к нему return(0);
}

DWORD WINAPI SecondThread(PVOID pvParam) {
// здесь выполняется какая-то длительная обработка
// Пытаемся обратиться к переменной в стеке FirstThread,
// ПРИМЕЧАНИЕ- это может привести к ошибке общей защиты
// нарушению доступа * ((int *) pvParam) = 5;

relurn(0);
}

Не исключено, что в приведенном коде FirstThread закончит свою работу до того, как SecondThread присвоит значение 5 переменной x из FirstThread. Если так и будет, SecondThread не узнает, что FirstThread больше не существует, и попытается изменить содержимое какого-то участка памяти с недействительным теперь адресом. Это неизбежно вызовет нарушение доступа: стек первого потока уничтожен по завершении.

FirstThread. Что же делать? Можно объявить x статической переменной, и компилятор отведет память для хранения переменной x не в стеке, а в разделе данных приложения (application's data section). Ho тогда функция станет нереентерабельной. Иначе говоря, в этом случае Вы не смогли бы создать два потока, выполняющих одну и ту же функцию, так как оба потока совместно использовали бы статическую переменную. Другое решение этой проблемы (и его более сложные варианты) базируется па методах синхронизации потоков, речь о которых поЙдет в главах 8, 9 и 10.

Параметры psaProcess, psaThread и blnheritHandles

Чтобы создать новый процесс, система должна сначала создать объекты ядра "про цесс" и "поток" (для первичного потока процесса). Поскольку это объекты ядра, ро дительский процесс получает возможность связать с ними атрибуты защиты. Пара метры psaProcess и psaThread позволяют определить нужные атрибуты защиты для объектов "процесс" и "поток" соответственно. В эти параметры можно занести NULL, и система закрепит за данными объектами дескрипторы защиты по умолчанию. В качестве альтернативы можно объявить и инициализировать две структуры SECU RITY_ATTRIBlITES; тем самым Вы создадите и присвоите объектам "процесс" и "по ток" свои атрибуты защиты.

Структуры SECURITY_ATTRIBUTES для параметров psaProcess wpsaTbread исполь зуются и для того, чтобы какой-либо из этих двух объектов получил статус наследуе мого любым дочерним процессом. (О теории, на которой построено наследование описателей объектов ядра, я рассказывал в главе 3.)

Короткая программа на рис. 4-2 демонстрирует, как наследуются описатели объек тов ядра. Будем считать, что процесс А порождает процесс В и заносит в параметр psaProcess адрес структуры SECURITY_ATTRIBUTES, в которой элемент blnheritHandle установлен как TRUE. Одновременно параметр psaThread указывает на другую струк туру SECURITY_ATTRIBUTES, в которой значение элемента bInheritHandle — FALSE.

Создавая процесс В, система формирует объекты ядра "процесс" и "поток", а за тем — в структуре, на которую указывает параметрppiProcInfo (о нем поговорим поз же), — возвращает их описатели процессу А, и с этого момента тот может манипули ровать только что созданными объектами "процесс" и "поток".

Теперь предположим, что процесс А собирается вторично вызвать функцию Create Process, чтобы породить процесс С. Сначала ему нужно определить, стоит ли предос тавлять процессу С доступ к своим объектам ядра. Для этого используется параметр blnberitHandles, Если он приравнен TRUE, система передаст процессу С все наследуе мые описатели В этом случае наследуется и описатель объекта ядра "процесс" про цесса В. А вот описатель объекта "первичный поток" процесса В не наследуется ни при каком значении bInberitHandles. Кроме того, если процесс А вызывает Create Process, передавая через параметр blnberitHandles значение FALSE, процесс С не насле дует никаких описателей, используемых в данный момент процессом А.

Параметры pszApplicationName и pszCommandLine

Эти параметры определяют имя исполняемого файла, которым будет пользоваться новый процесс, и командную строку, передаваемую этому процессу. Начнем cpszCom mandLine.

NOTE
Обратите внимание на тип параметра pszCommandLine: PTSTR. Он означает, что CreateProcess ожидает передачи адреса строки, которая не является констан той Дело в том, что CreateProcess в процессе своего выполнения модифици рует переданную командную строку, но перед возвратом управления восста навливает ее.

Это очень важно, если командная строка содержится в той части образа Вашего файла, которая предназначена только для чтения, возникнет ошибка доступа. Например, следующий код приведет к такой ошибке, потому что Visual С++ 6.0 поместит строку "NOTEPAD" в память только для чтения:

STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcess(NULL, TEXT("NOTEPAD"), NULL, NULL, FALSE, 0, NULL. NULL, &si, &pi);

Когда CreateProcess попытается модифицировать строку, произойдет ошиб ка доступа. (В прежних версиях Visual C++ эта строка была бы размещена в памяти для чтения и записи, и вызовы CreateProcess не приводили бы к ошиб кам доступа.)

Лучший способ решения этой проблемы — перед вызовом CreateProcess ко пировать константную строку во временный буфер:

STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
TCHAR szComrnandLine[] = TEXT("NOTEPAD");
CreateProcess(NULL, szCommandLine, NULL, NULL, FALSE, 0, NULI, NULL, &si, &pi);

Возможно, Вас заинтересуют ключи /Gf и /GF компилятора Visual C++, ко торые исключают дублирование строк и запрещают их размещение в области только для чтения. (Также обратите внимание на ключ /ZI, который позволяет задействовать отладочную функцию Edit & Continue, поддерживаемую Visual Studio, и подразумевает активизацию ключа /GF.) В общем, лучшее, что може те сделать Вы, — использовать ключ /GF или создать временный буфер. А еще лучше, если Microsoft исправит функцию CreateProcess, чтобы та не морочила нам голову.
Надеюсь, в следующей версии Windows так и будет.
Кстати, при вызове ANSI-версии CreateProcess в Windows 2000 таких про блем нет, поскольку в этой версии функции командная строка копируется во временный буфер (см. главу 2)
Параметр pszCommandLme позволяет указать полную командную строку, исполь зуемую функцией CreateProcess при создании нового процесса. Разбирая эту строку, функция полагает, что первый компонент в ней представляет собой имя исполняе мого файла, который Вы хотите запустить. Если в имени этого файла не указано рас ширение, она считает его EXE. Далее функция приступает к поиску заданного файла и делает это в следующем порядке:
Каталог, содержащий ЕХЕ-файл вызывающего процесса.
Текущий каталог вызывающего процесса.
Системный каталог Windows.
Основной каталог Windows.
Каталоги, перечисленные в переменной окружения PATH.
Конечно, если в имени файла указан полный путь доступа, система сразу обраща ется туда и не просматривает эти каталоги. Найдя нужный исполняемый файл, она создает новый процесс и проецирует код и данные исполняемого файла на адресное пространство этого процесса Затем обращается к процедурам стартового кода из библиотеки С/С++. Тот в свою очередь, как уже говорилось, анализирует командную строку процесса и передает (w)WinMain адрес первого (за именем исполняемого фай ла) аргумента как pszCmdLine.
Все, о чем я сказал, произойдет, только если параметр pszApplicationName равен NULL (что и бывает в 99% случаев). Вместо NULL можио передать адрес строки с име нем исполняемого файла, который надо запустить. Однако тогда придется указать не только его имя, но и расширение, поскольку в этом случае имя не дополняется рас ширением EXE автоматически. CreateProcess предполагает, что файл находится в те кущем каталоге (если полный путь не задан). Если в текущем каталоге файла нет, функция не станет искать его в других каталогах, и на этом все закончится
Но даже при указанном в pszApplicationName имени файла CreateProcess все равно передает новому процессу содержимое параметра pszCommandLine как командную строку.Допустим, Вы вызвали CreateProcess так:
// размещаем строку пути в области памяти для чтения и записи
TCHAR szPath[] = TEXT("WORDPAD README.TXT");
// порождаем новый процесс
CreateProcess(TEXT("C:\\WINNr\\SYSrEM32\\NOTEPAD EXE"), szPath );
Система запускает Notepad, а в его командной строке мы видим "WORDPAD README.TXT". Странно, да? Но так уж она работает, эта функция CreateProcess. Упо мянутая возможность, которую обеспечивает пареметр pszApplicationName, на самом деле введена в CreateProcess для поддержки подсистемы POSIX в Windows 2000.

Переадресация вызовов функций

Запись о переадресации вызова функции (function forwarder) — это строка в разделе экспорта DLL, которая перенаправляет вызов к другой функции, находящейся в другой DLL Например, запустив утилиту DumpBin из Visual С++ для Kcrncl32dll в Windows 2000, Вы среди прочей информации увидите и следующее

С \winnt\system32>DumpBin -Exports Kernel32.dll (часть вывода опущена)

360 167 HeapAlloc (forwarded to NTDLL RtlAllocateHeap)

361 168 HeapCompact (000128D9)

362 1Ь9 HeapCreate (000126EF)

363 16A HeapCreateTagsW (0001279E)

364 16B HpapDpstroy (0001?750)

365 16C HeapExtend (00012773)

366 16D HeapFree (forwarded to NTDLL RtlFreeHeap)

367 16E HeapLock (000128ED)

368 16F HeapQueryTagW (000127B8)

369 170 HeapReAlloc (forwarded to NTDLL RtlReAllocateHeap)

370 171 HeapSize (forwarded to NTDLL RtlSizeHeap) (остальное тоже опущено)

Здесь есть четыре переадресованные функции Всякий раз, когда Ваше приложение вызывает HeapAlloc, HeapFree, HeapReAlloc или HeapSize, его ЕХЕ-модуль динамически связывается с Kernel32.dll При запуске ЕХЕ-модуля загрузчик загружает Kernel32dll и, обнаружив, что переадресуемые функции на самом деле находятся в NTDLLdll, загружаег и эту DLL Обращаясь к HeapAlloc, программа фактически вызы васт функцию Rltоса1еНеар из NTULL.dll А функции HeapAlloc вообще нет1

При вызове НеарАllос (см ниже) функция GetProcAddress просмотрит раздел экспорта Kernel32dll и, выяснив, чю НеарАllос — переадресуемая функция, рекурсивно вызовет сама себя для поиска RtlAllocateHeap в разделе экспорта NTDLL.dll.

GetProcAddress(GetModuleHandle("Kernel32"), "НеарАllос" );

Вы тоже можете применять переадресацию вызовов функций в своих DLL. Самый простой способ — воспользоваться директивой pragma:

// переадресация к функции из DllWork

#pragma comment(linker, "/export:SomeFunc=DllWork.SomeOtherFunc")

Эта директива сообщает компоновщику, что DLL должна экспортировать функцию SomeFunc, которая на самом деле реализована как функция SomeOtherFunc в модуле DlIWork dll Такая запись нужна для каждой переадресуемой функции

Перечисление процессов, выполняемых в системе

Многие разработчики программного обеспечения пытаются создавать инструмен тальные средства или утилиты для Windows, требующие перечисления процессов, выполняемых в системе Изначально в Windows API не было функций, которые по зволяли бы это делать. Однако в Windows NT ведется постоянно обновляемая база данных Performance Data. В ней содержится чуть ли не тонна информации, доступ ной через функции рссстра вроде RegQueryValueEx, для которой надо указать корне

вой раздел HKEY_PERFORMANCE_DATA. Мало кто из программистов знает об этой базе данных, и причины тому кроются, на мой взгляд, в следующем.

Для нее не предусмотрено никаких специфических функций, нужно исполь зовать обычные функции реестра.

Ее нет в Windows 95 и Windows 98.

Структура информации в этой базе данных очень сложна; многие просто из бегают ею пользоваться (и другим не советуют).

Чтобы упростить работу с этой базой данных, Microsoft создала набор функций под общим названием Performance Data Helper (содержащийся в PDH.dll). Если Вас интересует более подробная информация о библиотеке PDH.dll, ищите раздел по функциям Performance Data Helper в документации Platform SDK

Как я уже упоминал, в Windows 95 и Windows 98 такой базы данных нет. Вместо них предусмотрен набор функций, позволяющих перечислять процессы. Они вклю чены в ToolHelp API За информацией о них я вновь отсылаю Вас к документации Platform SDK — ищите разделы по функциям Process32First и Process32Next,

Но самое смешное, что разработчики Windows NT, которым ToolHelp-функции явно не нравятся, не включили их в Windows NT. Для перечисления процессов они создали свой набор функций под общим названием Process Status (содержащийся в PSAPI.dll). Так что ищите в документации Platform SDK раздел по функции Enum Processes.

Microsoft, которая до сих пор, похоже, старалась усложнить жизнь разработчи кам инструментальных средств и утилит, все же включила ToolHelp-функции в Win dows 2000. Наконец-то и эти разработчики смогут унифицировать свой код хотя бы для Windows 95, Windows 98 и Windows 2000!

Передача данных через сообщения

Здесь мы обсудим, как система обеспечивает передачу данных между процессами с помощью сообщений В некоторых оконных сообщениях параметр lParam задает адрес блока памяти. Например, сообщение WM_SETTEXT использует lParam как ука затель на строку (с нулевым символом в конце), содержащую новый текст для окна. Рассмотрим такой вызов:

SendMessage(FindWindow{NULL, "Calculator"), WM_SETTEXT, 0, (LPARAM) "A Test Caption" );

Вроде бы все достаточно безобидно определяется описатель окна Calculator и делается попытка изменить его заголовок на "A Test Caption". Но приглядимся к тому, что тут происходит

В lParam передается адрес строки (с новым заголовком), расположенной в адрес ном пространстве Вашего процесса. Получив это сообщение, оконная процедура программы Calculator берет lParam и пытается манипулировать чем-то, что, "по ее мнению", является указателем на строку с новым заголовком.

По адрес в lParam указывает на строку в адресном пространстве Вашего процес са, а не программы Calculator Вот Вам и долгожданная неприятность — нарушение доступа к памяти. Но если Вы все же выполните показанную ранее строку, все будет работать нормально. Что за наваждение5

А дело в том, что система отслеживает сообщения WM_SETTEXT и обрабатывает их не так, как большинство других сообщений. При вызове SendMessage внутренний код функции проверяет, не пытаетесь ли Вы послать сообщение WM_SETTEXT. Если это так, функция копирует строку из Вашего адресного пространства в проекцию файла и делает его доступным другому процессу. Затем сообщение посылается пото ку другого процесса. Когда поток-приемник готов к обработке WM_SETTEXT, он оп ределяет адрес общей проекции файла (содержащей копию строки) в адресном про странстве своего процесса Параметру lParam присваивается значение именно этого адреса, и WM_SETTEXT направляется нужной оконной процедуре. После обработки этого сообщения, проекция файла уничтожается Не слишком ли тут накручено, а?

К счастью, большинство сообщений не требует такой обработки — она осуществ ляется, только если сообщение посылается другому процессу. (Заметьте: описанная обработка выполняется и для любого сообщения, параметры wParam или lParam ко торого содержат указатель на какую-либо структуру данных )

А вот другой случай, когда от системы требуется особая обработка, — сообщение WM_GETTEXT. Допустим, Ваша программа содержит код:

char szBuf[200];

SendMessage(FindWindow(NULL, "Calculator"), WM_GETTEXT, Sizeof(szBuf), (LPARAM) szBuf);

WM_GETTEXT требует, чтобы оконная процедура программы Calculator помести ла в буфер, на который указывает szBuf, заголовок своего окна. Когда Вы посылаете это сообщение окну другого процесса, система должна на самом деле послать два сообщения. Сначала — WM_GETTEXTLENGTH Оконная процедура возвращает число символов в строке заголовка окна. Это значение система использует при создании проекции файла, разделяемой двумя процессами,

Создав проекцию файла, система посылает для cro заполнения сообщение WM_GET TEXT Затем переключается обратно на процесс, первым вызвавший функцию SendMes-

sage, копирует данные из общей проекции файла в буфер, на который указывает szBuf, и заставляет SendMessage вернуть управление

Что ж, все хороши, пока Вы посылаете сообщения, известные системе А если мы определим собственное сообщение (WM_USER + x), собираясь отправить его окну другого процесса? Система не "поймет", что нам нужна общая проекция файла для корректировки указателей при их пересылке. Но выход есть — что сообщение WM_COPYDATA:

COPYDATASTRUCT cds;

SendMessage(hwndReceiver, WM_COPYDATA, (WPARAM) hwndSender, (LPARAM) &cds);

COPYDATASTRUCT — структура, определенная в WinUser.h:

typedef struct tagCOPYDATASTRUCT
{

ULONG_PTR dwData;
DWORD cbData;
PVOID lpData;

} COPYDATASTRUCT;

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

Элемент cbData задает число байтов, пересылаемых в другой процесс, a lpData указывает на первый байт данных Адрес, идентифицируемый элементом lpData, на ходится, конечно же, в адресном пространстве отправителя



Увидев, что Вы посылаете сообщение WM_COPYDATA, SendMessage создает проек цию файла размером cbData байтов и копирует данные из адресного пространства Вашей программы в эту проекцию. Затем отправляет сообщение окну-приемнику При обработке этого сообщения принимающей оконной процедурой параметр lParam указывает на структуру COPYDATASTRUCT, которая находится в адресном простран стве процесса-приемника Элемент lpData этой структуры указывает на проекцию файла в адресном пространстве процесса-приемника.

Вам следует помнить о трех важных вещах, связанных с сообщением WM_COPY DATA

Отправляйте его всегда синхронно, никогда не пытайтесь делать этого асинх ронно Последнее просто невозможно: как только принимающая оконная про цедура обработает сообщение, система должна освободить проекцию файла. При передаче WM_COPYDATA как асинхронного сообщения появится неопре деленность в том, когда оно будет обработано, и система не сможет освобо дить память, занятую проекцией файла.

На создание копии данных в адресном пространстве другого процесса неиз бежно уходит какое-то время Значит, пока SendMessage не вернст управление, нельзя допускать изменения содержимого общей проекции файла каким-либо другим потоком

Сообщение WM_COPYDATA позволяет 16-разрядным приложениям взаимо действовать с 32-разрядными (и наоборот), как впрочем и 32-разрядным — с 64-разрядными (и наоборот). Это удивительно просюй способ общения меж ду новыми и старыми приложениями. К тому же, WM_COPYDATA полностью поддерживается как в Windows 2000, так и в Windows 98 Но, если Вы все еще пишете 16-разрядные Windows-приложсния, учтите, что сообщение WM_COPY

DATA и структура COPYDATASTRUCT в Microsoft Visual С++ версии 1 52 не оп ределены Вам придется добавить их определения самостояельно.

// включите этот код в свою 16-разрядную Windows-программу
#define WM_COPYDATA 0x004A

typedef VOID FAR* PVOID;

typedef struct taqCOPYDATASTRUCT
{

DWORD dwData;
DWORD cbDdta;
PVOID lpData;

} COPYDATASTRUCT, FAR* PCOPYDATASTRUCT;

Сообщение WM_COPYDATA — мощный инструмент, позволяющий разработчикам экономить массу времени при решении проблем связи между процессами И очень жаль, что применяется оно нечасто Насколько полезно это сообщение, иллюстриру ет программа-пример LastMsgBoxInfo из главы 22

Передача памяти зарезервированному региону

Зарезервировав регион, Вы должны, прежде чем обращаться по содержащимся в нем адресам, передать ему физическую память Система выделяет региону физическую память из страничного файла на жестком диске При этом она, разумеется, учитывает свойственный данному процессору размер страниц и передает ресурсы постранично

Для передачи физической памяти вызовите VirtualAlloc еще раз, указав в параметpe fdwAllocationtype не MEM_RESERVE, a MEM_COMMIT. Обычно указывают тот же атрибут защиты, что и при резервировании региона, хотя можно задать и другой.

Затем сообщите функции VirtuaMlloc, по какому адресу и сколько физической памяти следует передать. Для этого в параметр pvAddress запишите желательный адрес, а в параметр dwSize — размер физической памяти в байтах. Передавать физическую память сразу всему региону необязательно.

Посмотрим, как это делается на практике. Допустим, программа работает на процессоре x86 и резервирует регион размером 512 Кб, начиная с адреса 5 242 880. Затем Вы передаете физическую память блоку размером 6 Кб, отстоящему от начала зарезервированного региона на 2 Кб. Тогда вызовите VirtualAlloc с флагом MEM_COMMIT так:

VirtualAlloc((PVOID) (5242880 + (2 * 1024)), 6 * 1024, MEM_COMMIT, PAGE_READWRITE);

В этом случае система передаст 8 Кб физической памяти в диапазоне адресов от 5 242 880 до 5 251 071 (т. e. 5 242 880 + 8 Кб - 1 байт), и обе переданные страницы получат атрибут защиты PAGE_READWRITE. Страница является минимальной единицей памяти, которой можно присвоить собственные атрибуты защиты. Следовательно, в регионе могут быть страницы с разными атрибутами защиты (скажем, одна - с атрибутом PAGE_READWRITE, другая — с атрибутом PAGE_READONLY).

Передача региону физической памяти

Чтобы зарезервированный регион адресного пространства можно было использовать, Вы должны выделить физическую память и спроецировать cc на этот регион. Такая операция называется передачей физической памяти (committing physical storage) Чтобы передать физическую память зарезервированному региону, Вы обращаетесь все к той жс функции VirtualAlloc

Передавая физическую память регионам, нет нужды отводить ее целому региот Можно, скажем, зарезервировать регион размером 64 Кб и нередать физическую па мять только его второй и четвертой страницам Парие. 13-1 представлен пример того, как может выглядеть адресное пространство процесса Как видите, структура адресного пространства зависит oт архитектуры процессора. Слева показано, чтo происходит с адресным пространством на процессоре x86 (страницы по 4 Кб), а справа — 1 на процессоре Alpha (страницы по 8 Кб)

Когда физическая память, переданная зарезервированному региону, больше не нужна, ее освобождают. Эта операция — возврат физической памяти (decommitting physical storage) — выполняется вызовом функции VirtualFree

Перехват API-вызовов подменой кода

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

Найдите адрес функции, вызов которой Вы хотите перехватывать (например, ExitProcess в Kernel32.dll). Сохраните несколько первых байтов этой функции в другом участке памяти. На их место вставьте машинную команду JUMP для перехода по адресу подставной функции Естественно, сигнатура Вашей функции должна быть такой жс, как и исходной, т. e все параметры, возвращаемое значение и правила вызова должны совпадать. Теперь, когда поток вызовет перехватываемую функцию, команда JUMP перенаправит его к Вашей функции На этом зтапе Вы можете выполнить любой нужный код. Снимите ловушку, восстановив ранее сохраненные (в п. 2) байты. Если теперь вызвать перехватываемую функцию (таковой больше не являющуюся), она будет работать так, как работала до установки ловушки. После того как она вернет управление, Вы можете выполнить операции 2 и 3 и тем самым вновь поставить ловушку на эту функцию.

Этот метод был очень популярен среди программистов, создававших приложения для 16-разрядной Windows, и отлично работал в этой системе В современных системах у этого метода возникло несколько серьезных недостатков, и я настоятельно не рекомендую его применять. Во-первых, он создает зависимость от конкретного процессора из-за команды JUMP, и, кроме того, приходится вручную писать машинные коды. Во-вторых, в системе с вытесняющей многозадачностью данный метод вообще не годится. На замену кода в начале функции уходит какое-то время, а в этот момент перехватываемая функция может понадобиться другому потоку. Результаты могут быть просто катастрофическими!

WINSOWS 98
В Windows 98 основные системные DLL (Kernel32, AdvAPI32, User32 и GDI32) защищены так, что приложение не может что-либо изменить на их страницах кода. Это ограничение можно обойти, только написав специальный драйвер виртуального устройства (VxD).

Перехват API-вызовов: пример

Внедрение DLL в адресное пространство процесса — замечательный способ узнать, что происходит в этом процессе. Однако простое внедрение DLL не дает достаточной информации, Зачастую надо точно знать, как потоки определенного процесса вызывают различные функции, а иногда и изменять поведение той или иной Windowsфункции.

Мне известна одна компания, которая выпустила DLL для своего приложения, работающего с базой данных. Эта DLL должна была расширить возможности основного продукта. При закрытии приложения DLL получала уведомление DLL_PROCESS_DETACH и только после этого проводила очистку ресурсов. При этом DLL должна была вызывать функции из других DLL для закрытия сокетов, файлов и других ресурсов, по к тому моменту другие DLL тоже получали уведомление DLL_PROCESS_DETACH, так что корректно завершить работу никак не удавалось.

Для решения этой проблемы компания наняла меня, и я предложил поставить ловушку на функцию ExitProcess. Как Вам известно, вызов ExitProcess заставляет систему посылать библиотекам уведомление DLL_PROCESS_DETACH, Перехватывая вызов ExitProcess, мы гарантируем своевременное уведомление внедренной DLL о вызове этой функции. Причем уведомление приходит до того, как аналогичные уведомления посылаются другим DLL. В этот момент внедренная DLL узнает о завершении процесса и успевает провести корректную очистку. Далее вызывается функция ExitProcess, что приводит к рассылке уведомлений DLL_PROCESS_DETACH остальным DLL, и они корректно завершаются. Это же уведомление получает и внедренная DLL, но ничего особенного она не делает, так как уже выполнила свою задачу.

В этом примере внедрение DLL происходило как бы само по себе, приложение было рассчитано на загрузку именно этой DLL, Оказываясь в адресном пространстве процесса, DLL должна была просканировать ЕХЕ-модуль и все загружаемые DLL-модули, найти все обращения ExitProcess и заменить их вызовами функции, находящейся во внедренной DLL. (Эта задача не так сложна, как кажется.) Подставная функция (функция ловушки), закончив свою работу, вызывала настоящую функцию ExitProcess из Kernel32.dll.

Данный пример иллюстрирует типичное применение перехвата API-вызовов, который позволил решить насущную проблему при минимуме дополнительного кода.

Перехват API-вызовов с использованием раздела импорта

Данный способ API-пeрeхвата рeшает обе упомянутые мной проблемы, Он прост и довольно надежен Но для его понимания нужно иметь представление о том, как осуществляется динамическое связывание. В частности, Вы должны разбираться в структуре раздела импорта модуля. В главе 19 я достаточно подробно объяснил, как создается этот раздел и что в нем находится. Читая последующий материал, Вы всегда можете вернуться к этой главе.

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

Поэтому, чтобы перехватить определенную функцию, надо лишь изменить ее адрес в разделе импорта. Все! И никакой зависимости от процессорной платформы. А поскольку Вы ничего не меняете в коде функции, то и о синхронизации потоков можно не беспокоиться.

Вот функция, которая делает эту сказку былью. Она ищет в разделе импорта модуля ссылку на идентификатор по определенному адресу и, найдя ее, подменяет адрес соответствующего идентификатора.

void ReplaceIATEntryInOneMod(PCSTR pszCalleeModName, PROC pfnCurrent, PROC pfnNew, HMODULE hmodCaller)
{

ULONG ulSize;

PIMAGE_IMPORT_DESCRIPTOR pImportDesc = (PIMAGE_IMPORT_DESCRIPTOR) ImageDirectoryEntryToData(hmodCallor, TRUE,IMAGE_DIRECTORY_ENTRY_IMPORT, &ulSize);

if (pImportDesc == NULL)

return,; // в этом модуле нет раздела импорта

// находим дескриптор раздела импорм со ссылками
// на функции DLL (вызываемого модуля)
for (; pImportDesc->Name; pImportDesc++)
{

PSTR pszModName = (PSiR) ((PBYFE) hmodCaller + pImportDcsc->Name);

if (lstrcmpiA(pszModName, pszCalleeModName) == 0)

break;

}

if (pImportDesc->Name == 0)

// этот модуль не импортирует никаких функций из данной DLL return;

// получаем таблицу адресов импорта (IAT) для функций DLL PIMAGE_THUNK_DATA pThunk = (PIMAGE_THUNK_DATA) ((PBYTE} hirodCaller + pImportDesc->FirstThunk);

// заменяем адреса исходных функций адресами своих функций
for (; pThunk->u1.Function; pThunk++)
{

// получаем адрес адреса функции
PROC* ppfn = (PROC*) &pThunk->u1.Function;

// та ли это функция, которая нас итересует?
BOOL fFound = (*ppfn == pfnCurrent);

// см. текст программы-примера, в котором
// содержится трюковый код для Windows 98

if (fFound)
{

// адреса сходятся, изменяем адрес в разделе импорта
WriteProcessMemory(GetCurrentProcess(), ppfn, &pfnNew, sizeof(pfnNew), NULL );

return; // получилось, выходим

}

}

// если мы попали сюда, значит, в разделе импорта
// нет ссылки на нужную функцию

}

Чтобы понять, как вызывать эту функцию, представьте, что у нас есть модуль с именем DataBase.exe. Он вызывает ExitProcess из Kernel32.dll, но мы хотим, чтобы он обращался к MyExitProcess в нашем модуле DBExtend.dll, Для этого надо вызвать ReplaceMTEntryInOneMod следующим образом.

PROC pfnOrig = GctProcAddress(GetModuleHandle("Kernel32"), "ExitProcess");
HMODULE hmodCaller = GetModuleHandle("DataBase.exe");



void RoplaceIATEntryInOrioMod(
"Kernel32.dll", // модуль, содержащий ANSI-функцию
pfnOrig, // адрес исходной функции в вызываемой DLL
MyExitProcess, // адрес заменяющей функции
hmodCaller); // описатель модули, из которого надо вызывать новую функцию

Первое, что делает ReplacelATEntryInOneMod, - находит в модуле hmodCalIer раздел импорта. Для этого она вызывает ImageDirectoryEntryToData и передает ей IMAGE_ DlRECTORY_ENTRY_IMPORT. Если последняя функция возвращает NULL, значит, в модуле DataBase.exe такого раздела нет, и на этом все заканчивается

Если же в DataBase.exe раздел импорта присутствует, то ImageDirectoryEntryToData возвращает его адрес как укачатель типа PIMAGE_IMPORT_DESCRIPTOR. Тогда мы должны искать в разделе импорта DLL, содержащую требуемую импортируемую функцию В данном примере мы ищем идентификаторы, импортируемые из Kernel32.dll (имя которой указывается в первом параметре ReplacelATEntryInOneMod), В цикле for сканируются имена DLL.


Заметьте, что в разделах импорта все строки имеют формат ANSI (Unicode не применяется). Вот почему я вызываю функцию lstrcmpiA, а не макрос lstrcmpi.

Если программа не найдет никаких ссылок на идентификаторы в Kernel32 dll, то и в этом случае функция просто вернет управление и ничего делать не станет. А если такие ссылки есть, мы получим адрес массива структур IMAGE_THUNK_DATA, в котором содержится информация об импортируемых идентификаторах. Далее в списке из KerneI32.dll ведется поиск идентификатора с адресом, совпадающим с искомым. В данном случае мы ищем адрес, соответствующий адресу функции ExitProcess.

Если такого адреса нет, значит, данный модуль не импортирует нужный идентификатор, и ReplaceLWEntryInOneMod просто возвращает управление. Но если адрес обнаруживается, мы вызываем WriteProcessMemory, чтобы заменить его на адрес подставной функции Я применяю WriteProcessMemory, а не InterlockedExchangePomter, потому что она изменяет байты, не обращая внимания на тип защиты страницы памяти, в которой эти байты находятся Так, если страница имеет атрибут защиты PAGE_READONLY, вызов InterlockedExchangePointer приведет к нарушению доступа, а WriteProcessMemory сама модифицирует атрибуты защиты и без проблем выполнит свою задачу.

С этого момента любой поток, выполняющий код в модуле DataBase.exe, при обращении к ExitProcess будет вызывать нашу функцию. А из нее мы сможем легко получить адрес исходной функции ExitProcess в Kernel32.dll и при необходимости вызвать ее,

Обратите внимание, что ReplaceIATEntryInOneMod подменяет вызовы функций только в одном модуле. Если в его адресном пространстве присутствует другая DLL, использующая ExitProcess, она будет вызывать именно ExitProcess из Kernel32.dll.

Если Вы хотите перехватывать обращения к ExitProcess из всех модулей, Вам придстся вызывать ReplacelATEntryInOneMod для каждого модуля в адресном пространстве процесса. Я, кстати, написал еще одну функцию, ReplacelATEntryInAllMods. С помощыо Toolhelp-функций она перечисляет все модули, загруженные в адресное пространство процесса, и для каждого из них вызывает ReplatelATEritryInOneMod, передавая в качестве последнего параметра описатель соответствующего модуля.



Но и в этом случае могут быть проблемы Например, что получится, если после вызова ReplacelATEntrylnAlMods какой-нибудь поток вызовет LoadLibrary для загрузки

новой DLL? Если в только что загруженной DLL имеются вызовы ExitProcess, она будет обращаться не к Вашей функции, а к исходной. Для решения этой проблемы Вы должны перехватывать функции LoadLtbraryA, LoadLibraiyW, LoаdLibraryExA и LoadLibraryExW и вызывать Rер1асеlAТЕпtrу1пОпеMod для каждого загружаемого модуля.

И, наконец, есть еще одна проблема, связанная с GetProcAddress. Допустим, поток выполняет такой код

typedef int (WINAPI *PFNEXITPROCESS)(UINT uExitCode);
PFNEXITPROCESS pfnExitProcess = (PFNEXITPROCESS) GetProcAddress( GetModuleHandle("Kernel32"), "ExitProcess");
pfnExitProcess(0);

Этот код сообщает системе, что надо получить истинный адрес ExitProcess в Kernel32.dll, а затем сделать вызов по этому адресу. Данный код будет выполнен в обход Вашей подставной функции. Проблема решается перехватом обращений к GetProcAddress При cc вызове Вы должны возвращать адрес своей функции

В следующем разделе я покажу, как на практике реализовать перехват API-вызовов и решить все проблемы, связанные с использованием LoadLibrary и GetProcAddress.

Перехват структурных исключений в С++

Обычно механизм обработки исключений в С++ не позволяет приложению восста новиться после таких серьезных исключений, как нарушение доступа или деление на нуль. Однако Microsoft добавила поддержку соответствующей функциональности в свой компилятор. Так, следующий код предотвратит аварийное завершение процесса.

void main()
{

try
{

* (PBYTE) 0 = 0; // нарушение доступа

}

catch ( ..)
{

// этот код обрабатывает исключения, связанные с нарушением доступа

}

// процесс завершается корректно

}

И это прекрасно, так как приложение может корректно справляться с серьезны ми исключениями. Но было бы еще лучше, если бы блок catch как-то различал коды исключений — чтобы мы могли писать, например, такой исходный код

void Functastic()
{

try
{

* (PBYTE) 0 = 0; // нарушение доступа

int x = 0;

x = 5 / x; // деление на нуль

}

catch (StructuredFxception)
{

switch (StructuredExceptionCode)
{

case EXCEPTION_ACCESS_VIOLATION:

// здесь обрабатывается нарушение доступа
break;

case EXCEPTION_INT_OIVIDE_BY_ZERO:

// здесь обрабатывается деление на нуль
break;

default:

// другие исключения мы не обрабатываем throw;
// может, какой-нибудь другой блок catch
// обработает это исключение

break;

// никогда не выполняется

}

}

}

Так вот, хочу Вас порадовать. В Visual С++ теперь возможно и такое. От Вас потре буется создать С++-класс, используемый специально для идентификации структурных исключений. Например:

#include <eh.h> // для доступа к _set_se_translator

...

class CSE
{

public:

// вызовите эту функцию для каждого потока

static void MapSEtoCE() { _set_se_translator(TranslateSEtoCE); }

operator DWORD() { return(m_er.ExcepUonCude); }

privale:

CSE(PEXCEPTION_POINTERS pep)
{

m_er = *pep->ExceptionRecord;
m_context = *pep->ContextRecord;

}

static void _cdecl TranslateSEtoCE(UINT dwEC, PEXCEPTION_POINTERS pep)
{

throw CSE(pep);

}

private:

EXCEPTION_RECORD m_er;
// машинно-независимая информация ofi исключении

CONTEXT m_context;
// машинно-зависимая информация об исключении

};

Внутри входных функций потоков вызывайте статическую функцию-член Map SEtoCE. В свою очередь она обращается к библиотечной С-функции _set_sefranslator, передавая ей адрес функции TranslateSEtoCE класса CSE. Вызов _set_se_translator сооб щает С++, что при возбуждении структурных исключений Вы хотите вызывать Trans lateSEtoCE. Эта функция вызывает конструктор CSE-объектя и инициализирует два элемента данных машинно-зависимой и машинно-независимой информацией об исключении. Созданный таким образом CSE-объскт может быть вытолкнут ак же, как и любая другая переменная. И теперь Ваш С++-код способен обрабатывать структур ные исключения, захватывая (catching) переменную этого типа.

Вот пример захвата такого С++-объекта.

void Functastic()
{

CSE::MapSEtoCE(); // должна быть вызвана до возникновения исключений

try
{

* (PBYTE) 0 = 0; // нарушение доступа

int x = 0;

x = 5 / x; // деление на нуль

}

catch (CSE se)
{

switch (se)
{

// вызывает функцию-член оператора DWORD()

case EXCEPTION_ACCESS_VIOLATION

// здесь обрабатывается исключение вызванное нарушением доступа
break;

case EXCEPTION_INT_DIVIDE_BY_ZERO

// здесь обрабатывается исключение, вызванное делением на нуль
break;

default:

// другие исключения мы не обрабатываем throw;
// может, какой-нибудь другой блок catch
// обработает это исключение
break;

// никогда не выполняется

}

}

}

Переключение потоков

Функция SwitchToThreadпозволяет подключить к процессору другой поток (если он есть):

BOOL SwitchToThread();

Когда Вы вызываете эту функцию, система проверяет, есть ли поток, которому не хватает процессорного времени. Если нет, SwitchToThread немедленно возвращает управление, а если да, планировщик отдает ему дополнительный квант времени (приоритет этого потока может быть ниже, чем у вызывающего). По истечении , этого кванта планировщик возвращается в обычный режим работы.

SwitchToThreadпозволяет потоку, которому не хватает процессорного времени, отнять этот ресурс у потока с более низким приоритетом. Она возвращает FALSE, если на момент ее вызова в системе нет ни одного потока, готового к исполнению, в ином случае — ненулевое значение.

Вызов SwitchToThread аналогичен вызову Sleep с передачей в dwMilliseconds нулевого значения. Разница лишь в том, что SwitchToThread дает возможность выполнять потоки с более низким приоритетом, которым не хвачает процессорного времени, а Sleep действует без оглядки на "голодающие" потоки.

WIDOWS 98
В Windows 98 функция SwitchToThread лишь определена, но не реализована

Перекодировка строк из Unicode в ANSI и обратно

Windows-функция MultiByteToWideChar преобразует мультибайтовые символы строки в широкобайтовые:

int MultiBytoToWideChar(
UINT uCodePage,
DWORD dwFlags,
PCSTR pMultiByteStr,
int cchMultiByte,
PWSTR pWideCharStr,
int cchWideChar);

Параметр uCodePage задает номер кодовой страницы, связанной с мультибайтовой строкой. Параметр dwFlags влияет на преобразование букв с диакритическими знаками. Обычно эти флаги не используются, и dwFlags равен 0. Параметр pMultiByteStr указывает на преобразуемую строку, a cchMultiByte определяет ее длину в байтах Функция самостоятельно определяет длину строки, если cchMultiByte равен -1.

Unicode-версия строки, полученная в результате преобразования, записывается в буфер по адресу, указанному в pWideCharStr. Максимальный размер этого буфера (в символах) задается в параметре cchWideCbar. Если он равен 0, функция ничего не преобразует, а просто возвращает размер буфера, необходимого для сохранения результата преобразования. Обычно конверсия мультибайтовой строки в ее Unicode-эквивалент проходит так:

1. Вызывают MultiByteToWideChar, передавая NULL в параметре pWideCharStr и 0 в параметре cchWideChar.

2. Выделяют блок памяти, достаточный для сохранения преобразованной строки. Его размер получают из предыдущего вызова MultiByteToWideChar.

3. Снова вызывают MultiByteToWideChar, на этот раз передавая адрес выделенно го буфера в параметре pWideCharStr, а размер буфера, полученный при первом обращении к этой функции, — в параметре cchWideChar.

4. Работают с полученной строкой.

5. Освобождают блок памяти, занятый Unicode-строкой.

Обратное преобразование выполняет функция WideCharToMultiByte

int WideCharToMultiByte(
UINT uCodePage,
DWORD dwFlags,
PCWSTR pWideCharStr,
int cchWideChar,
PSTR pMultiByteStr,
int cchMultiByte,
PCSTR pDefaultChar,
PBOOL pfUsedDefaultChar);

Она очень похожа на MultiByteToWideChar. И опять uCodePage определяет кодовую страницу для строки — результата преобразования Дополнительный контроль над процессом преобразования дает параметр dwFlags.
Его флаги влияют на символы с диакритическими знаками и на символы, которые система не может преобразовать. Такой уровень контроля обычно не нужен, и dwFlags приравнивается 0.

Пapaметр pWideCharStr указывает адрес преобразуемой строки, a cchWideChar задает ее длину в символах. Функция сама определяет длину исходной строки, если cchWideChar равен -1.

Мультибайтовый вариант строки, полученный в результате преобразования, записывается в буфер, на который указывает pMultiByteStr, Параметр cchMultiByte определяет максимальный размер этого буфера в байтах Передав нулевое значение в ccbMultiByte, Вы заставите функцию сообщить размер буфера, требуемого для записи результата. Обычно конверсия широкобайтовой строки в мультибайтовую проходит в той же последовательности, что и при обратном преобразовании.

Очевидно, Вы заметили, что WideCharToMultiByte принимает на два параметра больше, чем MultiByteToWideCbar, это pDefauItChar pfUsedDefaultChar. Функция WideCharToMultiByte использует их, только если встречает широкий символ, не представленный в кодовой странице, на которую ссылается uCodePage Если его преобразование невозможно, функция берет символ, на который указывает pDefaultChar. Если этот параметр равен NULL (как обычно и бывает), функция использует системный символ по умолчанию. Таким символом обычно служит знак вопроса, что при операциях с именами файлов очень опасно, поскольку он является и символом подстановки.

Параметр pfUsedDefaultChar указывает на переменную типа BOOL, которую функция устанавливает как TRUE, если хоть один символ из широкосимвольной строки не преобразован в свой мультибайтовый эквивалент. Если же все символы преобразованы успешно, функция устанавливает переменную как FALSE. Обычно Вы передаете NULL в этом параметре.

Подробнее эти функции и их применение описаны в документации Platform SDK.

Эти две функции позволяют легко создавать ANSI- и Unicode-версии других функций, работающих со строками. Например, у Вас есть DLL, содержащая функцию, которая переставляет все символы строки в обратном порядке Unicode-версию этой функции можно было бы написать следующим образом.



BOOL StringReverseW(PWSTR pWidoCharStr) {
// получаем указатель на последний символ в строке
PWSTR pEndOfStr = pWideCharStr + wcslen(pWideCharStr) - 1;

wchar_t cCharT;

// повторяем, пока не дойдем до середины строки
while (pWideCharStr < pEndOfStr) {
// записываем символ во временную переменную
cCharT = *pWideCharStr;

// помещаем последний символ на место первого
*pWideCharStr = *pEndOfStr;

// копируем символ из временной переменной на место последнего символа
*pEndOfStr = cCharT;

// продвигаемся на 1 символ вправо
pWideCharStr++ж

// продвигаемся на 1 символ влево
pEndOfStr--;
}

// строка обращена; сообщаем об успешном завершении
return(TRUE);
}

ANSI-версию этой функции можно написать так, чтобы она вообще ничем не занималась, а просто преобразовывала ANSI-строку в Unicode, передавала ее в функцию StringReverseW и конвертировала обращенную строку снова в ANSI. Тогда функция должна выглядеть примерно так:

BOOL StringReverseA(PSTR pMultiByteStr) {
PWSTR pWideCharStr;
int nLenOfWideCharStr;
BOOL fOk = FALSE;

// вычисляем количество символов, необходимых
// для хранения широкосимвольной версии строки
nLenOfWideCharStr = MultiRyteToWideChar(CP_ACP, 0,
pMultiByteStr, -1, NULL, 0);

// Выделяем память из стандартной кучи процесса,
// достаточную для хранения широкосимвольной строки,
// Не забудьте, что MultiByteToWideChar возвращает
// количество символов, а не байтов, поэтому мы должны
// умножить это число на размер широкого символа.
pWideCharStr = HeapAlloc(GetProcessHeap(), 0, nLenOfWideCharStr * sizeof(WCHAR));

if (pWideCharStr == NULL)
return(fOk);

// преобразуем нультибайтовую строку в широкосимвольную
MultiByteToWideChar(CP_ACP, 0, pMulti8yteStr, -1, pWideCharStr, nLenOfWideCharStr);

// вызываем широкосимвольную версию этой функции для выполнения настоящей работы
fOk = StnngReverseW(pWideCharStr);

if (fOk} {
// преобразуем широкосимвольную строку обратно в мультибайтовую
WideCharToMultiByte(CP_ACP, 0, pWideCharStr, -1, pMultiByteStr, strlen(pMultiByteStr), NULL, NULL);
}

// освобождаем память, выделенную под широкобайтовую строку
HeapFree(GetProcessHeap(), 0, pWideCharStr);

return(fOk),
}

И, наконец, в заголовочном файле, поставляемом вместе с DLL, прототипы этих функций были бы такими:

BOOL StringReverseW (PWSTR pWideCharStr);
BOOL StringReverseA (PSTR pMultiByteStr);

#ifdef UNICODE
#define StnngReverse StringReverseW
#else
#define StringRevcrsc StringReverseA
#endif // UNICODE

Переменные окружения

С любым процессом связан блок переменных окружения — область памяти, выделен ная в адресном пространстве процесса Каждый блок содержит группу строк такого вида

VarName1-VarValue1\0 VarName2-VarValue2\0 VarName3=VarValue3\0
...
VarNameX=VarValueX\0

\0

Первая часть каждой строки — имя переменной окружения. Зa ним следует знак равенства и значение, присваиваемое переменной Строки в блоке переменных ок ружения должны бьпь отсортированы в алфавитном порядке по именам переменных

Знак равенства разделяет имя переменной и ее значение, так что его нельзя ис пользовать как символ в имени переменной Важную роль играют и пробелы Например, объявив две переменные

XYZ= Windows (обратите внимание на пробел за знаком равенства) ABC=Windows

и сравнив значения переменных ХУZ и АВС, Вы увидите, что система их различает, — она учитывает любой пробел, поставленный перед знаком равенства или после него Вот что будет, если записать, скажем, так

XYZ =Home (обратите внимание на пробел перед знаком равенства) XYZ=Work

Вы получите первую переменную с именем "XYZ", содержащую строку "Home", и вторую переменную "XYZ", содержащую строку "Work"

Конец блока переменных окружения помечается дополнительным нулевым сим волом

WINDOWS 98
Чтобы создать исходный набор переменных окружения для Windows 98, надо модифицировать файл Autoexec bat, поместив в него группу строк SET в виде

SET VarName=VarValue

При перезагрузке система учтет новое содержимое файла Autoexecbat, и тогда любые заданные Вами переменные окружения станут доступны всем процессам, инициируемым в сеансе работы с Windows 98

WINDOWS 2000
При регистрации пользователя на входе в Windows 2000 система создает npo цесс-оболочку, связывая с ним группу строк — переменных окружения. Систе ма получает начальные значения этих строк, анализируя два раздела в рссст pe. В первом:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ SessionManager\Environment

содержится список переменных окружения, относящихся к системе, а во втором:

HKEY_CURRENT_USER\Environment

находится список переменных окружения, относящихся к пользователю, ко торый в настоящее время зарегистрирован в системе.

Пользователь может добавлять, удалять или изменять любые переменные через апплет System из Control Panel B этом апплете надо открыть вкладку Advanced и щелкнуть кнопку Environment Variables — тогда на экране появит ся следующее диалоговое окно.



Модифицировать переменные из списка System Variables разрешается толь ко пользователю с правами администратора.

Кроме того, для модификации записей в реестре Ваша программа может обращаться к Windows-функциям, позволяющим манипулировать с реестром. Однако, чтобы изменения вступили в силу, пользователь должен выйти из си стемы и вновь войти в нее. Некоторые приложения типа Explorer, Task Manager или Control Pancl могут обновлять свои блоки переменных окружения на базе новых значений в реестре, когда их главные окна получают сообщение WM_SET TINGCHANGE, Например, если Вы, изменив реестр, хотите, чтобы какие-то приложения соответственно обновили свои блоки переменных окружения, вызовите

SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE 0, (LPARAM) TEXT("Envnuntnent"))

Обычно дочерний процесс наследует набор переменных окружения от родитель ского Однако последний способен управлячь чем, какие переменные окружения на следуются дочерним процессом, а какие — нет. Но об этом я расскажу, когда мы зай

мемся функцией CreateProcess. Под наследованием я имею в виду, что дочерний про цесс получает свою копию блока переменных окружения от родительского, а не то, что дочерний и родительский процессы совместно используют один и тот же блок, Так что дочерний процесс может добавлять, удалять или модифицировать перемен ные в своем блоке, и эти изменения не затронут блок, принадлежащий родительско му процессу.

Переменные окружения обычно применяются для тонкой настройки приложения. Пользователь создает и инициализирует переменную окружения, затем запускает приложение, и оно, обнаружив эту переменную, проверяет ее значение и соответству ющим образом настраивается.



Увы, многим пользователям не под силу разобраться в переменных окружения, а значит, трудно указать правильные значения. Ведь для этого надо не только хорошо знать синтаксис переменных, но и, конечно, понимать, что стоит за теми или иными их значениями. С другой стороны, почти все (а может, и все) приложения, основан ные на GUI, дают возможность тонкой настройки через диалоговые окна. Такой под ход, естественно, нагляднее и проще.

А теперь, если у Вас еще не пропало жсланис манипулировать переменными ок ружения, поговорим о предназначенных для этой цели функциях. GetEnvironment Variable позволяет выявлять присутствие той или иной переменной окружения и определять ее значение:

DWORD GetEnvironmentVariable( PCTSTR pszName, PTSTR pszValue, DWORD cchValue);

При вызове GetEnvironmentVariable параметр pszName должен указывать на имя интересующей Вас переменной, pszValue — на буфер, в который будет помещено зна чение переменной, а в cchValue следует сообщить размер буфера в символах. Функ ция возвращает либо количество символов, скопированных в буфер, либо 0, если ей не удалось обнаружить переменную окружения с таким именем.

Кстати, в реестре многие строки содержат подставляемые части, например.

%USERPROFILE%\My Documents

Часть, заключенная в знаки процента, является подставляемой. В данном случае в строку должно быть подставлено значение неременной окружения USERPROFILE На моей машине эта переменная выглядит так:

C:\Documents and Settings\Administrator

После подстановки переменной в строку реестра получим

C:\Documents and Settings\Admimstrator\My Documents

Поскольку такие подстановки делаются очень часто, в Windows есть функция ExpandEnvironmentStrings.

DWORD ExpandEnvironmentStrings( PCTSTR pszSrc, PTSTR pszDst, DWORD nSize);

Параметр pszSrc принимает адрес строки, содержащей подставляемые части, а пареметр pszDsf — адрес буфера, в который записывается развернутая строка Пара метр nSize определяет максимальный размер буфера в символах.

Наконец, функция SetEnvironmentVariable позволяет добавлять, удалять и модифи цировать значение переменной

DWORD SetEnvironmentVariable(
PCTSTR pszName,
PCTSTR pszValue);

Она устанавливает ту переменную, на чье имя указывает параметр pszName, и присваивает ей значение, заданное параметром pszValue. Если такая переменная уже существует, функция модифицирует ее значение. Если же spszValue содержится NULL, переменная удаляется из блока

Для манипуляций с блоком переменных окружения всегда используйте именно эти функции. Как я уже говорил, строки в блоке переменных нужно отсортировать в ал фавитном порядке по именам псрсмснных (тогда GetEnvironmentVariable быстрее находит нужные переменные), a SetEnvironmentVariable как раз и следит за порядком расположения переменных.

Перенаправление DLL

WINDOWS 98
Windows 98 не поддерживает перенаправление DLL.

Когда разрабатывались первые версии Windows, оперативная намять и дисковое пространство были крайне дефицитным ресурсом, так что Windows была рассчитана на предельно экономное их использование — с максимальным разделением между потребителями. В связи с этим Microsoft рекомендовала размещать все модули, используемые многими приложениями (например, библиотеку С/С++ и DLL, относящиеся к MFC) в системном каталоге Windows, где их можно было легко найти.

Однако со временем это вылилось в серьезную проблему: программы установки приложений то и дело перезаписывали новые системные файлы старыми или не полностью совместимыми. Из-за этого уже установленные приложения переставали работать. Но сегодня жесткие диски стали очень емкими и недорогими, оперативная память тоже значительно подешевела. Поэтому Microsoft сменила свою позицию на прямо противоположную; теперь она настоятельно рекомендует размещать все фаЙлы приложения в своем каталоге и ничего не трогать в системном каталоге Windows. Тогда Вашс приложение не нарушит работу других программ, и наоборот.

С той же целью Microsoft ввела в Windows 2000 поддержку перенаправления DLL (DLL redirection). Она заставляет загрузчик операционной системы загружав модули сначала из каталога Вашего приложения и, только если их там нет, искать в других каталогах

Чтобы загрузчик всегда проверял сначала каталог приложения, нужно всего лишь поместить туда специальный файл Его содержимое не имеет значения и игнорируется — вяжно только его имя: оно должно быть в виде AppName.local. Так, если исполняемый файл Вашего приложения — SupcrAppexe, присвойте перенаправляющему файлу имя SuperApp cxc local

Функция LoadLibrary(Ex) проверяет наличие этого файла и, ссли он есть, загружает молуль из каталога приложения; в ином случае LoadLibrary(Ex) работает так же, как и раньше.

Перенаправление DLL исключительно полезно для работы с зарегистрированными СОМ-объектами. Оно позволяет приложению размещать DLL с СОМ-объектами в своем каталоге, и другие программы, регистрирующие те же объекты, не будут мешать его нормальной работе.

Побочные эффекты успешного ожидания

Успешный вызов WaitForSingleObject или WaitForMultipleObjecls на самом деле меняет состояние некоторых объектов ядра. Под успешным вызовом я имею в виду тот, при котором функция видит, что объект освободился, и возвращает значение, относитель ное WAITOBJECT_0. Вызов считается неудачным, если возвращается WAIT_TIMEOUT или WAIT_FAILED. В последнем случае состояние каких-либо объектов не меняется.

Изменение состояния объекта в результате вызова я называю побочным эффек, том успешного ожидания (successful wait side effect). Например, поток ждет объест "событие с автосбросом" (auto-reset event objcct) (об этих объектах я расскажу чуть позжс) Когда объект переходит в свободное состояние, функция обнаруживает это и может вернуть вызывающему потоку значение WAIT_OBJECT_0. Однако перед самым возвратом из функции событие переводится в занятое состояние — здесь сказывает ся побочный эффект успешного ожидания.

Объекты ядра "событие с автосбросом" ведут себя подобным образом, потому что таково одно из правил, определенных Microsoft для объектов этого типа. Другие объек ты дают иные побочные зффекты, а некоторые — вообще никаких К последним от носятся объекты ядра "процесс" и "поток", так что поток, ожидающий один из этих объектов, никогда не изменит его состояние. Подробнее о том, как ведут себя объек ты ядра, я буду рассказывать при рассмотрении соответствующих объектов.

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

Возьмем такой пример. Два потока вызывают WaitForMultipleObjects совершенно одинаково.

HANDLE h[2];

h[0] = hAutoResetEvent1;

// изначально занят
h[1] = hAutoResetEvent2;

// изначально занят
WaitForMulUpleObjects(2, И, TRUE, INFINITE);

На момент вызова WaitForMultipleObjects эти объекты-события заняты, и оба пото ка переходят в режим ожидания Но вот освобождается объект hAutoResetEventl Это становится известным обоим потокам, однако ни один из них не пробуждается, так как объект hAutoResetEvent2 по-прежнему занят.
Поскольку потоки все еще ждут, ни какого побочного эффекта для объекта hAutoResetEvent1 не возникает.

Наконец освобождается и объект hAutoResetEvent2 В этот момент один из пото ков обнаруживает, что освободились оба объекта, которых он ждал. Его ожидание успешно завершается, оба объекта снова переводятся в занятое состояние, и выпол нение потока возобновляется. А что же происходит со вторым потоком? Он продол жает ждать и будет делать это, пока вновь не освободятся оба объекта-события.

Как я уже упоминал, WaitForMiltipleObjects работает на уровне атомарного досту па, и это очень важно. Когда она проверяет состояние объектов ядра, никто не может "у нее за спиной" изменить состояние одного из этих объектов. Благодаря этому ис ключаются ситуации со взаимной блокировкой. Только представьте, что получится, если один из потоков, обнаружив освобождение hAutoResetEventl, сбросит его в заня тое состояние, а другой поток, узнав об освобождении hAutoResetEvent2, тоже переве дет его в занятое состояние. Оба потока просто зависнут, первый будет ждать осво бождения объекта, захваченного вторым потоком, а второй — освобождения объек та, захваченного первым. WaitForMultipleObjects гарантирует, что такого не случится никогда.

Тут возникает интересный вопрос. Если несколько потоков ждет один объект ядра, какой из них пробудится при освобождении этого объекта? Официально Microsoft отвечает на этот вопрос так: "Алгоритм действует честно" Что это за алгоритм, Micro soft не говорит, потому что нс хочст связывать себя обязательствами всегда придер живаться именно этого алгоритма. Она утверждает лишь одно- если объект ожидает ся несколькими потоками, то всякий раз, когда этот объект переходит в свободное состояние, каждый из них получает шанс на пробуждение.

Таким образом, приоритет потока не имеет значения- поток с самым высоким приоритетом не обязательно первым захватит объект. Не получает преимущества и поток, который ждал дольше всех. Есть даже вероятность, что какой-то поток сумеет повторно захватить объект.


Конечно, это было бы нечестно по отношению к другим потокам, и алгоритм пытается не допустить этого. Но никаких гарантий нет.

На самом деле этот алгоритм просто использует популярную схему "первым во шел — первым вышел" (FIFO). B принципе, объект захватывается потоком, ждавшим дольше всех. Но в системе могут произойти какие-то события, которые повлияют на окончательное решение, и ил-за этого алгоритм становится менее предсказуемым. Вот почему Microsoft и не хочет говорить, как именно он работает. Одно из таких собы тий — приостановка какого-либо потока. Если поток ждет объект и вдруг приоста навливается, система просто забывает, что он ждал этот объект. А причина в том, что нет смысла планировать приостановленный поток. Когда он в конце концов возоб новляется, система считает, что он только что начал ждать данный объект.

Учитывайте это при отладке, поскольку в точках прерывания (breakpoints) все потоки внутри отлаживаемого процесса приостанавливаются. Отладка делает алго ритм FIFO в высшей степени непредсказуемым из-за частых приостановки и возоб новления потоков процесса.

Почему Unicode?

Разрабатывая приложение, Вы определенно должны использовать преимущества Unicode. Даже ссли Вы пока не собираетесь локализовать программный продукт, разработка с прицелом на Unicode упростит эту задачу в будущем. Unicode также позволяет:

легко обмениваться данными на разных языках; распространять единственный двоичный EXE- или DLL-файл, поддерживающий все языки; увеличить эффективность приложений (об этом мы поговорим чуть позже).

Подключение к очередям виртуального ввода и переменным локального состояния ввода

Как Вы уже убедились, отказоустойчивость модели ввода достигается благодаря тому, что у каждого потока имеются собственные переменные локального состояния вво да, а подключение потока к RIT и отключение от него происходит по мере необхо димости. Иногда нужно, чтобы два потока (или более) разделяли один набор пере менных локального состояния ввода или одну очередь виртуального ввода

Вы можете заставить два и более потока совместно использовать одну и ту же очередь виртуального ввода и переменные локального состояния ввода с помощью функции AttachTbreadInput:

BOOL AttachThreadInput( DWORD idAttach, DWORD idAttachTo, BOOL fAttach);

Параметр idAttach задаст идентификатор потока, чьи переменные локального со стояния ввода и очередь виртуального ввода Вам больше не нужны, а паряметр idAtta chedTo — идентификатор потока, чьи переменные локального состояния ввода и вир туальная очередь ввода должны совместно использоваться потоками И, наконец, па раметр fAttach должен быть или TRUE, чтобы инициировать совместное использова ние одной очереди, или FALSE — тогда каждый поток будет вновь использовать свои переменные состояния ввода и очередь А чтобы одну очередь (и переменные состо яния ввода) разделяли более двух потоков, вызовите АttасЬТhrеаdInput соответствую щее число раз.

Вернемся к одному из предыдущих примеров и допустим, что поток А вызывает AttachThreadlnput, передавая в первом параметре свой идентификатор, во втором — идентификатор потока В и в последнем — TRUE:

AttachThreadInput(idThreadA, idThreadB, TRUE);

Теперь любое событие аппаратного ввода, адресованное окну A1, B1 или B2, будет добавлено в конец очереди виртуального ввода потока В. Аналогичная очередь пото ка А больше не получит новых событий, если только Вы не разъедините очереди, повторно вызвав AttachThreadInput с передачей FALSE в параметре fAttach

Рис. 27-3. Аппаратные сообщения для окон А1, В1 и B2 помещаются в очередь виртуального ввода потока В

Потоки, присоединенные к одной очереди виртуального ввода (VIQ), сохраняют индивидуальные очереди сообщений (синхронных, асинхронных и ответных), а так же флаги пробуждения.
Однако Вы серьезно снизите надежность системы, если зас тавите все потоки использовать одну очередь сообщений. Если какой-нибудь поток зависнет при обработке нажатия клавиши, другие потоки не получат никакого ввода. Поэтому использования AttachThreadInput следует по возможности избегать.

Система неявно соединяет очереди виртуального ввода двух потоков, если какой то из них устанавливает ловушку регистрации (journal record hook) или ловушку вос произведения (journal playback hook). Когда ловушка снимается, система восстанав ливает схему организации очереди ввода, существовавшую до установки ловушки.

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

Есть еще один случай, когда система неявно вызывает AttachThreadlnput. Допустим, приложение создает два потока. Первый открывает на экране диалоговое окно Затем второй поток вызывает CreateWindow, указывая стиль WS_CHILD и передавая описа

тель этого диалогового окна, чтобы оно стало "родителем" дочернего окна. Тогда система сама вызывает АttасhТhrеаdIпрut, чтобы поток (которому принадлежит дочер нее окно) использовал ту же очередь ввода, что и поток, создавший исходное диало говое окно Это приводит к синхронизации ввода во всех дочерних окнах исходного диалогового окна.

Подстройка планировщика для активного процесса

Когда пользователь работает с окнами какого-то процесса, последний считается ак тивным (foreground process), a остальные процессы — фоновыми (background proces ses). Естественно, пользователь заинтересован в повышенной отзывчивости активно го процесса по сравнению с фоновыми Для этого Windows подстраивает алгоритм планирования потоков активного процесса, В Windows 2000, когда процесс становит

ся активным, система выделяет его потокам более длительные кванты времени Такая регулировка применяется только к процессам с классом приоритета normal

Windows 2000 позволяет модифицировать работу этого механизма подстройки Щелкнув кнопку Performance Options на вкладке Advanced диалогового окна System Properties, Вы открываете следующее окно

Переключатель Applications включает подстройку планировщика для активного процесса, а переключатель Background Services — выключает (в этом случае оптими зируется выполнение фоновых сервисов) В Windows 2000 Professional по умолчанию выбирается переключатель Applications, а в остальных версиях Windows 2000 — пе реключатель Background Services, так как серверы редко используются в интерактив ном режиме

Windows 98 тоже позволяет подстраивать распределение процессорного време ни для потоков активного процесса с классом приоритета normal Когда процесс этого класса становится активным, система повышает на 1 приоритет его потоков, если их исходные приоритеты были lowest, below normal, normal, above normal или highest, приоритет потоков idle или time-critical не меняется Поэтому поток с относительным приоритетом normal в активном процессе с классом приоритета normal имеет уро вень приоритета 9, а не 8 Когда процесс вновь становится фоновым, приоритеты его потоков автоматически возвращаются к исходным уровням

WINDOWS 98
Windows 98 не предусматривает возможности настройки этого механизма, так как не рассчитана на работу в качестве выделенного сервера

Причина для таких изменений активных процессов очень проста система дает им возможность быстрее реагировать на пользовательский ввод Если бы приоритеты их потоков не менялись, то и обычный процесс фоновой печати, и обычный, но актив ный процесс, принимающий пользовательский ввод, — оба одинаково конкурирова ли бы за процессорное время И тогда пользователь, набирая текст в активном при ложении, заметил бы, что текст появляется на экране какими-то рывками Но благо даря тому, что система повышает уровни приоритета потоков активного процесса, они получают преимущество над потоками обычных фоновых процессов

Подводя итоги

А теперь попробуем осмыслить понятия адресных пространств, разделов, регионов, блоков и страниц как единое целое. Лучше всего начать с изучения карты виртуальной памяти, на которой изображены все регионы адресного пространства В пределах одного процесса. В качестве примера мы воспользуемся программой VMMap из главы 14. Чтобы в полной мере разобраться в адресном пространстве процесса, рассмотрим его в том виде, в каком оно формируется при запуске VMMap под управлением Windows 2000 на 32-разрядной процессорной платформе x86 Образец карты адресного пространства VMMap показан в таблице 13-2. На отличиях адресных пространств в Windows 2000 и Windows 98 я остановлюсь чуть позже.

Карта в таблице 13-2 показывает регионы, расположенные в адресном пространстве процесса. Каждому региону соответствует своя строка в таблице, а каждая строка состоит из шести полей.

В первом (крайнем слева) поле проставляется базовый адрес региона. Наверное, Вы заметили, что просмотр адресного пространства мы начали с региона по адресу 0x00000000 и закончили последним регионом используемого адресного простран-

ства, который начинается по адресу 0x7FFE0000. Все регионы непрерывны. Почти все базовые адреса занятых регионов начинаются со значений, кратных 64 Кб. Это связано с гранулярностью выделения памяти в адресном пространстве. А если Вы увидите какой-нибудь регион, начало которого не выровнено по значению, кратному 64 Кб, значит, он выделен кодом операционной системы для управления Вашим процессом.

Базовый адрес		Тип		Размер		Блоки		Атрибут( ы) защиты		Описание
00000000		Free		65536
00010000		Private		4096		1		-RW-
00011000		Free		G1440
00020000		Private		4096		1		-RW-
000? 1000		Free		61440
00030000		Private		1048576		3		-HW-		Стек потока
00130000		Private		1048576		2		-RW-
00230000		Mapped		65536		2		-RW-
00240000		Mapped		90112		1		-R-		\Device\HarddiskVolume1\WINN7\system32\unicode.nls
00256000		Free		40960
00260000		Mapped		208896		1		-R-		\Device\HarddiskVolume1\WINNT\system32\locale.nIs
00293000		Free		53248
002A0000		Happed		266240		1		-R-		\Pevicc\HarddiskVolume1\WINNT\system32\sortkey.nls
002E1000		Free		61440
002F0000		Mapped		16384		1		-R-		\Device\HarddiskVolume1\WINNT\system32\sorttbls.nls
002F4000		Free		49152
00300000		Mapped		819200		4		ER-
0003С8000		Free		229376
00400000		Image		106496		5		ERWC		С \CD\x86\Debug\14_VMMap.ехе
0041A000		Free		24576
00420000		Mapped		274432		1		-R-
00463000		Free		53248
00470000		Mapped		3145728		2		ER
00770000		Private		4096		1		-RW-
00771000		Free		61440
00780000		Private		4096		1		-RW-
00781000		Free		61440
00790000		Private		65536		2		-RW-
007A0000		Mapped		8192		1		-R-		\Device\HarddiskVolume1\WINNT\system32\ctype.nls
007А2000		Free		1763893248
699D0000		Image		45056		4		ERWC		C:\WINNT\Systpm32\PSAPI dll
6990В000		Free		238505984
77D50000		Image		450560		4		ERWC		С:\WINNT\system32\RPCRT4 DLL
770ВЕ000		Free		8192
770С0000		Image		344064		5		ERWC		С:\WINNT\system32\ADVAPI32 dll
77Е14000		Free		49152
77E20000		Image		401408		4		ERWC		C:\WINNT\system32\USER32 dll
77Е82000		Free		57344
77Е90000		Image		720896		5		ERWC		С \WINNT\system32\KERNEL32.dll
77F40000		Image		241664		4		ERWC		С \WINKT\system32\GUI32 DLL
77F7В000		Free		20480
77FB0000		image		483328		5		ERWC		С \WINNT\System32\ntdll.dll
77FF000		Free		40960
78000000		Image		290816		6		bMWC		С \WINNT\system32\MSVCRI.dll
78047000		Free		124424192
7F6F0000		Mapped		1048576		2		ER--
7F7F0000		Free		8126464
7FFB0000		Mapped		147456		1		-R--
7FFD4000		Free		40960
7FFDE000		Private		4096		1		ERW-
7FFDF000		Private		4096		1		ERW-
7FFE0000		Private		65536		2		-R--

<
Таблица 13-2. Образец карты адресного пространства процесса в Windows 2000 на 32-разрядном процессоре типа x86

Во втором поле показывается тип региона Free (свободный), Private (закрытый), Image (образ) или Mapped (проецируемый) Эти типы описаны в следующей таблице,

Тип	Описание
Free	Этот диапазон виртуальных адресов не сопоставлен ни с каким типом физической памяти. Его адресное пространство не зарезервировано, приложение может зарезервировать регион по указанному базовому адресу или в любом месте в границах свободного региона
Private	Этот диапазон виртуальных адресов сопоставлен со страничным файлом.
Image	Этот диапазон виртуальных адресов изначально был сопоставлен с образом ЕХЕ- или DLL-файла, проецируемого в память, но теперь, возможно, уже нет Например, при записи в глобальную переменную из образа модуля механизм поддержки "копирования при записи" выделяет соответствующую страницу памяти из страничного файла, а не исходною образа файла
Mapped	Этот диапазон виртуальных адресов изначально был сопоставлен с файлом данных, проецируемым в память, но теперь, возможно, уже нет. Например, файл данных мог быть спроецирован с использованием механизма поддержки "копирования при записи" Любые операции записи в этот файл приведут к тому, что соответствующие страницы памяти будут выделены из страничного файла, а не из исходного файла данных.

Способ вычисления этого поля моей программой VMMap может давать неправильные результаты. Поясню почему Когда регион занят, VMMap пытается "прикинуть", к какому из трех оставшихся типов он может относиться, — в Windows нет функций, способных подсказать точное предназначение региона. Я определяю это сканированием всех блоков в границах исследуемого региона, по результатам которого программа делает обоснованное предположение Но предположение есть предположение Если Вы хотите получше разобраться в том, как это делается, просмотрите исходный код VMMap, приведенный в главе 14.

В третьем поле сообщается размер региона в байтах.


Например, система спроецировала образ User32. dll по адресу 0x77E20000. Когда она резервировала адресное

пространство для этого образа, ей понадобилось 401 408 байтов. Не забудьте, что в третьем поле всегда содержатся значения, кратные размеру страницы, характерному для данного процессора (4096 байтов для x86).

В четвертом поле показано количество блоков в зарезервированном регионе. Блок — это неразрывная группа страниц с одинаковыми атрибутами защиты, связанная с одним и тем же типом физической памяти (подробнее об этом мы поговорим в следующем разделе). Для свободных регионов это значение всегда равно 0, так как им не передается физическая память. (Поэтому в четвертой графе никаких данных для свободных регионов не приводится.) Но для занятых регионов это значение может колебаться в пределах от 1 до максимума (его вычисляют делением размера региона на размер страницы). Скажем, у региона, начинающегося с адреса Ox77E20000, размер — 401 408 байтов. Поскольку процесс выполняется на процессоре x86 (страницы памяти по 4096 байтов), максимальное количество блоков в этом регионе равно 98 (401 408/4096); ну а, судя по карте, в нем содержится 4 блока.

В пятом поле — атрибуты защиты региона. Здесь используются следующие сокращения: E = execute (исполнение), R = read (чтение), W= write (запись), С = copy-onwrite (копирование при записи). Если ни один из атрибутов в этой графе не указан, регион доступен без ограничений. Атрибуты защиты не присваиваются и свободным регионам. Кроме того, здесь Вы никогда не увидите флагов атрибутов защиты PAGE_ GUARD или PAGE_NOCACHE — они имеют смысл только для физической памяти, а не для зарезервированного адресного пространства. Атрибуты защиты присваиваются регионам только эффективности ради и всегда замещаются атрибутами защиты, присвоенными физической памяти.

В шестом (и последнем) поле кратко описывается содержимое текущего региона. Для свободных регионов оно всегда пустое, а для закрытых — обычно пустое, так как у VMMap нет возможности выяснить, зачем приложение зарезервировало данный закрытый регион.Однако VMMap все жe распознает назначение тех закрытых регионов, в которых содержатся стеки потоков. Стеки потоков выдают себя тем, что содержат блок физической памяти с флагом атрибутов защиты PAGE_GUARD. Если же стек полностью заполнен, такого блока у него нет, и тогда VMMap не в состоянии распознать стск потока.

Для регионов типа Image программе VMMap удается определить полное имя файла, проецируемого на этот регион. Она получает эту информацию с помощью ToolHelp-функций, о которых я упоминал в конце главы 4. В Windows 2000 программа VMMap может идентифицировать регионы, сопоставленные с файлами данных; для этого она вызывает функцию GetMappedFileName (ее нет в Windows 98).

Получение статистической информации о задании

Мы уже обсудили, как с помощью QueryInformationJobObject получить информацию о текущих ограничениях, установленных для задания. Этой функцией можно пользоваться и для получения статистической информации. Например, чтобы выяснить базовые учетные сведения, вызовите ее, передав JobObjeсtBasicAccountingInformation во втором параметре и адрес структуры JOBOBJECT_BASIC_ACCOUNTING_INFORMATION:

typedef struct _JOBOBJECT_BASIC_ACCOUNTING_INFORMATION
{
LARGE_INTEGER TotalUserTime;
LARGE_INTEGER TotalKernelTime;
LARGE_INTEGER ThisPeriodTotalUserTime;
LARGE_INTEGER ThisPeriodTotalKernelTime;
DWORD TotalPageFaultCount;
DWORD TotalProcesses;
DWORD ActiveProcesses;
DWORD TotalTerminatedProcesses;
} JOBOBJECT_BASIC_ACCOUNTING_INFORMATION, *PJOBOBJECT_BASIC_ACCOUNTING_INFORMATION;

Элементы этой структуры кратко описаны в таблице 5-3.

Элемент		Описание
TotalUserTtme		Процессорное время, израсходованное процессами задания в пользовательском режиме
TotalKernelTime		Процессорное время, израсходованное процессами задания в режиме ядра
ThisPeriodTotalUserTime		То же, что TotalUserTime, но обнуляется, когда базовые oгpa ничения изменяются вызовом SetIniformationJobObject, а флаг JOB OBJECT_LIMIT_PRESERVE_JOB_TIME не используется
ThisPeriodTotalKernelTime		То же, что ThisPeriodTotalUserTime, но относится к процессор ному времени, израсходованному в режиме ядра
TotalPageFaultCount		Общее количество ошибок страниц, вызванных процессами задания
TotalProcesses		Общее число процессов, когда-либо выполнявшихся в зтом задании
ActiveProcesses		Текущее количество процессов в задании
TotalTermtnatedProcesses		Количество процессов, завершенных из-за превышения ими отведенного лимита процессорного времени

Таблица 5-3. Элементы структуры JOBOBJECT_BASIC_ACCOUNTING_INFORMATION

Вы можете извлечь те же сведения вместе с учетной информацией по вводу-выводу, передав JobObjectBasicAndIoAccountingInformation во втором параметре и адрес структуры JOBOBJECT_BASIC_AND_IO_ACCOUNTING_INFORMATION:

typedef struct JOBOBJECT_BASIC_AND_IO_ACCOUNTING_INFORMATION
{
JOBOBJECT_BASIC_ACCOUNTING_TNFORMATION Basiclnto;
IO_COUNTERS IoInfo;
} JOBOBJECT_BASIC_AND_IO_ACCOUNTING_INFORMATION;

Как видите, она просто возвращает JOBOBJECT_BASIC_ACCOUNTlNG_INFORMATION и IO_COUNTERS. Последняя структура показана на следующей странице.

typedef struct _IO_COUNTERS
{
ULONGlONG ReadOperationCount;
ULONGLONG WriteOperationCount;
ULONGLONG OtherOperationCount;
ULONGLONG ReadTransferCount;
ULONGLONG WriteTransferCount;
ULONGLONG OtheiTransferCount;
} IO_COUNTERS;

Она сообщает о числе операций чтения, записи и перемещения (а также о количестве байтов, переданных при выполнении этих операций). Данные относятся ко всем процессам в задании. Кстати, новая функция GetProcessIoCounters позволяет получить ту же информацию о процессах, не входящих ни в какие задания.

BOOL GetProcessIoCounters( HANDLE hProcess, PIO_GOUNTERS pToCounters);

QueryInformationJobObject такжe возвращает набор идентификаторов текущих про цессов в задании Но перед этим Вы должны прикинуть, сколько их там может быть, и выделить соответствующий блок памяти, где поместятся массив идентификаторов и структура JOBOBJECT_BASIC_PROCESS_ID_LIST

typedef struct _JOBOBJECT_BASIC_PROCESS_ID_LIST
{
DWORD NumberOfAssigncdProcessps;
DWORD NurrberOfProcessIdsInList;
DWORD ProcessIdList[1];
} JOBOBJECT_BASIC_PROCESS_ID_LIST, *PJOBOBJECT_BASIC_PROCESS_ID_LIST ;

В итоге, чтобы получить набор идентификаторов текущих процессов в задании, нужно написать примерно такой код:

void EnumProcessIdsInJob(HANDLE hjob)
{

// я исхожу из того, что количество процессов
// в этом задании никогда не превысит 10
#define MAX_PROCESS_TDS 10

// определяем размер блока памяти (в байтах)
// для хранения идентификаторов и структуры
DWORD cb = sizeof(JOBOBJECT_BASlC_PROCESS_ID LIST) + (MAX_PROCESS_IDS - 1) * sizeof(DWORD);

// выделяем этот блок памяти
PJOBOBJECT_BASIC_PROCESS_ID_LIST pjobpil = _alloca(cb);

// сообщаем функции, на какое максимальное число процессов


// рассчитана выделенная нами память pjobpil->NumberOfAssignedProcesseb = MAX_PROCESS_IDS;

// запрашиваем текущий список идентификаторов процессов
QuerylnformationJobObject(hjob, JobObjectBasicProcessIdList pjobpil, cb &cb);

// перечисляем идентификаторы процессов
for (int x =- 0; x < pjobpil->NumberOfProcessIdsInList; x++)
{

// используем
pjobpil->ProcessIdList[x]
}

// так как для выделения памяти мы вызывали _alloca,
// освобождать память нам не потребуется
}

Вот и все, что Вам удастся получить через эти функции, хотя на самом деле операционная система знает о заданиях гораздо больше. Эту информацию, которая хранится в специальных счетчиках, можно извлечь с помощью функций из библиотеки Performance Data Helper (PDH dIl) или через модуль Performance Monitor, подключаемый к Microsoft Management Console (MMC). Рис 5-3 иллюстрирует некоторые из доступных в системе счетчиков заданий (job object counters), а рис. 5-4 — счетчики, относящиеся к отдельным параметрам заданий (job object details counters) Заметьте, что в задании Jeff содержится четыре процесса calc, cmd, notepad и wordpad.



Рис. 5-3. MMC Performance Monitor счетчики задания



Рис. 5-4. MMC Performance Monitor счетчики, относящиеся к отдельным параметрам задания

Извлечь сведения из этих счетчиков Вы сможете только для тех заданий, которым были присвоены имена при вызове CreateJobObject. По этой причине, наверное, лучше всегда именовать задания, даже если Вы и не собираетесь ссылаться на них по именам из других процессов.

Посылка асинхронных сообщений в очередь потока

Когда с потоком связывается структура THREADINFO, он получает свой набор очере дей сообщений. Если процесс создает три потока и все они вызывают функцию Create Window, то и наборов очередей сообщений будет тоже три Сообщения ставятся в очередь асинхронных сообщений вызовом функции PostMessage:

BOOL PostMessage( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

При вызове этой функции система определяет, каким потоком создано окно, иден тифицируемое параметром hwnd, Далее система выделяет блок пямяти, сохраняет в нем параметры сообщения и записывает этот блок в очередь асинхронных сообще ний данного потока. Кроме того, функция устанавливает флаг пробуждения QS_POST MESSAGE (о нем — чуть позже). Возврат из PostMessage происходит сразу после того, как сообщение поставлено в очередь, поэтому вызывающий поток остается в неведе нии, обработано ли оно процедурой соответствующего окна На самом деле вполне вероятно, что окно даже не получит это сообщение Такое возможно, если поток, создавший это окно, завершится до того, как обработает все сообщения из своей очереди.

Рис. 26-1. Три потока и соответствующие им структуры THREADINFO

Сообщение можно поставить в очередь асинхронных сообщений потока и вызо вом PostThreadMessage:

BOOL PostThreadMessage( DWORD dwThreadId, UINT uMsg, WPARAM wParam, LPARAM lParam);

NOTE
Какой поток создал окно, можно определить с помощью GetWindowThreadPro cessId:

DWORD GetWindowThreadProcessId( HWND hwnd PDWORD pdwProccssId);

Она возвращает уникальный общесистемный идентификатор потока, ко торый создал окно, определяемое параметром hwnd. Передав адрес перемен ной типа DWORD в параметре pdwProcessId, можно получить и уникальный общесистемный идентификатор процесса, которому принадлежит этот поток. Но обычно такой идентификатор не нужен, и мы просто передаем NULL

Нужный поток идентифицируется первым параметром, dwThreadId. Когда сооб щение помещено в очередь, элемент hwnd структуры MSG устанавливается как NULL. Применяется эта функция, когда приложение выполняет какую то особую обработку в основном цикле выборки сообщений потока, — в этом случае он пишется так, что бы после выборки сообщения функцией GetMessage (или PeekMessage) код в цикле сравнивал hwnd с NULL и, выполняя эту самую особую обработку, мог проверить зна чение элемента msg структуры MSG.
Если поток определил, что сообщение не адре совано какому-либо окну, DispatchMessage не вызывается, и цикл переходит к выбор ке следующего сообщения.

Как и PostMessage, функция PostThreadMessage возвращает управление сразу после того, как сообщение поставлено в очередь потока И вновь вызывающий поток оста ется в неведении о дальнейшей судьбе сообщения

И, наконец, еще одна функция, позволяющая поместить сообщение в очередь асин хронных сообщений потока:

VOID PostOuitMessage(int nExilCode);

Она вызывается для того, чтобы завершить цикл выборки сообщений потока Ее вызов аналогичен вызову

PostThreadMessage(GetCurrentThreadId(), WM_OUIT, nExitCode, 0);

Но в действительности PostQuitMessage не помещает сообщение ни в одну из оче редей структуры THREADINFO. Эта функция просто устанавливает флаг пробуждения QS_QUIT (о нем я тоже расскажу чуть позже) и элемент nExitCode структуры THREAD INFO. Так как эти операции не могут вызвать ошибку, функция PostQuitMessage не возвращает никаких значений (VOID).

Посылка синхронных сообщений окну

Оконное сообщение можно отправить непосредственно оконной процедуре вызовом SendMessage:

LRESULT SendMessage( HWNO hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Оконная процедура обработает сообщение, и только по окончании обработки функция SendMessage вернет управление. Благодаря этому ее используют гораздо чаще, чем PostMessage или PostThreadMessage При переходе к выполнению следующей стро ки кода поток, вызвавший SendMessage, может быть уверен, что сообщение уже обра ботано.

Вот как работает SendMessage Если поток вызывает SendMessage для посылки со общения окну, созданному им же, то функция просто обращается к оконной проце дуре соответствующего окна как к подпрограмме. Закончив обработку, оконная про цедура передает функции SendMessage некое значение, а та возвращает его вызвавше му потоку.

Однако, если поток посылает сообщение окну, созданному другим потоком, опе рации, выполняемые функцией SendMessage, значительно усложняются. Windows требует, чтобы оконное сообщение обрабатывалось потоком, создавшим окно. Поэто му, если вызвать SendMessage для отправки сообщения окну, созданному в другом про цессе и, естественно, другим потоком, Ваш поток не сможет обработать это сообще ние — ведь он не работает в адресном пространстве чужого процесса, а потому не имеет доступа к коду и данным соответствующей оконной процедуры. И действитель но, Ваш поток приостанавливается, пока другой поток обрабатывает сообщение. По этому, чтобы один поток мог отправить сообщение окну, созданному другим пото ком, система должна выполнить следующие действия.

Во-первых, переданное сообщение присоединяется к очереди сообщений пото ка-приемника, в результате чего для зтого потока устанавливается флаг QSSEND MESSAGE. Во-вторых, если поток-приемник в данный момент выполняет какой-то код и не ожидает сообщений (через вызов GetMessage, PeekMessage или WaitMessage), пе реданное сообщение обработать не удастся — система нс прсрвст работу потока для немедленной обработки сообщения. Но когда поток-приемпик ждет сообщений, си стема сначала проверяет, установлен ли флаг пробуждения QS_SENDMESSAGE, и, если да, просматривает очередь синхронных сообщений, отыскивая первое из них.
В оче реди может находиться более одного сообщения Скажем, несколько потоков одно временно послали сообщение одному и тому же окну. Тогда система просто ставит эти сообщения в очередь синхронных сообщений потока.

Итак, когда поток ждет сообщений, система извлекает ил очереди синхронных сообщений первое и вызывает для ею обработки нужную оконную процедуру Если таких сообщений больше нет, флаг QS_SENDMESSAGE сбрасывается. Пока поток-при емник обрабатывает сообщение, поток, отправивший сообщение через SendMessage, простаивает, ожидая появления сообщения в очереди ответных сообщений По окон чании обработки значение, возвращенное оконной процедурой, передается асинх ронно в очередь ответных сообщений потока-отправителя Теперь он пробудится и извлечет упомянутое значение из ответного сообщения. Именно это значение и бу дет результатом вызова SendMessage C этого момента поток-отправитель возобнов ляет работу в обычном режиме

Ожидая возврата управления функцией SendMessage, поток в основном простаи вает. Но кое-чем он может заняться, если другой поток посылает сообщение окну, созданному первым (ожидающим) потоком, система тут же обрабатывает это сооб щение, не дожидаясь, когда поток вызовет GetMessage, PeekMessage или WaitMessage

Поскольку Windows обрабатывает межпоточные сообщения описанным выше образом, Ваш поток может зависнуть Допустим, в потоке, обрабатывающем синхрон ное сообщение, имеется "жучок", из-за которого поток входит в бесконечный цикл Что же произойдет с потоком, вызвавшим SendMessage? Возобновится ли когда-нибудь его выполнение? Значит ли это, что ошибка в одном приложении "подвесит" другое? Ответ — да!

Это верно даже в том случае, если оба потока принадлежит одному процессу

Избегать подобных ситуаций позволяют четыре функции, и первая из них — SendMessageTimeout

LRESULT SendMessageTimeout( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT fuFlags, UINT uTimeout, PDWORD_PTR pdwResult);

Она позволяет задавать отрезок времени, в течение которого Вы готовы ждать ответа от другого потока на Ваше сообщение Ее первые четыре параметра идентич ны параметрам функции SendMessage. В пэраметре fuFlags можно передавать флаги SMTO_NORMAL (0), SMTO_ABORTIFHUNG, SMTO_BLOCK, SMTO_NOTIMEOUTIFNO THUNG или комбинацию этих флагов.



Флаг SMTO_ABORTIFHUNG заставляет SendMessageTimeout проверить, не завис ли ноток приемник^, и, если да, немедленно вернуть управление Флаг SMTO_NOTIME OUTIFNOTHUNG сообщает функции, что она должна игнорировать ограничение по времени, если поток-приемник не завис. Флаг SMTO_BLOCK предотвращает обработ ку вызывающим потоком любых других синхронных сообщений до возврата из Send MessageTimeout, Флаг SMTO_NORMAL определен в файле WinUser.h как 0, он исполь зуется в том случае, если Вы нс указали другие флаги

Я уже говорил, что ожидание потоком окончания обработки синхронного сооб щения может быть прервано для обработки другого синхронного сообщения. Флаг SMTO_BLOCK предотвращает такое прерывание Он применяется, только если поток, ожидая окончания обработки своего сообщения, не в состоянии обрабатывать про чие синхронные сообщения. Этот флаг иногда приводит к взаимной блокировке по токов до конца таймаута Так, если Ваш поток отправит сообщение другому, а тому нужно послать сообщение Вашему, ни один из них не сможет продолжить обработку, и оба зависнут

Параметр uTimeout определяет таймаут — время (в миллисекундах), в течение которого Вы готовы ждать ответного сообщения. При успешном выполнении функ ция возвращает TRUE, а результат обработки сообщения копируется no адресу, ука занному в параметре pdwResult,

Кстати, прототип этой функции в заголовочном файле WinUser.h неверен. Функ цию следовало бы определить как возвращающую значение типа BOOL, поскольку значение типа LRFSULT на самом деле возвращается через ее параметр Это создает определенные проблемы, так как SendAlebbageTimeout вернет FALSE, если Вы переда дите неверный описатель окна или если закончится заданный период ожидания. Един ственный способ узнать причину неудачного завершения функции — вызвать GetLast Error. Последняя вернет 0 (ERROR_SUCCESS), если ошибка связана с окончанием пе риода ожидания. А если причина в неверном описателе, GetLastError даст код 1400 (ERROR_INVALID_WINDOW_HANDLE).

Если Вы обращаетесь к SendMessageTimeout для посылки сообщения окну, создан ному вызывающим потоком, система просто вызывает оконную процедуру, помещая возвращаемое значение в pdwResult. Из-за этого код, расположенный за вызовом



Операционная система считает поток зависшим, если он прекращает обработку сообще ний более чем на 5 секунд.

SendMessageTimeout, не выполняется до тех пор, пока не заканчивается обрабочка сообщения, — ведь все эти операции осуществляются одним потоком.

Теперь рассмотрим вторую функцию, предназначенную для отправки межпоточ ныхсообщений:

BOOL SendMessageCallhack( HWND hwnd, UINT uHsg, WPARAM лРагат, LPARAM lParam, SENDASYNCPROC pfnResultCallBack, ULONG_PTR dwOata);

И вновь первые четыре параметра идентичны параметрам функции SendMessage При вызове Вашим потоком SendMessageCallback отправляет сообщение в очередь синхронных сообщений потока-приемника и тут же возвращает управление вызыва ющему (т e Вашему) потоку Закончив обработку сообщения, поток-приемник асин хронно отправляет свое сообщение в очередь ответных сообщений Вашего потока. Позже система уведомит Ваш поток об этом, вызвав написанную Вами функцию; у нее должен быть следующий прототип,

VOID CALLBACK ResultCallBack( HWND hwnd. UINT uMsg, ULONG_PIR dwData, LRESULT lResult);

Адрес этой функции обратного вызова передается SendMessageCallback в параметре pfnResultCallBack А при вызове ResultCallBack в первых двух параметрах передаются описатель окна, закончившего обработкусообщения, и код (значение) самого сооб щения. Параметр dwData функции ResultCallBack всегда получает значение, передан ное SendMessageCallback в одноименном параметре. (Система просто берет то, что указано там, и передает Вашей функции ResultCallBack) Последний параметр функ ции ResultCallBack сообщает результат обработки сообщения, полученный от окон ной процедуры

Поскольку SendMessageCallback, передавая сообщение другому потоку, немедлен но возвращает управление, ResultCallBack вызывается после обработки сообщения потоком-приемником не сразу, а с задержкой. Сначала поток-приемник асинхронно ставит сообщение в очередь ответных сообщений потока-отправителя Затем при первом же вызове потоком-отправителем любой из функций GetMessage, PeekMessage, WaitMessage или одной из Send-функций сообщение извлекается из очереди ответных сообщений, и лишь потом вызывается Ваша функция ResultCallback.



Существует и другое применение функции SendMessageCallback В Windows пре дусмотрен метод, позволяющий разослать сообщение всем перекрывающимся окнам (overlapped windows) в системе; он состоит в том, что Вы вызываете SendMessage и в параметре hwnd передаете ей HWND_BROAUCAST (определенный как -1) Этот ме тод годится только для широковещательной рассылки сообщений, возвращаемые значения которых Вас не интересуют, поскольку функция способна вернуть лишь одно значение, LRESULT. Но, используя SendMessageCallback, можно получить резуль таты обработки "широковещательного" сообщения от каждого перекрытого окна Ваша функция SendMessageCallback будет вызываться с рсзульгатом обработки сооб щения от каждого из таких окон.

Если SendMessageCallback вызывается для отправки сообщения окну, созданному вызывающим потоком, система немедленно вызывает оконную процедуру, а после обработки сообщения — функцию ResultCallBack, После возврата из ResultCallback выполнение начинается со строки, следующей за вызовом SendMessageCallback.

Третья функция, предназначенная для передачи межпоточных сообщений:

BOOL SendNotifyMessage( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

Поместив сообщение в очередь синхронных сообщений потока-приемника, она немедленно возвращает управление вызывающему потоку. Так. ведет себя и PostMessage, помните? Но два отличия SendNotifyMessage от PostMessage все же есть.

Во-первых, если SendNotifyMessage посылает сообщение окну, созданномудругим потоком, приоритет данного синхронного сообщения выше приоритета асинхрон ных сообщений, находящихся в очереди потока-приемника Иными словами, сооб щения, помещаемые в очередь с помощью SendNolifyMessage, всегда извлекаются до выборки сообщений, отправленных через PostMessage,

Во-вторых, если сообщение посылается окну, созданному вызывающим потоком, SendNotifyMessage работает точно так же, как и SendMessage, т. e не возвращает управ ление до окончания обработки сообщения

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


Например, WM_ACTIVATE, WM_DESTROY, WM_ENABLE, WM_SIZE, WM_SETFOCUS, WM_MOVE и многие Другие сообщения - это просто уведомления, посылаемые системой окну в синхронном, а не асинхронном режиме. Поэтому система не прерывает свою работу только ради того, чтобы окон ная процедура могла их обработать. Прямо противоположный эффект дает отправка сообщения WM_CREATE — тогда система ждет, когда окно закончит его обработку. Если возвращено значение -1, значит, окно не создано.

И, наконец, четвертая функция, связанная с обработкой межпоточных сообщений:

BOOL ReplyMessage(LRESULT lResult);

Она отличается от трех описанных выше. В то время как Send-функции использу ются посылающим сообщения потоком для защиты себя от зависания, ReplyMessage вызывается потоком, принимающим оконное сообщение Вызвав ее, поток как бы говорит системе, что он уже получил результат обработки сообщения и что этот ре зультат нужно упаковать и асинхронно отправить в очередь ответных сообщений потока-отправителя Последний сможет пробудиться, получить результат и возобно вить работу.

Поток, вызывающий ReplyMessage, передаст результат обработки сообщения через параметр lResult После вызова ReplyMessage выполнение потока-отправителя возоб новляется, а поток, занятый обработкой сообщения, продолжает эту обработку. Ни один из потоков не приостанавливается — оба работают, как обычно. Когда поток, обрабатывающий сообщение, выйдет из своей оконной процедуры, любое возвраща емое значение просто игнорируется.

Заметьте: ReplyMessage надо вызывать из оконной процедуры, получившей сооб щение, но нс из потока, вызвавшего одну из Send-функций. Поэтому, чтобы написать "защищенный от зависаний" код, следует заменить все вызовы SendMessage вызовами

одной из трех Send-функций и не полагаться на то, что оконная процедура будет вызывать именно ReplyMessage.

Учтите также, что вызов ReplyMessage при обработке сообщения, посланного этим же потоком, не влечет никаких действий. На это и указывает значение, возвращаемое ReplyMessage- TRUE.


— при обработке межпоточного сообщения и FALSE — при попыт ке вызова функции для обработки внутрипоточного сообщения.

Если Вас интересует, является обрабатываемое сообщение внутрипоточным или межпоточным, вызовите функцию InSendMessage:

BOOL InSendMessage();

Имя этой функции не совсем точно соответствует тому, что она делает в действи тельности На первый взгляд, функция должна возвращать TRUE, ссли поток обраба тывает синхронное сообщение, и FALSE — при обработке им асинхронного сообще ния. Но это не так. Она возвращает TRUE, если поток обрабатывает межпоточное син хронное сообщение, и FALSE — при обработке им внутрипоточного сообщения (син хронного или асинхронного). Возвращаемые значения функций lnSendMessage и ReplyMessage идентичны.

Есть еще одна функция, позволяющая определить тип сообщения, которое обра батывается Вашей оконной процедурой:

DWORD InSendMessageEx(PVOID pvReserved);

Вызывая ее, Вы должны передать NULL в параметре pvReserved. Возвращаемое зна чение указывает на тип обрабатываемого сообщения. Значение ISMEX_NOSEND (0) говорит о том, что поток обрабатывает внутрипоточное синхронное или асинхрон ное сообщение. Остальные возвращаемые значения представляют собой комбинацию битовых флагов, описанных в следующей таблице

Флаг	Описание
ISMEX_ SEND	Поток обрабатывает межпоточное синхронное сообщение, посланное через SendMessage или SendMessageTtmeout; если флаг ISMEX REPLIED не установлен, поток-отправитель блокируется в ожидании ответа
ISMEX_NOTIFY	Поток обрабатывает межпоточное синхронное сообщение, посланное череч SendNotify Message, поток- отправитель не ждет ответа и не блоки руется
ISMEX_CALLBACK	Поток обрабатывает межпоточное синхронное сообщение, посланное через SendMessageCallback; поток- отправитель не ждет ответа и не бло кируется
ISMEX_REPLIED	Поток обрабатывает межпоточпое синхронное сообщение и уже выз вал ReplyMessage; поток-отправитель не блокируется

Поток необработанного ввода

Общая схема модели аппаратного ввода в системе показана на рис. 27-1. При запуске система создает себе особый поток необработанного ввода (raw input thread, RIT) и системную очередь аппаратного ввода (system hardware input queue, SHIQ). RIT и SHIQ — это фундамент, на котором построена вся модель аппаратного ввода.

Обычно RIT бездействует, ожидая появления какого-нибудь элемента в SHIQ Ког да пользователь нажимает и отпускает клавишу на клавиатуре или кнопку мыши, либо перемещает мышь, соответствующий драйвер устройства добавляет аппаратное собы тие в SHIQ Тогда RIT пробуждается, извлекает этот элемент из SHIQ, преобразует его в сообщение (WM_KEY*, WM_?BUTTON* или WM_MOUSEMOVE) и ставит в конец оче реди виртуального ввода (virtualized input queue, VIQ) нужного потока. Далее RIT воз вращается в начало цикла и ждет появления следующего элемента в SHIQ RIT никог да не перестает реагировать на события аппаратного ввода — весь его код написан самой Microsoft и очень тщательно протестирован.

Как же RIT узнает, в чью очередь надо пересылать сообщения аппаратного ввода? Ну, с сообщениями от мыши все ясно: RIT просто выясняет, в каком окне находится ее курсор, и, вызвав GetWindowThreadProcessId, определяет поток, создавший это окно. Поток с данным идентификатором и получит сообщение от мыши.

В случае сообщений от клавиатуры все происходит несколько иначе. В любой момент с RIT "связан" лишь какой-то один поток, называемый активным (foreground thrcad). Именно сму принадлежит окно, с которым работает пользователь в данное время.

Рис. 27-1. Модель аппаратного ввода

Когда пользователь входит в систему, процесс Windows Explorer порождает поток, который создает панель задач и рабочий стол. Этот поток привязывается к RIT. Если Вы запустите Calculator, то его поток, создавший окно, немедленно подключится к RIT После этого поток, принадлежащий Explorer, отключается от RIT, так как единовре менно с RIT может быть связан только один поток. При нажатии клавиши в SHIQ появится соответствующий элемент.
Это приведет к тому, что RIT пробудится, преоб разует событие аппаратного ввода в сообщение от клавиатуры и поместит его в VIQ потока Calculator.

Каким образом различные потоки подключаются к RIT? Если при создании про цесса его поток создает окно, последнее автоматически появляется на переднем пла не (становится активным), и этот поток присоединяется к RIT. Кроме того, RIT отве чает за обработку особых комбинаций клавиш- Alt+Tab, AIr+Esc и Ctrl+Alt+Del. Посколь ку эти комбинации клавиш RIT обрабатывает самостоятельно, пользователи могут в любой момент активизировать соответствующие окна с клавиатуры; ни одно прило жение не в состоянии перехватить упомянутые комбинации клавиш Как только поль зователь нажимает одну из таких комбинаций клавиш, RIT активизирует выбранное окно, и в результате его поток подключается к RIT. Кстати, в Windows есть функции, позволяющие программно активизировать окно, присоединив сго поток к ШТ. Мы обсудим их несколько позже.

На рис 27-1 видно, как работает механизм защиты потоков друг от друга. Посы лая сообщение в окно B1 или B2, RIT помещает его в очередь виртуального ввода потока В. Обрабатывая это сообщение, поток — при синхронизации на каком-либо объекте ядра — может войти в бесконечный цикл или попасть в ситуацию взаимной блокировки. Если так и случится, он все равно останется присоединенным к RIT, и сообщения будут поступать именно в его очередь виртуального ввода

Однако пользователь, заметив, что ни окно B1, ни окно B2 не реагируют на его действия, может переключиться, например, в окно А1 нажатием клавиш Alt+Tab По скольку RIT сам обрабатывает комбинацию клавиш Alt+Tab, переключение пройдет без всяких проблем. После активизации окна A1 к RIT будет подключен поток А. Теперь пользователь может спокойно работать с окном A1, даже несмотря на то что поток В и оба его окна зависли.

Преобразование псевдоописателя в настоящий описатель

Иногда бывает нужно выяснить настоящий, а не псевдоописатель потока. Под "настоящим" я подразумеваю описатель, который однозначно идентифицирует уникальный поток Вдумайтесь в такой фрагмент кода:

DWORD WINAPI ParentThread(PVOID pvParam)
{
HANDLE hThreadParent = GetCurrentThread();
CreateThread(NULL, 0, ChildThread, (PVOID) hThreadParent, 0, MULL);

// далее следует какой-то код
}

DWORD WINAPI ChildThread(PVOID pvParam)
{
HANDLE hThreadParent = (HANDLE) pvParam;

FILETIME ftCreationTime, ftExitTime, ftKernelTime, ftUserTime;

GetTh readTimes(hThreadParent, &ftCreationTime, &ftExitTime, &ftKernelTime, &ftUserTime);

// далее следует какой-ro код.
}

Вы заметили, чго здесь не все ладно. Идея была в том, чтобы родительский поток передавал дочернему свой описатель. Но он передает псевдо-, а не настоящий описатель. Начиная выполнение, дочерний поток передает этот псевдоописатель функции GetThreadTimes, и она вследствие этого возвращает временные показатели своего — а вовсе не родительского потока. Происходит так потому, что псевдоописатель является описателем текущего потока, т e. того, который вызывает эту функцию.

Чтобы исправить приведенный выше фрагмент кода, превратим псевдоописатель в настоящий через функцию DuplicateHandle (о ней я рассказывал в главе 3):

BOOL DuplicateHandle( HANDLE hSourceProcess, HANDLE hSource, HANDLE hTargetProcess, PHANDLE phTarget, DWORD fdwAccess, BOOL bInhentHandle, DWORD fdwOpfions);

Обычно она используется для создания нового "процессо-зависимого" описателя из описателя объекта ядра, значепие которого увязано с другим процессом. А мы воспользуемся DuplicateHandle не совсем по назначению и скорректируем с ее помощью наш фрагмент кода так:

DWORD WINAPI ParentThread(PVOID pvParam)
{
HANDLE hThreadParent;

DuplicateHandle(
GetCurrentProcebs(), // описатель процесса, к которому относится псевдоописатель потока,
GetCurrentThread(), // псевдоописатель родительского потока;
GetCurrentProcess(), // описатель процесса, к которому относится новый, настоящий описатель потока


&hThreadParent, // даст новый настоящий описатель идентифицирующий родительский поток;
0, // игнорируется из-за DUPLICATE_SAME_ACCESS FALSE, новый описатель потока ненаследуемый, DUPLICATE_SAME_ACCESS); // новому описателю потока присваиваются те же атрибуты защиты, что и псевдоописателю

CreateThread(NULL, 0, ChildThread, (PVOID) hThreadParent, 0, NULL) ;

// далее следует какой-то код
}

DWORD WINAPI ChildThread(PVOID pvParam)
{

HANDLE hThreadParent = (HANDLE) pvParam;

FILETIME ftCreaUonTime, ftExitTime, ftKernelTime, ftUserTime;

GetThreadTimes(hThreadParent, &ftCreationTime, &ftExitTime, &ftKernelTime, &ftUserTime);

CloseHandle(hThreadParent);

// далее следует какой-то код..
}

Тeпeрь родительский поток преобразует свой "двусмысленный" псевдоописатель в настоящий описатель, однозначно определяющий родительский поток, и передает его в CreateThread. Когда дочерний поток начинает выполнение, его параметр pvParam содержит настоящий описатель потока. В итоге вызов какой-либо функции с этим описателем влияет не на дочерний, а на родительский поток.

Поскольку DuplicateHandle увеличивает счетчик пользователей указанного объекта ядра, то, закончив работу с продублированным описателем объекта, очень важно не забыть уменьшить счетчик. Сразу после обращения к GetThreadTimes дочерний поток вызывает CloseHandle, уменьшая тем самым счетчик пользователей объекта "родительский поток" на 1. В этом фрагменте кода я исходил из того, что дочерний поток не вызывает других функций с передачей этого описателя. Если же ему надо вызвать какие-то функции с передачей описателя родительского потока, то, естественно, к CloseHandle следует обращаться только после тогo, как необходимость в этом описателе у дочернего потока отпадет.

Надо заметить, что DuphcateHandle позволяет преобразовать и псевдоописатель процесса. Вот как это сделать:

HANDLE hProcess; DuplicateHandle( GetCurrentProcess(), // Описатель процесса, к которому // относится псевдоописатель GetCurrentProcess(), // Псевдоописатель процесса GetCurrentProcess(), // Описатель процесса, к которому // относится настоящий описатель &hProcess, // Дает новый, настоящий описатель, // идентифицирующий процесс 0, // Игнорируется из-за DUPLICATE_SAME_ACCESS FALSE, // Новый описатель процесса ненаследуемый DUPLICATE_SAME_ACCESS); // Новому описателю процесса присваиваются // те же атрибуты защиты, что и псевдоописателю

внедрения DLL

Допустим, Вы хотите создать подкласс от экземпляра окна, порожденного другим процессом. Это, как Вы помните, позволит изменять поведение окна Все, что от Вас для этого требуется, — вызвать функцию SetWindowLongPtr, чтобы заменить адрес оконной процедуры в блоке памяти, принадлежащем окну, новым — указывающим на Вашу функцию WndProc. В документации Platform SDK утверждастся, что приложение

не может создать подкласс окна другого процесса Это не совсем верно Проблема создания подкласса окна из другого процесса па самом деле сводится к преодолению границ адресного пространства

Вызывая SetWindowLongPtr для создания подкласса окна (как показано ниже), Вы говорите системе, что все сообщения окну, на которое указывает hwnd, следует направлять не обычной оконной процедуре, а функции MySubclassProc

SetWindowLongPtr(hwnd, GWLP_WNDPROC, MySubclassProc);

Иными словами, когда системе надо передать сообщение процедуре WndProc указанного окна, она находит ее адрес и вызывает напрямую В нашем примере система видит, что с окном сопоставлен адрес функции MySubclassProc, и поэтому вызывает именно ее, а нс исходную оконную процедуру

Проблема с созданием подкласса окна, принадлежащего другому процессу, состоит в том, что процедура подкласса находится в чужом адресном пространстве Упрощенная схема приема сообщений оконной процедурой представлена па рис 22.1 Процесс А создает окно На адресное пространство этого процесса проецируется файл User32.dlI Эта проекция User32.dll О1вечает за прием и диспетчеризацию сообщений (синхронных и асинхронных), направляемых любому из окон, созданных потоками процесса А Обнаружив кякое-то сообщение, она определяет адрес процедуры WndProc окна и вызывает ее, передавая описатель окна, сообщение и параметры wParam и lParam Когда WndProc обработает сообщение, Uscr32 dll вернется в начало цикла и будет ждать следующее оконное сообщение

Рис. 22-1. Поток процесса В пытается создать подкласс окна, сформированного потоком процесса А

Теперь допустим, что процесс В хочет создать подкласс окна, порожденного одним из потоков процесса А Сначала код процесса В должен определить описатель этого окна, что можно сделать самыми рязными способами В примере на рис 22-1 поток процесса В просто вызывает FindWindow, затем — SetWtndowLongPtr, пытаясь изменить адрес процедуры WndProc окна Обратитевниманис пытаясь Этот вызов не дает ничего, кроме NULL Функция SetWindowLongPtr просто проверяет, не хочет

ли процесс изменить адрес WndProc окна, созданного другим процессом, и,если да, игнорирует вызов
А если бы функция SetWindowLongPtr могла изменить адрес WndProc? Система тогда связала бы адрес процедуры MySubclassProc с указанным окном. Затем при посылке сообщения этому окну код User32 в процессе А извлек бы данное сообщение, получил адрес MySubclassProc и попытался бы вызвать процедуру по этому адресу. Но это привело бы к крупным неприятностям, так как MySubclassProc находится в адресном пространстве процесса В, а активен — процесс А. Очевидно, если бы User32 обратился по данному адресу, то на самом деле он обратился бы к какому-то участку памяти в адресном пространстве процесса А, что, естественно, привело бы к нарушению доступа к памяти
Чтобы избежать этого, было бы неплохо сообщить системе, что MySubclassProc находится в адресном пространстве процесса В, и тогда она переключила бы контекст перед вызовом процедуры подкласса Увы, по ряду причин такая функциональность в системе не реализована.
Подклассы окон, созданных потоками других процессов, порождаются весьма редко. Большинство приложений делает это лишь применительно к собственным окнам, и архитектура памяти в Windows этому не препятствует. Переключение активных процессов отнимает слишком много процессорного времени. Код MySubclassProc должен был бы выполняться потоком процесса В, но каким именно - новым или одним из существующих? Как User32.dll узнает, с каким процессом связан адрес оконной процедуры?
Поскольку удачных решений этих проблем нет, Microsoft предпочла запретить функции SeiWindowLongPtr замену процедуры окна, созданного другим процессом.
Тем не менее порождение подкласса окна, созданного чужим процессом, возможно: нужно просто пойти другим путем. Ведь на самом деле проблема не столько в создании подкласса, сколько в закрытости адресного пространства процесса. Если бы Вы могли как-то поместить код своей оконной процедуры в адресное пространство процесса А, это позволило бы вызвать SetWindowLongPtr и передать ей адрес MySubclassProс, в процессе А.Я называю такой прием внедрением (injecting) DLL в адресное пространство процесса. Мне известно несколько способов подобного внедрения Рассмотрим их по порядку, начиняя с простейшего.

ы использования фильтров и обработчиков исключений

В отличие от обработчиков завершения (рассмотренных в предыдущей главе), филь тры и обработчики исключений выполняются непосредственно операционной сис темой — нагрузка на компилятор при этом минимальна. В следующих разделах я рас скажу, как обычно выполняются блоки try-except, как и когда операционная система проверяет фильтры исключений и в каких случаях она выполняет код обработчиков исключений.

ы использования обработчиков завершения

Поскольку при использовании SEH компилятор и операционная система вместе кон тролируют выполнение Вашего кода, то лучший, на мой взгляд, способ продемонст рировать работу SEH — изучать исходные тексты программ и рассматривать порядок выполнения операторов в каждом из примеров

Поэтому в следующих разделах приведен ряд фрагментов исходного кода, а свя занный с каждым из фрагментов тект поясняет, как компилятор и операционная система изменяют порядок выполнения кода.

Принудительное завершение процесса

Запретить функции UnhandledExceptionFilter вывод окна с сообщением об исключе нии можно вызовом SetErrorMode с передачей идентификатора SEM_NOGPFAULT ERKORBOX:

UINT SetErrorMode(UINT fuErrorMode);

Тогда UnhandledExceptionFilter, вызванная для обработки исключения, немедлен но вернет EXCEPTION_EXECUTE_HANDLER, что приведет к глобальной раскрутке и выполнению обработчика в BaseProcessStart или BaseThreudStart, который закроет процесс.

Лично мне этот способ не нравится, так как пользователь нс получает никакого предупреждения — приложение просто исчезает.

Приоритеты потоков

В начале главы я сказал, что поток получает доступ к процессору на 20 мс, после чего планировщик переключает процессор на выполнение другого потока. Так происходит, только если у всех потоков один приоритет, но на самом деле в системе существуют потоки с разными приоритетами, а это меняет порядок распределения процессорного времени.

Каждому потоку присваивается уровень приоритета — от 0 (самый низкий) до 31 (самый высокий). Решая, какому потоку выделить процессорное премя, система сначала рассматривает только потоки с приоритетом 31 и подключает их к процессору по принципу карусели. Если поток с приоритетом 31 не исключен из планирования, он немедленно получает квант времени, по истечении которого система проверяет, есть ли еще один такой поток. Если да, он тоже получает свой квант процессорного времени.

Пока в системе имеются планируемые потоки с приоритетом 31, ни один поток с более низким приоритетом процессорного времени не получает. Такая ситуация на зывается "голоданием* (starvation). Она наблюдается, когда потоки с более высоким приоритетом так интенсивно используют процессорное время, что остальные практически не работают. Вероятность этой ситуации намного ниже в многопроцессорных системах, где потоки с приоритетами 31 и 30 могут выполняться одновременно. Система всегда старается, чтобы процессоры были загружены работой, и они простаивают только в отсутствие планируемых потоков.

На первый взгляд, в системе, организованной таким образом, у потоков с низким приоритетом нет ни единого шанса на исполнение. Но, как я уже говорил, зачастую потоки как раз и не нужно выполнять. Например, если первичный поток Вашего процесса вызывает GetMessage, а система видит, что никаких сообщений пока нет, она приостанавливает его выполнение, отнимает остаток неиспользованного времени и тут же подключает к процессору другой ожидающий поток. И пока в системе не появятся сообщения для потока Вашего процесса, он будет простаивать — система не станет тратить на него процессорное время.
Но вот в очереди этого потока появляется сообщение, и система сразу же подключает его к процессору (если только в этот момент не выполняется поток с более высоким приоритетом).

А теперь обратите внимание на еще один момент. Потоки с более высоким приоритетом всегда вытесняют потоки с более низким приоритетом независимо оттого, исполняются последние или нет. Допустим, процессор исполняет поток с приоритетом 5, и тут система обнаруживает, что поток с более высоким приоритетом готов к выполнению. Что будет? Система остановит поток с более низким приоритетом — даже ссли не истек отведенный ему квант процессорного времени — и подключит к процессору поток с более высоким приоритетом (и, между прочим, выдаст ему полный квант времени),

Кстати, при загрузке системы создается особый поток — поток обнуления страниц (zero page thread), которому присваивается нулевой уровень приоритета. Ни один поток, кроме этого, не может иметь нулевой уровень приоритета. Он обнуляет свободные страницы в оперативной памяти при отсутствии других потоков, требующих внимания со стороны системы.

Приостановка и возобновление потоков

В объекте ядра "поток" имеется переменная — счетчик числа простоев данного потока. При вызове CreateProcess или CreateThread он инициализируется значением, равным 1, которое запрещает системе выделять новому потоку процессорное время. Такая схема весьма разумна: сразу после создания поток не готов к выполнению, ему нужно время для инициализации.

После гого как поток полностью инициализирован, CreateProcess или CreateThread проверяет, не передан ли ей флаг CREATE_SUSPENDED, и, если да, возвращает управление, оставив поток в приостановленном состоянии. В ином случае счетчик простоев обнуляется, и поток включается в число планируемых — если только он не ждет какого-то события (например, ввода с клавиатуры).

Создав поток в приостановленном состоянии, Выможете настроить некоторые его свойства (например, приоритет, о котором мы поговорим позже). Закончив настройку, Вы должны разрешить выполнение потока. Для этого вызовите ResumeThread и пере дайте описатель потока, возвращенный функцией CreateThread (описатель можно взять и из структуры, на которую указывает параметр ppiProcInfo, передаваемый в CreateProcess).

DWORD ResumeThread(HANDLE hThread);

Если вызов ResumeThread прошел успешно, она возвращает предыдущее значение счетчика простоев данного потока; в ином случае — 0xFFFFFFFF.

Выполнение отдельного потока можно приостанавливать несколько раз. Если поток приостановлен 3 раза, то и возобновлен он должен быть тоже 3 раза — лишь тогда система выделит ему процессорное время. Выполнение потока можно приостановить не только при его создании с флагом CREATE_SUSPENDED, но и вызовом SuspendThread.

DWORD RuspendThread(HANDLE hThread);

Любой поток может вызвать эту функцию и приостановить выполнение другого потока (конечно, если его описатель известен). Хоть об этом нигде и не говорится (но я все равно скажу!), приостановить свое выполнение поток способен сам, а возобновить себя без посторонней помощи — нет. Как и ResumeThread, функция SuspendThread возвращает предыдущее значение счетчика простоев данного потока. Поток можно приостанавливать не более чем MAXIMUM_SUSPEND_COUNT раз (в файле WinNT.h это значение определено как 127). Обратите внимание, что SuspendThread в режиме ядра работает асинхронно, но в пользовательском режиме не выполняется, пока поток остается в приостановленном состоянии.

Создавая реальное приложение, будьте осторожны с вызовами SuspendThread, так как нельзя заранее сказать, чем будет заниматься его поток в момент приостановки. Например, он пытается выделить память из кучи и поэтому заблокировал к ней доступ. Тогда другим потокам, которым тоже нужна динамическая память, придется ждать его возобновления. SuspendThread безопасна только в том случае, когда Вы точно знаете, что делает (или может делать) поток, и предусматриваете все меры для исключения вероятных проблем и взаимной блокировки потоков. (О взаимной блокировке и других проблемах синхронизации потоков я расскажу в главах 8, 9 и 10.)

---

---