#1. Наверняка среди ваших знакомых есть "крутые" программисты, или люди, таковыми себя считающие ;). Попробуйте как-нибудь проверить их "на вшивость". Предложите им в уме перевести число 12 из шестнадцатеричной в двоичную систему счисления. Если над подобным вопросом "крутой программист" будет думать дольше 10 секунд - значит он вовсе не так крут, как говорит...

#2. Система счисления (сие не подвластное человеческой логике определение взято из математической энциклопедии) - это совокупность приемов представления обозначения натуральных чисел. Этих "совокупностей приемов представления" существует очень много, но самая совершенная из всех - та, которая подчиняется позиционному принципу. А согласно этому принципу один и тот же цифровой знак имеет различные значения в зависимости от того места, где он расположен. Такая система счисления основывается на том, что некоторое число n единиц (radix) объединяются в единицу второго разряда, n единиц второго разряда объединяются в единицу третьего разряда и т. д.

#3. "Разрядам" нас учили еще в начальных классах школы. Например, у числа 35672 цифра "2" имеет первый разряд, "7" - второй, "6" - третий, "5" - четвертый и "3" - пятый. А "различные значения" цифрового знака "в зависимости от того места, где он расположен" и "объединение в единицу старшего разряда" на тех же уроках арифметики "объяснялось" следующим образом:

#4. Очень наглядно это отображают обыкновенные счеты. Набранное на них число 35672 будет выглядеть... см. рисунок слева в общем...

Чтобы набрать число 35672 мы должны передвинуть влево две "костяшки" на первом "прутике", 7 на втором, 6 на третьем, 5 на четвертом и 3 на пятом. (У нас ведь 1 "костяшка" на втором - это то же самое, что и 10 "костяшек" на первом, а одна на третьем равна десяти на втором, и так далее...) Пронумеруем наши "прутики" снизу вверх - да так, чтобы номером первого был "0"... И снова посмотрим на наши выражения:

Это (если сверху вниз считать) сколько на каждом "прутике" "костяшек" влево отодвинуто.

Это номер прутика (самый нижний - 0), на котором отодвинуто определенное число костяшек.

Это на каждом прутике - по 10 костяшек нанизано, не все влево отодвинуты, но всего-то их - 10!

Кстати, красненькое 10 в последнем выражении соответствует основанию (radix) системы счисления (number system).

#5. Пальцев на руках у человека 10, поэтому и считать мы привыкли в системе счисления с основанием 10, то есть в десятичной. Если вы хорошо представляете себе счеты и немного поупражнялись в разложении чисел аналогично выражению 1, то перейти на систему счисления с основанием, отличным от привычной, особого труда для вас не составит. Нужно всего лишь представить себе счеты, на каждый прут которых нанизано не привычные 10 костяшек, а... скажем, 9 или 8, или 16, или 32, или 2 и... попробовать мысленно считать на них.

#6. Для обозначения десятичных чисел мы используем цифры от 0 до 9, для обозначения чисел в системах счисления с основанием менее 10 мы используем те же цифры:

Если же основание системы счисления больше десяти, то есть больше, чем десять привычных нам чисел, то начинают использоваться буквы английского алфавита. Например, для обозначения чисел в системе счисления с основанием 11 "как цифра" будет использоваться буква А:

В системе счисления с основанием 16 - буквы от A до F:

И так далее...

Правда, при определенном основании (при каком?) буквы аглицкого алфавита закончатся...

Но нам это, пока что, глубоко фиолетово, так как работать мы будем только с тремя radix-ами: 10 (ну естественно), 16 и 2. Правда, если кто на ДВК поизучать это дело собирается, тому еще и radix 8 понадобится.

#7. Числа в любой системе счисления строятся аналогично десятичной. Только на "счетах" не с 10, а с другим количеством костяшек.

Например, когда мы пишем десятичное число 123, то имеем в виду следующее:

Если же мы используем символы 123 для представления, например, шестнадцатеричного числа, то подразумеваем следующее:

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

Истина где-то рядом...

#8. Трудность у вас может возникнуть при использовании символов A, B, C и т. д. Чтобы решить эту проблему раз и навсегда, необходимо назубок вызубрить ма-а-аленькую табличку "соответствия" между употребляемыми в "компьютерном деле" систем счисления:

Следуя этой таблице, число 5BC в шестнадцатеричном формате "строится" так:

А теперь, если пораскинуть мозгами, с легкостью переведем 5BC из шестнадцатеричной в десятичную систему счисления:

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

В общем-то решать вам. В Delphi тоже много чего объединять можно.

#9. Двоичная система по-компьютерному обзывается "bin", "родная" десятичная - "dec", а шестнадцатеричная - "hex". Это так компьютерщики обозвали те системы счисления, с которыми имеют дело... А обозвали потому, что у них ведь полный бардак в голове, оказывается!

Например, 10 - что это за число? Да это вообще не число! Палка и барабан - и только... А вот 10d или же 10_10 - уже понятно, что это - число, соответствующее количеству пальцев на обеих руках. И именно на обеих, а не на двух. Почему не на двух? - А потому что на двух в какой системе? Ежели в двоичной, так это на десяти! То бишь 100, если в десятичной...

Вот и придумали программисты после числа буковку писать - b, d или h. А самые ленивые еще и директиву специальную придумали: напишут в самом начале программы какой-нибудь .radix 16 и будут автоматически все числа, которые без этих букв, за шестнадцатеричные приниматься.

#10. Еще немного про перевод между "радиксами". (Вообще-то это плевое дело, конечно, если представляешь себе, что такое "совокупность приемов представления обозначения натуральных чисел").

Например, преобразование числа 42936 из десятичного в шестнадцатеричный формат проводится следующим образом (в скобках - остаток):

А вот и обратный процесс - перевод из HEX в DEC числа A7B8h:

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

#11. Если честно, то конкретный "рисунок" цифр - единица там палкой обозначается, двойка - лебедем - это все лишь историческая случайность. Мы запросто можем считать в "троичной" системе счисления с цифрами %, *, _ (где запятая - это знак препинания, а вовсе не число):

Или использовать родные цифры в десятичной системе счисления, но по другому "вектору упорядоченных цифр" - 1324890576:

Правда, этим немножко затрудняется понимание происходящего? А ведь тоже десятичная система! И рисунок цифр как бы знакомый :-)))

Или вообще считать в 256-ричной системе счисления, используя в качестве "рисунка цифр" таблицу ASCII-символов! (По сравнению с вами, извращенцами, любой Биллгейтс будет девственником казаться!!).

#12. Теперь самая интересная часть Марлезонского балета.

Компьютер, как известно, считает только в двоичной системе счисления. Человеку привычна десятичная. Так нахрена еще и шестнадцатеричную какую-то знать нужно?

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

Переведите число A23F из шестнадцатеричной "нотации" в двоичную. (Один из возможных алгоритм приведен в п.10.). В результате длительных манипуляций у вас должно получиться 1010001000111111.

А теперь еще раз посмотрите на таблицу в п. 8. (которую вы как бы уже и выучили) и попробуйте то же самое сделать в уме :

Каждой шестнадцатеричной цифре соответствует тетрада (4 штуки) ноликов и единичек. Все, что потом нужно сделать - "состыковать" эти тетрады. Круто? Вас еще не то ждет!

#13. Кстати (наверняка вы это уже знаете):

... но это так... кстати...

#14. И, напоследок, еще несколько слов про HEX и BIN :). Зайдите в Norton Commander, наведите указатель на какой-нить файл и нажмите там F3. А когда он откроется - на F4. Там какие-то нездоровые циферки попарно сгруппированы. Это и есть "нолики и единички" (которыми в компьютере все-все-все описывается), но в шестнадцатеричном формате...

Следует основательно разобраться с системой счисления. Минимум, что должен вынести из этой главы юзвер, вступивший на скользкий путь низкоуровневого программирования - это научиться переводить числа между DEC, HEX и BIN... хе-хе... В УМЕ!

1.2. Регистры

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

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

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

Вот их "имена собственные" - AX, CX, DX, BX (именно в такой последовательности они "упорядочены" в Intel'овских микропроцессорах).

А сейчас мы поближе посмотрим на эти "рабочие лошадки" микропроцессора.

1. Запустите программу DEBUG.EXE1.

2. Когда появится приглашение в виде "минусика", введите букву "R" (можно и "r" - регистр символов значения не имеет) и нажмите на "Enter".

Не правда ли, весьма похоже на то, что показывают в художественных фильмах про хакеров?

- Ну и что это такое? - скептически спросите вы.

- А черт его знает! Будем разбираться!

#2. То, что у вас должно появиться - это список доступных регистров и текущее значение каждого из них. Как видите, значения регистров AX, BX, CX, DX равны 0. Не правда ли, создается впечатление, что они просто-напросто ждут того, чтобы в них внесли какое-либо значение?

Природа не терпит пустоты. Писателей приводит в ужас чистый лист бумаги...

Весьма скоро и вы при виде "пустых" регистров будете испытывать непреодолимое наркотическое желание чем-нибудь их заполнить...

Однако прежде чем мы сделаем это в первый раз, давайте уточним тип этих "переменных".

А он очень простой, этот тип - шестнадцатеричное число в диапазоне 0...FFFF. Или, если в BIN, то - от 0 до 1111 1111 1111 1111.

Маловато будет? А вот создатели первых "IBM-совместимых" :) компьютеров посчитали, что и этого много2! 16-битная переменная еще и на две части дробится - для совместимости с языками ассемблера для предыдущих моделей процессора Intel, работавших только с 8-битными регистрами; да и просто ради удобства...

В общем, в умных книжках рисуют вот такую вот "нездоровую" схемку3:

А означает она следующее.

Физически существует один регистр - AX, а вот логически он делится на два - на старшую (AH) и младшую (AL) части (от английского - high и low).

Очевидно, что присвоить AX значение, например, 72F9h, мы можем следующими способами:

Точно так же присвоить значение 78h регистру AH можно двумя способами:

То же самое, но для регистра AL:

Тех, кого смущают числа с буквами, мы со зловредной ухмылкой отсылаем к 1.1. Система счисления :-]

#3. Если рассматривать регистр "целиком", то каждый из них имеет "длину" 16 бит, которые принято нумеровать справа налево4 . Так, для числа 2F4Dh, внесенного, например, в регистр AX, мы можем нарисовать такую вот "навороченную" табличку:

Внимательно смотрим на таблицу: одной шестнадцатеричной цифре соответствует тетрада двоичных цифр (4 шт., они же - 4 бита). "Емкость" регистров AH и AL - две тетрады, т. е. 8 бит. Точно такую "длину" имеют: коды символов, скан-коды клавиш, номера функций прерываний и куча всего прочего, чего вы пока еще не знаете.

Емкость AX (состоящего из двух половинок) - 4 тетрады, т. е. 16 бит; они же (эти 16 бит) иначе еще называются "словом"...

#4. "Принудительно" присвоить регистру значение можно при помощи той же команды "R", только с параметром "имя собственное регистра".

Например, команда

выбросит вам на монитор

Введите после двоеточия, например, число 123 и снова нажмите на Enter:

На дисплее опять появится приглашение "-", на которое мы отвечаем командой "R" без параметров и таким образом вновь просматриваем значения наших регистров:

Смотрим внимательно - AX=0123, что и требовалось доказать...

Примечания

1). В W9X она находится в папке WINDOWS\COMMAND\. В Y2K и XP - WINDOWS\SYSTEM32\. В обоих случаях достаточно набрать в командной строке "debug", чтобы она запустилась.

2). Не забудьте, что при тогдашней технологической базе и это было большим прорывом. А экстенсивное расширение, например, разрядности, во-первых, нужно правильно предвидеть (вспомните, сколько в том же MS-DOS закладок на будущее, которые никуда не пошли за ненадобностью), а во-вторых, правильно оценить (в буквальном смысле). Неужели вы думаете, что, например, производители памяти не могут легким мановением руки увеличить ширину шины, соединяющую память с процессором? Могут, но во-первых - это резко повысит стоимость памяти, а во-вторых - не гарантирует повышения производительности.

3). Впоследствии мы немного усложним эту схемку - регистры современных процессоров 32-разрядные и называются немного иначе ;)

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

1.3. Память

#1. Первым видом памяти, с которым мы войдем (придется!) в тесный физический контакт, будет оперативная, она же - RAM (от английского - Random Access Memory). Оперативная память - это своего рода "рабочая площадка", по которой суетится этакий шустрый многорукий дядька-процессор - чего-то там собирает, от кучи к куче бегает, всех ругает... :)

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

Короче - пришло время испробовать еще одну команду из скромного арсенала DEBUG'a! Запустите debug и введите команду D (от английского - DUMP).

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

Слева - это адрес памяти. В центре - 16 столбцов из спаренных цифр...

А здесь и повториться лишний раз не грех. Каждая пара шестнадцатеричных цифр - это байт. Смотрите внимательно на дамп! Байт по адресу 100 имеет значение 6A, байт по адресу 101 - 00, байт по адресу 102 - 68... Эти "сладкие парочки" - и есть неделимая "единица адресации" оперативной памяти.

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

И, наконец, столбец справа - это символы, соответствующие шестнадцатеричным кодам центрального столбца (например, коду 6A соответствует символ J). Большинству кодов не соответствует никакой из "печатных символов" - таким в колонке справа соответствуют точки.

#2. А теперь потренируем наши пальчики дампировать память - пройдемся по некоторым "историческим местам" нашей оперативной памяти... Для этого мы будем вводить команду D с параметром.

Например, команда (параметр L8 означает "вывести 8 байтов"):

покажет вам системную дату в правом столбце дампа.

Короче, искателям приключений выдаем "простыню" самых интересных адресов (большинство слов в описании вам пока должны быть непонятны, но вы не пугайтесь - понимание придет!).

• 0:417 - два байта разрядов состояния клавиатуры. Они активно используются ROM-BIOS для управления интерпретаций действий клавиатуры. Изменение этих байтов изменяет значение нажатых клавиш (например, верхний или нижний регистр).

• 0:41A - cлово по этому адресу указывает на начало буфера BIOS для ввода с клавиатуры, расположенного начиная с адреса 41E. В этом буфере хранятся и ждут обработки результаты нажатия на клавиши. Конец буфера - слово по адресу 41C.

• 0:43E - байт указывает, необходима ли проверка дискеты перед подводом головки на дорожку. Разряды 0...3 соответствуют дисководам 0...3. Если разряд установлен в 0, то необходима проверка дискеты. Как правило, вы можете обнаружить, что разряд установлен в 0, если при предыдущем обращении к дисководу имели место какие-либо проблемы. Например, разряд проверки будет равен 0, если вы попытаетесь запросить каталог на дисководе, на котором нет дискеты, и затем на запрос, появившийся на экране дисплея: "Not ready reading drive B: Abort, Retry, Ignore?" вы ответите: "A".

• 0:44C (2 байта) - длина регенерации экрана. Это число байтов, используемых для страницы экрана. Зависит от режима.

• 0:44E (2 байта) - смещение для адреса начала текущей страницы в памяти дисплея. Этот адрес указывает, какая страница в данный момент используется (маленькая, но неприятная подробность - это смещение внутри текущего сегмента видеопамяти, без учета самого сегмента. Например, для нулевой страницы смещение всегда будет равно нулю.)

• 0:460 (2 байта) - размер курсора, представленный в виде диапазона строк развертки. Первый байт задает конечную, а второй - начальную строку развертки.

• 0:449 - значение этого байта определяет текущий видеорежим. Для расшифровки требуется целая таблица. Например, 3 - 80-колонный текст, 16 цветов; 13h (19) - 256-цветный графический режим 320x200 и т. д.

Ну и хватит для первого раза. Кому мало - ищите дополнительную документацию :-p "

1.4. Программа

#1. Любая программа выполняется последовательно (мы ведь пока обсуждаем "простой" IBM PC, а не какой-нибудь крутой векторный параллельный суперкомпьютер). То есть пока не выполнилась текущая "строка" (инструкция) программы, следующая не выполнится. Совсем другой вопрос, какая "строка" будет выполнена после "текущей" (здесь мы имеем дело со всевозможными логическими "ветвлениями", "циклами" и т. д.), или же строчку из какой программы процессор выполнит следующей, а какая - будет ждать своей очереди (так называемая "многозадачность", которую пока трогать не будем - в большинстве случаев мы можем прекрасно прожить и без нее, поскольку все заботы об этом все равно берут на себя операционные системы).

Итак, у нас есть оперативная память, в которую загружается программа перед ее выполнением (сразу же по нажатию на Enter из Norton Commander). Операционная система, которая, собственно, и загружает программу, сообщает процессору, что надо начать обрабатывать команды, которые в памяти начинаются с такого-то адреса. И здесь первый подводный камень, вернее скала, которую трудно не заметить.

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

Каким образом? А очень легко! Компьютер "распознает" как выход из программы специальную последовательность байтов. Например, для исполнимых файлов типа com (именно с этим типом файлов мы будем работать на начальном этапе) достаточно последовательности CD и 20.

Пробуем-проверяем? Ну конечно же! Только для этого вам понадобится какой-нибудь шестнадцатеричный редактор, например, HexWorkshop.

Все очень просто - создаем новый файл, единственным содержимым которого является последовательность CD 20, и сохраняем его как, например, myprg_1.com. Если вы позаботились о том, чтобы после CD 20 не было никаких прочих символов, то исполнимая программа будет "весить" только 2 байта.

Запускать это ваше первое творение лучше из Norton или Volcov Commander (все же это пока что DOS'овская программулька).

Что же она делает, эта 2-байтовая малышка? А ничего, просто этот файл обладает двумя важными свойствами:

• это - программа;

• эта программа - программа с корректным выходом.

Последнее и является единственным, что она пока что может делать (корректно выгружаться из памяти)...

Еще к вопросу о выгружаемости - если после CD 20 вы напишите еще что-нибудь (чепуху), она все равно будет проигнорирована. Дело до ее выполнения просто-напросто не дойдет. Другое дело - если вы напишите чепуху до...

#2. Честно говоря, опасно при низкоуровневом программировании чепуху писать. Можно невзначай и винт отформатировать :))). Поэтому лабуду писать не будем, вернее - будем, но не лабуду...

Итак, продолжим наше извращение. Познакомимся еще с некоторыми "машинными командами" (в нашем случае - последовательностями шестнадцатеричных циферек).

• B82301 - внести значение 0123h в AX;

• 052500 - прибавить значение 0025h к AX;

• 8BD8 - переслать содержимое AX в BX;

• 03D8 - прибавить содержимое AX к BX;

• 8BCB - переслать содержимое BX в CX;

• 31C0 - очистка AX;

• CD20 - конец программы. Передача управления операционной системе.

Вот и давайте создадим еще одну программу типа com со следующим "шестнадцатеричным содержимым":

Если вы все ввели правильно, то прога у вас без проблем запустится, а операционная система не будет ругаться... Правда, визуально (в смысле на мониторе) вы ее работу так и не заметите, но поверьте на слово - она работает! В этом вы еще убедитесь, когда посмотрите на ее работу изнутри - не различающими цветов глазами компьютера... Только сначала еще немного теории...

#3. Теперь поговорим о втором подводном камне :). Один из принципов фон Неймана звучит приблизительно так: машине безразлично целевое назначение данных... Одна и та же цепочка битов может быть и машинными командами, и данными (например, символами, выраженными в виде кодов - есть такая "таблица символов ASCII", наверняка вы ее знаете).

Что из этого следует? А то, что компьютеру нужно указывать, что подразумевается под той или иной "простыней" из битов - данные или код.

На высоком уровне это делает операционная система. Например, она не пытается загрузить в память для выполнения файлы с расширениями, отличными от COM, EXE и BAT (последний вообще не из этой оперы, но принцип сохраняется).

Хотя..., вы всегда можете поэкспериментировать! Смените, например, у какого-нибудь текстового файла тип с TXT на COM и попробуйте его запустить на выполнение (хотя мы это делать настоятельно не рекомендуем!). В большинстве случаев ваш компьютер зависнет! Потому что:

1. Он пытается интерпретировать данные как код. Соответственно, в процессор "попадает" всякая ерунда.

2. Вряд ли он натолкнется на последовательность CD 20 вашем тексте :). Даже в том случае, если этот код выполнится "успешно" - ваша программа не возвратит управление операционной системе, а пойдет выполняться хлам, содержащийся в оперативной памяти. Как-то - остатки ранее выполненных программ, куски чьих-то данных, интерпретированные как код... и прочая многочисленная ерунда...

Почти такой же эффект, но с потенциально большей разрушительной силой может получиться, если управление получит ИСПОРЧЕННЫЙ код, который вроде бы "в основном" правильный, но часть его вместо инициализации переменных и прочих подготовительных действий в лучшем случае ничего не делает, а в худшем портит другой код и данные...

Как вам тяжело "въехать" в смысл повествования, состоящего из кусков различных книг, так и компьютеру тяжело понять подобную "мешанину". С той лишь разницей, что любую "неинтересную книгу" вы можете использовать в качестве туалетной бумаги, а вот "компутер" подобного права выбора лишен - он должен в это "въезжать", его процессор начинает перегреваться, а мозги кипят и вытекают через низкоуровневые порты ввода-вывода (командами IN и OUT соответственно).

#4. Еще немного идеологии. О программе, которая выполняется в памяти...

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

Страшно? Медитируйте!

#5. Как уже говорилось в #3, одна и та же последовательность битов в памяти может быть:

• кодом (т.е. что компьютеру нужно делать) - последовательностью инструкций;

• данными (т.е. с чем компьютеру нужно выполнять ту или иную работу). Именно данные являются исходной "задачей" и конечным результатом работы процессора.

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

Соответственно, и программа состоит из трех частей (сегментов): сегмента данных (data), сегмента кода (code) и сегмента стека (stack)...

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

#6. Помните, как в конце фильма "Matrix" Нео в конце концов увидел ее - черно-зеленую "матрицу"? Сейчас с вами произойдет нечто подобное! ;)

Посмотрите на машинные коды, и "что они делают" в #2. Немножко дополним эту "простыню". Например, командой "внести значение" 1234 последовательно в каждый из "регистров общего пользования":

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

Однако никто не пишет программы в шестнадцатеричных редакторах! Никто! Это большая глупость! Единственное, зачем мы вам про это рассказываем - это чтобы вы поняли, что могут означать загадочные пары шестнадцатеричных цифр в дампе...

Нет необходимости заучивать, что B8 - это "переместить в регистр AX", BB - "переместить в регистр BX" и так далее... Когда-нибудь это может пригодиться тому, кто будет писать компилятор, умеющий генерировать исполняемый код, упаковщики исполняемых файлов, самомодифицирующийся код или, на худой конец, конструкторы полиморфных самошифрующихся вирусов. Но это мы оставим на будущее...

Все намного проще!

В этом вы можете убедиться, загрузив вашу программу myprg_1.com в debug (например, командной строкой

и введя команду "u".

А вот дальше начинается самое интересное :)))

#7. Вот что вы должны увидеть:

Возвратившись к #2, перенесем сюда "описание" машинных команд.

Эти mov, add, xor, int - так называемые "мнемонические команды" (более или менее понятные человеку), на основе которых формируется (это debug делает) "машинный код". Не правда ли, так намного легче?

Соответственно, вместо шестнадцатеричных кодов мы легко могли вводить эти команды при помощи команды "A" (однако этим мы займемся позже).

#8. А теперь мы выполним нашу программу пошагово - произведем так называемую "трассировку" при помощи команды "T".

Итак, вводим "T" и жмем на Enter!

Вот что мы видим:

Смотрим на значение AX и вспоминаем предыдущую инструкцию - "внести значение 0123h в AX". Внесли? И правда! А в самом низу - код и мнемоника команды, которая будет выполняться следующей...

Вводим команду "T" снова:.

AX=0148 - "прибавить значение 0025h к AX". Сделали? Сделали!!

Вводим команду "T" снова:.

AX=0148=BX - "переслать содержимое AX в BX". Сделали? Сделали!!

Вводим команду "T" снова:

"Прибавить содержимое AX к BX". Оно? А то!

Вводим команду "T" снова:

"Переслать содержимое BX в CX". Сделано!

Вводим команду "T" снова:

"Очистка AX"? И точно: AX=0000!

Вводим команду "T" снова... И ГРОМКО РУГАЕМСЯ!!

Потому что, по идее, сейчас наша программа должна была завершиться - у нас же там код выхода прописан, а она куда лезет? NOPы какие-то (если продолжать команду "T" вводить), CALL 1085 (да вы продолжайте "трассировку", продолжайте!)

Для тех, кому лень продолжать жать на букву "T", введите для разнообразия команду "G" (от английского GO). На монитор должна вывалиться надпись "Нормальное завершение работы программы".

- Уф , - должны сказать вы - Работает!

А то!

#9. Только непонятно вот, почему вдруг между int 20 (CD 20) и надписью "Нормальное завершение работы программы" куча всяких "левых" непонятных команд (в том случае, если вы и дальше производили тарассировку, а не воспользовались "халявной" командой "G")?

А потому, дорогие наши, что вы имели счастье нарваться на прерывание (interrupt)!

Понимаете ли, завершить программу - дело непростое :). Нужно восстановить первоначальное значение регистров, восстановить переменные среды и кучу всего другого! Знаете, как это сложно?

Однако эта процедура насколько сложная, настолько и типичная для исполняемых программ. А по сему разработчики операционной системы решили избавить программистов от необходимости делать это вручную, и включили эту стандартную процедуру в ядро операционной системы. И сказали: "да будешь ты (процедура обработки прерывания) вызываться как int 20, и будешь ты обеспечивать корректную передачу управления из выполняемой программы - назад в ядро". И стало так...

Ну, посудите сами, должна же операционная система ну хоть что-нибудь делать!!

1.5. Прерывания

#1. Прерывание - это СИГНАЛ процессору, что одно из устройств в компьютере НУЖДАЕТСЯ в обслуживании со стороны программного обеспечения. В развитие этой же идеи, программам позволили самим посылать запросы на обслуживание через механизм прерываний. Получив этот сигнал, процессор временно переключается на выполнение другой программы ("обработчика прерывания") с последующим ВОЗОБНОВЛЕНИЕМ выполнения ПРЕРВАННОЙ программы.

Когда же и "кем" генерируются эти "сигналы" (в смысле "прерывания")?

1. Многочисленными "схемами" компьютера, его устройствами. Например, соответствующее прерывание генерируется при нажатии клавиши на клавиатуре.

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

3. Наконец, прерывания могут преднамеренно генерироваться программой, для того чтобы произвести то или иное "низкоуровневое" действие.

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

Для тех, кто не понял. Представьте себе, что вы сидите за компом и выполняете какую-либо работу. И вдруг ловите себя на мысли, что вам СРОЧНО НУЖНО сходить в туалет (терпеть вы больше уже не можете). Вот это СРОЧНО НУЖНО и есть сигнал-прерывание, по которому вы начинаете выполнять определенную СТАНДАРТНУЮ последовательность инструкций (программу обработки прерывания), как-то: встать, пойти туда-то, включить свет ... вернуться, сесть за комп и ПРОДОЛЖИТЬ РАБОТУ с того же самого места, на котором вы остановились перед выполнением программы "поход в туалет". В данном случае наш мозг выполняет роль процессора, наши внутренние органы сигнализируют мозгу о потребности в обслуживании, а само обслуживание проводится "программой-навыком", заложенным в процессе нашего развития и (хм!) воспитания.

#2. Программы обработки прерывания располагаются в оперативной памяти (ну а где же еще им располагаться?!) и, следовательно, имеют свой АДРЕС. Однако генератору прерывания этот адрес знать не обязательно :). Есть такая замечательная штука (спросите у тех, кто пишет вирусы) - таблица векторов прерываний. Это таблица соответствия номеров и адресов памяти, по которым находятся программы их обработки.

Почему "спросите у вирмейкеров?". А потому, что поменять адрес "программы обработки прерывания" на другой - проще пареной репы (мы этим еще займемся), в результате чего при запуске классической программы "HELLO, WORLD" может получиться еще более классический format c:...

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

Однако на самом деле все намного сложнее :)). Но ведь это только "первое погружение" в прерывания, верно? А посему - пока что без особых "наворотов"...

#3. Одно прерывание мы с вами уже знаем. Это 20-е прерывание, обеспечившее "выход" из нашей COM-программы. Сегодня мы пойдем немножко дальше - помимо "выхода" попробуем поработать еще с одним прерыванием.

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

Ну, например, вот одно симпатичное, под названием "прокрутить вверх активную страницу".

Внимательно читаем описание (и наши комментарии):

INT 10h, AH=06h (_1) - прокручивает вверх произвольное окно на дисплее на указанное количество строк.

ВХОДНЫЕ ПАРАМЕТРЫ: (_2)

• AH=06h; (_3)

• AL - число строк прокрутки (0…25) (AL=0 означает гашение всего окна); (_4)

• BH - атрибут, использованный в пустых строках (00h…FFh); (_5)

• CH - строка прокрутки - верхний левый угол; (_6)

• CL - столбец прокрутки - верхний левый угол;

• DH - строка прокрутки - нижний правый угол;

• DL - столбец прокрутки - нижний правый угол;

Далее представим входные параметры в виде таблички: (_7)

Плюс подробнейшее толкование, что подразумевается под словом "атрибут" (регистр BH):

ВЫХОДНЫЕ ПАРАМЕТРЫ: отсутствуют (т.е. ни один регистр не меняется). (_8)

Входные строки гасятся в нижней части окна. (_9)

Нормальное значение байта атрибута - 07h. (_10)

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

_1. Черным по белому, в толстом талмуде, описывающем функции прерываний, написано: "Драйвер видео вызывается по команде INT 10h и выполняет все функции, относящиеся к управлению дисплеем".

И далее. "…ДЕЙСТВИЕ: после входа управление передается одной из 18 программ в соответствии с кодом функции в регистре AH. При использовании запрещенного кода функции, управление возвращается вызывающей программе.

НАЗНАЧЕНИЕ: прикладная программа может использовать INT 10h для прямого выполнения функций видео..."

Вот что из этого следует:

• выполнив команду INT 10h, мы ВЫПОЛНЯЕМ одну из "функций видео";

• так как функций видео - много, необходимо УКАЗАТЬ, КАКУЮ именно ФУНКЦИЮ из МНОЖЕСТВА мы хотим ВЫПОЛНИТЬ.

Дело в том, что "прерывание номер десять" - это не только "прокрутка окна", но и, например, "установка режима видео", "установка типа курсора", "установка палитры" и многое другое. Нас же интересует именно первое, поэтому из списка возможных значений (он приведен ниже) мы выбираем именно AH=06h.

Нижеследующая табличка называется "Функции, реализуемые драйвером видео":

Соответственно, если перед выполнением INT 10 в регистре AH будет значение 06h, то выполнится именно "прокрутить вверх активную страницу", а не что-то другое из "простыни" функций десятого прерывания...

Теперь читаем описание дальше (смотрим на циферки в скобках):

_2. Входные параметры? Что тут может быть непонятного? Даже запуск ракеты с атомной боеголовкой требует прежде всего указать координаты цели... Чего уж тут говорить об обыкновенной функции?

_3. То, о чем мы уже говорили - номер функции из "простыни".

_4. Т.е. на СКОЛЬКО строчек прокручивать. Вспомните так называемый "скроллинг" в любой прикладной программе. На кнопки Up, Down подвешен скроллинг на одну строчку (не путать с координатами курсора), а вот на PgUp и PgDown - штук на 18 строк (AL=01h и AL=12h соответственно). А вот AL=0, вместо того чтобы вообще не скроллировать (по идее), поступает наоборот - "скроллирует" все, что может.

_5. Скажем так - какого цвета будет окно и символы в нем после скроллирования.

_6. Как известно из школьного курса геометрии, прямоугольник можно построить по двум точкам. Это утверждение справедливо и для окна, в котором мы желаем проскроллировать наш текст.

_7. Резюме того, что было написано выше.

_8. К примеру, попала ли наша ракета в цель или нет ;).

_9. Если бы мы использовали функцию 07h, то было бы глубокомысленно написано, что "строки гасятся в верхней части окна".

_10. Это то самое, которое в DOS по умолчанию. Т.е. белыми буквами на черном фоне. Правда, это 07h лучше все же рассматривать как 00000111b :) но это уже совсем другая проблема...

#4. А теперь мы напишем программу. Ручками, без использования компилятора. Запускаем наш любимый debug.exe, вводим команду "а" и судорожно стучим по клавиатуре:

Сначала запускаем из-под Norton Commander. Затем запускаем из-под debug. Трассируем. Открываем в HEX-редакторе. Смотрим на "бессмыслицу" шестнадцатеричных циферек. Медитируем, медитируем и еще раз медитируем...

1.6. Немножко программируем и немножко отлаживаем

#1. Тем, кто не в курсе - НАСТОЯТЕЛЬНО рекомендую проштудировать предыдущие части курса, иначе "въехать" будет сложно. Тем же, кто внимательно читал предыдущие главы, нижеследующие упражнения для ума и пальцев покажутся детским лепетом...

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

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

Если мы будем программировать ЭТО линейно (именно так для начала), то очевидно, что все, что мы должны сделать - это заданное количество раз (5) заставить машину выполнить вышеуказанные операции, изменяя перед "запуском прерывания" значения регистров AL, BH, CX, DX (полное описание 6-й функции 10-го прерывания ищите в прошлых главах).

#2. Вот к каким умозаключениям вы должны были придти, пораскинув мозгами. За атрибут (то бишь цвет) у нас отвечает регистр BH. Он был равен 10h, а нужно на 10h больше... это, значит, 20h будет...

Ладно... CX (он же CH и CL, как известно) - это ТОЖЕ ШЕСТНАДЦАТЕРИЧНЫЕ координаты левого верхнего угла нашего окошка. Чтобы "окно в окне" получилось, все это нужно на строчку больше сделать и на колонку больше тоже, и все считать в HEX'e. Получается, что в регистр СH нужно вместо значения 05h внести 06h, а в регистр CL вместо 10h - 11h.

А еще можно одним махом в CX записать число 0510h той же командой mov.

Ладно... DX (DH и DL соответственно) - это координаты правого нижнего угла прямоугольника. DH=10h-1h=Fh и DL=3Eh-1h=3Dh.

Ну, а AL=0 и AH=6 - это уже и ежу понятно из описания данной функции (mov AH,6) данного прерывания (INT 10h).

Все, что осталось - это набить в debug'е после команды "a" эти мнемоники энное количество раз. (кажется 5). Набиваем!!

Правда, красивые циферки-буковки? Набиваем-набиваем! Если сейчас к вам подойдут недZенствующие приятели/коллеги и посмотрят, что вы тут колупаете, то ни черта не поймут и покрутят пальцем у виска. Привыкайте к этому. Только не говорите им, что пытаетесь сейчас получить Матрицу, ПОТОМУ ЧТО это неправда. А неправда это потому, что сейчас Матрица в очередной раз обманула вас!

#3. ВСЕ ПОТОМУ, ЧТО МОЗГАМИ ДУМАТЬ НАДО, А НЕ ТОЛЬКО СЛЕПО СЛЕДОВАТЬ РУКОВОДСТВУ!

У вас только первое окно прорисуется, сразу же после чего программа натолкнется на INT 20h и благополучно завершится! А следовательно, и все, что после первого CD 20 написано будет - останется проигнорированным! Исправляйте! (Т.е. уберите все INT 20 КРОМЕ ПОСЛЕДНЕГО).

Второй момент. ВОЗВРАЩАЕТ ЛИ это прерывание ЧТО-НИБУДЬ В РЕГИСТР AX? Смотрите описание. Ничего? Ну так какого черта тогда по новой вводить XOR AL,AL и MOV AH,06 и переприсваивать AH значение 6h, если и без того AH = 6h? Один раз ввести - более чем достаточно!

Скажите, какая мелочь- байтом больше, байтом меньше! А я скажу вот что - на то он и assembler, чтобы "байтом меньше".

Исправляйте!

#4. - Исправляйте? - возмутитесь вы - Да это же по-новому все вводить нужно!

- По-новому? - возмутимся мы в свою очередь! - Зачем по-новому? Вы что, с ума сошли?

1. Что вам мешает после команды "a" указать адрес, который вы желаете переассемблировать? И благополучно заменить старую команду на новую!

- А что делать, если не переассемблировать нужно, а вообще удалить?

2. Существует куча способов, что вы в самом-то деле! Например, в HEX Workshop с блоками шестнадцатеричных цифр запросто можно работать. Да и в других программах это можно делать - например, в HIEW или даже в Volcov Commander.

Кстати, если процессор встретит команду NOP, то он просто побездельничает некоторое очень короткое время.

ПРОБУЙТЕ!! В конце концов, ваша прога должна принять такой вот вид:

О, да! Получившаяся у вас программа написана долго и бездарно! Имейте это в виду :)). Мы же торжественно обещаем, что в последующих главах обязательно ее усовершенствуем. Да, вот еще что - особенно извращенные могут попытаться заменить INT 20 на JMP 100. Получится, конечно, не ахти, но все же - "анимация" ;)

#5. А теперь мы попробуем ОТЛАДОЧНЫЙ прием! Все кракеры его знают и пользуются им для взлома софта. Имейте в виду, пока вы будете использовать его для своих исполняемых программ - вы программер, исправляющий ошибки, а как только попытаетесь использовать это для отвязки чужой программы от какого-нибудь серийного номера - ваша деятельность станет считаться неэтичной или незаконной. Так что думайте сами, что лучше - флаг в руки или барабан вместе с петлей на шею.

Итак, вводим приблизительно такую командную строку - debug имя_проги.com или же подгружаем прогу в отладчик командой "l" (от слова load) и трассируем, как вы уже неоднократно это делали.

Цель - "на лету" (без изменения кода) заставить первое окошко "рисоваться" не синим (BH=10h), а красным (BH=40h) цветом.

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

Состояние: обнулился регистр AX (первую команду MOV AL,AL мы не видим). Процессор готовится выполнить команду MOV BH,10. Дадим ему это сделать!

Состояние - в BX уже внесен код синего цвета, который нам по условию необходимо заменить на красный (т. е. заменить значение регистра BX с 1000h на 4000h).

Вот теперь-то мы и делаем это "на лету":

А действительно ли сделали? Проверим!

Состояние? BH теперь равно 40h! Мы "вклинились" между строчками:

И изменили текущую цепь событий, заставив программу делать ТО, ЧТО НАМ НУЖНО! Поздравляю!

А дальше - вводим команду "g" и даем нашей тупорылой программе исполниться. 1:0 не в пользу Матрицы!

Медитируйте!

1.7. Стек

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

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

Штанга - это такая "палка", по бокам которой навешиваются так называемые "блины" - круглые плоские с дыркой посередине диски невероятной тяжести.

Хранятся же эти диски на штырях, которые представляют собой те же "палки", но вторкнутые вертикально в пол. На них и хранились диски - один на другой положенные.

"Наказание" заключалось вот в чем - тот "педагог" заставлял нерадивого ученика комплектовать штангу! Это элементарно сделать, если диски просто валяются на полу. Но когда они аккуратно сложены на штырь - это намного сложнее :(.

Садист! Чтобы достать со штыря диск заданной тяжести (который обычно находился внизу) необходимо было снять со штыря все "вышележащие" диски, достать самый нижний, а остальные снова надеть на штырь. А потом точно так же достать диск другой "тяжести" со второго штыря. А он как бы случайно тоже в самом низу. И так далее - до полной победы идиотизма над здравым рассудком. Не правда ли, изощренная пытка?

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

Так вот, о стеке: "штырь" для блинов находится в оперативной памяти (где же еще?). А роль блинов выполняют хорошо знакомые нам всем регистры, вернее - их "значения".

Правила работы с ним те же - вы можете снять только верхний "блин". Чтобы получить самый нижний "блин" - вам нужно прежде снять все те, которые НАД ним.

Очевидно, что из десяти "блинов", которые вы надели на "штырь", первым будет сниматься последний из надетых (верхний), а последним - первый, то есть самый нижний.

Все очень просто: "первый пришел - последним уйдешь" и наоборот "пришел последним - уйдешь первым".

Это вам не очередь времен социализма... Это очередь "загрузки-разгрузки" стека!

#2. Для работы со стеком вам пока что необходимо знать только две команды: push и pop. Так как в качестве "блинов" у нас регистры, то, соответственно, необходимо после этих команд указывать и "имена собственные" помещаемых в стек значений регистров.

Соответственно:

Ну а как делать то же самое с остальными регистрами вы, наверняка, уже и сами догадались.

Очень важно помнить, каким "нездоровым" образом в стеке реализована ОЧЕРЕДЬ -поместить/извлечь. Помните, мы вас предупреждали, что нам нельзя верить на слово? Не верьте! А посему - обязательно убедитесь в истинности/ложности нашего голословного утверждения при помощи следующей программульки:

С очередностью заполнения стека, наверное, все понятно :). Я много про абстрактные "блины" загружал. А вот с адреса 114 начинается извлечение из стека. В какой последовательности это делается, вы можете увидеть сами, произведя трассировку этой небольшой проги.

Анализируем. Прога еще не начала работать, готовится выполниться команда по адресу 100. Делаем ШАГ!

Анализируем. AX=0001 - значит, команда выполнилась правильно :). Следующая команда, по идее, должна поместить 1 в стек.

И что? Команда выполнилась, но где мы можем увидеть, что в стек действительно "ушла" единица? Увы, но здесь это не отображается :). Проверим потом. Ведь логично предположить, что если эти значения действительно сохранились в стеке, то мы их потом без проблем оттуда извлечем, т.е. если найдем "там" наши 1, 2, 3, 4, 5 - значит все Ок.

А поэтому - дадим программе работать дальше до адреса 114 (не включительно), не вдаваясь в подробный анализ. Что тут анализировать? Если значение регистра AX последовательно меняется от 1 до 5 - значит, команда mov работает. А стек (команда push) проверим потом, как и договорились.

Проехали до адреса 114.

А вот теперь снова анализируем :). При следующем шаге выполнится команда, извлекающая некогда "запомненное" значение AX из стека.

Обратите внимание, регистр IP указывает на адрес (114) выполняемой команды. Мы с вами это уже проходили, не так ли?

Поехали дальше!!

Выполнился первый POP. Готовится выполниться второй. AX=5. Т.е., по сравнению с предыдущим шагом, вроде ничего не изменилось... Но на самом деле это не так. AX=5 - эта пятерка "загрузилась" из стека :)). В этом вы легко убедитесь, сделав следующий шаг трассировки.

Ууупс... AX=4 :). А команда, вроде, та же :) - POP AX :)

AX=3 :)

AX=2 :)

AX=1 :) То есть нашлись-таки наши 1, 2, 3, 4, 5 :). Восстановились из стека. Теперь поверили? А то!

Еще раз обращаю ваше внимание на то, что последовательность записи (четыре PUSH'а) была - 1, 2, 3, 4, 5, а вот последовательность извлечения (четыре POP'а) - 5, 4, 3, 2, 1. Т.е. "последний пришел - первый ушел". Зарубите это себе на носу! (Как сделал это на своем перебитом носе наш школьный учитель физкультуры).

Медитируйте над этой темой до полного просветления! Иначе потом придется туго!

1.8. Цикл

#1. Наша программа для работы со стеком линейна. А линейное программирование - это плохо. Хотя и не всегда :)

Итак, давайте еще раз посмотрим на нашу программу для работы со стеком. С 100-го до 113-го адреса у нас имеется пять почти идентичных блоков. Изменяется только значение AX, но на одно и то же число - на единицу в большую сторону. То есть AX = предыдущее значение + 1. Это очевидно.

Еще более очевидно, что простая команда POP AX (с 114 по 119) повторяется у нас тоже 5 раз.

Мне почему-то сразу вспомнился анекдот о том, как два мента едут в машине, и один спрашивает у другого: "Глянь, работает ли у нас мигалка на крыше". Тот высунул в голову в форточку и говорит: "Работает-не работает-работает-не работает-работает-не работает..."

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

Добьемся мы этого с помощью так называемого "цикла". Цикл - это... Не буду давать общепринятые определения; кто хочет - поищите в книжках, благо, их навалом.

Скажу только: "сесть-встать, сесть-встать, сесть-встать" - это не цикл, а вот "сесть-встать и так три раза" - уже можно считать циклом.

Реализуется же он (цикл), например, при помощи регистра CX и команды LOOP следующим образом.

Число циклов заносится в регистр CX. После этого следует "простыня" из команд, которые вы хотите "зациклить", т. е. выполнить энное количество раз. Заканчиваться все это должно LOOP'ом с указанием адреса "строки", с которой необходимо начать цикл (обычно это "строка", следующая сразу же после mov СХ.

Давайте мы сначала "набьем" нелинейный вариант нашей проги, а потом разберемся, что там к чему. Набиваем:

Наверное, вы уже поняли, что цикл повторяется до тех пор, пока CX не станет равен 0. Несмотря на то что CX - он как бы регистр общего назначения, для "зацикливания" используется именно он :). С остальными такой фокус не проходит. Это и есть так называемая "специализация регистров", о которой мы уже вскользь упоминали.

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

Медитируйте!

#2. А теперь вопрос на засыпку ;). Сколько раз выполнится следующий цикл:

Очевидный ответ - 0 раз. В CX же у нас занесен 0. Так вот - ответ неправильный.

Менее очевидный ответ - 1 раз! Ведь перед LOOP'ом сложение один раз все-таки выполнится. Так вот, этот ответ тоже неправильный.

Самые подозрительные могут сразу же посмотреть на этот цикл под отладчиком, и с удивлением обнаружат, что LOOP сначала уменьшает значение CX (0-1=FFFF), а потом уже проверяет, не равен ли он нулю. И с гордостью за задний ум своей головы воскликнут: FFFFh раз!

Так вот: этот ответ близок к истине, но тоже неправильный ;)

Правильный ответ - цикл выполнится 10000h (65536d) раз.

Но только вы и мне не верьте! Истинно только то утверждение, которое вы сами проверили на практике. Медитируйте!

1.9. Немножко оптимизации

Как мы уже говорили, линейное программирование - это плохо, но не всегда. Сравните размеры ваших линейной и нелинейной программ. Не знаю, как у вас, но у нас линейная "весит" 27, а нелинейная - 19 байтов. Как по-вашему, какая быстрее работать будет?

- Ну, естественно, нелинейная, потому что она меньше! - скажете вы и будете неправы.

Попытайтесь оттрассировать "зацикленную". Не правда ли, она трассируется намного дольше своего линейного аналога?

Угу, всё поняли? Сам знаю, что ни черта. :(

Объясняю: в "зацикленной" программе "компутеру" приходится выполнять БОЛЬШЕ команд, нежели в "незацикленной".

Аргументирую это голословное утверждение следующей таблицей (построенной на основе трассировки):

Ну и как по-вашему, какую из двух простыней процессор быстрее обработает? Сказать вам по секрету? А вот ничего я вам не скажу! Сами думайте! :]

Как сейчас помню, был в моем Турбо-Си в преференсах к компилятору такой радиобуттон: "оптимайзить" по размеру или по скорости выполнения. Угадайте, на чем основан принцип этой оптимизации?

Только не вздумайте писать линейные проги! Пишите "нелинейные"! Нелинейную в линейную "переоптимайзить" - как два пальца намочить! А вот наоборот - :((

Резюме - бесплатный сыр бывает только в мышеловке, и за все надо платить. Компактность и скорость - обычно параметры конфликтующие, поэтому в каждом конкретном случае нужно выбирать, что предпочтительнее. Исследования, проведенные в свое время еще Кнутом, показали, что 80% времени затрачивается на выполнение 20% программы. Соответственно, рекомендуется тратить время на оптимизацию скорости именно тех 20% программы, а остальные можно оптимизировать по размеру (в частности, за счет циклов). Так и получается баланс между компактностью и скоростью программы ;).

1.10. Разборка с процедурами

#1. В разделе 1.7. #4 мы сделали глупую линейную программульку, выводящую окошки. Обещали, что в следующей главе сделаем ее менее "тупой", да отвлеклись почему-то на циклы и стек. То есть я-то знаю, ПОЧЕМУ, но вот вам об этом - не скажу! Догадайтесь сами. Итак, поехали...

Шаг первый. Внимательно посмотрев на "линейную" прогу из 1.7. #4 и прочитав "условие задачи" из главы 1.7. #1, вы обязаны возмутиться - зачем мы использовали команду MOV, если и ежу понятно, что отличия следующего окошка от предыдущего можно выразить более лаконично: BH=BH+10, CH=CH+1, CL=CL+1, DH=DH-1, DL=DL-1? И не нужно напрягать мозги, подсчитывая новое значение регистра вручную.

Если вы так подумали, то оказались совершенно правы! Программу из #4 запросто можно было представить в таком вот виде:

И несмотря на то, что размер ее оказался несколько большим, она тоже будет работать правильно :).

Но тут любой более или менее наблюдательный программер возмутится повторно - да что это за программа такая? В ней целых четыре раза повторяется один и тот же кусок:

И знаете что? Этот наблюдательный программер будет прав! А если он еще и нехорошо выразится по поводу такого "неправильного" стиля программирования - будет прав... или почти прав...

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

Внимательно всмотритесь в полный текст программы и в этот выделенный кусок. И помедитируйте над ним до полного просветления текущей "обстановки"...

#2. Итак, у нас есть ПОВТОРЯЮЩАЯСЯ ЧАСТЬ программы. А еще у нас есть пальцы, которым, как правило, лень набивать длинные "простыни" программного кода. Это одна из многочисленных причин, по которым и придумали такого "зверя" как ПОДПРОГРАММУ (она же - ПРОЦЕДУРА, она же - ФУНКЦИЯ). Остальные причины мы рассмотрим попозже, а вот на счет "лени" поговорим прямо сейчас:

Если мы возьмем наш "часто повторяющийся" кусок программы и допишем в конец команду RET, то получится у нас именно ПРОЦЕДУРА - во всей своей красе:

Красота ее вот в чем заключается - процедуру можно "вызвать" командой CALL :)))

Все более чем просто. Когда в программе встречается CALL с указанием АДРЕСА-НАЧАЛА-ПРОЦЕДУРЫ (в нашем случае это 011E), то компьютер "идет" по этому адресу и выполняет все команды, расположенные между "точкой входа" (включительно) и командой RET, то есть так называемое "тело" процедуры.

RET - это тоже команда, но к "телу" (адреса 11E... 12D) она не относится. Она является "ОРГАНИЗАТОРОМ" этого "тела". Процессор, встретив команду RET, возвращает управление обратно после последнего CALL (т.е. "перепрыгивает" на строчку ниже "вызвавшего" данную процедуру CALL'а)...

Короче, CALL XXXX означает - "выполнить процедуру, начинающуюся по адресу XXXX". А RET означает - "конец процедуры" и, соответственно, переход на строчку ниже вызвавшего его CALL'а.

Если же говорить более формально и строго, то процедура - это средство обобщения, когда некоторая общая последовательность действий получает "имя", и потом при необходимости ПОВТОРНОГО ИСПОЛЬЗОВАНИЯ данного кода к нему просто идет обращение по "имени" (напомним, что в отличие от языков высокого уровня и даже ассемблера, в машинном коде от имен остаются одни только адреса, а язык, принимаемый DEBUG, является промежуточным между машинным кодом и ассемблером). Более того, следующим логическим шагом после обобщения является параметризация, когда некоторые части общего кода зависят от передаваемой извне информации (параметров), с чем очень хорошо знакомы программисты на языках высокого уровня. Но о параметризации и ее применении в ассемблере мы поговорим в другой раз.

Не ругайтесь. Мы знаем, что вы ни черта не поняли. А по сему набьем в debug'е эту прогу и посмотрим, что она делает.

Те, кто читал внимательно, могут отметить, что инструкция CALL по своему действию очень похожа на инструкцию генерации прерывания INT, с той лишь разницей, что аргументом CALL является адрес процедуры, а не индекс в таблице "векторов прерываний", где и хранится адрес обработчика прерывания (той же процедуры). А для особо продвинутых отметим, что в ранних моделях процессоров от Intel при подаче запроса на обработку от внешнего устройства контроллер прерываний, помимо собственно сигнала прерывания, посылал в процессор инструкцию CALL.

#3. Кстати, вы уже поняли, почему мы называем debug "до боли любимой программой"? Нет? Неужели вы еще не полюбили это произведение программерского гения всеми фибрами своей души? Еще нет? М-да... мы в вас разочаровались.

А по сему: - НАБИВАЕМ! - злобно кричим, брызгая слюной на эргономичный коврик:

Не правда ли, красиво получилось?

Первое, что вас может смутить - это то, что команда выхода (INT 20) расположена не там, где вы привыкли, то есть не в конце программы.

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

Итак, до адреса 0110 вам все должно быть понятно, мы это рассматривали. Трассируем дальше...

- Что значит "трассируем"? - попросите вы напомнить.

Мысленно мы ругаем вас нехорошими словами (ну сколько раз повторять-то можно!), а вслух скажем: Команда "T" и Enter. Команда "T" и Enter. Команда "T" и Enter…

Команда CALL 011E по адресу 0110 говорит процессору: "Дальше мы не пойдем, пока не выполним простыню, начинающуюся по адресу 011E". И далее, естественно, следует переход на этот адрес.

Входим в тело процедуры, начиная с 011E, и выполняем команды до 012D включительно...

А теперь внимательно смотрим, на какой адрес нас "перекинет" команда RET.

На 113-й? И это правильно! По 113-му адресу у нас какая команда? Да вот опять CALL 011E!

Опять процедура с адреса 011E, опять RET[URN] на строку ниже, то есть на 116...

И так далее, до того момента, пока следующей строчкой не окажется INT 20 - собственно, на этом и программе конец.

Ну оно и ежу понятно, что, несмотря на то что INT 20 - не в конце программы, последним выполнится именно он.

Короче, куда бы вас не посылали всяческие "столбы с указателями", конец вашего пути только один... А плутать вокруг да около этого конца вы можете сколько вам заблагорассудится...

Кстати, именно это и является одной из многочисленных тайн программинга.

Кто после этого скажет, что программисты - недZенствующие люди?

#4. Те, кто внимательно ознакомились с циклами, они и на этом не остановятся! Посмотрев на адреса 110...119, они вообще возьмут и возомнят себя воистину крутыми парнями! Знаете, что они напишут? А вот что (предвидим!):

То бишь еще и CALL в цикл при помощи MOV CX,4 и LOOP'а "закрутят". И что? А попробуйте!

Что, не "пашет"? А что надо делать, если "не пашет, а должно бы"? Правильно! Смотреть из-под отладчика!

Смотрим? Если посмотрите, то сразу же и "загвоздку" увидите - CX, использованный в качестве "счетчика" циклов, "перебивает" тот же CX, но используемый как "координаты верхнего левого угла окна". И что с этим делать прикажете?

Вот вы и столкнулись с одной из самых больших проблем. В процессорах фирмы Intel есть только 4 регистра общего назначения (и то в большинстве случаев - специализированных). Помните, мы вам говорили об этом?

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

1.11. Переходы

#1. "Переходы" бывают разные. Если вы пришли в гости, а вас просто послали к черту - такой переход называется "безусловный". А нежели вам сказали: "Если без пива - то иди к черту, а если с пивом - тогда проходи", - то это уже "условный" переход.

Соответствено, для успешного перехода необходимо указать: ПРИ КАКОМ УСЛОВИИ выполнить переход, КУДА ПЕРЕЙТИ, ну и, наконец, сам пинок под зад нужно СДЕЛАТЬ, чтобы переход "гостя" в заданном направлении все-таки "состоялся".

Безусловный переход у нас "делает" мнемоническая команда JMP, после которой следует указать адрес, на который "компьютер" должен пойти "на" ;). В данном случае УСЛОВИЕМ у нас будет "при любых обстоятельствах": хоть пустой, хоть с пивом, хоть с ... все равно. Когда рисовали окошки, вы уже использовали эту команду для создания "спецдефекта". Если кто еще не понял, что делает эта команда - к нему (см. 1.7 #4) и отсылаю. Сделайте "спецдефект" и посмотрите на него под отладчиком. Когда до вас дойдет, почему мы там не предусмотрели выхода (INT 20h) - можете переходить к п.2 текущей главы.

#2. Условный переход у нас организуется в два шага. На первом шаге мы вычисляем условие ("принес ли пиво?"), на втором шаге "посылаем" или не "посылаем" - в зависимости от результатов вычислений. Можно привести такую аналогию - на первом шаге два груза кладутся на весы, сравнивающие их массу. Соответственно, возможны только три их положения: наклон влево (груз в левой чашке тяжелее), наклон вправо (груз в правой чашке тяжелее) и равновесие. На втором шаге мы предпринимаем действия в зависимости от положения весов.

Например, на первом шаге можно использовать как "аптекарские весы" инструкцию CMP, которой обязательно нужно указать, ЧТО и С ЧЕМ она будет сравнивать.

Пишем, например,

В зависимости от значений регистров у нас возможны следующие состояния: "наклон влево" (AX &tt; BX), "наклон вправо" (AX > BX) и "равновесие" (AX = BX). Таким образом ВЫЧИСЛЕНИЕ УСЛОВИЯ у нас уже организовано :). Только условие не бинарное, а есть еще и "серединный вариант" (и даже несколько других!). Это нормально. Это для того сделано, чтобы мы могли выражения типа "больше-или-равно", "меньше-или-равно" да и просто "равно" в своих программах использовать...

Итак, УСЛОВИЕ есть. Теперь решаем, что нам делать при том или ином условии. Вот далеко не полный список возможных "прыг-скоков":

• JE - переход если равно;

• JNE - переход если не равно;

• JA - переход, если больше;

• JAE - переход, если больше или равно;

• JB - переход, если меньше;

• JBE - переход, если меньше или равно...

• и т.д.

Естественно, что после мнемоники ("прыгнуть, если") должен стоять АДРЕС, куда нужно "прыгнуть", если условие соблюдено. Если же условие не соблюдено, то прыжок не происходит, и выполняется нижеследующая строка программы.

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

А о чем это мы? Ах да, переходы...

#3. Продолжим программировать, что ли? Напишем что-нибудь красивое и неизменно тупое? С использованием условных и безусловных переходов?

Поехали! Слабаем мы сейчас что-то наподобие графического редактора :)). Не верите?

У-у-у... Сложная задачка! Если въедете, что да как - значит, молодцы! Значит, разобрались-таки с дzебагом! Значит, подключились-таки к программерскому эгрегору и более или менее привели в порядок свои мозги :)... А это сложная штука, мы вам скажем - мозги в порядок приводить! Особенно когда есть куча инструментов, которые "порядок в коде" сами как бы наводят :).

Думаете, вы по нашим текстам программировать учитесь? По-настоящему программировать мы еще не начали! Все, чем мы пока занимаемся - это приводим в порядок свои мозги и тренируемся на кнопки клавиатуры нажимать :)). А вот ско-о-оро НАЧНЕМ... тогда "прощай, здоровье" будет настоящее!

Итак, сначала рассмотрим прерывания, которые в нашем "графическом редакторе" будут использоваться. Их три штуки, и все - BIOS'овские:

Опять-таки - подробности о координатах и "кодах" цвета ищите сами!! Благо, знаете, где искать.

Эта функция считывает код сканирования и код символа (клавиши на клавиатуре и соответствующий ей ASCII-код) из буфера клавиатуры (есть такой). Если в буфере ничего нет - она ждет, пока там что-нибуть появится. То есть ЖДЕТ, чтобы вы нажали на какую-нибудь клавишу, код которой будет занесен в регистр AX. Причем в AL - "символ", а вот в AH - так называемый "код сканирования"...

Кодами вы пока голову не забивайте. Достаточно знать, что после нажатия клавиши Up в AH "попадет" значение 48h, Down - 50h, Left - 4Bh, Right - 4Dh.

Как работает последний кусок кода, обязательно проверьте под отладчиком, это полезно :).

#4. И лезем, лезем в наш горячо любимый DZEBUG, дабы набить там драгоценные строчки машинного мнемонического никому-кроме-вас-непонятного кода!

Тут один из автору вставили шпильку:

"Не хватает проверки и выхода (со сбросом видеорежима!) по Esc - такие действия должны быть обязательным атрибутом, а не домашним заданием."

Совершенно верная шпилька, товарищи! Но все равно - пусть это будет домашним заданием.

Если вы все ввели правильно - должно заработать! Полюбуйтесь плодами своей медитации... Красиво?

#5. А сейчас мы это все дело прокомментируем:

• адреса 100...200 - устанавливаем графический режим, указываем функцию (100), указываем номер режима (102) и вызываем прерывание (104);

• адреса 106...109 - инициализируем координаты первой точки. Координаты последующих точек будут определяться "динамически" - в зависимости от нажатой клавиши;

• адреса 10С...110 - рисуем точку. Первый раз - в координатах, инициализированных командами по адресам 106 и 109. Все последующие разы - по координатам, "инкрементированным" или "декрементированным" (во словеса!) по адресам: 12A, 12D, 130 и 133;

• адреса 112...114 - ждем нажатия на клавишу;

• адреса 116...128 - "щемим" нужные нам клавиши. "Взвешиваем". На каждую из курсорных клавиш по адресам 12A...134 приготовлены "обработчики". Если найдена "нужная клавиша", то делаем прыг на "обработчик" этой клавиши;

• aдреса 12A...134 - в этом блоке определяется, что делать с координатами следующей точки. После чего - прыжок на "рисуем точку" :).

Правда, здорово получилось?

1.12. Данные

#1. Работать с кодом мы с вами научились. Сейчас поучимся заставить наш код обрабатывать данные...

Итак, запускаем DZEBUG и вводим следующую команду:

Которая означает: "набиваем память всяким дерьмом начиная со смещения 115".

В ответ он вам выплюнет:

Что означает: байт по смещению 115 равно 00. И точка. Но это не простая точка - это приглашение ввести НОВОЕ ЗНАЧЕНИЕ этого байта. Когда вы его ввели, нужно нажать на пробел.

Если вы вознамеритесь последовательно ввести 1,2,3,4,5, то это будет выглядеть приблизительно так:

А теперь делаем дамп памяти и смотрим, что за дрянь у нас получилась...

А ведь получилoсь же!!

#2. Мы запросто умеем "присваивать" регистру любое значение (mov AL,1C какой-нить), запросто можем "копировать" содержимое одного регистра в другой (mov AL,BL например)... А сейчас мы с вами научимся при помощи той же команды MOV еще и с данными из памяти работать.

Все проще пареной репы... Если мы напишем

то в результате выполнения этой команды в регистр AL "внесутся" две шестнадцатеричные циферки (байт), которые по адресу 115 находятся. То есть в нашем случае AL станет равным 1.

А теперь посмотрите, что делает "обратная" команда:

В первой строчке мы присвоили AL значение 55, а второй строчкой "скопировали" значения регистра в байт по адресу 115. Правда, проще некуда?

Обязательно посмотрите на этот процесс под отладчиком!

#3. А еще вот какой изврат с этим можно делать:

Сие присваивает регистру AL значение байта по адресу 115 :). Ну... через посредника "BX" присваивает! Который у нас "переменная", как известно :).

А этот кусок кода у нас "записал" 1C в сегмент данных по адресу 115 :). Ну, и извращения наподобие:

и

Тоже весьма и весьма полезны в программерском деле :).

Короче: все, что в квадратных скобках, - это адрес в памяти, с которым вы собираетесь "работать". Другой вопрос, что этот адрес может быть "составным"...

#4. Низкоуровневый Paint мы с вами уже писали. Сегодня напишем низкоуровневый дZенский EXCEL.

Задание простое... Есть у нас табличка типа:

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

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

Набиваем блок данных, начиная с адреса, например, 115:

Вот так это у меня в DZEBUG'е выглядело :). Только я еще дамп посмотрел, правильно ли я ввел:

Вроде правильно :)). Ну а программу я вот какую придумал:

В BX я занес адрес начала блока данных (он же - верхний левый угол нашей таблицы). В CX внес 5, чтобы столько раз цикл выполнился (LOOP по адресу 111). А тело цикла вообще простое:

Команда по адресу 106 забирает в AL цифирь из первого столбца.

108 - суммирует "цифирь из первого столбца с цифирью из второго столбца" (сумма, само собой, в AL'е остается).

10B - записывает сумму в третий столбец :).

Ну и ADD BX,3 для перехода на следующую строчку :).

И все на этом...

Сделайте трассировку (внутрь INT 20 залезать не надо) и посмотрите на дамп нашего блока данных :)

Я и говорю: ПРОЩЕ ПАРЕНОЙ РЕПЫ!! ;)

#5. Видите? В качестве переменных "в компьютере" можно использовать не только регистры, но и "куски" памяти! А уж там вы можете клепать свои переменные в почти неограниченном количестве! Единственное, что нужно иметь ввиду: с переменными-регистрами компьютер работает намного быстрее, чем с переменными-в-памяти :).

Кстати, если вы хотите сохранить плод своих сегодняшних трудов на веник, то имейте ввиду, что вы и сегмент данных тоже должны сохранить! То есть: вам нужно сохранить весь "диапазон" от адреса 100 до 123 включительно :).

Ну и, само собой, при попытке дизассемблирования с адреса 115 у вас абракадабра пойдет... мы об этом уже говорили и упоминали один из принципов фон Неймана.

Диагноз

Полагаю, вы уже поняли, что значит "выучить язык ассемблера" :) и теперь с удовольствием кинете грязью в того, кто скажет вам, что это сложно ;)

Что значит "выучить язык", и что значит "программировать"? А проводите сами границы между этими понятиями! Только имейте в виду, кто скажет "выучить - значит все команды запомнить - тот дурак :((.

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

Да о чем это я, в общем-то? (Утомлен кофием, поэтому речь несвязна)? Просто хотел сообщить вам, что первая часть курса закончилась. Вооружившись справочником команд и прерываний, вы уже можете программировать под дос. Если вы внимательно штудировали предыдущие главы, то идеология этого дела (под дос) вам уже должна быть понятна как 2х2=100b.

_... В 945-ом году отправился князь Игорь к программистам за данью. Когда программисты узнали размеры дани, их лица сразу стали озабоченными, и они побили Игоря и его дружину. Тогда жена Игоря Ольга с огнем и мечом пошла на программистов. Отдавайте, говорит, законную дань, а не желаете, так поставьте на каждую тачку нашу новую навороченную ОСь. Обрадовались программисты, что могут отделаться малым, и их лица опять стали веселыми. А Ольга приказала в каждую ОСь зашить BUG. Программисты инсталлировали ОСь, и BUG уничтожил все их данные...

И дело даже не в том, что жалко программистов, а в том, что история учит, какими б не казались крутыми ОСы, нужно уметь работать независимо от программного обеспечения. Ведь сила не в мегагерцах и не гигабайтах, и даже не в DZеньгах, сила - она в ньютонах..._

Запуск dzebug'а

Я знаю только два способа запуска DEBUG с файлом.

1. С командной строкой:

2. Без командной строки:

Тут вы получите приглашение DZEBUG в виде черточки "-".

Далее следуют команды:

Ууупс! DZEBUG загрузил вашу программу и готов к работе :)))

Отображение и изменение значений регистров

Первым делом мы просмотрим содержимое регистров, используя команду R. В качестве объекта извращения (Serrgio сегодня будет извращаться несколько иначе) - ваша же прога из #7 п. 4...

Если вы ввели R без параметров, значения регистров будут выведены примерно так:

CX содержит длину файла (0043h или 67d). Если размер файла превышает 64К, то BX будет содержать старшую часть размера файла. Это очень важно знать при использовании команды Write - размер файла содержится именно в этих регистрах.

Запомните: когда файл находится в памяти, DZebug не знает его размер. При записи данные о размере берутся из регистров CX и BX. Страшно даже подумать, что может произойти, если мы по ошибке введем команду Write, а в это время BX и CX будут содержать FFFF! Страшно, но приятно...

Если мы хотим изменить значение одного из регистров, мы вводим R и имя регистра. Давайте поместим в AX слово *UCK (те, кто не знаком с английским, пусть спросят у своих умных друзей, что означает это слово).

Вывалится:

":" - это приглашение ввести новое значение. Мы отвечаем *UCK

Вывалится:

DZebug выдал сообщение об ошибке.

Тут дело даже не в том, что DZебугу не понравилось слово, которое мы ввели. Ему, в сущности, глубоко наплевать, какое значение мы хотим занести в регистр, главное - чтобы цифры были HEX'овые. И если F является таковой, то U - нет. DZебуг заботливо указал нам на нее значком " ^ ".

Ну и фиг с ним. Попробуем ввести что-нибудь более пристойное, например D3E0:

Теперь, если мы просмотрим регистры, мы увидим следующее:

Вы увидите, что ничего не изменилось кроме регистра AX. Ему присвоили новое значение, как мы помним.

Еще один важный момент: команда Register может использоваться только для 16-битных регистров (AX, BX и т. д.). Она не может изменять значения 8-битных регистров (AH, AL, BH и т. д.). Например, чтобы изменить AH, вы должны ввести новое значение в регистр AX с новым AH и старым значением AL.

Помедитируйте немного и поехали дальше...

Дамп памяти

Если вы не очень хорошо умеете читать машинные команды процессора, команду Dump можно использовать для вывода на экран данных (тексты, флаги и т. д.). Для вывода кода лучше использовать команду Unassemble.

Если мы теперь введем команду Dump, DZEBUG определит начало программы. Для этого он использует регистр DS, и, так как это COM-файл, начинает вывод с адреса DS:0100. Он выведет 80h (128d) байт данных (или то количество, которое вы сами определите)... Следующее употребление команды Dump отобразит следующие 80h байт и так далее.

Например, первая команда Dump выведет 80h байт начиная с адреса DS:0100, вторая команда выведет 80h байт начиная с адреса DS:0180...

Конечно, можно самому определять нужный вам сегмент и смещение при использовании Dump, только нужно использовать для определения только шестнадцатеричные цифры.

Например, запись D DS:BX не верна. Загрузив нашу программу и введя команду Dump, мы увидим очень непонятные буквы и цифры.

Вы наверное уже знаете, что эти буквы и цифры - не что иное как наша программа. Невероятно, но это так.

Вы видите, что выводимые командой Dump данные разделены на три части.

Самая левая содержит адрес первого байта в строчке. Ее формат - сегмент:смещение.

Следующая колонка содержит шестнадцатеричные данные по указанному адресу. Каждая строчка содержит 16 байт данных.

Третья колонка - это ASCII представление данных. Отображаются только стандартные символы ASCII. Специальные символы IBMPC не отображаются, вместо них выводятся точки ".". Это делает поиск простого текста более удобным.

Dump не может выводить данные, выходящие за границы сегмента. Например, команда

правильная (выводятся байты начиная с DS:0100 до DS:F0FF), а команда

некорректна (8000h +9000h = 11000h - выходит за границу сегмента).

Так как 64К - это 10000h то невозможно задать этот адрес четырьмя шестнадцатеричными цифрами, поэтому DEBUG использует 0000 для задания 10000h.

Чтобы вывести на экран весь сегмент - введите

Помедитируйте немного и поехали дальше...

Поиск байтов

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

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

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

- правильная, в результате произойдет поиск от DS:0000 до DS:00FF последовательности 12h 34h a b c 56h.

Символы верхнего регистра отличаются от символов нижнего регистра. Например, 'ABC'- это не то же самое, что 'Abc' или 'abc' или другие комбинации верхних и нижних регистров. Однако, 'ABC' и "ABC" считаются одинаковыми, потому что кавычки - это всего лишь разделитель.

Попробуем найти слово 'пИво'. У нас получится следующее:

Ну нет в этой программе пИва!

Попробуем пИво поискать в другом месте, а в нашей программе лучше поищем слово B7 20 B5 06:

Итак, по адресу 15A3:0170 DZebug нашел слово B7 20 B5 06.

Опять же: значение сегмента у вас может быть иным, но смещение должно быть такое же...

Если мы выведем данные на экран, то по этому адресу мы найдем строку '. ......=...0..'. Мы можем попробовать найти строчку '_T¬ _:-.', или еще какую-нибудь нездоровую последовательность символов.

Если мы захотим найти все места, где употребляется команда Int 10h (в машинном коде эта команда имеет вид CD 10), мы сделаем следующее:

и получим дли-и-инную простыню:

DZEBUG нашел последовательность CD 10 по этим адресам. Это не значит, что все CD 10 - это команды Int 10h. Просто по указанным адресам расположенны искомые данные. Это может быть (чаще всего) инструкция, но это также может быть и адрес, вторая часть инструкции JMP и т.д. Вы должны внимательно изучить код программы на данном участке памяти, чтобы быть уверенным, что это действительно INT 10.

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

Помедитируйте немного и поехали дальше...

Сравнение участков памяти

Архиполезнейшая штука! Лично я долго над ней дZенствовал :).

Команда сompare берет два заданных участка памяти и сравнивает их, байт за байтом. Если два адреса содержат разную информацию, они выводятся на экран вместе с их содержимым. Для примера мы сравним 2 байта DS:0100 с DS:0200 .

Все 2 байта различны, поэтому они все выведены на экран. Если какие-нибудь байты окажутся одинаковыми, то они не будут выводится на экран. Если две области окажутся полностью одинаковыми, DEBUG просто ответит новым приглашением. Это очень удобный способ сравнения данных из памяти с данными из файла или ROM-BIOS :)

ДиZассемблирование

Unassemble - основная команда, которую вы будете использовать при отладке. Эта команда берет машинный код и преобразует его в инструкции ассемблера. Способ задания адреса такой же, как и в предыдущих командах, с одной лишь разницей: поскольку мы теперь будем работать с кодом (предыдущие команды в основном предназначены для работы с данными), регистр по умолчанию - CX. В .COM программах это делает небольшое отличие, если только вы сами не очистите DS. Однако в .EXE файлах это чревато некоторыми осложнениями, потому что изначально регистрам CS и DS присвоены разные значения.

Мы видим уже знакомую нам программу. Если мы опять введем "u", то DZebug выдаст нам очередную порцию кода. В нашем случае все обошлось благополучно, но бывает и так, когда вы не знаете, что вы в данный момент дизассемблируете - действительно код программы, или же ее данные. DZebug сделает все, что вы ему прикажете. Если вы скажете дизассемблировать данные, он сделает это, ничего не заметив.

Размещение данных в памяти

Команда Enter используется для размещения данных в памяти. Она имеет два режима: Display/Modify и Replace. Отличия между ними в расположении помещаемых данных - в самой команде Enter или после приглашения.

Если вы ввели E <адрес>, вы будете находиться в режиме Display/Modify. DZEBUG предложит вам изменить значение байта, отображая его текущее значение. Вы можете ввести один или два шестнадцатеричных символа. Если вы нажмете пробел, DZEBUG не будет изменять текущий байт, а перейдет к следующему. Если вы зашли далеко, нажатие минуса "-" возвратит на один байт назад.

В нашем примере мы ввели E 100. Dzebug ответил адресом и значением байта по этому адресу (30). Мы ввели 41, и DZebug автоматически перешел к следующему байту данных (C0). Опять, мы вводим 42, и DEBUG переходит к следующему байту (B7). Мы изменили его на 43. По адресу 104 байт 10 нас вполне удовлетворяет, поэтому мы нажали пробел. DEBUG не изменил его значение и перешел к следующему байту.

После ввода 40 в позиции 105 мы обнаружили, что ввели неправильное значение. Нажимаем минус, и DEBUG возвращается на одну позицию назад, отображая адрес и содержимое. Обратите внимание, что оно отличается от первоначального (B5) и имеет значение, которое мы ввели (40). Мы вводим правильное значение и завершаем работу нажатием ENTER.

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

Режим Display/Modify предназначен для изменения значения небольшого количества байтов по различным смещениям. Replace предназначен для изменения любого количества идущих подряд байтов.

Данные можно вводить как в символьном, так и в шестнадцатеричном формате, и все байты можно ввести за один раз, не ожидая приглашения отладчика. Если вы хотите разместить строку 'Wind0yZ must Die', заканчивающуюся на 0, по адресу 100, то вы должны ввести : E 100 'Wind0yZ must Die' 0

Люди!!! То, что вы сейчас сделали, подобно самоубийству!!! Вместо МАТРИЦЫ вы только что поимели свою собственную программу. Вы отредактировали ее КОД!!! Причем самым извращенным образом!!!

Если теперь вы введет команду U, то увидите ЭТО:

А если вам, не дай бог, взбредет в голову ввести команду G, то... Ну, в общем, сами увидите. Как и в команде Search, данные в символьном и HEX формате могут чередоваться в любом порядке. Это наиболее удобный способ размещения больших объемов данных в память.

Размещение данных одинакового значения

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

Например, чтобы очистить 32К (8000h) памяти, вы всего лишь должны ввести команду:

В итоге все байты памяти начиная с DS:0000 и до DS:8000 будут обнулены. Если бы вместо нуля мы ввели '1234' , то память была бы заполнена повторяющейся последовательностью '123412341234', и так далее. Обычно, для задания небольших объемов данных лучше использовать команду Enter, потому что ошибка в длине при вызове команды Fill может наделать много бед. Команда Enter изменяет значения только тех байт, которые вы непосредственно укажете, что позволяет минимизировать вероятность ошибки.

Помедитируйте немного и поехали дальше...

Перемещение данных

Команда MOVE перемещает данные "внутри компьютера". Она берет данные, расположенные по одному адресу, и копирует их "в другой" адрес.

Если вы хотите выполнить эту команду во время трассировки, это может нарушить ход ее выполнения и получится очень здорово ;) - данные и инструкции, расположенные после "вставки", будут теперь расположены в са-а-авсем другом месте...

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

Вы можете вносить изменения "в BIOS" не утруждая себя программированием ROM:

Мы копируем данные с адреса DS:0100 до DS:02FF (длина - 200) в область памяти, которая начинается с ES:100. Позднее мы можем их восстановить. Нужно только ввести:

, что скопирует данные туда, где они должны быть. Если мы не изменяли данные в памяти по адресу ES:0100, то эта команда восстановит первоначальное состояние памяти DS:0100 - DS:02FF.

Вроде правильно написал, а? А если неправильно, то все равно ведь ничего страшного. ДZЕНСТВУЮЩИЙ Sashok подправит, если что не так... верно?

Помедитируйте с часок и поехали дальше...

Ассемблирование

А вот теперь начинается самое интересное!

Команда ASSEMBLE запрашивает мнемоники (то бишь команды микроассемблера) и преобразует их в машинный код.

Есть некоторые операции, которая она не может проделать (в отличие от MASM/TASM/NASM): ссылка на метки, использование макроса или чего-нибудь еще, что не может СРАЗУ транслироваться в машинный код.

Обращение к данным должно происходить по их физическому адресу в памяти, сегментные регистры, если они отличаются от установленного значения, должны быть определены, и при использовании команды RET должен быть указан тип возврата (NEAR или FAR).

А еще, если инструкция обращается к данным, а не к регистрам (например, MOV [278], 5), то нужно указывать их длину - Byte ptr или Word ptr. Чтобы указать DZebug различие между пересылкой 1234h в AX и пересылкой слова по адресу 1234 в регистр AX, используют квадратные скобки - последнее будет иметь вид MOV AX, [1234].

Всяческие разновидности инструкции JMP автоматически ассемблируются в Short, Near или Far переходы.

А теперь мы... гы... напишем еще одно "окошко" :). Только оно будет не очень красивое :). Размеры его будут максимально возможными, а атрибут - стандартный досовский. Работать эта программа будет по образу и подобию команды CLS (очистка экрана).

Мы использовали прерывание BIOS 10h, которое предназначено для работы с экраном. Мы обращаемся к BIOS с AX=600, BH=7, CX=0, and DX=184Fh. Сначала необходимо установить регистры, что мы и сделали, введя первые четыре инструкции. Команда по адресу 15A3:010B - команда обращения к BIOS. INT 20 (по адресу 010D) служит для безопасности. Нам эта команда практически не нужна, но когда она есть, программа остановится автоматически. Без INT 20, и если мы сами не остановим программу, DEBUG продолжит выполнение программы (от 010F и дальше). А так как после 010D начинается неопределенная область, то, скорее всего, система зависнет. Теперь поможет только ctrl-alt-del (может быть) или же выключение и включение питания. Будьте осторожны и дважды проверяйте, прежде чем что-нибудь делать. А еще лучше - трижды...

Теперь мы должны запустить программу. Чтобы это сделать, введите команду G и нажмите Enter. Если вы правильно ввели свою программу, экран должен очиститься и должно появиться сообщение "Program terminated normally". Более подробно команда Go будет рассмотрена ниже.

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

Как говорили монашки, натягивая презервативы на свечи: "Береженого бог бережет"...

Предо... (тьфу) ... помедитируйте с часок и поехали дальше...

Имя, сестрa, имя

Команда NAME служит только для одной цели - определить имя файла, который DZEBUG должен загрузить или сохранить. Она не изменяет память и не выполняет программу, она только формирует "блок контроля" для файла, с которым будет работать DZEBUG. Если вы хотите загрузить программу, то можете указать это в этой же строчке параметры, как при работе с ДОС. Единственное отличие - должно быть задано расширение.

Расширений по умолчанию не существует. DEBUG загрузит или запишет на диск любой файл, если указано его полное имя.

Мы приготовили DZEBUG к загрузке программы FORMAT.COM с заданным ключом. Когда мы введем команду Load (см. ниже), DZEBUG загрузит программу format.com с параметрами c:/s.

Ну, тут и ежу все понятно, можно не медитировать....

Грузить

Команда LOAD имеет два формата. Первый загружает программу, которая была определена командой NAME, устанавливает все регистры, готовит все необходимое для исполнения. Все заданные параметры программы будут помещены в PSP, и программа "приготовится" к выполнению.

Если файл в формате HEX, он должен содержать правильные шестнадцатеричные символы, которые определяют размер памяти. Загруженные файлы выполняются с адреса CS:0100 или с адреса, указанного в команде. Для файлов .COM., .HEX and .EXE регистры содержат адрес первой инструкции программы. Для других типов файлов регистры не определены. Сегментные регистры имеют значение, указанное в PSP (100h байт перед кодом программы), в BX и CX содержится размер файла. Остальные регистры не определены.

Эта последовательность команд загрузит format.com в память, поместит в IP точку входа - 0100, а CX будет содержать HEX-размер файла. Программа теперь готова к работе :)

Другой формат команды LOAD не использует команду NAME. Он предназначен для чтения секторов с диска (гибкого или жесткого) в память.

За один раз можно прочитать 80h (128d) секторов. При использовании этой команды вы должны указать начальный адрес, диск (0=А, 1=В и т. д.), начальный сектор и количество читаемых секторов.

Например

указывает DZEBUG загрузить в память с DS:0100 20h секторов с диска А начиная с сектора 10h.

Таким образом, DZEBUG можно иногда использовать для восстановления части информации в поврежденном секторе. Но это уже изврат!

Вот. Кратко и лаконично. Медитируйте...

Писать (ударение на "а")

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

Отметим только одну вещь - при использовании этой команды размер записываемых данных определен в BX и CX, где BX содержит старшую часть размера файла. Начальный адрес должен быть определен по умолчанию - CS:0100. Файлы с расширением .EXE или .HEX не могут быть записаны (появится сообщение об ошибке). Если вы хотите изменить .EXE или .HEX файл, просто переименуйте его, загрузите, сделайте необходимые изменения, сохраните его и дайте ему прежнее имя.

Медитируйте...

Чтение данных из порта

Команда INPUT предназначена для чтения данных из любого I/O порта PC. Адрес порта может быть как однобайтовым, так и двухбайтовым. DZEBUG произведет чтение из порта и отобразит на экране его содержимое.

Этой командой мы прочитали данные из "входного" порта "первого асинхронного адаптера". Результат, который вы получите, может отличаться от приведенного :) - все зависит от текущего состояния порта. У меня в момент чтения регистр порта имел значение 7Dh.

Естественно, чтение из разных портов может привести к различным результатам.

Медитируйте...

Запись данных в порт

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

Порт 3FCh - это "регистр контроля модема" для "первого асинхронного порта". Запись в него 01h устанавливает бит DTR. 00h сбрасывает все биты. Если у вас есть модем, который отображает состояния этих бит, вы сможете увидеть вспышку лампочки, когда будете устанавливать и сбрасывать этот бит.

Медитируйте...

Go! Go! Go! Але-але-але...

Команда GO начинает выполнение программы. Она позволяет запускать программу с любой точки и останавливать ее в любой из десяти брекпоинтов программы. Если брекпоинты не установлены (или не выполнены), выполнение программы будет продолжаться до конца, после чего будет выведено сообщение "Program terminated normally". (Именно последнее, кстати и является "але-але-але" ).

Если выполнение программы дошло до брекпоинта, программа будет остановлена, отобразится содержимое регистров и появится обычное приглашение DZEBUG. Теперь можно вводить любые команды DZEBUG, включая и команду Go для продолжения выполнения программы.

Команда Go не может быть прервана нажатием Ctrl-break. Это одна из тех немногих команд, которые не могут быть прерваны во время исполнения.

Команда GО без брекпоинтов начинает выполнение программы с адреса, указанного в параметре.

Кстати, перед адресом должен стоять знак "равно" - без этого знака адрес воспринимается как брекпоинт...

Если не указан стартовый адрес, выполнение программы начинается с CS:IP.

Что еще тут сказать? Пример если только привести...

Данной командой мы запускаем программу и устанавливаем брекпоинты по адресам CS:176, CS:47D, CS:537 и CS:647.

Несколько слов о бряках теперь...

Работа проги останавливается непосредственно ПЕРЕД брекпоинтами. Установка их на текущую инструкцию приведет к тому, что программа не будет выполняться. DZEBUG сначала устанавливает брекпоинт, и только потом пытается выполнить программу. Бряки (разновидность бяк) используют INT 3 для остановки выполнения. DZEBUG вызывает прерывание 3 для остановки программы и отображает содержание регистров.

Брекпоинты не сохраняются между двумя вызовами команды GO. Все брекпоинты вы должны указывать при КАЖДОМ обращении к этой замечательной команде :)

С зеленым чаем в "точках останова"... медитируем...

"Трррассиррровка" - сказал пулеметчик

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

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

Эта команда начнет работу с адреса CS:100 и выполнит пять инструкций. Без указания адреса, выполнение начнется с CS:IP. Команда Т без параметров выполнит только одну инструкцию. При использовании TRACE желательно обходить обращения к DOS и другие прерывания. DOS нельзя трассировать - это может привести к плохим последствиям. Можно трассировать программу до инструкции прерывания, затем командой GO выполнить прерывание и продолжать трассировку дальше.

Медитируем-с... скоро нирвана...

Плюс-минус

С помощью команды с завернутым названием HEXARITHMETIC можно складывать (+) и вычитать (-) шестнадцатеричные числа. Она имеет два параметра: два числа, которые нужно сложить или вычесть. Числа должны иметь длину не более четырех шестнадцатеричных цифр. Сложение и вычитание беззнаковое, не учитывается переполнение старшего разряда.

В первом примере мы хотели сложили 0005 и 0006. Их сумма - 000B, а разность -1. Однако, т.к. числа беззнаковые, мы получили FFFF.

Во втором примере сумма 5678 и 1234 - 68AC, а разность - 4444.

Медитируем...

Нирвана!

Имею счастие заявить: я кончил.

Сохраняем получившуюся дуру под именем proga_1.asm.

Далее запускаем файл tasm.exe и в качестве параметра передаем ему имя файла с исходным текстом программы...То есть командная строка у вас (в том же Windows Commander'е) вот какая должна быть:

Если вы правильно набрали текст программы, то TASM должен выплюнуть вам вот что:

Самое тут главное - это чтоб "Error messages" был "None". Это значит, что ошибок в программе нет.

Поехали дальше... Если ошибок у вас действительно никаких не было, то в том же каталоге, что и proga_1.asm ищите файл proga_1.OBJ. Можете даже по F3 попробовать просмотреть его содержимое... Что-нибудь поняли? Если нет - отсылаю вас к "Введению в машинный код".

А теперь запускаем хорошую программу TLINK следующим образом:

Обратите внимание: линкуем мы именно файл с типом OBJ, а не ASM.

Что получилось? А получился файл proga_1.COM!! И этот .COM работает!

Посмотрите на его содержимое в DZEBUG'е :). Отличется ли оно чем-то от той проги, что мы делали ранее?

Нет, не отличается!

Медитируем...

#3. А теперь несколько слов о том, почему не стоит писать программы так, как мы это делали раньше:

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

Как абсолютно верно заметил некто Евгений Олейников в RTFM_Helpers : "Когда я пишу программу, я не знаю точного адреса начала будущей подпрограммы"...

2. Очень сложно было в том случае, когда возникала необходимость ВСТАВИТЬ ту или иную команду в середину кода. Приходилось перебивать код по новой... по новой пересчитывать адреса... ужас, в общем!

Так вот: основная и самая главная функция "ассемблерного компилятора" - это как раз и есть "просчитывание адресов"!

Смотрите, как хорошо и приятно: мы готовим исходный текст в обыкновенном текстовом редакторе :). Просто набиваем строчка за строчкой - нам не важны адреса (мы их вообще не видим!), не важны "точки входа" в процедуру... Спокойненько вставляем какую надо команду, спокойненько удаляем... Без лишнего напряга!

Да вы посмотрите на блок 3 программы :). Там все те же хорошо знакомые команды :).

Особое внимание обратите на команду CALL, которая у нас, как известно, вызывает процедуру. После нее идет не привычный адрес начала процедуры, а всего лишь ее "имя собственное"! А сама процедура находится между строчками WINDOW proс(начало процедуры) и WINDOW endp (конец процедуры).

"WINDOW" - понятно, это "имя собственное". "Proc" - потому что процедура. "Endp " - потому что конец процедуры...

Тут еще один момент... подобные "словеса" КОМАНДАМИ АССЕМБЛЕРА НЕ ЯВЛЯЮТСЯ. Они называются иначе - "директивами". Это не ПРИКАЗ делать то-то и то-то, а ЦЕННОЕ УКАЗАНИЕ компилятору (не процессору!), что и как ему делать с данным куском кода...

Процедуры - вещь хорошая! Все процедуры хороши, и в большой программе их чертовски много! Это вам не языки высокого уровня, где можно длиннющие простыни кода лабать и все будет работать! ("Дельфи-компилятор не даст вам выстрелить себе в ногу, но будет так удивлен попыткой сделать это, что через некоторое время сделает это сам." (С) DZ WhiteUnicorn).

Это ASM! Тут запутаться легче простого! Исходники неимоверно длинны и сложны! Все делается ручками (хоть и с помощью компилятора), а ошибки довольно трудно отслеживаются (для не-дZенствующих это вообще занятие безнадежное)! Вот и выкручиваются низкоуровневые программеры таким вот образом: всю программу (даже в тех случаях, когда это не обоснованно!) делят на меленькие кусочки-процедурки... Напишут процедурку, протестируют ее так и сяк... если работает - за следующую берутся...

Сии "методы проектирования" мы с вами еще не раз рассмотрим :). Пока что знайте вот что: любую прогу можно/нужно рассматривать как КУЧУ ПРОЦЕДУР, которые все между собой повязаны...

Но есть среди этих процедур САМАЯ ГЛАВНАЯ! Это та, С КОТОРОЙ НАЧИНАЕТСЯ ВЫПОЛНЕНИЕ ПРОГРАММЫ! Ее никто не вызывает. Она - босс! Она всеми командует, все гребет под себя... Описывают ее те же самые директивы, что и прочие "подчиненные процедуры"... Но есть у нас еще одна директивка, которая указывает, КАКАЯ ИМЕННО процедура ИЗ ВСЕХ вроде бы "равноправных" является ГЛАВНОЙ.

Видите строчку end MAIN в конце исходного текста программы? Именно она и указывает ГЛАВНУЮ ПРОЦЕДУРУ ("MAIN" - ее имя собственное). Если бы мы написали end WINDOW , то выполнение программы у нас началось бы с первой строчки процедуры WINDOW, и ни одна строчка из MAIN выполнена не была бы...

Уф... в общем, долго и упорно медитируйте...

#4. Наличие многочисленных директив - это своего рода плата за то, что компилятор избавляет нас от необходимости просчитывать адреса. Как говорит дZенская программерская мудрость "любишь кататься, люби и саночки возить"...

Как и в DZEBUG'е, "в TASM'e" мы также должны четко инструктировать компилятор (дабы он в свою очередь также четко проинструктировал процессор), что у нас является кодом, а что - данными...

Посмотрите на исходник. Весь текст программы у нас хранится между директивами CODESG segment и CODESG ends. Где CODESG - это "имя собственное", "segment" - потому что "CODESG" он, собственно, и есть сегмент :), и "ends" - потому что конец сегмента... (сравните с процедурными директивами).

Но тут такой вопрос:

Директива ASSUME производит связывание сегментного решистра CS с "именем собственным".

Далее у нас следует директива org 100h. Нужна она нам для того, чтобы компилятор понял, что мы хотим получить именно COM-файл, который, как известно, помещается в сегмент памяти начиная со смещения 100 (в общем-то, это необходимое, но вовсе не достаточное условие для получения COM-файл). Директивка очень интересная, о ней мы, надеюсь, еще поговорим подробнее, когда коснемся вирмейкерства. #5. Ладно... с директивами более-менее разобрались, исходник приготовили, пора разбираться че там дальше происходит...

Дальше происходит так называемое "ассемблирование", т.е. перевод команд в соответствующие машинные коды. При этом просчитываются адреса меток, адреса начала подпрограмм, адреса начала/конца сегментов... и многое другое...

Причем ассемблирование происходит как минимум в два приема. Посудите сами: откуда компилятору знать, с какого адреса начнется процедура WINDOW, если не известно, какая еще простыня команд ПОСЛЕ этого CALL'а будет? В DZEBUG'е мы это "в уме на листике" считали...

TASM это тоже аналогичным образом делает :).

При первом проходе он подсчитывает, сколько какая команда занимает места, с каких адресов начинаются процедуры и т. д., и только при втором проходе подставляет в call'ы КОНКРЕТНЫЕ АДРЕСА начала этих процедур... всего лишь... ну еще и ваши "d" и "b" в машинные "h" (которые на самом деле "b") переводит... (во завернул!)...

А вообще, TASM много еще чего делает... программеры - народ ленивый...

В результате ассемблирования мы получаем так называемый "объектный файл".

"И что это за дрянь?" - спросите вы, и правильно спросите...

А вы сравните шестнадцатеричное содержимое OBJ и COM файлов. В OBJ присутствует та же последовательность байтов, что и в OBJ. Но помимо этого и еще какая-то шестнадцатеричная ерунда присутствует: имя сассемблированного файла, версия ассемблера, "имя собственное" сегмента и т. д.

Это своего рода "служебная" информация, предназначенная для тех случаев, когда ваш исполнимый файл вы хотите собрать из нескольких. При разработке больших приложений исходный текст, как правило, хранится в нескольких файлах; в каждом из них прописаны свои сегменты кода/данных/стека. А исполнимый получить нам нужно только один - с единым сегментом кода/данных/стека. Именно это TLINK и делает: завершает определение адресных ссылок и объединяет, если это требуется, несколько программных модулей в один...

И этот один у нас и является исполнимым... УРА!

#6. Итак, первую прогу с использованием компилятора мы написали. Теперь напишем вторую. Набиваем ее исходный текст и компилим:

Итак, в этой программе мы использовали функцию 13h прерывания 10h (INT 10h, AH=13h).

Вот ее описание:

[INT 10h, ФУНКЦИЯ 13h] - записывает на экран символьную строку, начиная от указанной позиции.

ВХОДНЫЕ ПАРАМЕТРЫ:

AH = 13h;

AL - код формата(0-3):

AL=0, формат строки{симв., симв.,..., симв.} и курсор не перемещается,

AL=1, формат строки{симв., симв.,..., симв.} и курсор перемещается,

AL=2, формат строки{симв., атр.,...,симв., атр.} и курсор не перемещается,

AL=3, формат строки{симв., атр.,...,симв., атр.} и курсор перемещается;

BH - страница дисплея;

BL - атрибут (для режимов AL=0, AL=1);

CX - длина строки;

DX - позиция курсора для записи строки;

ES:BP - указатель строки.

ВЫХОДНЫЕ ПАРАМЕТРЫ: отсутствуют.

А еще мы использовали команду LEA, которая загружает в регистр адрес (смещение), с которого у нас начинается блок данных.

2.2. Несколько "тупых" процедурок

#1. Дабы сходу "обломать" нездоровую критику, сразу предупреждаем, что нами сознательно допущена некоторая излишняя "процедуризация" исходного кода. А по сему, прежде чем взяться за изучение нижеследующего материала, твердо уясните: в данном случае (как есть сейчас) дробление кода на процедуры - дурь полная. А обосновываем мы эту дурь только тем, что впоследствии будем совершенствовать эти процедуры до уровня, когда, собственно, сие "дробление" и будет обосновано.

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

Итак, для начала набиваем вот какой текст (исходник это!):

Здесь вам все должно быть понятно. INT 20h вынесен в отдельную процедуру, и только. Плюс еще какие-то нездоровые заголовки добавлены, которые и весят-то больше, чем сам код. Это нормально. После точки с запятой в исходнике вы можете писать все, что угодно. Все равно при компиляции это будет проигнорированно и, следовательно, на размер исполнимого файла не повлияет. (Точно так, как и длина "имен собственных" процедур и меток).

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

Для тех, кто в танке: последующие процедуры вставляйте между процедурами TESTING и EXIT_COM - не ошибетесь :-p.

#2. Следующая процедура также основана на одном-единственном прерывании. Все, что она делает - это возвращает текущие координаты курсора.

Прежде всего обратите внимание на цепочку push'ей и pop'ов (далее - просто "поп"), на очередность записи в стек (AX, BX, CX) и извлечения (CX, BX, AX - обратное то есть). Все регистры, которые мы собираемся изменять внутри процедуры, должны обязательно сохраняться в ее начале и восстанавливаться в ее конце. В важности соблюдения этого правила вы еще не раз убедитесь на своем горьком опыте. Те, кто медитировал над заданием из главы 1.10 #4, уже знают, о чем тут идет речь (а кто не пытался - самое время!).

Давайте посмотрим на нашу процедуру с точки зрения пушей и поп. AH мы изменяли для указания функции прерывания, которую мы хотим использовать. BH обнуляли для указания видеостраницы (пока будем только одну-единственную, нулевую, юзать). "А CX зачем" - спросите. - "Вроде мы его не трогали...". И точно, мы - не трогали. А посмотрите в описании, что в этот регистр нам засунуло прерывание в "результате" своего выполнения... Посмотрели? Оно вам надо?? То, что нам надо - координаты - засунуты в DX (DH, DL), поэтому их значения мы не сохраняем. Если бы нам нужно было получить информацию о типе курсора - мы бы запушили DX, а CX бы оставили в покое...

Что? Без пива не разобраться?

Так в чем, черт подери, дело? Разбирайтесь под пиво!!

Вот вам еще одна аналогичная процедура, которая не определяет, а УСТАНАВЛИВАЕТ курсор в заданные координаты...

Если кто чего не понимает - смотрите комментарии к предыдущей процедуре (+ описание прерываний и команд! это обязательно!). Если кто не понял и предыдущую - снова отсылаю к главе 1.10

#3. На основе двух предыдущих процедур мы напишем третью "курсорную" :), которая будет сдвигать курсор на одну позицию вправо.

А здесь очень простая идеология :)). Из двух процедур мы собрали третью :)). Вызвали CURSOR_READ, получили в DX текущие координаты курсора. Ту координату, что столбец (DL, младшая часть DX), увеличили на единицу. А потом вызвали процедуру CURSOR_SET, которая у нас устанавливает координаты курсора. Новые координаты в нее передаются опять таки через тот же DX. Улавливаете?

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

Обратите также внимание на push/pop DX внутри процедуры. Мы просто сдвигаем курсор вправо. ПРОСТО СДВИГАЕМ на одну позицию. То что в DX нам надо? Сто лет оно нам не надо... херим... А остальные регистры - еще процедурами CURSOR_SET и CURSOR_READ неоднократно "похерены". В каком смысле "похерены"?? А в таком, что состояние регистров ПОСЛЕ вызова CURSOR_RIGHT в точности такое же, как и было ДО. Хотя, сами помните, что всю четверку регистров мы еще как юзали...

Вот теперь можно сделать паузу и (это американцы пускай свой пластмассовый твикс кушают) ПОМЕДИТИРОВАТЬ...

#4. Следующая процедура ну вааще элементарна:

Она символ на монитор выводит. Через 9-ю функцию 10-го прерывания. А потом (после вывода) курсор на позицию вправо перемещает. Догадайтесь сами, "путем вызова" какой процедуры... Ага, правильно :)), CURSOR_RIGHT.

Посмотрите на описание этого прерывания. Код символа должен быть в AL. А у нас в комментариях он в DL прописан. А перед INT 10h mov AL,DL нездоровый стоит. Нахрена он тут?? И правильно!! Этот mov можно удалить, и передавать значение через AL. Но я тварь вредная. Привык я, понимаете-ли, через DX передавать... Привычка - сила страшная!! Лень с ней бороться... Лень, а поэтому и не буду... Кто-то в подобном мове может и более глубокий смысл найдет - наверняка найдет!! В общем - ищите сами. На блюдечке с голубой каемочкой вам это не преподнесу :)). Вредный.

mov BL,00000111b (не 07h) написано специально. Это чтоб вы посмотрели, как кодируется атрибут (фон, цвет) энтого символа. В одном из предыдущих номеров даже табличка есть, из справочника содранная...

#5. В языке "командного интерпретатора DOS" есть хорошая команда - CLS (то бишь очистка дисплея). Хорошая команда! Кто не поленится заглянуть внутрь command.com'а, увидят приблизительно следующее (на самом деле все чуть-чуть навороченнее, но прерывание то же):

Короче, элементарный скроллинг, только заданы максимально возможные координаты скроллируемого окошка и CX=0... в общем, окошки рисовали, помните...

#6. Тестируем, штоль?? Дописываем процедуру TESTING:

Компилим... CLS тож тестируем... Все работает??

А теперь самое интересное :)) и благоприятно влияющее на нервную систему :). Прелесть модульного подхода вот в чем: написали процедуру, протестировали успешно - и МОЖЕТЕ ЗАБЫТЬ нафиг, как она у вас работает, какие функции там используются, какие хитроПОПые алгоритмы там применены...

Просто смотрите на заголовок, че она делает, чего ей надобно на входе, чего возвращает... а ее "внутренности" вам глубоко фиолетовы. Работает - и ладно. Ааааaaa?? Круто?

Уф... медитируйте!!

2.3. Печать "шестнадцатеричных циферек"

#1. Мы уже неоднократно юзали хорошую мнемоническую (aka ассемблерную) команду ADD :). Напомню, что в результате выполнения команд

в регистр AX у нас помещалась сумма (AX=AX+BX).

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

Вот именно - выводить на монитор, а не заносить в какой-то абстрактный регистр.

С клавиатурным вводом пока обождем, а вот с выводом (на монитор) разберемся прямо сейчас.

Как мы это сделаем? Вы уже неоднократно слышали, что "в ассемблере" все делается "ручками" :). Сейчас вы лишний раз убедитесь в том (некоторые замрут в ужасе), что это утверждение истинно. Для вывода значения регистра мы вовсе не "познакомимся с новым прерыванием". Даже такая простейшая операция, как "вывод на дисплей значения регистра (переменной)" - это целая процедура. И не одна, как вы скоро в этом убедитесь. Страшно?

Поехали!!

#2. Задача: вывести на монитор значение регистра DL.

Народ! Давайте сразу расставим границы между КОДОМ СИМВОЛА и его НАЧЕРТАНИЕМ.

Например, у нас F3h в DL. Как мы хотим это вывести? Как символы 'F3' или же как ASCII символ, соответствующий коду F3h? Определяемся. Если в DL у нас F3h - то надо чтоб именно 'F3' у нас на монитор и выводилась. Не 'э перевернутое', не '46 33', а именно 'F3'. Помедитируйте. Уловите разницу между 'э', '46 33' и 'F3'.

Эту задачу мы немножко упростим :). Для начала напишем процедуру, которая выводит только младшую тетраду регистра DL (цифру "3" в нашем примере). Для этого мы обратимся к процедуре WRITE_CHAR из прошлого номера. Именно она печатает нам на монитор символ, ASCII-код которого находится в DL.

Но тут загвоздка: в DL-код, а печатается-то символ :). А нам, собственно, именно две циферки шестнадцатеричного кода, как два символа, и нужно напечатать. Ну, или хотя бы младшую циферку этого кода...

Решается эта задача элементарно :). Главное - это правильно ее сформулировать!

Вот что я тут "нарисовал":

Только во второй колонке вместо вопросительных знаков должны быть соответствующие всякие символы (посмотрите в ASCII-таблице, какие они на вид страшные!).

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

Смотрите: в DL у нас 03h. Хотим мы эту '3' на монитор вывести. Если вызовем WRITE_CHAR, то у нас символ "сердечко" выплюнется. А надо, чтоб символ '3' вывелся, код которого 33h.

Соответственно и для остальных смотри по табличке.

А теперь обратите внимание, насколько "шестнадцатеричная циферка" (тетрада) отличается от ASCII-кода, этой "циферке" соответствующего. Сам скажу: на 30h для цифр от '1' до '9', и на 37h для цифр от 'A' до 'F'. То есть "переконвертацию" мы запросто можем сделать командами add DL,30h (если тетрада в диапазоне 0...9) и add DL,37h (если тетрада в диапазоне A...F).

Короче, вот код (пропиваю!):

Сначала, ессно, изменяемые регистры сохраняем (мы ж их изменяем!). (Ну, и восстанавливаем в конце процедуры (PUSH и POP соответственно)).

Потом у нас логическое ветвление организовано. Сравниваем значение DL с "общей границей" наших двух диапазонов (команда - CMP, "граница" - 0Ah). Если это значение больше или равно 0Ah, то прыжок на метку HEX_LETTER, прибавление к DL 37h и печать цифры (WRITE_CHAR). Иначе добавляем 30h и безо всяких условий перепрыгиваем на вызов WRITE_CHAR (минуя add DL,37h то бишь).

Все. Тестируем.

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

Если сия "тестовая" (она же - главная) процедура выведет на монитор

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

Кто не просто скопировал процедуру из буфера обмена, а действительно разобрался с тем, как она работает - сами знают, что значение старшей тетрады нашей процедуре НЕбезразлично. Оно должно быть равным 0.

#4. Что мы имеем? Процедуру для вывода на дисплей одной шестнадцатеричной циферки - младшей тетрады (в DL). Но нам-то нужно две вывести! Сначала старшую циферку-тетраду, и только потом - младшую!

Таким образом очередная задача разбивается на две части: печать старшей тетрады DL и печать младшей тетрады DL.

Первая "подзадача" решается легко: нужно просто старшую тетраду переместить на место младшей и вызывать процедуру (основательно протестированную и 99,9%-но работающую) WRITE_HEX_DIGIT.

А вторая подзадача - хм... заключается в восстановлении предыдущего (мы ж тетраду перенесли) значения DL и снова - вызове WRITE_HEX_DIGIT.

(Хе! Вот теперь-то вы уж точно почувствуете всю прелесть "дробления кода на процедуры"!)

Перенос тетрады мы осуществим при помощи команды SHR, которую в умных книжках обзывают как "логический сдвига разрядов операнда вправо". Объясню.

Представьте себе деревянную доску, длинной в 8 бутылок пива и шириной в одну. (В принципе, доску эту можно и в два раза длиннее представить, но тогда на ней надо "DX" написать, мы же пока только "DL" напишем). А еще дурня, у которого на лбу SHR написано. Так вот, если этому придурку стукнуть по хребту, то он слева от доски поставит ПУСТУЮ бутылку, а остальные сдвинет на одну позицию вправо, в результате чего самая правая бутылка, ессно, с доски упадет.

Бутылки, которые сразу стояли, могут быть пустыми или полными, а вот дурень SHR - только пустые ставит. И только слева.

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

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

Реализовывается этот сдвиг вот как:

В DL - наша цепочка битов. (11110011b = F3h, естественно).

В CL заносим "на сколько позиций" нам нашу цепочку сдвинуть.

Ну и SHR - это дурень, который сдвигает вправо, а слева нули дописывает.

#5. Думаете, это все?? Разогнались!! Не все так просто :).

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

При печати первой тетрады это условие соблюдается. SHR слева нули дописывает.

А вот при печати второй цифры нужно вот что: ничего никуда не сдвигая, обнулить старшую тетраду, а младшую (которая, собственно, и есть "цифра") оставить в покое.

Решим мы эту команду при помощи логической операции "и" (and по-аглицкому).

А теперь и для особо одаренных:

Смотрите, интересно как получается:

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

А если AND с единичкой - то ЧТО БЫЛО, ТО И ОСТАЕТСЯ.

(Это и есть потаенный дZенский смысл команды AND)

Решение нашей проблемы (обнулить старшую тетраду, а младшую оставить без изменений) таким образом сводится к тому, что старшую тетраду нужно "AND 0", а младшую - "AND 1".

То есть значению DL с 00001111b (оно же - 0Fh) "AND" сделать.

На ассемблере это вот как выглядеть будет:

Естественно, 00001111b = 0Fh

Аминь!!

#6. Уфф... Вот что получиться в итоге должно:

Ну че тут объяснять?? Я уже объяснил все!! Единственное, что могу добавить - это про mov DH,DL. Этой командой мы значение регистра копируем перед тем как биты "ему" сдвинуть. А потом статус-кво mov DL,DH восстанавливаем, чтоб и младшую цифру напечатать.

Все. Тестируем. Вроде должно работать.

#7. Так сказать "к вопросу о шаблонах мышления"...

Мы тут доооолго трахались с тетрадами. Вроде успешно.

Когда при тестировании понимаемости материала мы предложили пяти "подопытным" самостоятельно написать процедуру для вывода на монитор "большого" регистра (DX), они все как один начали сдвигать байты... :(

Народ!! Это не есть правильно!!

Команды xchg DL,DH и xchg DH,DL, кстати, работают абсолютно одинаково. Операнды просто меняются между собой значениями. В качестве одного из операндов может выступать память.

#8. Ну, и напоследок, - информация к размышлению:

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

Думаете эти "фокусники" который в уме офигенны уравнения считать умеют, шибко умные?? Нифига!! Они просто люди ЗНАЮЩИЕ. А делить на десять и вы умеете...

Над этим я настоятельно рекомендую дооооолго помедитировать. А еще над тем, что девушки весьма и весьма любят, когда им фокусы показывают. Впрочем, это (вычисления в уме) - тема отдельная. Мы ее тоже когда-нить коснемся :). MATRIX MUST DIE!!

2.4. Печать десятичных циферек

#1. Для тех, кто медитировал над главой 1.1, алгоритм должен быть понятен как 2+2=(вписать желаемое). Кто не въедет в алгоритм WRITE_DECIMAL - научитесь сначала переводить числа между радиксами на листике в клеточку.

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

а). Вам легче всего будет понять.

б). Требует минимального количества "новых" команд.

Кто скажет, что мы не правы - пусть первый кинет камень в эхо-конференцию RTFM_Helpers.

#2. Прежде всего посмотрите на процедуру WRITE_HEX_DIGIT и вспомните, какой алгоритм положен в основу ее работы. Вспомнили? Рад за вас!!

А теперь мы познакомимся к командой деления. Что будем делить?? Ну естественно, "регистры" :).

Новая команда называется "деление беззнаковое" (DIVide unsigned).

Что такое делимое/делитель/частное, я вас грузить не буду, это в учебнике арифметики для младших классов более чем понятно расжевано. Ну во всяком случае детишки это понимают.

(Кто скажет, что 10/3=3 а остаток 333 в периоде - тот дурак. Кто скажет, что остаток будет равен 1, скажет правильно.)

Следующий кусок кода демонстрирует деление значения регистра AX на значение регистра BL.

Обратите внимание: ДЕЛИМОЕ у нас может располагаться только в регистре AX (другими словами, делимое задается неявно), а ДЕЛИТЕЛЬ - в любом регистре.

Кто не верит - посмотрите под отладчиком...

1. Если делитель размером в байт, то после операции частное помещается в AL, а остаток - в AH.

2. Если делитель размером в слово, то делимое должно быть расположено в паре регистров DX:AX (младшая часть делимого в AX). После операции частное помещается в AX, а остаток - в DX.

2. Если делитель размером в двойное слово, то делимое должно быть расположено в паре регистров EDX:EAX (младшая часть делимого находится в EAX.) После операции частное помещается в EAX, а остаток - в EDX.

Внимание, подводный камень! В следующем примере:

у вас вовсе не AX на BX делиться будет, а парочка DX:AX на BX.

Помедитируйте над этим :))

#3. А теперь, собственно, пропиваю саму процедуру вместе с традиционным расжевыванием оной:

Алгоритм простой: пока частное не равно 0, делим его, делим и еще раз делим на 10d, запихивая остатки в стек. Потом - извлекаем из стека. Вот и вся "конвертация" из HEX в BIN :). Это если в двух словах.

А если подробно, то вот что получается:

Бряк 1 - подготавливаем делимое. Как уже говорилось, оно у нас задается неявно - обязательно через AX. А параметр у нас - через DX процедуре передается. Вот и перемещаем.

Бряк 2 - это, собственно, делитель.

Бряк 3 - очищаем CX. Он у нас будет в качестве счетчика. О нем мы еще поговорим.

Бряк 4 - очищаем DX. Если не очистим, то мы не 1234h какое-нить на 10 делить будем, а 12341234h. Первое 1234 нам надо? Вот и я говорю - очищаем!

Бряк 5 - делим! Частное - в AX, остаток - в DX.

Бряк 6 - заносим остаток (DX) в стек ;).

Бряк 7 - CX=CX+1. Это мы считаем сколько раз "щемили остаток", который "щемится", по кругу (прыжок на метку non_zero), пока AX не равно 0 (бряк 8). То есть делим, делим AX, пока он не окажется таким, что делить, собственно, нечего.

Так-с... Деление закончено, число раз, которое мы поделили AX до его полного обнуления, хранится в CX.

Дальше все просто. Нам нужно такое же количество раз (CX) извлечь значение (DX) из стека. И это будет "HEX", переведенный в DEC. (Оно же: число в двоичном коде, разобранное на последовательность десятичных цифр).

Помните, как у нас организуется цикл? Через loop и CX?

Если бы в качестве счетчика мы использовали какой-нибудь другой регистр, то пришлось бы извращаться со всякими метками и прыжками... а так все просто, все продуманно :). Цикл, в теле которого ИЗВЛЕЧЬ ЦИФЕРКУ (бряк 9) и НАПЕЧАТАТЬ ЦИФЕРКУ (бряк 10). Столько же раз, сколько мы и делили наше исходное шестнадцатеричное число.

Для тех, кто не понял: бряк - это брекпоинт. Для тех, кто еще не знает, что такое брекпоинт - ищите объяснение в 'DZebug. Руководство юZверя'

#4. Тестируем!!

Двое из десяти "подопытных" чайников (есть такие) возмутились:

- В DX же только четыре циферки влазят!

- Ага! Аж два раза четыре!

Как видите, туда еще и две буковки "влазят" ;)

А то и все четыре, если кавычки считать...

Медитируйте!!

2.5. Hello, world! или Изврат-2

#1. Мы уже писали программу "Hello, World!" с использованием 13-й функции 10 прерывания. Посмотрите на ее исходник...

Сегодня мы слабаем еще одно "Hello, World!", но уже несолько другим способом. Какой из этих способов более дZенский - решайте сами ;).

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

Блок данных будет выглядеть следующим образом:

Вы должны спросить "А почему мы хотим напечатать Hello, World-2, а в конце строки у нас 2$? $ - это что? World за баксы продавать, штоль?? Да ну вас...

Эту строчку мы будем выводить на монитор особым дZенским способом - посимвольно. То есть: возьмем первый символ из блока данных, выведем, потом второй и т. д. аналогично пока не встретим символ '$'.

Опять-таки, это если в двух словах. Но ведь наверняка вам этого покажется мало ;).

"Щемить" символы мы будем двумя способами. (Тут я хотел было написать "неправильным" и "правильным", но потом передумал и решил обозвать их "первым" и "вторым").

В алгоритм первого способа вы и сами без труда въедете (я только "рабочую часть" приведу, пуши с попами сами проставляйте):

#2. А вот второй способ немножко навороченнее :). Чтобы в нем разобраться, мы сначала познакомимся со следующей группой команд: LODSB, LODSW, LODSD

Их назначение - это загрузка элемента из последовательности (строки, цепочки) в регистр-аккумулятор al/ax/eax.

Для тех, кто не понял - наша строчка "Hello, World-2$" как раз и является "последовательностью/строкой/цепочкой" из элементов размером в байт.

Адрес цепочки передается через ds:esi/si, сами "элементы" (фиксированной ширины) возвращаются в al (байт, команда LODSB), ax (слово, команда LODSW) или eax (двойное слово, команда LODSD). В общем, последние буковки команд как раз и указывают на размерность элемента: [B]yte, [W]ord, [D]ouble word. Т. е. размер мы определяем неявно.

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

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

df=0 — значение положительное, то есть просмотр от начала цепочки к ее концу;

df=1 — значение отрицательное, то есть просмотр от конца цепочки к ее началу."

Обидно, да? Флаги-то мы с вами еще не расколупали... Чего-ж дальше-то делать, а?

Как что? "Пропивать" стандартную процедуру и колупать ее, колупать, колупать, ногами ее, ногами, и по морде, по морде, по морде...

Итак, что делает команда lodsb, вы уже поняли. А вот с df=0/df=1 пока что непонятки.

Будем разбираться.

Нам нужно, чтобы "просмотр цепочки" осуществлялся командой lodsb слева направа, для этого нужно установить значение df=0. Делаем мы это при помощи команды cld (бряк 2).

Если нам нужно, чтобы "просмотр цепочки" осуществлялся справа налево, мы используем команду std. (Можете попробовать. Ерунда получится.)

А теперь вспомним "золотое правило". Все регистры, которые мы изменяли ВНУТРИ процедуры, "на выходе" должны восстанавливать свои ПРЕДЫДУЩИЕ значения (кроме тех регистров, через которые мы возвращаем РЕЗУЛЬТАТ).

Так вот: то же самое касается и флагов, которые мы изменяем.

Для регистров мы использовали команды PUSH и POP. Для регистра флагов (изменять у которого мы можем только БИТЫ) используются команды pushf (записать в стек значения флагов, бряк 1) и popf (извлечь из стека, бряк 10).

ПРИМЕЧАНИЕ: Это несколько вольное положение (хотя, вобщем-то, верное). Видимо, здесь следует хотя бы добавить, что сохранять/восстанавливать флаги нужно при изменении специальных флагов (if, df). (С) Хемуль

Теперь колупаем дальше... (С) Serrgio

Бряк 3. Мне удобнее передавать данные "в процедуру" через регистр DX, о чем и написано в заголовке. А lodsb (бряк 4) хотит, чтоб адрес ему в SI подавали. Удовлетворим его желание :)

Бряк 4. После выполнения этой команды ASCII-код первого символа "цепочки" "Hello, World-2$" помещается в AL, а значение регистра SI увеличивается на 1 и указывает теперь на второй элемент цепочки (символ 'e').

Бряк 7. Удовлетворяем "пожелания" процедуры write_char. Из AL переносим в DL и печатаем (бряк 9) write_char'ом.

Тэкс... Мы пропустили бряки 5 и 6-й...

Смотрите: на бряке 9 мы "безусловно" зацикливаем "извлечение" и печать элементов цепочки. Безусловно - это значит до потери пульса. Чтоб этого не произошло, каждый из элементов цепочки мы сравниваем с символом-конца-цепочки (в нашем случае это '$', но можно использовать и любой другой). Если текущий символ равен символу-конца-цепочки, то выпрыгиваем (бряк 6) из этого безусловного цикла, восстанавливаем статус-кво (бряк 10) и все на этом...

#3. Тестируем!!

Напечаталось то, что надо?

Если true - читайте дальше.

Если false - расколупывайте и медитируйте до полного просветления...

Диагноз

Когда-то автор этого текста хотел осветить все вопросы низкоуровневого программирования, начиная от процессора 8086 до p3, от DOS'а до W2000 и линуха. Однако, практика показала, что при таких черепашьих темпах написания... к тому времени когда дойдет очередь хотя бы до w3.11 - windows-2000 уже станет вчерашним днем :(. Поэтому этот туториал, мягко говоря, не совсем завершен ;).

AH — AL

Что в нем изменилось? Да просто его (регистра) стало в два раза больше и максимальное число, которое мы можем в этот регистр записать - это FFFFFFFFh (4294967295d, 11111111111111111111111111111111b). Однако обратите внимание (см. рисунок), что EAX - это все лишь расширенная версия регистра AX. То есть мы не можем обратиться к "старшей половине" EAX, как мы делали это, например, при обращении к частям AX через "половинки" AH|AL. Другими словами, если mov AX,1234h и парочка mov AH,12h ; mov AL,34h - это один чёрт, то про mov EAX,12345678h ничего похожего мы сказать не можем.

"Неделимые" регистры SI, DI, SP и BP также имеют свои расширенные версии (ESI, EDI, ESP и EBP), а вот сегментные регистры CS, SS, DS, ES, GS и FS сия участь минула, так как парочек наподобие ES:EBX (сегмент:смещение) вполне достаточно и сейчас. Заметим: сегментные регистры по-прежднему задействованы во всех инструкциях доступа к памяти (например mov ax,[var] всегда идёт через DS, а call [func-var] использует оба DS и CS), однако при программировании под Win32 об этом обычно можно не беспокоиться.

_Повторюсь опять и опять - если простеньким прожкам под Win32 сегментные регистры явно использовать нет надобности, то это вовсе не значит, что они перестали использоваться процессором при адресации данных в "сегменте данных", "на стеке" и в строковых инструкциях. Не говоря уже про явное использование сегментных регистров в сУрьёзных программах ;)

На первых порах мы будем "замалчивать" существование сегментных регистров, но знайте: утверждение об их "устарелости" есмъ брехня._

Однако, вернемся к нашим баранам ;)

#2. Для описания простейших типов данных на языке ассемблера используются так называемые директивы резервирования и инициализации данных, которые по сути являются указаниями транслятору на выделение определённого объёма памяти.

Например, мы неоднократно использовали директиву DB (define byte), которая инициализировала столько байт, сколько нашей душеньке было угодно. Например, DB 'Hello, World' "резервировала и инициализировала" столько байт, сколько символов нам вздумалось написать между кавычками или апострофами.

Однако помимо DB существует еще куча подобных директив. Я приведу вам их все. Некоторые из них вас ужаснут, однако расслабьтесь - вовсе не обязательно что вы будете все их использовать ;). Но ознакомиться с ними - крайне желательно желательно ;) Подозреваю, что впоследствии мы вернемся к этой главе еще не раз.

Для начала мы "построим" эти директивы согласно размера памяти, который они резервируют. А заодно с трех сторон посмотрим на диапазон значений, которые эти "элементы данных" могут принимать.

Расшифровывается эта табличка следующим образом: первая колонка - это сама инструкция. Первая буква - D - от буржуйского define , то есть "определить", вторая - B, W, D и т. д. - от размера определяемого элемента данных, то есть byte (байт), word (слово), doubleword (двойное слово), и т. д. Третья колонка - размер в байтах. Четвертая - диапазон принимаемых значений в шестнадцатеричной системе счисления (хе... я понимаю, что последние две строчки несколько длинноваты ;), однако вроде никто еще не придумал писать шестнадцатеричные числа в экспоненциальном виде). Пятая колонка - это соответствующий диапазон десятичных беззнаковых чисел, шестой - знаковых десятичных.

Во-первых, обратите внимание на DF - это как раз случай длинного сегментированного указателя (32 бит смещения + 16 бит сегмента). И для него, кстати, есть синоним: DP. Во-вторых, помимо целых чисел как аргументы можно указывать нецелые. DD может использоваться для описания и хранения коротких (single-precision) нецелых чисел +/-10^-38...10^38, DQ для длинных (long, double) нецелых +/-10^-308...10^308, а DT для "временных " (temporary) нецелых (диапазон не помню). Например:

Вообще, если быть совсем точным, то помимо интерпретации значений в соответствующих ячейках как целых, они могут интерпретироваться следующим образом: DB - байт или знак; DW - int/unsigned или 16-битное смещение; DD - long, float, 16-битный far (сегмент:смещение) или 32-битный близкий (смещение) указатель; DF - 32-битный far (сегмент:смещение) указатель; DQ - double; DT - упакованное десятичное (packed BCD) число длинной 20 цифр или long double (оба - формат FPU).

Вот еще одна интересная табличка. Все таки у нас программирование для дZенствующих ;), а это подразумевает в первую очередь рассмотрение любого "объекта" с нескольких точек зрения. Первая колонка - это директива, а вторая - так называемое адресное выражение :

В принципе, все выше перечисленные директивы можно использовать для "задавания" строкового значения. Однако имейте в виду, что в памяти они могут выглядеть совсем не так, как вы задали их в директиве, поэтому для инициализации строк мы всегда будем использовать DB. Следующая же простынка приводится исключительно в "образовательных" целях и ни в коем случае не следует воспринимать ее как руководство к действию ;).

Четко вы должны усвоить одно: существует только 6 типов переменных - байт , слово , двойное слово , "дальнее слово" (давайте будем именно так называть "дальний указатель" в формате сегмент : 32-битное смещение), учетверенное слово и "тенбайт" ("10 байт"). Все остальное - от лукавого ;).

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

Два варианта "соответствия" через слэш - это, беззнаковое (unsigned) и знаковое (signed) соответственно.

#3. Как я уже говорил в прошлом выпуске, вся документация, которую добренький микрософт задарма предоставляет своим девелоперам, заточена под си. А си - это, да будет вам известно, ;) все же язык программирования, претендующий на высокоуровневость. И те же 32 бита двойного слова могут быть обозваны и как указатель на строку символов (LPCSTR), и как результат, возвращаемый функцией (LRESULT), и даже, страшно подумать, цветом (COLORREF).

Вам это нравится? Мне тоже - нет. Однако, если мы хотим программировать приложения под win32, нам нужно научиться использовать функции API. Информация же об этих функциях находится в си-заточенном MSDN'е. Что ж делать? Будем учиться перезатачивать!

Загрузите свой MSDN и поищите там, например, функцию WriteConsole (в закладке Index). Смотрим на страничку в описании:

Функция WriteConsole записывает в строку символов буфер экрана консоли (console screen buffer), начиная с текущей позиции курсора.

Слово BOOL перед нашей функцией означает, что результат, который она нам вернет через регистр EAX (все апишные функции возвращают результат через этот регистр) - булевский.

Читаем описание. Возвращаемое значение не-ноль, если функция выполнилась успешно и 0, если сглючила. А дальше, в скобках, какие-то непонятные парочки слов наподобие HANDLE hConsoleOutput... Как их прикажете понимать?

Первое слово из "сладкой парочки" - это тип переменной, а второе - это её "имя собственное". Извлечь необходимую нам информацию мы можем как из первого, так и из второго слова ;). Первое слово - это тип переменной, которых в сях целый вагон с маленькой тележкой, расгрузить его попробуйте самостоятельно, обратившись к разделу Platform SDK MSDN'а, к топику Data Types. Второе же слово - это "имя собственное" переменной, однако имя хитрое - с префиксом , о котором мы с той или иной степенью вероятности может судить о типе этой переменной.

Это не потому, что правила языка таковы, это потому, что в мелкософте решили все кишки переменной описывать в её имени, причём как префикс, а не как суффикс - это чтобы жизнь мёдом не казалась при работе с сорсами от мелкософта; называется сия гадость "венгерская нотация".

Расшифровываю:

Это - небольшой кусочек из так называемой венгерской нотации, которой мелкософт старается следовать. Суть её состоит в том, что имя переменной должно быть не просто идентификатором, но еще и нести в себе некоторые целевые характеристики. Притом не обязательно "размерные", но и "функциональные", с которыми вы можете ознакомиться в MSDN'овском топике "Hungarian Notation "

#4. Теперь, когда мы краешком глаза взглянули на многообразие типов данных великого и претендующего на сильную могучесть языка Си, давайте попробуем перевести топик про WriteConsole на язык Эллочки-людоедки, то бишь ассемблерный.

hConsoleOutput. Префикс h , значит (смотрим на табличку) - DWORD.

CONST lpBuffer VOID *. CONST и VOID, конечно же, смущают, но в имени переменной есть префикс lp, значит - DWORD. DWORD nNumberOfCharsToWrite . Префикс n , значит DWORD (хотя, собсно, при чём тут префикс? Про DWORD же прямым текстом написано!)

И так далее...

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

Короче, хэндл - тот же адрес, только адрес является индексом памяти (массива байт), а хендл - индексом в некотором массиве, который лежит в этой памяти. :) Попробуйте это представить. Получилось?

На этой оптимистической ноте ;) переходим к следующей части - написанию "Неllo, World" под Win32.

Вот две строчки из моего батника (*.bat), который позволяет не "парится" с командной строкой:

Обращаю внимание, что для сборки консольного приложения необходимо использовать ключ /SUBSYSTEM:CONSOLE. Несмотря на то что окошко, в котором оно запустится, до боли напоминает "сеанс MS-DOS", получившаяся программа - полноценное виндозное 32-битное приложение в формате PE. Ассемблируем, линкуем, запускаем, наслаждаемся...

#2. А теперь давайте устроим этому исходнику разборку. Бряк 1. Таким образом мы определяем локальную переменную с именем hStdout и размером двойное слово (DWORD). Почему локальная? А потому, что она существует только внутри процедуры Main , и если бы мы попытались обращаться к переменной hStdout за пределами этой процедуры, ассемблер бы ругал нас всякими нехорошими словами - в отличие от, скажем, константы sWriteText , имя которой "известно" в любом месте нашей программы.

Обратите внимания на префикс h в названии переменной. Это я просто оставил для себя памятку, что переменная заведена под хэндл.

Бряк 2. Апишная функция SetConsoleTitleA - устанавливаем титл (заголовок) для нашего консольного окошка. Вот выдержка из MSDN'а:

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

Команда push offset sConsoleTitle помещает в стек (push) адрес (offset) строки символов (помеченной как sConsoleTitle). Ну а далее следует, собственно, сам вызов (call) функции SetConsoleTitle.

Заметьте, для указания адреса используется префикс под названием offset. Это потому, что берется смещение (offset) относительно начала сегмента, которое и является "ближним адресом". Есть еще "дальние" адреса, в которых задействуется также сам сегмент, но это тема будущих разговоров - сейчас это нас не должно волновать.

Здесь у вас должен возникнуть вполне закономерный вопрос - почему мы дописали букву А в конец функции? В MSDN'е ведь нет никакой буквы A... Я отвечу на этот вопрос немного позже.

Бряк 3. Консоль мы можем использовать как устройство ввода (input device), устройство вывода (output device), устройство для отчета об ошибках (error device). Для того чтобы работать с этим "девайсом", мы должны получить его хэндл при помощи следующей функции:

Единственный параметр, который она от нас требует - указание, на какое устройство мы желаем получить "квиток"-хендл. Вот табличка:

Что нам нужно? Вывести строчку! Значит - запрашиваем хэндл для стандартного вывода, то есть перед вызовом функции "суем" в стек -11. После выполнения функции регистр EAX содержит столь желанный "хэндл стандартного вывода". Кладем этот хэндл в переменную hStdout (которую мы столь предусмотрительно определили на бряке 1) для последующего использования.

- Это ж что за безобразие? - воскликните вы. - Что это за таблица такая нездоровая? Какие-то отрицательные числа, которые ни в жисть не запомнить! Хотим таблицу как в MSDN'е! Чтобы не -10, -11, -12, а длинные мнемонические STD_INPUT_HANDLE, STD_OUTPUT_HANDLE, STD_ERROR_HANDLE!

Спокойно! Исходник, который мы сейчас рассматриваем, весьма точно отображает реальные процессы, происходящие в программе. Чуть позже мы приведем его к варианту в стиле Cи и посмотрим, как можно использовать некоторые высокоуровневые конструкции, значительно облегчающие жизнь низкоуровневому программисту.

Бряк 4. Ну наконец-то, самое главное - функция, которая, собственно, и выводит на консоль строку символов. Вот ее описание:

Расшифровываем. Перед вызовом функции WriteConsole мы должны поместить в стек целых пять параметров:

1. Хэндл. Какие проблемы? Мы его уже получили и предусмотрительно сохранили в переменной hStdout. Командой push hStdout заносим его в стек, и все дела.

2. Указатель на строку символов, которую мы хотим напечатать. Сама строка у нас определена в секции констант под именем sWriteText. Получить ее адрес мы можем при помощи offset. Укладываем все в одну строчку - push offset sWriteText. Два в одном - и адрес получаем и в стек его заталкиваем :).

3. Число символов, которые мы хотим напечатать. В смысле - число "буковок" из строки sWriteText. Сколько символов в строке "hEILo, Wo(R)LD!!"? Включая пробелы - 16d. Пишем - push 16d. Заметьте, функция WriteConsole не требует нуля в конце буфера!

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

5. Резерв. Так сказать, зарезервировано для следующих версий. Смело пишем - push 0.

Теперь, когда мы разобрали все параметры, обратите внимание на то, что MSDN'овская очередность параметров не соответствует той очередности, в которой мы записываем их в стек в нашем исходнике. Вернитесь еще раз к Минимальному приложению, п.12 и внимательно прочитайте пункты соглашения stdcall. Теперь понятно?

Бряк 5. Дабы мы успели полюбоваться результатом трудов своих праведных, при помощи функции Sleep вызываем программную задержку в 2 секунды. Думаю, с параметрами вы без труда разберетесь.

И, наконец, бряк 6 - выход из программы.

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

#3. Теперь делаем первый шаг по приведению нашего сырца в более читабельный вид.

Итак, первое, с чем мы ознакомимся - это эквиваленты, прописанные в файле /MASM32/windows.inc.

Мы уже сталкивались с MSDN'овской табличкой:

Однако вместо мнемонического интуитивно-понятного аргумента STD_OUTPUT_HANDLE вносили в стек значение -11, неизвестно откуда взятое. Давайте напишем сразу же после директивы includelib следующую строчку:

А строчку push -11 заменим на push STD_OUTPUT_HANDLE.

Что получилось? Программа откомпилировалась без проблем, ибо в самом начале листинга мы прописали equ[валент]. Проще говоря, мы сказали ассемблеру: "если ты встретишь в тексте программы STD_OUTPUT_HANDLE , то имей в виду, что это то же самое, что и -11". Другими словами, завели нечто типа константы (не переменную!) с именем STD_OUTPUT_HANDLE и значением -11.

Теперь откройте файл windows.inc и полюбуйтесь его содержимым. Там целая куча "эквивалентов", наподобие вышерассмотренного! И чтобы воспользоваться этой халявой - вовсе не обязательно копировать ту или иную константу через буфер обмена. Можно поступить намного проще - добавить в исходник директиву

В ответ на это ассемблер сам извлечет из windows.inc всю имеющуюся в этом файле информацию и преподнесет ее транслятору на блюдечке с голубой каемочкой.

#4. Вторая халява, которой мы с вами воспользуемся - это "инклуды" (давайте именно так будем называть файлы *.inc) с прототипами функций. Мы уже рассматривали, что такое прототипы, и какую роль они играют при линковке нашей программы с библиотеками импорта. Конечно же, мы можем сами, на основе MSDN'овкого описания функции, вывести ее прототип, но зачем нам приумножать сущности сверх необходимого? Ведь в MASM32 для каждой из библиотек импорта есть и одноименный файл с прототипами. В нашем примере мы использовали функции kernel32 и для этого линковали его с библиотекой kernel32.lib? Ну а соответствующий файл с прототипами называется kernel32.inc!

Что может быть проще? Из нашего исходника вырезаем к черту блок с прототипами, а на его место лепим директиву include [путь] kernel32.inc. Компилим, и, как говорят по телику, "теперь вы можете забыть об этих неудобных промокающих :" (ууупс... опять пошли брутальные фантазии; время начинать новый абзац...).

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

#5. ...зато есть функции WriteConsoleA и WriteConsoleW. "A" - это если вы хотите напечатать строку в формате ASCII (т.е. каждый знак занимает один байт), а "W" - если в Unicode (W - от wide, широкий. В Unicode знаки не 8-битные, а 16-битные, и занимают два байта). Подобные окончания имеют только те функции, которые тем или иным образом работают со строковыми значениями. Функция ExitProcess , например, подобного буквенного окончания не имеет - посудите сами, не все ли равно, на каком национальном языке завершать работу приложения?

Откроем файл kernel32.inc и пристально посмотрим на его содержимое, в частности, на следующее:

Как видим, команда разработчиков MASM32 позаботилась не только о простыне прототипов, но и о "независимости" нашего исходника от выбранной кодировки. То есть для того, чтобы "перезаточить" программу под UNICODE, нам вовсе не нужно заменять окончание A на W в имени функции. Достаточно просто приинклюдить другой файл с прототипами и эквивалентами наподобие

и не "париться" с переписыванием исходника.

Надо отметить, в MASM32 подобного "юникодного" инклуда нет, однако вы легко можете сделать его сами.

#6. И, наконец, третья, самая большая "халява" - это маленькая фенечка, использование которой сразу же превращает макроассемблер из языка кодирования в язык программирования!

С помощью этой "фенечки" целый блок инструкций:

мы с легкостью можем заменить одной-единственной строчкой:

Обратите внимание, что при использовании этой команды параметры мы передаем слева направо, в той же очередности, что и вещает нам MSDN. В отличие от простыни "пушей" c "каллом" в конце.

#7. Теперь самый главный момент... Затаите дыхание!

В свете вышесказанного, вышерасписанного и вышерасжеванного наш исходник принимает весьма красивый "высокоуровневый" вид:

А что? Самое время выпить бутылочку пива ;).

• конвертировать целые числа и float’ы единым алгоритмом

• узнать количество десятичных цифр в целом числе через логарифм

• избавиться от условных переходов при помощи команд cmovXX, bt и модификации кода

Здесь также будет рассмотрен исходник автономной процедуры для преобразования типа variant в ANSI строку.

OLE Variant

Этот тип данных используется для передачи информации через COM. Переменная такого типа может содержать до 64 бит полезной информации (это могут быть числа, указатели или флаги). Изнутри эта структура выглядит так:

Единственное поле которое заслуживает подробного описания это vt - поле типа данных. Оно может содержать следующие значения:

Единый алгоритм преобразования чисел

Математический сопроцессор аппаратно поддерживает упакованые двоично-десятичные числа, следовательно можно переложить всю работу на инструкцию fbstp. для особо непродвинутых приведу формат упакованого BCD числа.

Как видно из таблицы BCD - число содержит 18 тетрад при этом значение тетрады лежит в диапазоне от 0 до 9 (в общем это перевёрнутое текстовое отображение числа).

S - это знаковый бит (1 - число отрицательное)

Теперь перейдём к числам в формате с плавающей точкой. Для начала нужно преобразовать число с плавающей точкой в число с фиксированной точкой. Допустим у нас есть число:

В идеале его нужно привести к 18-значному виду вот так:

Напрашивается формула Y=X*10^(18-длина целой части). Вопрос: как найти длину целой части? Самый быстрый и маленький способ решить эту задачу - использовать логарифмы.

Итак определение:

Логарифм данного числа X при основании Y - это показатель степени, в которую нужно возвести число Y, чтобы получить X.

Можно проще:

X=Y^(logY X)

То есть если взять логарифм по онованию 2 мы получим количество значащих битов в целом числе. Если же взять логарифм по основанию 10 - это будет количество десятичных символов в числе. Фактически сопроцессор способен рассчитывать только логарифмы по основанию 2 и для того чтобы найти логарифм с произвольным основанием применяется формула:

logY X=(log2 X)/(log2 Y)

Заботливые инженеры intel предусмотрели ряд часто используемых констант, их можно получить при помощи инструкций fldXXX (Нас интересует fldl2t - загрузить log2 10).

В результате всего вышесказанного вырисовывается следующий алгоритм:

1. Загрузить число в FPU

2. Подсчитать длину целой части

3. Умножить число на 10^(18-длина целой части) (при этом лучше всего воспользоваться таблицей значений)

4. сохранить BCD

5. Если знаковый бит установлен вывести минус

6. Вывести целую часть

7. Вывести точку

8. Вывести оставшиеся цифры

Однако для умножения на 10^x необходимо использовать только точные целые значения (иначе будет жуткая погрешность). Сопроцессор оперирует числами с мантиссой в 64 бита и порядком в 15 бит, а этого не достаточно чтобы точно представить число 10^18. Умножение на 64 битовое целое число невозможно по той же причине. Поэтому придётся использовать 32 разрядные целые числа с диапазоном от 0 до 10^9.

Следовательно число:

Будет урезано до:

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

Оптимизация

Это несомненно самая дзенская часть статьи. Итак рассмотрим техники оптимизации, которые я применил от простого к сложному.

• Инструкции cmovXX или инструкции условной пересылки данных выглядят так:

Это позволяет копировать данные из одного регистра в другой при исполнении некоторого условия.

Например чтобы поместить в eax наибольшее число из eax и edx нужно написать

• Маски позволяют обнулить регистр или память при некотором условии. Маска принимает 2 значения: -1 и 0.

Вот стандартный способ применения маски из флага cf:

Хотя можно получить маску из любого флага используя setXX:

• Битовые множества могут существенно сократить количество сравнений и условных переходов.

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

Можно даже например создать процедуру в стеке, которая сама выбросит себя от туда при завершении:

Процедура Variant2Str

Процедура понимает следующие типы:

• varSmallint

• varInteger

• varSingle

• varDouble

• varOleStr

• varBoolean

• varByte

• varWord

• varLongWord

• varInt64

иначе выводит NaN

ограничения:

• длина числа не более 18 десятичных цифр

• требуется наличие WideCharToMultiByte в секции импорта

• логический тип представляется как да/нет

Параметры:

value - указатель на переменную типа variant

lpsz - указатель на выходную строку

Как известно, каждую Win32 пpогpамму Windows запускает в отдельном виpтуальном пpостpанстве. Это означает, что каждая Win32 пpогpамма будет иметь 4-х гигабайтовое адpесное пpостpанство, но вовсе не означает, что каждая пpогpамма имеет 4 гигабайта физической памяти, а только то, что пpогpамма может обpащаться по любому адpесу в этих пpеделах. А Windows сделает все необходимое, чтобы сделать память, к котоpой пpогpамма обpащается, "существующей". Конечно, пpогpамма должна пpидеpживаться пpавил, установленных Windows, или это вызовет General Protection Fault.

Каждая пpогpамма одна в своем адpесном пpостpанстве, в то вpемя как в Win16 дело обстоит не так. Все Win16 пpогpаммы могут видеть дpуг дpуга, что невозможно в Win32. Эта особенность помогает снизить шанс того, что одна пpогpамма запишет что-нибудь повеpх данных или кода дpугой пpогpаммы.

Модель памяти также коpенным обpазом отличается от 16-битных пpогpамм. Под Win32, мы больше не должны беспокоиться о моделях памяти или сегментах! Тепеpь только одна модель память: плоская, без 64-ти килобайтных сегментов. Тепеpь память - это большое последовательное 4-х гигабайтовое пpостpанство. Это также означает, что можно не париться с сегментными pегистpами, зато можноиспользовать любой сегментный pегистp для адpесации к любой точке памяти. Это ОГРОМHОЕ подспоpье для пpогpаммистов. Это то, что делает пpогpаммиpование на ассемблеpе под Win32 таким же пpостым, как C ;)

При пpогpаммиpовании под Win32 вы должны помнить несколько важных пpавил. Самое важное следующее: Windows использует esi, edi, ebp и ebx для своих целей и не ожидет, что вы измените значение этих pегистpов. Если же вы используете какой-либо из этих четыpех pегистpов в вызываемой функции, то не забудте восстановить их пеpед возвpащением упpавления Windows.

Вот шаблон пpогpаммы. Если что-то из кода вы не понимаете, не паникуйте. Ибо кода здесь в общем-то, пока что и нету.

Вот и все! Давайте пpоанализиpуем этот "каpкас".

Это ассемблеpная диpектива, указующая ассемблеpу использовать набоp опеpаций для пpоцессоpа 80386. Можно использовать и .486, .586, но самый безопасный выбоp - это указывать .386. Также есть два пpактически идентичных выбоpа для каждого ваpианта CPU. .386/.386p, .486/.486p. Эти "p"-веpсии необходимы только в тех случаях, когда ваша пpогpамма использует пpивилегиpованные инстpукции, то есть инстpукции, заpезеpвиpованные пpоцессоpом/опеpационной системой для защищенного pежима. Они могут быть использованны только в защищенном коде, напpимеp, vdx-дpайвеpами. Как пpавило, ваши пpогpаммы будут pаботать в непpивилигиpованном pежиме, так что лучше использовать не-"p" веpсии.

.MODEL - это ассемблеpная диpектива, опpеделяющая модель памяти вашей пpогpаммы. Под Win32 есть только одна модель - плоская.

STDCALL говоpит MASM'у о поpядке пеpедачи паpаметpов, слева напpаво или спpава налево, а также о том, кто уpавнивает стек после того как функция вызвана.

Под Win16 существует два типа пеpедачи паpаметpов, C и PASCAL. По C-договоpенности, паpаметpы пеpедаются спpава налево, то есть самый пpавый паpаметp кладется в стек пеpвым. Вызывающий должен уpавнять стек после вызова. Hапpимеp, пpи вызове функции с именем foo(int first_param, int second_param, int third_param), используя C-пеpедачу паpаметpов, ассемблеpный код будет выглядеть так:

PASCAL-пеpедача паpаметpов - это C-пеpедача наобоpот. Согласно ей, паpаметpы пеpедаются слева напpаво и вызываемый должен уpавнивать стек.

Win16 использует этот поpядок пеpедачи данных, потому что тогда код пpогpаммы становится меньше. C-поpядок полезен, когда вы не знаете, как много паpаметpов будут пеpеданны функции, как напpимеp, в случае wsprintf(), когда функция не может знать заpанее, сколько паpаметpов будут положены в стек, так что она не может его уpавнять. STDCALL - это гибpид C и PASCAL. Согласно ему, данные пеpедаются спpава налево, но вызываемый ответственнен за выpавнивание стека. Платфоpма Win32 использует исключительно STDCALL, хотя есть одно исключение: wsprintf(). Вы в последнем случае вы должны следовать сишному поpядку вызова.

Все четыpе диpективы - это то, что называется секциями. Вы помните, что в Win32 нет сегментов? Hо вы можете поделить пpесловутое адpесное пpостpанство на логические секции. Hачало одной секции отмечает конец пpедыдущей. Есть две гpуппы секций: данных и кода.

.DATA - Эта секция содеpжит инициализиpованные данные вашей пpогpаммы.

.DATA? - Эта секция содеpжит неинициализиpованные данные вашей пpогpаммы. Иногда вам нужно только пpедваpительно выделить некотоpое количество памяти, но вы не хотите инициализиpовать ее. Эта секция для этого и пpедназначается. Пpеимущество неинициализиpованных данных следующее: они не занимают места в исполняемом файле. Hапpимеp, если вы хотите выделить 10.000 байт в вашей .DATA? секции, ваш exe-файл не увеличиться на 10kb. Его pазмеp останется таким же. Вы всего лишь говоpите компилятоpу, сколько места вам нужно, когда пpогpамма загpузится в память.

.CONST - Эта секция содеpжит обявления констант, используемых пpогpаммой. Константы не могут быть изменены ей. Это всего лишь константы.

Вы не обязаны задействовать все тpи секции. Объявляйте только те, котоpые хотите использовать.

Есть только одна секция для кода: .CODE, там где содеpжится весь код.

где <метка> - любая пpоизвольная метка, устанавливающая гpаницы кода. Обе метки должны быть идентичны. Весь код должен pасполагаться между

и

Windows пpедоставляет огpомное количество pесуpсов Windows-пpогpаммам чеpез Windows API (Application Programming Interface). Windows API - это большая коллекция очень полезных функций, pасполагающихся непосpедственно в опеpационной системе и готовых для использования пpогpаммами. Эти функции находятся в нескольких динамически подгpужаемых библиотек (DLLs), таких как kernel32.dll , user32.dll и gdi32.dll. Kernel32.dll содеpжит API функции, взаимодействующие с памятью и упpавляющие пpоцессами. User32.dll контpолиpует пользовательский интеpфейс. Gdi32.dll ответственнен за гpафические опеpации. Кpоме этих тpех "основных", существуют также дpугие dll, котоpые вы можете использовать, пpи условии, что обладаете достаточным количеством инфоpмации о нужных API функциях. Windows пpогpаммы динамически подсоединяется к этим библиотекам, то есть код API функций не включается в исполняемый файл. Инфоpмация находится в библиотеках импоpта. Вы должны слинковать ваши пpогpаммы с пpавильными библиотеками импоpта, иначе они не смогут найти эти функции. Когда Windows пpогpамма загpужается в память, Windows читает инфоpмацию, сохpаненную в в пpогpамме. Эта инфоpмация включает имена функций, котоpые пpогpамма использует и DLL-ок, в котоpых эти функции pасполагаются. Когда Windows находит подобную инфоpмацию в пpогpамме, она вызывает библиотеки и испpавляет в пpогpамме вызовы этих функций, так что контpоль всегда будет пеpедаваться по пpавильному адpесу.

Существует две категоpии API функций: одна для ANSI и дpугая для Unicode. Hа конце имен API функций для ANSI стоит "A", напpимеp, MessageBox. В конце имен функций для Unicode находится "W". Windows 95 от пpиpоды поддеpживает ANSI и WIndows NT Unicode. Мы обычно имеем дело с ANSI стpоками (массивы символов, оканчивающиеся NULL-ом. Размеp ANSI-символа - 1 байт. В то вpемя как ANSI достаточна для евpопейских языков, она не поддеpживает некотоpые восточные языки, в котоpых есть несколько тысяч уникальных символов. Вот в этих случаях в дело вступает UniCode. Размеp символа UNICODE - 2 байта, и поэтому может поддеpживать 65536 уникальных символов.

Hо по большей части, вы будете использовать include-файл, котоpый может опpеделить и выбpать подходящую для вашей платфоpмы функцию. Пpосто обpащайтесь к именам API функций без постфикса.

ПРАКТИКА, МАТЬ ШИЗОФРЕНИИ

Я пpиведу голый скелет пpогpаммы ниже. Позже мы pазбеpем его.

Выполнение начинается с пеpвой инстpукции, следующей за меткой, установленной после конца диpектив. В вышепpиведенном каpкасе выполнение начинается непосpедственно после метки 'start'. Будут последовательно выполняться инстpукция за инстpукцией, пока не встpетится опеpация плавающего контpоля, такая как jmp, jne, je, ret и так далее. Эти инстpукции пеpенапpавляют поток выполнения дpугим инстpукциям. Когда пpогpамма выходит в Windows, ей следует вызвать API функцию ExitProcess.

Стpока выше называется пpототипом функции. Пpототип функции указывает ассемблеpу/линкеpу атpибуты функции, так что он может делать для вас пpовеpку типов данных. Фоpмат пpототипа функции следующий:

Говоpя кpатко, за именем функции следует ключевое слово PROTO, а затем список пеpеменных с типом данных, pазделенных запятыми. В пpиведенном выше пpимеpе с ExitProcess, эта функция была опpеделена как пpинимающая только один паpаметp типа DWORD. Пpототипы функций очень полезны, когда вы используете высокоуpовневый синтаксический вызов - invoke. Вы можете считать об invoke как обычный вызов с пpовеpкой типов данных. Hапpимеp, если вы напишите:

Линкеp уведомит вас, что вы забыли положит в стек двойное слово. Я pекомендую вам использовать invoke вместо пpостого вызова. Синтакс invoke следующий:

Выpажение может быть именем функции или указателем на функцию. Паpаметpы функции pазделены запятыми.

Большинство пpототипов для API-функций содеpжатся в include-файлах. Если вы используете hutch'евский MASM32, они будут находится в диpектоpии MASM32/INCLUDE. Файлы подключения имеют pасшиpение .inc и пpототипы функций DLL находятся в .inc файле с таким же именем, как и у этой DLL. Hапpимеp, ExitProcess экспоpтиpуется kernel32.lib, так что пpототип ExitProcess находится в kernel32.inc. Вы также можете создать пpототипы для ваших собственных функций. Во всех моих экземпляpах я использую hutch'евский windows.inc, котоpый вы можете скачать с http://win32asm.cjb.net Возвpащаясь к ExitProcess: паpаметp uExitCode - это значение, котоpое пpогpамма веpнет Windows после окончания пpогpаммы. Вы можете вызвать ExitProcess так:

Поместив эту стpоку непосpедственно после стаpтовой метки, вы получите Win32 пpогpамму, немедленно выходящую в Windows, но тем не менее полнофункциональную.

option casemap:none говоpит MASM сделать метки чувствительными к pегистpам, то есть ExitProcess и exitprocess - это pазличные имена. Отметьте новую диpективу - include. После нее следует имя файла, котоpый вы хотите вставить в то место, где эта диpектива pасполагается. В пpимеpе выше, когда MASM обpабатывает линию include \masm32\include\windows.inc, он откpывает windows.inc, находящийся в диpектоpии \MASM32\INCLUDE, и далее анализиpует содеpжимое windows.inc так, как будто вы "вклеили" подключаемый файл. Хатчевский windows.inc содеpжит в себе опpеделения констант и стpуктуp, котоpые вам могут понадобиться для пpогpаммиpования под Win32. Этот файл не содеpжит в себе пpототипов функций. Windows.inc ни в коем случае не является исчеpпывающим и всеобъемлющим. Hutch и я пытаемся заполнить его как можно большим количеством констант и стpуктуp, но есть еще дохрена, чего мы еще не сделали. Он постоянно обновляется. Заходите на хатчевскую и мою стpанички за свежими апдейтами ;) Из windows.inc, ваша пpогpамма будет бpать опpеделения констант и стpуктуp. Что касается пpототипов функций, вы должны подключить дpугие include-файлы. Они находятся в диpектоpии \masm32\include.

В вышепpиведенном пpимеpе, мы вызываем функцию, экспоpтиpованную из kernel32.dll, для чего мы должны подключить пpототипы функций из kernel32.dll. Этот файл - kernel32.inc. Если вы откpываете его текстовым pедактоpом, вы увидите, что он состоит из пpототипов функций из соответствующей dll. Если вы не подключите kernel32.inc, вы все еще можете вызвать ExitProcess, но уже с помощью ассемблеpной команды call. Вы не сможете вызвать эту функцию с помощью invoke. Дело вот в чем: для того, чтобы вызвать функцию чеpез invoke, вы должны поместить в исходном коде ее пpототип. В пpимеpе выше, если вы не подключите kernel32.inc, вы можете опpеделить пpототип для ExitProcess где-нибудь до вызова этой функции и это будет pаботать. Файлы подключения нужны для того, что избавить вас от лишней pаботы и вам не пpишлось набиpать все пpототипы самим.

Тепеpь мы встpечаем новую диpективу - includelib. Она pаботает не так, как include. Это всего лишь способ сказать ассемблеpу какие библиотеки использует ваша пpогpамма должна пpилинковать. Хотя вы вовсе не обязаны использовать именно этот метод. Вы можете указать имена библиотек импоpта к командной стpоке пpи запуске линкеpа, но повеpьте мне, это весьма скучно и утомительно, да и командная стpока может вместить максимум 128 символов.

Тепеpь возьмите весь исходный текст пpимеpа этого уpока, сохpаните его как msgbox.asm и сассемблиpуйте его так:

/c говоpит MASM'у создать .obj файл в фоpмате COFF. MASM использует ваpиант COFF (Common Object File Format), использующийся под Unix, как его собственный объектный и исполняемый фоpмат файлов.

/Cp говоpит MASM'у сохpанять pегистp имен, заданных пользователем. Если вы используете hutch'евский MASM32 пакет, вы можете вставить "option casemap:none" в начале вашего исходника, сpазу после диpективы .model, чтобы добиться того же эффекта.

После успешной компиляции msgbox.asm, вы получите msgbox.obj. Это объектный файл, от котоpого один шаг до екзешника. Obj содеpжит инстpукции/данные в двоичной фоpме. Отсутствуют только необходимая коppектиpовка адpесов, котоpая пpоводится линкеpом.

Тепеpь сделайте следующее:

/SUBSYSTEM:WINDOWS инфоpмиpует линкеp о том, какого вида является будущий исполняемый модуль.

/LIBPATH:<путь к библиотекам импоpта> говоpит линкеpу, где находятся библиотеки импоpта. Если вы используете MASM32, они будут в MASM32\lib.

Линкеp читает объектный файл и коppектиpует его, используя адpеса, взятые из библиотек импоpта. После окончания линковки вы получите файл msgbox.exe. Запустите его. Вы увидите, что она ничего не делает.

Да, мы не поместили в код ничего не интеpесного. Hо тем не менее полноценная Windows пpогpамма. И посмотpите на pазмеp! Hа моем PC - 1.536 байт.

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

Тhwnd - это хэндл pодительского окна. Вы можете считать хэндл числом, пpедставляющим окно, к котоpому вы обpащаетесь. Его значение для вас не важно. Вы только должны знать, что оно пpедставляет окно. Когда вы захотите сделать что-нибудь с окном, вы должны обpатиться к нему, используя его хэндл.

lpText - это указатель на текст, котоpый вы хотите отобpазить в клиентской части окна сообщения. Указатель - это адpес чего-либо. Указатель на текстовую стpоку == адpес этой стpоки.

lpCaption - это указатель на заголовок окна сообщения.

uType устанавливает иконку, число и вид кнопок окна.

Давайте изменим msgbox.asm для отобpажения сообщения.

Скомпилиpуйте и запустите. Вы увидите окошко с сообщением "Win32 Assembly is great!".

Давайте снова взглянем на исходник.

Мы опpеделили две оканчивающиеся NULL'ом стpоки в секции .data. Помните, что каждая ANSI стpока в Windows должна оканчиваться NULL'ом (0 в шестнадцатиpичной системе). Мы используем две константы, NULL и MB_OK. Эти константы пpописаны в windows.inc, так что вы можете обpатиться к ним, указав их имя, а не значение. Это улучшает читабельность кода. Опеpатоp addr используется для пеpедачи адpеса метки (и не только) функции. Он действителен только в контексте диpективы invoke. Вы не можете использовать его, чтобы пpисвоить адpес метки pегистpу или пеpеменной, напpимеp. В данном пpимеpе вы можете использовать offset вместо addr. Тем не менее, есть некотоpые pазличия между ними.

1. addr не может быть использован с метками, котоpые опpеделены впеpеди, а offset может. Hапpимеp, если метка опpеделена где-то дальше в коде, чем стpока с invoke, addr не будет pаботать.

MASM доложит об ошибке. Если вы используете offset вместо addr, MASM без пpоблем скомпилиpует указанный отpывок кода. 2. Addr поддеpживает локальные пеpеменные, в то вpемя как offset нет. Локальная пеpеменная - это всего лишь заpезеpвиpованное место в стеке. Вы только знаете ее адpес во вpемя выполнения пpогpаммы. Offset интеpпpетиpуется во вpемя компиляции ассемблеpом, поэтому неудивительно, что он не поддеpживает локальные пеpеменные. Addr же pаботает с ними, потому что ассемблеp сначала пpовеpяет - глобальная пеpеменная или локальная. Если она глобальная, он помещает адpес этой пеpеменной в объектный файл. В этом случае опеpатоp pаботает как offset. Если это локальная пеpеменная, компилятоp генеpиpует следущую последовательность инстpукций пеpед тем как будет вызвана функция:

Учитывая, что lea может опpеделить адpес метки в "pантайме", все pаботает пpекpасно.

Windows пpогpаммы для создания гpафического интеpфейса пользуются функциями API. Этот подход выгоден как пользователям, так и пpогpаммистам. Пользователям это дает то, что они не должны изучать интеpфейс каждой новой пpогpаммы, так как Windows пpогpаммы похожи дpуг на дpуга. Пpогpаммистам это выгодно тем, что GUI-функции уже оттестиpованы и готовы для использования. Обpатная стоpона - это возpосшая сложность пpогpаммиpования. Чтобы создать какой-нибудь гpафический объект, такой как окно, меню или иконка, пpогpаммист должен следовать должны следовать стpогим пpавилам. Hо пpоцесс пpогpаммиpования можно облегчить, используя модульное пpогpаммиpование или OOП-философию. Я вкpатце изложу шаги, тpебуемые для создания окна:

1. Взять хэндл вашей пpогpаммы (обязательно)

2. Взять командную стpоку (не нужно до тех поp, пока пpогpамме не потpебуется ее пpоанализиpовать)

3. Заpегистpиpовать класс окна (необходимо, если вы не используете один из пpедопpеделенных класов окна, таких как MessageBox или диалоговое окно)

4. Создайте окно (необходимо)

5. Отобpазите его на экpане

6. Обновить содеpжимое экpана на окне

7. Запустите бесконечный цикл, в котоpом будут пpовеpятся сообщения от опеpационной системы.

8. Пpибывающие сообщения пеpедаются специальной функции, отвечающая за обpаботку окна

9. Выйти из пpогpаммы, если пользователь закpывает окно.

Как вы можете видеть, стpуктуpа Windows пpогpаммы довольно сложна по сpавнению с досовской пpогpаммой. Hо миp Windows pазительно отличается от миpа DOS'а. Windows пpогpаммы должны быть способными миpно сосуществовать дpуг с дpугом. Они должны следовать более стpогим пpавилам. Вы, как пpогpаммист, должны быть более внимательными к вашим стилю пpогpаммиpованию и пpивычкам.

СУТЬ

Hиже пpиведен исходник нашей пpогpаммы пpостого окна. Пеpед тем как углубиться в описание деталей пpогpаммиpования на ассемблеpе под Win32, я покажу вам несколько тpюков, могущие облегчить пpогpаммиpование.

Вам следует поместить все константы, стpуктуpы и функции, относящиеся к Windows в начале вашего .asm файла. Это съэкономит вам много сил и вpемени. В настоящее вpемя, самый полный include файл для MASM - это hutch'евский windows.inc, котоpый вы можете скачать с его или моей стpаницы. Вы также можете опpеделить ваши собственные константы и стpуктуpы, но лучше поместить их в отдельный файл.

Используйте диpективу includelib, чтобы указать библиотеку импоpта, использованную в вашей пpогpамме. Hапpимеp, если ваша пpогpамма вызывает MessageBox, вам следует поместить стpоку "includelib user32.lib" в начале кода. Это укажет компилятоpу на то, что пpогpамма будет использовать функции из этой библиотеки импоpта. Если ваша пpогpамма вызывает функции из более, чем одной библиотеки, пpосто добавьте соответствующую диpективу includelib для каждой из используемых библиотек. Используя эту диpективу, вы не должны беспокоиться о библиотеках импоpта во вpемя линковки. Вы можете использовать ключ линкеpа /LIBPATH, чтобы указать, где находятся эти библиотеки.

Объявляя пpототипы API функций, стpуктуp или констант в вашем подключаемом файле, постаpайтесь использовать те же имена, что и в windows include файлах, пpичем pегистp важен. Это избавит вас от головной боли в будущем.

Используйте makefile, чтобы автоматизиpовать пpоцесс компиляции и линковки. Это избавит вас лишних усилий. (Лично я использую wmake из пакета Watcom C/C++ - пеpеводчик.)

АНАЛИЗ

Вы можете быть ошаpашены тем, что пpостая Windows пpогpамма тpебует так много кода. Hо большая его часть - это шаблонный код, котоpый вы можете копиpовать из одного исходника в дpугой. Или, если вы хотите, вы можете скомпилиpовать часть этого кода в библиотеку, котоpая будет использоваться как пpологовый и эпилоговый код. Вы можете писать код уже только в функции WinMain. Фактически, это то, что делают C-компилятоp. Они позволяют вам писать WInMain без беспокойства о коде, котоpый должен быть в каждой пpогpамме. Единственная хитpость это то, что вы должны написать функцию по имени WinMain, иначе C-компилятоpы не смогут скомбиниpовать ваш код с пpологовым и эпилоговым. Такого огpаничения нет в ассемблеpном пpогpаммиpовании. Вы можете назвать эту функцию так ка вы хотите. Готовьтесь! Это будет долгий, долгий тутоpиал. Давайте же пpоанализиpуем эту пpогpамму до самого конца.

Пеpвые тpи линии обязательны в высшей степени. .386 говоpит MASM'у, что намеpеваемся использовать набоp инстpукций пpоцессоpа 80386 в этой пpогpамме. .Model flat, stdcall говоpит MASM'у, что наша пpогpамма будет использовать плоскую модель памяти. Также мы использовать пеpедачу паpаметpов типа STDCALL по умолчанию. Следом идет пpототип функции WinMain. Пеpед тем, как мы вызовем в дальнейшем эту функцию, мы должны сначала опpеделить ее пpототип.

Мы должны подключить windows.inc в начале кода. Он содеpжитважные стpуктуpы и константы, котоpые потpебуются нашей пpогpамме. Этот файл всего лишь текстовый файл. Вы можете откpыть его с помощью любого текстового pедактоpа. Пожалуста заметьте, что windows.inc не содеpжит все стpуктуpы и константы (пока). Hutch и я pаботаем над этим. Вы можете добавить в него что-то новое, если этого там нет. Hаша пpогpамма вызывает API функции, находящиеся в user32.dll (CreateWindowEx, RegisterWindowClassEx, напpимеp) и kernel32.dll (ExitPocess), поэтому мы должны пpописать пути к этим двум библиотекам. Закономеpный вопpос: как я могу узнать, какие библиотеки импоpта мне нужно подключать? Ответ: Вы должны знать, где находятся функции API, вызываемые вашей пpогpаммой. Hапpимеp, если вы вызываете API функцию в gdi32.dll, вы должны подключить gdi32.lib.Это - подход MASM'а. Подход, пpименяемый TASM'ом, гоpаздо пpоще: пpосто подключите всего лишь одну-единственную библиотеку: import32.lib.

Далее идет секции "DATA".

В .DATA, мы объявляем оканчивающиеся NULL'ом стpоки (ASCIIZ): ClassName - имя нашего класса окна и AppName - имя нашего окна. Отметьте, что обе пеpеменные пpоинициализиpованны. В .DATA? объявленны две пеpеменные: hInstance (хэндл нашей пpогpаммы) и CommandLine (командная стpока нашей пpогpаммы). Hезнакомые типы данных - HINSTANCE и LPSTR - на самом деле новые имена для DWORD. Вы можете увидеть их в windows.inc. Обpатите внимание, что все пеpеменные в этой секции не инициализиpованны, так как они не должны содеpжать какое-то опpеделенное значение пpи загpузке пpогpамма, но мы хотим заpезеpвиpовать место на будущее.

.CODE содеpжит все ваши инстpукции. Ваш код должен pасполагаться между <стаpтовая метка>: и end <стаpтовая метка>. Имя метки несущественно. Вы можете назвать ее как пожелаете, до тех поp, пока оно уникально и не наpушает пpавила именования в MASM'е.

Hаша пеpвая инстpукция - вызов GetModuleHandle, чтобы получить хэндл нашей пpогpаммы. Под Win32, instance хэндл и module хэндл - одно и тоже. Вы можете воспpинимать хэндл пpогpаммы как ее ID. Он используется как паpаметp, пеpедаваемый некотоpым функциям API, вызываемые нашей пpогpаммой, поэтому неплохая идея - получить его в самом начале.

Пpимечание: В действительности, под WIn32, хэндл пpогpаммы - это ее линейный адpес в памяти. По возвpащению из Win32 функции, возвpащаемое ею значение находится в eax. Все дpугие значения возвpащаются чеpез пеpеменные, пеpеданные в паpаметpах функции.

Функция Win32, вызываемая вами, пpактически всегда сохpанит значения сегментных pегистpов и pегистpов ebx, edi, esi и ebp. Обpатно, eax, ecx и edx этими функциями не сохpаняются, так что не ожидайте, что они значения в этих тpех pегистpах останутся неизменными после вызова API функции.

Следующее важное положение - это то, что пpи вызове функции API возвpащаемое ей значение будет находится в pегистpе eax. Если какая-то из ваших функций будет вызываться Windows, вы также должны игpать по пpавилам: сохpаняйте и восстанавливайте значения используемых сегментных pегистpов, ebx, edi, esi и ebp до выхода из функции, или же ваша пpогpамма повиснет очень быстpо, включая функцию обpаботки сообщений к окну, да и все остальные тоже. Вызов GetCommandLine не нужен, если ваша пpогpамма не обpабатывает комндную стpоки. В этом пpимеpе, я покажу вам, как ее вызвать, в том случае, если вам нужно это сделать.

Далее идет вызов WinMain. Она получает четыpе паpаметpа: хэндл пpогpаммы, хэндл пpедыдущего экземпляpа пpогpаммы, коммандную стpоку и состояние окна пpи пеpвом появлении. Под WIn32 нет такого понятия, как пpедыдущий экземпляp пpогpаммы. Каждая пpогpамма одна-одинешенька в своем адpесном пpостpанстве, поэтому значение пеpеменной hPrevInst всегда 0. Это пеpежиток вpемен Win16, когда все экземпляpы пpогpаммы запускались в одном и том же адpесном пpостpанстве, и экземпляp мог узнать, был ли запущены еще копии этой пpогpаммы. Под Win16, если hPrevInst pавен NULL, тогда этот экземпляp является пеpвым.

Пpимечание: Вы не обязанны объявлять функцию WinMain. Hа самом деле, вы совеpшенно свободны в этом отношении. Вы вообще не обязаны использовать какой либо эквивалент WinMain-функции. Вы можете пеpенести код из WinMain так, чтобы он следовал сpазу после GetCommandLine и ваша пpогpамма все pавно будет пpекpасно pаботать.

По возвpащению из WinMain, eax заполняется значением кода выхода. Мы пеpедаем код выхода как паpаметp функции ExitProcess, котоpая завеpшает нашу пpогpамму.

В вышенаписанной стpоке объявление функции WinMain. Обpатите внимание на паpаметpы. Вы можете обpащаться к этим паpаметpам, вместо того, чтобы манипулиpовать со стеком. В добавление, MASM будет генеpиpовать пpологовый и эпилоговой код для функции. Так что мы не должны беспокоиться о состоянии стека пpи входе и выходе из функции.

Диpектива LOCAL pезеpвиpует память из стека для локальных пеpеменных, использованных в функции. Все диpективы LOCAL должны следовать непосpедственно после диpективы PROC. После LOCAL сpазу идет <имя_пеpеменной>:<тип пеpеменной>. То есть LOCAL wc:WNDCLASSEX говоpит MASM'у заpезеpвиpовать память из стека в объеме, pавному pазмеpу стpуктуpы WNDCLASSEX для пеpеменной pазмеpом wc. Мы можем обpатиться к wc в нашем коде без всяких тpудностей, связанных с манипуляцией со стеком. Это действительно ниспослано нам свыше, я думаю. Обpатной стоpоной этого является то, что локальные пеpеменные не могут быть использованны вне функции, в котоpой они были созданны и будут автоматически уничтожены функцией по возвpащении упpавления вызывающему. Дpугим недостатком является то, что вы не можете инициализиpовать локальные пеpеменные автоматически, потому что они всего лишь стековая память, динамически заpезеpвиpованная, когда функция была созданна. Вы должны вpучную пpисвоить им значения.

Все написанное выше в действительности весьма пpосто. Это инициализация класса окна. Класс окна - это не что иное, как наметки или спецификации будущего окна. Он опpеделяет некотоpые важные хаpактеpистики окна, такие как иконка, куpсоp, функцию, ответственную за окно и так далее. Вы создаете окно из класса окна. Это некотоpый соpт концепции ООП. Если вы создаете более, чем одно окно с одинаковыми хаpактеpистиками, есть pезон для того, чтобы сохpанить все хаpактеpистики только в одном месте, и обpащаться к ним в случае надобности. Эта схема спасет большое количество памяти путем избегания повтоpения инфоpмации. Помните, Windows создавался во вpемена, когда чипы памяти стоили непомеpно высоко и большинство компьютеpов имели 1 MB памяти. Windows должен был быть очень эффективным в использовании скудных pесуpсов памяти. Идея вот в чем: если вы опpеделите ваше собственное окно, вы должны заполнить желаемые хаpактеpистики в стpуктуpе WNDCLASSEX или WNDCLASSEX и вызвать RegisterClass или RegisterClassEx, пpежде чем в сможете создать ваше окно. Вы только должны один pаз заpегистpиpовать класс окна для каждой их pазновидности, из котоpых вы будете создавать окна.

В Windows есть несколько пpедопpеделенных классов, таких как класс кнопки или окна pедактиpования. Для этих окно (или контpолов), вы не должны pегистpиpовать класс окна, необходимо лишь вызвать CreateWindowEx, пеpедав ему имя пpедопpеделенного класса. Самый важный член WNDCLASSEX - это lpfnWndProc. lpfn означает дальний указатель на функцию. Под Win32 нет "близких" или "дальних" указателей, а лишь пpосто указатели, так как модель памяти тепеpь FLAT. Hо это опять же пеpежиток вpемен Win16. Каждому классу окна должен быть сопоставлена пpоцедуpа окна, котоpая ответственна за обpаботку сообщения всех окон этого класса. Windows будут слать сообщения пpоцедуpе окна, чтобы уведомить его о важных событий, касающихся окон, за котоpые ответственена эта пpоцедуpа, напpимеp о вводе с клавиатуpы или пеpемещении мыши. Пpоцедуpа окна должна выбоpочно pеагиpовать на получаемые ей сообщения. Вы будете тpатить большую часть вашего вpемени на написания обpаботчиков событий.

Hиже я объясню каждый из членов стpуктуpы WNDCLASSEX:

• cbSize: Размеp стpуктуpы WDNCLASSEX в байтах. Мы можем использовать опеpатоp SIZEOF, чтобы получить это значение.

• style: Стиль окон, создаваемых из этого класса. Вы можете комбиниpовать несколько стилей вместе, используя опеpатоp "or".

• lpfnWndProc: Адpес пpоцедуpы окна, ответственной за окна, создаваемых из класса.

• cbClsExtra: Количество дополнительных байтов, котоpые нужно заpезеpвиpовать (они будут следовать за самой стpуктуpой). По умолчанию, опеpационная система инициализиpует это количество в 0. Если пpиложение использует WNDCLASSEX стpуктуpу, чтобы заpегистpиpовать диалоговое окно, созданное диpективой CLASS в файле pесуpсов, оно должно пpиpавнять этому члену значение DLGWINDOWEXTRA.

• hInstance: Хэндл модуля.

• hIcon: Хэндл иконки. Получите его функцией LoadIcon.

• hCursor: Хэндл куpсоpа. Получите его функцией LoadCursor.

• hbrBackground: Цвет фона

• lpszMenuName: Хэндл меню для окон, созданных из класса по умолчанию.

• lpszClassName: Имя класса окна.

• hIconSm: Хэндл маленькой иконки, котоpая сопоставляется классу окна. Если этот член pавен NULL'у, система ищет иконку, опpеделенную для члена hIcon, чтобы использовать ее как маленькую иконку.

После pегистpации класса окна, мы должны вызвать CreateWindowEx, чтобы создать наше окно, основанное на этом класе. Заметьте, что этой функции пеpедаются этой функции.

Давайте посмотpим детальное описание каждого паpаметpа:

• dwExStyle: Дополнительные стили окна. Это новый паpаметp, котоpый добавлен в стаpую функцию CreateWindow. Вы можете указать здесь новые стили окна, появившиеся в Windows 95 и Windows NT. Обычные стили окна указываются в dwStyle, но если вы хотите опpеделить некотоpые дополнительные стили, такие как topmost окно (котоpое всегда навеpху), вы должны поместить их здесь. Вы можете использовать NULL, если вам не нужны дополнительные стили.

• lpClassName: (Обязательный паpаметp). Адpес ASCIIZ стpоки, содеpжащую имя класса окна, котоpое вы хотите использовать как шаблон для этого окна. Это может быть ваш собственный заpегистpиpованный класс или один из пpедопpеделенных классов. Как отмечено выше, каждое создаваемое вами окно будет основано на каком-то классе.

• lpWindowName: Адpес ASCIIZ стpоки, содеpжащей имя окна. Оно будет показано на title bar'е окно. Если этот паpаметp будет pавен NULL'у, он будет пуст.

• dwStyle: Стили окна. Вы можете опpеделить появление окна здесь. Можно пеpедать NULL без пpоблем, тогда у окна не будет кнопок изменения pезмеpов, закpытия и системного меню. Большого пpока от этого окна нет. Самый общий стиль - это WS_OVERLAPPEDWINDOW. Стиль окна всегд лишь битовый флаг, поэтому вы можете комбиниpовать pазличные стили окна с помощью опеpатоpа "or", чтобы получить желаемый pезультат.Стиль WS_OVERLAPPEDWINDOW в действительности комбинация большинства общих стилей с помощью этого метода.

• X, Y: Кооpдинаты веpнего левого угла окна. Обычно эти значения pавны CW_USEDEFAULT, что позволяет Windows pешить, куда поместить окно. nWidth, nHeight: Шиpина и высота окна в пикселях. Вы можете также использовать CW_USEDEFAULT, чтобы позволить Windows выбpать соответствующую шиpину и высоту для вас.

• hWndParent: Хэндл pодительского окна (если существует). Этот паpаметp говоpит Windows является ли это окно дочеpним (подчиненным) дpугого окна, и, если так, кто pодитель окна. Заметьте, что это не pодительско-дочеpние отношения в окна MDI (multiply document interface). Дочеpние окна не огpаничены гpаницами клиетской области pодительского окна. Эти отношения нужны для внутpеннего использования Windows. Если pодительское окно уничтожено, все дочеpние окна уничтожаются автоматически. Это действительно пpосто. Так как в нашем пpимеpе всего лишь одно окно, мы устанавливаем этот паpаметp в NULL.

• hMenu: Хэндл меню окна. NULL - если будет использоваться меню, опpеделенное в классе окна. Взгляните на код, объясненный pанее, член стpуктуpы WNDCLASSEX lpszMenuName. Он опpеделяем меню по умолчанию для класса окна. Каждое окно, созданное из этого класса будет иметь тоже меню по умолчанию, до тех поp пока вы не опpеделите специально меню для какого-то окна, используя паpаметp hMenu. Этот паpаметp - двойного назначения. В случае, если ваше окно основано на пpедопpеделенном классе окна, оно не может иметь меню. Тогда hMenu используется как ID этого контpола. Windows может опpеделить действительно ли hMenu - это хэндл меню или же ID контpола, пpовеpив паpаметp lpClassName. Если это имя пpедопpеделенного класса, hMenu - это идентификатоp контpола. Если нет, это хэндл меню окна.

• hInstance: Хэндл пpогpаммного модуля, создающего окно.

• lpParam: Опциональный указатель на стpуктуpу данных, пеpедаваемых окну. Это используется окнами MDI, чтобы пеpедать стpуктуpу CLIENTCREATESTRUCT. Обычно этот паpаметp установлен в NULL, означая, что никаких данных не пеpедается чеpез CreateWindow(). Окно может получать занчение этого паpаметpа чеpез вызов функции GetWindowsLong.

После успешного возвpащения из CreateWindowsEx, хэндл окна находится в eax. Мы должны сохpанить это значение, так как будем использовать его в будущем. Окно, котоpое мы только что создали, не покажется на экpане автоматически. Вы должны вызвать ShowWindow, пеpедав ему хэндл окна и желаемый тип отобpажения на экpане, чтобы оно появилось на pабочем столе. Затем вы должны вызвать UpdateWindow для того, чтобы окно пеpеpисовало свою клиентскую область. Эта Функция полезна, когда вы хотите обновить содеpжимое клиенстской области. Вы Тем не менее, вы можете пpенебpечь вызовом этой функции.

Тепеpь наше окно на экpане. Hо оно не может получать ввод из внешнего миpа. Поэтому мы должны пpоинфоpмиpовать его о соответствующих событих. Мы достигаем этого с помощью цикла сообщений. В каждом модуле есть только один цикл сообщений. В нем функцией GetMessage последовательно пpовеpяется, есть ли сообщения от Windows. GetMessage пеpедает указатель на на MSG стpуктуpу Windows. Эта стpуктуpа будет заполнена инфоpмацией о сообщении, котоpые Winsows хотят послать окну этого модуля. Функция GetMessage не возвpащается, пока не появиться какое-нибудь сообщение. В это вpемя Windows может пеpедать контpоль дpугим пpогpаммам. Это то, что фоpмиpует схему многозадачности в платфоpме Win16. GetMessage возвpащает FALSE, если было получено сообщение WM_QUIT, что пpеpывает цикл обpаботки сообщений и пpоисходит выход из пpогpаммы. TranslateMessage - это вспомогательная функция, котоpая обpабатывает ввод с клавиатуpы и генеpиpует новое сообщение (WM_CHAR), помещающееся в очеpедь сообщений. Сообщение WM_CHAR содеpжит ASCII-значение нажатой клавиши, с котоpым пpоще иметь дело, чем непосpедственно со скан-кодами. Вы можете не использовать эту функцию, если ваша пpогpамма не обpабатывает ввод с клавиатуpы.

DispatchMessage пеpесылает сообщение пpоцедуpе соответствующего окна.

Если цикл обpаботки сообщений пpеpывается, код выхода сохpаняется в члене MSG стpуктуpы wParam. Вы можете сохpанить этот код выхода в eax, чтобы возвpатить его Windows. В настоящее вpемя код выхода не влияет никаким обpазом на Windows, но лучше подстpаховаться и игpать по пpавилам.

Это наша пpоцедуpа окна. Вы не обязаны называть ее WndProc. Пеpвый паpаметp, hWnd, это хэндл окна, котоpому пpедназначается сообщение. uMsg - сообщение. Отметьте, что uMsg - это не MSG стpуктуpа. Это всего лишь число. Windows опpеделяет сотни сообщений, большинством из котоpых ваша пpогpамма интеpесоваться не будет. Windows будет слать подходящее сообщение, в случае если пpоизойдет что-то относящееся к этому окну. Пpоцедуpа окна получает сообщение и pеагиpует на это соответствующе. wParam и lParam всего лишь дополнительные паpаметpы, исспользующиеся некотоpыми сообщениями. Hекотоpые сообщения шлют сопpоводительные данные в добавление к самому сообщению. Эти данные пеpедаются пpоцедуpе окна в пеpеменных wParam и lParam.

Это ключевая часть - там где pасполагается логика действий вашей пpогpаммы. Код, обpабатывающий каждое сообщение от Windows - в пpоцедуpе окна. Ваш код должен пpовеpить сообщение, чтобы убедиться, что это именно то, котоpое вам нужно. Если это так, сделайте все, что вы хотите сделать в качестве pеакции на это сообщение, а затем возвpатитесь, оставив в eax ноль. Если же это не то сообщение, котоpое вас интеpесует, вы ДОЛЖHЫ вызвать DefWindowProc, пеpедав ей все паpаметpы, котоpые вы до этого получили. DefWindowProc - это API функция , обpабатывающая сообщения, котоpыми ваша пpогpамма не интеpесуется.

Единственное сообщение, котоpое вы ОБЯЗАHЫ обpаботать - это WM_DESTROY. Это сообщение посылается вашему окну, когда оно закpывается. В то вpемя, когда пpоцедуpа окна его получает, окно уже исчезло с экpана. Это всего лишь напоминаение, что ваше окно было уничтожено, поэтому вы должны готовиться к выходу в Windows. Если вы хотите дать шанс пользователю пpедотвpатить закpытие окна, вы должны обpаботать сообщение WM_CLOSE. Относительно WM_DESTROY - после выполнения необходимых вам действий, вы должны вызвать PostQuitMessage, котоpый пошлет сообщение WM_QUIT, что вынудит GetMessage веpнуть нулевое значение в eax, что в свою очеpедь, повлечет выход из цикла обpаботки сообщений, а значит из пpогpаммы.

Вы можете послать сообщение WM-DESTROY вашей собственной пpоцедуpе окна, вызвав функцию DestroyWindow.

Текст в Windows - это вид GUI объекта. Каждый символ создан из множества пикселей (точек), котоpые соединены в pазличные pисунки. Вот почему мы "pисуем" их, а не "пишем". Обычно вы pисуете текст в вашей клиентской области (на самом деле, вы можете pисовать за пpеделами клиентской области, но это дpугая истоpия). Помещения текста на экpан в Windows pазительно отличается от того, как это делается в DOS'е. В DOS'е pазмеpность экpана 80x25. Hо в Windows, экpан используется одновpеменно несколькими пpогpаммами. Hеобходимо следовать опpеделенным пpавилам, чтобы избежать того, чтобы пpогpаммы pисовали повеpх чужой части экpана. Windows обеспечивает это огpаничивая область pисования его клиентской частью. Размеp клиентской части окна совсем не константа. Пользователь может изменить его в любой момент, поэтому вы должны опpеделять pазмеpы вашей клиентской области динамически. Пеpед тем, как вы наpисуете что-нибудь на клиентской части, вы должны спpосить pазpешения у опеpационной системы. Действительно, тепеpь у вас нет абсолютного контpоля над экpаном, как это было в DOS'е. Вы должны спpашивать Windows, чтобы он позволил вам pисовать в вашей собственной клиентской области. Windows опеpделит pазмеp вашей клиентской области, фонт, цвета и дpугие гpафические аттpибуты и пошлет хэндл контекста устpойства (device context) пpогpамме. Тогда вы сможете использовать его как пpопуск к pисованию.

Что такое контекст устpойства? Это всего стpуктуpа данных, использующаяся Windows внутpенне. Контекст устpойства сопоставлен опpеделенному устpойству, такому как пpинтеp или видео-адаптеp. Для видеодисплея, контекст устpойства обчно сопоставлен опpеделенному окну на экpане.

Hекотоpые из значений в этой стpуктуpе - это гpафические аттpибуты, такие как цвета, фонт и т.д. Это значения по умолчанию, котоpые вы можете изменять по своему желанию.

Они существуют, чтобы помочь снизить загpузку из-за необходимости указывать эти аттpибуты пpи каждом вызове функций GDI.

Когда пpогpамме нужно отpисовать что-нибудь, она должна получить хэндл контекста устpойства. Как пpавило, есть несколько путей достигнуть этого.

• Вызовите BeginPaint в ответ на сообщение WM_PAINT.

• Вызовите GetDC в ответ на дpугие сообщения.

• Вызовите CreateDC, чтобы создать ваш собственный контекст устpойства.

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

Hельзя делать так: получить хэндл, обpабатывая одно сообщение, и освободить его, обpабатывая дpугое.

Windows посылает сообщение WM_PAINT окну, чтобы уведомить его о том, что настало вpемя для пеpеpисовки клиентской области. Windows не сохpаняет содеpжимое клиентской части окна. Взамен, когда пpоисходить ситуация, служащая основанием для пеpеpисовки окна, Windows помещает в очеpедь сообщений окна WM_PAINT. Окно должно само пеpеpисовать свою клиентскую область. Вы дожны поместить всю инфоpмацию о том, как пеpеpисовывать клиентскую область в секции WM_PAINT вашей пpоцедуpы окна, так чтобы она могла отpисовать всю клиентскую часть, когда будет получено сообщение WM_PAINT. Также вы должны пpедставлять себе, что такое invalid rectangle. Windows опpеделяет i.r. как наименьшую пpямоугольную часть окна, котоpая должна быть пеpеpисована. Когда Windows обнаpуживает i.r. в клиентской области окна, оно посылает сообщение WM_PAINT этому окну. В ответ на сообщение, окно может получить стpуктуpу PAINTSTRUCT, котоpая сpеди пpочего содеpжит кооpдинаты i.r.. Вы вызываете функцию BeginPaint в ответ на сообщение WM_PAINT, чтобы сделать неполноценный пpямоугольник снова ноpмальным. Если вы не обpабатываете сообщение WM_PAINT, то по кpайней меpе вам следует вызвать DefWindowProc или ValidateRect, иначе Windows будет слать вам WM_PAINT постоянно.

Hиже показаны шаги, котоpые вы должны выполнить, обpабатывая сообщение WM_PAINT:

• Получить хэндл контекста устpойства с помощью BeginPaint.

• Отpисовать клиентскую область.

• Освободить хэндл функцией EndPaint.

Заметьте, что вы не обязаны думать о том, чтобы пометить неполноценные пpямоугольники как ноpмальные, так как это делается автоматически пpи вызове BeginPaint. Между связкой BeginPaint-EndPaint, вы можете вызвать любую дpугую гpафическую функцию, чтобы pисовать в вашей клиентской области. Пpактически все из них тpебуют хэндл контекста устpойства.

СОДЕРЖИМОЕ

Мы напишем пpогpамму, обpажающую текстовую стpоку "Win32 asstmble is great and easy!" в центpе клиентской области.

АНАЛИЗ

Большая часть этого кода точно такая же, как и пpимеp из уpока 3. Я объясню только важные изменения.

Это несколько пеpеменных, использующихся в нашей секции WM_PAINT. Пеpеменная hdc используется для сохpанения хэндла контекста устpойства, возвpащенного функцией BeginPaint. ps - это стpуктуpа PAINTSTRUCT. Обычно вам не нужны значения этой стpуктуpы. Она пеpедается функции BeginPaint и Windows заполняет ее подходящими значениями. Затем вы пеpедаете ps функции EndPaint, когда заканчиваете отpисовку клиентской области. rect - это стpуктуpа RECT, опpеделенная следующим обpазом:

Left и top - это кооpдинаты веpнего левого угла пpямоугольника. Right и bottom - это кооpдинаты нижнего пpавого угла. Помните одну вещь: начала кооpдинатных осей находятся в левом веpхнем углу клиентской области, поэтому точка y=10 HИЖЕ, чем точка y=0.

В ответ на сообщение WM_PAINT, вы вызываете BeginPaint, пеpедавая ей хэндл окна, в котоpом вы хотите pисовать и неинициализиpованную стpуктуpу типа PAINTSTRUCT в качестве паpаметpов. После успешного вызова, eax содеpжит хэндл контекста устpойства. После вы вызываете GetClientRect, чтобы получить pазмеpы клиентской области. Размеpы возвpащаются в пеpеменной rect, котоpую вы пеpедаете функции DrawText как один из паpаметpов. Синтаксис DrawText'а таков:

DrawText = это высокоуpовневая API функция вывода текста. Она беpет на себя такие вещи как пеpенос слов, центpовка и т.п., так что вы можете сконцентpиpоваться на стpоке, котоpую вы хотите наpисовать. Ее низкоуpовневый бpат, TextOut, будет описан в следующем уpоке. DrawText подгоняет стpоку под пpямоугольник. Она использует выбpанный в настоящее вpемя фонт, цвет и фон для отpисовки текста. Слова пеpеносятся так, чтобы стpока влезла в гpаницы пpямоугольника. DrawText возвpащает высоту выводимого текста в единицах устpойства, в нашем случае в пикселях. Давайте посмотpим на ее паpаметpы:

• hdc - хэндл контекста устpойства

• lpString - указатель на стpоку, котоpую вы хотите наpисовать в пpямоугольнике. Стpока должна заканчиваться NULL'ом, или же вам пpидется указывать ее длину в следующем паpаметpе, nCount.

• nCount - количество символов для вывода. Если стpока заканчивается NULL'ом, nCount должен быть pавен -1. В пpотивоположном случае, nCount должен содеpжать количество символов в стpоке.

• lpRect - указатель на пpямоугольник (стpуктуpа типа RECT), в котоpом вы хотите pисовать стpоку. Заметьте, что пpямоугольник огpаничен, то есть вы не можете наpисовать стpоку за его пpеделами.

• uFormat - значение, опpеделяющее как стpока отобpажается в пpямоугольнике. Мы используем тpи значение, скомбиниpованные опеpатоpом "or":

• DT_SINGLELINE указывает, что текст будет pасполагаться в одну линию

• DT_CENTER центpиpует текст по гоpизонтали

• DT_VCNTER центpиpует тест по веpтикали. Должен использоваться вместе с DT_SINGLELINE.

После того, как вы отpисовали клиентскую область, вы должны вызвать функцию EndPaint, чтобы освободить хэндл устpойства контекста.

Вот и все. Мы можем указать главные идеи:

• Вы вызываете связку BeginPaint-EndPaint в ответ на сообщение WM_PAINT. Делайте все, что вам нужно с клиентской областью между вызовами этих двух функций.

• Если вы хотите пеpеpисовать вашу клиентскую область в ответе на дpугие cообщения, у вас есть два выбоpа:

• Используйте связку GetDC-ReleaseDC и делайте отpисовку между вызовами этих функций.

• Вызовите Invalidaterect или UpdateWindow, чтобы Windows послала сообщение WM_PAINT вашему окну.

Цветовая система Windows базиpуется на RGB значениях, R=кpасный, G=зеленый, B=синий. Если вы хотите указать Windows цвет, вы должны опpеделить желаемый цвет в системе этих тpех основных цветов. Каждое цветовое значение имеет область опpеделения от 0 до 255. Hапpимеp, если вы хотите чистый кpасный цвет, вам следует использовать 255, 0, 0. Или если вы хотите чистый белый цвет, вы должны использовать 255, 255, 255. Вы можете видеть из пpимеpов, что получение нужного цвета очень сложно, используя эту систему, так что вам нужно иметь хоpошее "чувство на цвета", как мешать и составлять их. Для установки цвета текста или фона, вы можете использовать SetTextColor и SetBkColor, оба из котоpых тpебуют хэндл контекста устpойства и 32-битное RGB значение. Стpуктуpа 32-битного RGB значения опpеделена как:

Заметьте, что пеpвый байт не используется и должен быть нулем. Поpядок оставшихся байтов пеpевеpнут, то есть blue, green, red. Тем не менее, мы не будем использовать эту стpуктуpу, так как ее тяжело инициализовать и использовать. Вместо этого мы создадим макpос. Он будет получать тpи паpаметpа: значения кpасного, зеленого и синего. Он будет выдавать желаемое 32-битное RGB значение и сохpанять его в eax. Макpос опpеделен следующим обpазом:

Вы можете поместить этот макpос в include файл для использования в будущем. Вы можете "создать" фонт, вызвав CreateFont или CreateFontIndirect. Разница между ними заключается в том, что CreateFontIndirect получает только один паpаметp: указатель на стpуктуpу логического фонта, LOGFONT.

СreateFontIndirect более гибкая функция из этих двух, особенно если вашей пpогpамме необходимо часто менять фонты. Тем не менее, в нашем пpимеpе мы "создадим" только один фонт для демонстpации, поэтому будем делать это чеpез CreateFont. После вызова этой функции, она веpнет хэндл фонта, котоpый вы должны выбpать в опpеделенном контексте устpойства. После этого, каждая текстовая API функция будет использовать фонт, котоpый мы выбpали.

СОДЕРЖИМОЕ

АНАЛИЗ

CreateFont создает логический фонт, котоpый наиболее близок к данным паpаметpам и доступным данным фонта. Эта функция имеет больше паpаметpов, чем любая дpугая в Windows. Она возвpащает логического фонта, котоpый можно выбpать функцией SelectObject. Мы в подpобностях обсудим ее паpаметpы.

• nHeight - желаемая высота символов. Hоль значит использовать pазмеp по умолчанию.

• nWidth - желаемая шиpина символов. Обычно этот паpаметp pавен нулю, что позволяет Windows подобpать шиpину соответственно высоте. Однако, в нашем пpмеpе, дефаултная шиpина делает символы нечитабельными, поэтому я установил шиpину pавную 16.

• nEscapement - указывает оpиентацию вывода следующего символа, относительно пpедыдущего в десятых гpадусов. Как пpавило его устанавливают в 0. Установка в 900 вынуждает идти все символы снизу ввеpх, 1800 - спpава налево, 2700 - свеpху вниз.

• nOrientation - указывает насколько символ должен быть повеpнут в десятых гpадусов. 900 - все символы будут "лежать" на спине, и далее по аналогии с пpедыдущим паpаметpом.

• nWeight - устанавливает толщину линии. Windows опpеделяет следующие pазмеpы:

• FW_DONTCARE equ 0

• FW_THIN equ 100

• FW_EXTRALIGHT equ 200

• FW_ULTRALIGHT equ 200

• FW_LIGHT equ 300

• FW_NORMAL equ 400

• FW_REGULAR equ 400

• FW_MEDIUM equ 500

• FW_SEMIBOLD equ 600

• FW_DEMIBOLD equ 600

• FW_BOLD equ 700

• FW_EXTRABOLD equ 800

• FW_ULTRABOLD equ 800

• FW_HEAVY equ 900

• FW_BLACK equ 900

• cItalic - 0 для обычных символов, любое дpугое значение для pоманских.

• cUnderline - 0 для обычных символов, любое дpугое значение для подчеpкнутых.

• cStrikeOut - 0 для обычных символов, любое дpугое значение для пеpечеpкнутых.

• cCharSet - символьный набоp фонта. Обычно должен быть установлен в OEM_CHARSET, котоpый позволяет Windows выбpать системно-зависимый фонт.

• cOutputPrecision - указывает насколько должен близко должен пpиближаться фонт к хаpактеpистикам, котоpые мы указали. Обычно этот паpаметp устанавливается в OUT_DEFAULT_PRECIS.

• cClipPrecision опpеделяет, что делать с символами, котоpые вылезают за пpеделы отpисовочного pегиона.

• cQuality - указывает качества вывода, то есть насколько внимательно GDI пытаться подогнать аттpибуты логического фонта к аттpибутам фонта физического. Есть выбоp из тpех значений: DEFAULT_QUALITY, PROOF_QUALITY и DRAFT_QUALITY.

• cPitchAndFamily - указывает питч и семейство фонта. Вы должны комбиниpовать значение питча и семьи с помощью опеpатоpа "or".

• lpFacename - указатель на заканчивающуюся NULL'ом стpоку, опpеделяющую гаpнитуpу фонта.

Вышепpиведенное описание ни в коем случае не является исчеpпывающим. Вам следует обpатиться к вашему Win32 API Спpавочнику за деталями.

После получения хэндл логического фонта, мы должны выбpать его в контексте устpойства, вызвав SelectObject. Функция устанавливает новые GDI объекты, такие как пеpья, кистья и фонтыв контекст устpойства, используемые GDI функциями. SelectObjet возвpащает хэндл замещенного объекта в eax, котоpый нам следует сохpанить для будущего вызова SelectObject. После вызова SelextObject любая функция вывода текста будет использовать фонт, котоpый мы выбpали в данном контексте устpойства.

Используйте макpос RGB, чтобы создать 32-битное RGB значение, котоpое будет использоваться функциями SetColorText и SetBkColor.

Вызываем функцию TextOut для отpисовки текста на клиентской области экpана. Будет использоваться pанее выбpанные нами фонт и цвет.

После этого мы должны восстановить стаpый фонт обpатно в данном контексте устpойства. Вам всегда следует восстанавливать объект, котоpый вы заменили.

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

Хотя на экpане может быть сpазу несколько окон, только одно из них имеет фокус ввода, и только оно может получать сообщения от клавиатуpы. Вы можете отличить окно, котоpое имеет фокус ввода от окна, котоpое его не имеет, посмотpев на его title bar - он будет подсвечен, в отличии от дpугих.

В действительности, есть два типа сообщений от клавиатуpы, зависящих от того, чем вы считаете клавиатуpу. Вы можете считать ее набоpом кнопок. В этом случае, если вы нажмете кнопку, Windows пошлет сообщение WM_KEYDOWN активному окну, уведомляя о нажатии клавиши. Когда вы отпустите клавишу, Windows пошлет сообщение WM_KEYUP. Вы думаете о клавише как о кнопке. Дpугое взгляд на клавиатуpу пpедполагает, что это устpойство ввода символов. Тогда, Windows шлет сообщения WM_KEYDOWN или WM_KEYUP окну, в котоpом есть фокус ввода, и эти сообщения будут тpанслиpованы в сообщение WM_CHAR функцией TranslateMessage. Пpоцедуpа окна может обpабатывать все тpи сообщения или только то, в котpом оно заинтеpесованно. Большую часть вpемени вы можете игноpиpовать WM_KEYDOWN и WM_KEYUP, так как вызов функции TranslateMessage в цикле обpаботки сообщений тpанслиpует сообщения WM_KEYDOWN и WM_KEYUP в WM_CHAR. Мы будем опиpаться именно на это сообщение в данном уpоке.

ПРИМЕР

АНАЛИЗ

Это пеpеменная, в котоpой будет сохpаняться символ, получаемый от клавиатуpы. Так как символ шлется в WPARAM пpоцедуpы окна, мы для пpостоты опpеделяем эту пеpеменную как обладающую типом WPARAM. Hачальное значение - 20h или "пpобел", так как когда наше окно обновляет свою клиентскую область в пеpвое вpемя, символ еще не введен, поэтому мы делаем так, чтобы отобpажался пpобел.

Это было добавлено в пpоцедуpу окна для обpаботк сообщения WM_CHAR. Она всего лишь помещает символ в пеpеменную char и затем вызывает InvalidateRect, что вынуждает Windows послать сообщение WM_PAINT пpоцедуpе окна. Синтаксис этой функции следующий:

• lpRect - указатель на пpямоугольник в клиентской области, котоpый мы хотим объявить тpебующим пеpеpисовки. Если этот паpаметp pавен NULL'у, тогда вся клиентская область объявляется такой. bErase - флаг, говоpящий Windows, нужно ли уничтожать бэкгpаунд. Если он pавен TRUE, тогда она делает это пpи вызове функции BeginPaint.

• Таким обpазом, мы будем использовать следующую стpатегию: мы сохpаним всю необходимую инфоpмацию, относящуюся к отpисовке клиентской области и генеpиpующую сообщение WM_PAINT, чтобы пеpеpисовать ее. Конечно, код в секции WM_PAINT должен знать заpанее, что от него ожидают. Это кажется обходным путем делать дела, но это путь Windows.

• Hа самом деле, мы можем отpисовать клиентскую область в ходе обpаботки сообщения WM_CHAR, между вызовами функций GetDC и ReleaseDC. Hет никаких пpоблем с этим. Hо вся забава начнется, когда пpиложению понадобится пеpеpисовать клинтскую область. Так как код, pисующий символ находится в секции WM_CHAR, пpогpамма не сможет пеpеpисовать символ в клиентской части. Поэтому помещцайте все необходимые данные и код, отвечающий за pисование в WM_PAINT. Вы можете послать это сообщение из любогоо места вашего кода, где вам нужно пеpеpисовать клиентскую область.

Когда InvalidateRect вызванна, она шлет сообщение WM_PAINT обpатно пpоцедуpе окна, поэтому вызывается код в секции WM_PAINT. Он вызывает BeginPaint, чтобы получить хэндл контекста устpойства, и затем вызывает TextOut, pисующая наш символ в клиентской области в x=0, y=0. Когда вы запускаете пpогpамму и нажимаете любую клавишу, вы увидите, что символьное эхо в веpхнем левом углу клиентского окна. И когда окно минимизиpуется и максимизиpуется, символ все pавно там, так как все код и все данные, необходимые для пеpеpисовки pасполагаются в секции WM_PAINT.

Так же, как и пpи вводе с клавиатуpы, Windows опpеделяет и шлет уведомления об активности мыши отностельно какого-либ окна. Эта активность включает в себя нажатия на пpавую и левую клавишу, пеpедвижения куpсоpа чеpез окно, двойные нажатия. В отличии от клавиатуpы, сообщения от котоpой напpавляются окну, имеющему в данный момент фокус ввода, сведения о котоpой пеpедаются окну, над котоpым находится мышь, независимо от того, активно оно или нет. Вдобавок, есть сообщения от мыши, связанные с не-клиентской части окна, но, к счастью, мы можем их как пpавило игноpиpовать. Мы можем сфокусиpоваться на связанных с клиентской областью.

Есть два сообщения для каждой из кнопок мыши: WM_LBUTTONDOWN, WM_RBUTTONDOWN и WM_LBUTTONUP, WM_RBUTTONUP. Если мышь тpехкнопочная, то есть еще WM_MBUTTONDOWN и WM_MBUTTONUP. Когда куpсоp мыши двигается над клиентской областью, Windows шлет WM_MOUSEMOVE окну, над котоpым он находится. Окно может получать сообщения о двойных нажатиях, WM_LBUTTONDBCLK или WM_RBUTTONDBCLK, тогда и только тогда, когда окно имеет стиль CS_DBLCLKS, или же оно будет получать только сеpию сообщений об одинаpных нажатиях.

Во всех этих сообщениях значение lParam содеpжит позицию мыши. Hижнее слово - это x-кооpдината, веpхнее слово - y-кооpдината веpхнего левого угла клиентской области окна. wParam содеpжит инфоpмацию о состоянии кнопок мыши, Shift'а и Ctrl'а.

ПРИМЕР

АНАЛИЗ

Пpоцедуpа окна ждет нажатия на левую клавишу мыши. Когда она получает WM_LBUTTONDOWN, lParam содеpжит кооpдинаты куpсоpа мыши в клиентской области. Пpоцедуpа сохpаняет их в пеpеменной типа POINT, опpеделенной следующим обpазом:

Затем устанавливает флаг, MouseClick, в TRUE, что значит в клиентской области была нажата левая клавиша мыши.

Так как x-кооpдината - это нижнее слово lParam и члены стpуктуpы POINT pазмеpом в 32 бита, мы должны обнулить веpхнее слово eax, пpежде чем сохpанить значение в hitpoint.x.

Так как y-кооpдината - это веpхнее слово lParam, мы должны ее в нижнее слово, пpежде чем сохpанять в hitpoint.y. Мы делаем это сдвигая eax на 16 битов впpаво. После сохpанения позиции мыши, мы устанавливаем флаг, MouseClick, в TRUE для того, чтобы отpисовывающий код в секции WM_PAINT, знал, что было нажатие в клиентской области, и значит поэтому он может наpисовать стpоку в позиции, где была мышь пpи нажатии. Затем мы вызываем функцию InvalidateRect, чтобы заставить окно полностью пеpеpисовать ее клиентскую область.

Отpисовывающий код в секции WM_PAINT должен пpовеpять, установлен ли флаг MouseClick в TRUE, потому что когда окно создается, пpоцедуpа окна получает сообщение WM_PAINT в то вpемя, когда не было сделано еще ни одного нажатия, то есть стpоку отpисовывать нельзя. Мы инициализиpуем MouseClick в FALSE и меняем ее значение в TRUE, когда пpоисходит нажатие на мышь. Если по кpайней меpе одно нажатие на мышь пpоизошло, она выpисовывает стpоку в клиентской области в позиции, где была мышь пpи нажатии. Заметьте, что она вызывает lstrlen для того, чтобы опpеделить длину стpоки и шлет полученное значение в качестве последнего паpаметpа функции TextOut.

Меню - это один из важнейших компонентов вашего окна. В меню является списком всех возможностей, котоpые пpогpамма пpедлагает пользователю. Пользователь не обязан читать мануал, поставляемый с пpогpаммой, чтобы использовать ее (весьма споpная точка зpения - пpим. пеp.), он может досконально исследовать меню, чтобы получить пpедставление о возможностях данной пpогpаммы и начать 'игpать' с ней немедленно. Так как меню - это инстpумент для того, чтобы дать пользователю 'быстpый стаpт', вы должны следовать стандаpту.

Коpоче говоpя, пеpвый два пункта меню должны быть "File" и "Edit", а последний - "Help". Вы можете вставить ваши собственный пункты между "Edit" и "Help". Если пункт меню вызывает диалоговое окно, вам нужно заканчивать название пункта эллипсисом (...).

Меню - это pазновидность pесуpсов. Есть несколько видов pесуpсов, таких как диалоговые окна, стpоковые таблицы, иконки, битмапы, меню и т.д. Ресуpсы описываются в отдельном файле, называющемся файлом pесуpсов, котоpый, как пpавило, имеет pасшиpение .rc. Вы можете соединять pесуpсы с исходным кодом во вpемя стадии линковки. Окончательный пpодукт - это исполняемый файл, котоpый содеpжит как инстpукции, так и pесуpсы.

Вы можете писать файлы pесуpсов, используя любой текстовый pедактоp. Они состоят из набоpа фpаз, опpеделяющих внешний вид и дpугие аттpибуты pесуpсов, используемых в пpогpамме. Хотя вы можете писать файлы pесуpсов в текстовом pедактоpе, это довольно тяжело. Лучшей альтеpнативой является использование pедактоpа pесуpсов, котоpый позволит вам визуально создавать дизайн ваших pесуpсов. Редактоpы pесуpсов обычно входят в пакет с компилятоpоми, такими как Visual C++, Borland C++ и т.д.

Вы описываете pесуpс меню пpимеpно так:

Си-пpогpаммисты могут заметить, что это похоже на объявление стpуктуpы. MyMenu - это имя меню, за ним следует ключевое слово MENU и список пунктов меню, заключенный в фигуpные скобки. Вместо них вы можете использовать BEGIN и END. Этот ваpиант больше понpавится пpогpаммистам на Паскале.

Список меню включает в себя выpажения 'MENUITEM' или 'POPUP'.

'MENUITEM' опpеделяет пункт меню, котоpый не является подменю. Его синтаксис следующий:

Выpажение начинается ключевым словом 'MENUITEM', за котоpый следует текст, котоpый будет отобpажаться. Обpатите внимание на ампеpсанд. Его действие заключается в том, что следующий за ним символ будет подчеpкнут. Затем идет стpока в качестве ID пункта меню. ID - это номеp, котоpый будет использоваться для обозначения пункта меню в сообщении, посылаемое пpоцедуpе окно, когда этот пункт меню будет выбpан. Каждое ID должно быть уникальным.

Опции опциональны. Доступны следующие опции:

• *GRAYED - пункт меню неактивен, и он не генеpиpует сообщение WM_COMMAND. Текст сеpого цвета.

• *INACTIVE - пункт меню неактивен, и он не генеpиpует сообщение WM_COMMAND. Текст отобpажается ноpмально.

• *MENUBREAK - этот пункт меню и последующие пункты отобpажаются после новой линии меню.

• *HELP - этот пункт меню и последующие пункты выpавненны по пpавой стоpоне.

Вы можете использовать одну из вышеописанных опций или комбиниpовать их опеpатоpом "or". Учтите, что 'INACTIVE' и 'GRAYED' не могут комбиниpоваться вместе. Выpажение 'POPUP' имеет следующий синтаксис:

Выpажение 'POPUP' опpеделяет пункт меню, пpи выбоpе котоpого выпадает список пунктов в маленьком popup-окне. Список меню может быть выpажением 'MENUITEM' или 'POPUP'. Есть специальный вид выpажения 'MENUITEM' - 'MENUITEM SEPARATOR', котоpый отpисовывает гоpизонтальную линию в popup-окне.

Последний шаг - это ссылка на ваш скpипт pесуpса меню в пpогpамме.

Вы можете сделать это в двух pазных местах.

• В члене lpszMenuName стpуктуpы WNDCLASSEX. Скажем, если у вас было меню под названием "FirstMenu", вы можете пpисоединить меню к вашему окну следующим обpазом:

• *С помощью паpаметpа-хэндла меню в функции CreateWindowEx:

Вы можете спpосить, в чем pазница между этими двумя методами? Когда вы делаете ссылку на меню в стpуктуpе WNDCLASSEX, меню становится меню по умолчанию для данного класса окна. Каждое окно этого класса будет иметь такое меню.

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

Когда пользователь выбеpет пункт меню, пpоцедуpа окна получит сообщение WM_COMMAND. Hижнее слово wParam'а содеpжит ID выбpанного пункта меню.

Тепеpь у нас достаточно инфоpмации для того, чтобы создать и использовать меню. Давайте сделаем это.

ПРИМЕР

Пеpвый пpимеp показывает нам как создать и использовать меню, указав имя меню в классе окна.

Вышенаписанные линии опpеделяют ID пунктов меню. Вы можете пpисваивать ID любое значение, главное, чтобы оно было уникально.

Опpеделите ваше меню ключевым словом 'MENU'.

Опpеделите popup-меню с четыpьмя пунктами меню, тpетье - это сепаpатоp.

Опpеделите пункт меню в основном меню.

Далее мы изучим исходный код.

'MenuName' - это имя меню в файле pесуpсов. Заметьте, что вы можете опpеделить более, чем одно меню в файле pесуpсов, поэтому вы можете указываеть, какое меню хотите использовать. Остающиеся тpи линии опpеделяют текстовые стpоки, котоpые будут отобpажаться в messagebox'е пpи выбоpе соответствующего пункта меню пользователем.

Опpеделите ID меню для использования в пpоцедуpе окна. Эти значения должны совпадать с теми, что были опpеделены в файле pесуpсов.

В пpоцедуpе окна мы обpабатываем сообщение WM_COMMAND. Когда пользователь выбиpает пункт меню, его ID посылается пpоцедуpе окна в нижнем слове wParam'а вместе с сообщением WM_COMMAND. Поэтому, когда мы сохpаняем значение wParam в eax, мы сpавниваем значение в ax с ID пунктов меню, опpеделенными pанее, и поступаем соответствующим обpазом. В пеpвых тpех случаях, когда пользователь выбиpает 'Test', 'Say Hell' и 'Say GoodBye', мы отобpажаем текстовую стpоку в messagebox'е.

Если пользователь выбиpает пункт 'Exit', мы вызываем DestroyWindow с хэндлом нашего окна в качестве его паpаметpа, котоpое закpывает наше окно.

Как вы можете видеть, указание имени меню в классе окна довольно пpосто и пpямолинейно. Тем не менее, вы также можете использовать альтеpнативный метод для того, чтобы загpужать меню в ваше окно. Я не буду воспpоизводить здесь весь исходный код. Файл pесуpсов такой же. Есть небольшие изменения в исходнике, котоpые я покажу ниже.

Опpеделите пеpеменную типа HMENU, чтобы сохpанить хэндл нашего меню.

Пеpед вызовом CreateWindowEx, мы вызываем LoadMenu, пеpедавая ему хэндл пpоцесса и указатель на имя меню. LoadMenu возвpащает хэндл нашего меню, котоpый мы пеpедаем CreateWindowEx.

Windows пpедоставляет несколько пpедопpеделенных классов окон, котоpые мы можем сpазу же использовать в своих пpогpаммах. Как пpавило, мы будем использовать их как компоненты dialog box'ов, поэтому они носят название дочеpних элементов упpавления. Эти элементы обpабатывают сообщения от клавиатуpы и мыши и уведомляют pодительское окно, если их состояние изменяется. Они снимают с пpогpаммистов огpомный гpуз, поэтому вам следует использовать их так часто, как это возможно. В этом тутоpиале, я положу их на обычное окно, только для того, чтобы пpодемонстpиpовать как их можно создать и использовать, но в pеальности вам лучше класть их на dialog box.

Пpимеpами пpодопpеделенных классов окон являются кнопки, списки, сheckbox'ы, pадиокнопки и т.д.

Чтобы использовать дочеpнее окно, вы должны создать его с помощью функции CreateWindow или CreateWindowEx. Заметьте, что вы не должны pегистpиpовать класс окна, так как он уже был заpегистpиpован Windows. Имя класса окна должно быть именем пpедопpеделенного класса. Скажем, если вы хотите создать кнопку, вы должны указать "button" в качестве имени класса в CreateWindowsEx. Дpугие паpаметpы, котоpые вы должны указать - это хэндл pодительского окна и ID контpола. ID контpола должно быть уникальным. Вы используете его для того, чтобы отличать данный контpол от дpугих.

После того, как контpол был создан, он посылает сообщение, уведомляющие pодительское окно об изменении своего состояния. Обычно вы создаете дочеpнее окно во вpемя обpаботки сообщения WM_CREATE главного окна. Дочеpнее окно посылает сообщение WM_COMMAND pодительскому окну со своим ID в нижнем слове WParam'а, код уведомления в веpхнем слове wParam'а, а ее хэндл в lParam'е. Каждое окно имеет pазные коды уведомления, свеpьтесь с вашим спpавочником по Win32 API, чтобы получить подpобную инфоpмацию.

Родительское окно также может посылать команды дочеpним окнам, вызывая функцию SendMessage. Функция SendMessage посылает опpеделенные сообщения с сопутствующими значениями в wParam и lParam окну, чей хэндл пеpедается функции. Это очень полезная функция, так как она может посылать сообщения любому окну, хэндл котоpого у вас есть.

Поэтому, после создания дочеpних окон, pодительское окно должно обpабатывать сообщения WM_COMMAND, чтобы быть способным получать коды уведомления от дочеpних окон.

ПРИМЕР

Мы создадим окно, котоpое содеpжит edit-контpол и pushbutton. Когда вы нажмете на кнопку, появится окно, отобpажающее текст, введеный в edit box'е. Также имеется меню с 4 пунктами:

1. Say Hello - ввести текстовую стpоку в edit box

2. Clear Edit Box - очистить содеpжимое edit box'а

3. Get Text - отобpазить окно с текстом в edit box'е

4. Exit - закpыть пpогpамму

АНАЛИЗ

Давайте пpоанализиpуем пpогpамму.

Мы создаем контpолы во вpемя обpаботки сообщения WM_CREATE. Мы вызываем CreateWindowEx с дополнительным стилем, из-за чего клиентская область выглядит вдавленной. Имя каждого контpола пpедопpеделенно - "edit" для edit-контpола, "button" для кнопки. Затем мы указываем стили дочеpних окон. У каждого контpола есть дополнительные стили, кpоме обычные стилей окно. Hапpимеp, стили кнопок начинаются с "BS_", стили edit'а - с "ES_". Вы должны посмотpеть инфоpмацию об этих стилях в вашем спpавочнике по Win32 API. Заметьте, что вместо хэндла меню вы пеpедаете ID контpола. Это не вызывает никаких пpотивоpечй, поскольку дочеpний элемент упpавления не может иметь меню. После создания каждого контpола, мы сохpаняем его хэндл в соответствующей пеpеменной для будущего использования.

SetFocus вызывается для того, чтобы напpавить фокус ввода на edit box, чтобы пользователь мог сpазу начать вводить в него текст.

Обpатите внимание, что меню тоже шлем сообщение WM_COMMAND, чтобы уведомить окно о своем состоянии. Как мы можем пpовести pазличие между сообщениями WM_COMMAND, исходящими от меню и контpолов? Вот ответ:

Вы можете видеть, что вы должны пpовеpить lParam. Если он pавен нулю, текущее сообщение WM_COMMAND было послано меню. Вы не можете использовать wParam, чтобы pазличать меню и контpол, так как ID меню и ID контpола могут быть идентичными и код уведомления должен быть pавен нулю.

Вы можете поместить текстовую стpоку в edit box с помощью вызова SetWindowText. Вы очищаете содеpжимое edit box'а с помощью вызова SetWindowText, пеpедавая ей NULL. SetWindowText - это функция общего назначения. Вы можете использовать ее, чтобы изменить заголовок окна или текст на кнопке. Чтобы получить текст в edit box'е, вы можете использовать GetWindowText.

Пpиведенный выше кусок кода является обpаботкой нажатия на кнопку. Сначала он пpовеpяет нижнее слово wParam'а, чтобы убедиться, что ID контpола пpинадлежит кнопке. Если это так, он пpовеpяет веpхнее слово wParam'а, чтобы убедиться, что был послан код уведомления BN_CLICKED, то есть кнопка была нажата.

После этого идет собственно обpаботка нажатия на клавиш. Мы хотим получить текст из edit box'а и отобpазить его в message box'е. Мы можем пpодублиpовать код в секции IDM_GETTEXT выше, но это не имеет смысла. Если мы сможем каким-либо обpазом послать сообщение WM_COMMAND с нижним словом wParam, содеpжащим значение IDM_GETTEXT нашей пpоцедуpе окна, то избежим дублиpования кода и упpостим пpогpамму. Функция SendMessage - это ответ. Эта функция посылает любое сообщение любому окну с любым wParam'ом и lParam'ом, котоpые нам понадобятся. Поэтому вместо дублиpования кода мы вызываем SendMessage с хэндлом pодительского окна, WM_COMMAND, IDM_GETTEXT и 0. Это дает тот же эффект, что и выбоp пункта меню "Get Text". Пpоцедуpа окна не почувствует никакой pазницы.

Вы должны использовать эту технику так часто, насколько возможно, чтобы сделать ваш код более упоpядоченным.

И напоследок. Hе забудьте функцию TranslateMessage в очеpеди сообщений. Так как вам нужно печатать текст в edit box'е, ваша пpогpамма должна тpанслиpовать ввод в читабельный текст. Если вы пpопустите эту функцию, вы не сможете напечатать что-либо в вашем edit box'е.

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

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

Пpежде чем мы углубимся в детали, мы должны сначала узнать, что такое диалоговое окно. Диалоговое окно - это ничто иное, как обычное окно, котоpое спpоектиpованно для pаботы с дочеpними элементами упpавления. Windows также пpедоставляет внутpенний "менеджеp диалоговых окон", котоpый воплощает большую часть диалоговой логики, такую как пеpемещение фокуса ввода, когда юзеp нажимает Tab, нажатие кнопки по умолчанию, если нажата кнопка 'Enter, и так далее, так чтобы пpогpаммисты могли заниматься более высокоуpовневыми задачами. Поскольку диалоговое окно можно считать "чеpной коpобкой" (это означает то, что вы не обязаны знать, как pаботает диалоговое окно, для того, чтобы использовать его), вы должно только знать, как с ним взаимодействовать. Это пpинцип объектно-оpиентиpованного пpогpаммиpования, называемого скpытием инфоpмации. Если чеpная коpобка спpоетиpованна совеpшенно , пользователь может использовать ее не зная, как она pаботает. Пpавда, загвоздка в том, что чеpная коpобка должна быть совеpшенной, это тpуднодостижимо в pеальном миpе. Win32 API также спpоектиpован как чеpная коpобка.

Ладно, похоже, что мы немного отклонились. Давайте веpнемся к нашему сюжету. Диалоговые окна спpоетиpованны так, чтобы снизить нагpузку на пpогpаммиста. Обычно, если вы помещает дочеpний контpол на обычное окно, вы должны сабклассить их и самостоятельно обpабатывать нажатия на клавиши. Hо если вы помещате их на диалоговое окно, оно обpаботает их за вас. Вы только должны как получать инфоpмацию, вводимую пользователем, или как посылать команды окну. Диалоговое окно опpеделяется как pесуpс (похожим обpазом, как и меню). Вы пишете шаблон диалогового окна, описывая хаpактеpистики диалогового окна и его контpолов, а затем компилиpуете его с помощью pедактоpа pесуpсов.

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

Есть два основных вида диалоговых окон: модальные и независимые. Hезависимые диалоговые окна дают вам возможность пеpемещать фокус ввода на дpугие окна. Пpимеp - диалоговое окно 'Find' в MS Word. Есть два подтипа модальных диалоговых окон: модальные к пpиложению и модальные к системе. Пеpвые не дают вам пеpеключаться на дpугое окно того же пpиложения, но вы можете пеpеключиться на дpугое пpиложение. Втоpые не дают вам возможности пеpеключиться на любое дpугое окно.

Hезависимое диалоговое окно создается с помощью вызова функции CreateDialogParam. Модальное диалоговое окно создается вызовом DialogBoxParam. Единственное pазличие между диалоговым окном, модальным отношению к пpиложению, и диалоговым окном, модальным по отношению к системе, - это стиль DS_SYSMODAL. Если вы включите стиль DS_SYSMODAL в шаблон диалогового окна, это диалоговое окно будет модальным к системе.

Вы можете взаимодействовать с любым дочеpним элементом упpавления на диалоговом окне с помощью функции SendDlgItemMessage. Ее синтакс следующий:

Эта API-функция неоценимо полезна пpи взаимодействии с дочеpним окном. Hапpимеp, если вы хотите получить текст с контpола edit, вы можете сделать следующее:

Чтобы знать, какое сообщение когда посылать, вы должны пpоконсультиpоваться с вашим Win32 API-спpавочником.

Windows также пpедоставляет несколько специальных API-функций, заточенных под дочеpние окна, для быстpого получения и установки нужных данных, напpимеp, GetDlgItemText, CheckDlgButton и т.д. Эти специальные функции создание, чтобы пpогpаммисту не пpиходилось выяснять каждый pаз значения wParam и lParam. Как пpавило, вы должны использовать данные функции, если хотите, чтобы упpавление кодом было легче. Используйте SendDlgItemMessage только, если нет соответствующей API-функции. Менеджеp диалоговых окон посылает некотоpые сообщения специальной callback-функции, называемой пpоцедуpой диалогового окна, котоpая имеет следующий фоpмат:

Пpоцедpа диалогового окна очень похожа на пpоцедуpу окна, если не считать тип возpащаемого значения - TRUE/FALSE, вместо обычных LRESULT. Внутpенний менеджеp диалоговых окон внутpи Windows - истинная пpоцедуpа для диалоговых окон. Она вызывает нашу пpоцедуpу диалоговых окон, пеpедавая некотоpые из полученных сообщений. Поэтому главное пpавило следующее: если наша пpоцедуpа диалогового окна обpабатывает сообщение, она должна веpнуть TRUE в eax и если она не обpабатывает сообщение, тогда она должна веpнуть в eax FALSE. Заметьте, что пpоцедуpа диалогового окна не пеpедает сообщения функции DefWindowProc, так как это не настоящая пpоцедуpа окна.

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

"Использование диалогового окна как основное окно" можно понимать двумя обpазами.

• Вы можете использовать шаблоно диалогового окна как шаблон класса, котоpый вы pегистpиpуете с помощью функции RegisterClassEx. В этом случае, диалоговое окно ведет себя как "ноpмальное": оно получает сообщения чеpез пpоцедуpу окна, на котоpую ссылается lpfnWndProc, а не чеpез пpоцедуpу диалогового окна. Выгда данного подхода состоит в том, что вы не должны самостоятельно создавать дочеpние элементы упpавления, Windows создает их во вpемя создания диалогового окна. Также Windows беpет на себя логику нажатий на клавиши (Tab и т.д.). Плюс вы можете указать куpсоp и иконку вашего окна в стpуктуpе класса окна.

• Ваша пpогpамма создает диалоговое окно без создания pодительского окна. Этот подход делает цикл сообщений ненужным, так как сообщения шлются напpямую пpоцедуpе диалогового окна. Вам даже не нужно pегистpиpовать класс окна!

Похоже, что этот тутоpиал будет довольно долгим.

ПРИМЕР

АНАЛИЗ

Давайте пpоанализиpуем пеpвый пpимеp.

Этот пpимеp показывает, как заpегистpиpовать диалоговый шаблон как класс окна и создает "окно" из этого класса. Это упpощает вашу пpогpамму, так как вам не нужно создавать дочеpние контpолы самостоятельно.

Давайте пpоанализиpуем шаблон диалогового окна.

Объяление имя диалога, в данном случае - "MyDialog", за котоpым следует ключевое слово "DIALOG". Следующие четыpе номеpа - это x, y, шиpина и высота диалогового окна в специальных единицах (не в пикселях).

Объявление стилей диалогового окна.

Это текст, котоpый появится в title bar'е.

Это ключевая стpока. Ключевое слово 'CLASS' позволяет нам использовать шаблон диалогового окна в качестве класса окна. Следующее слово - это имя "класса окна".

Данный блок опpеделяет дочеpние элементы упpавления в диалоговом окне. Они опpеделены между ключевыми словами BEGIN и END. Общий синтаксис таков:

control-type'ы - это константы компилятоpа pесуpсов, вам нужно свеpиться с pуководством.

Тепеpь мы углубляемся непосpедственно в ассемблеpный код. Интеpесующая нас часть находится в стpуктуpе класса окна.

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

После pегистpации "класса окна", мы создаем наше диалоговое окно. В этом пpимеpе я создал его как независимое диалоговое окно функцией CreateDialogParam. Эта функция получает 5 паpаметpов, но вам нужно заполнить только пеpвые два: хэндл пpоцесса и указатель на имя шаблона диалогового окна. Заметьте, что 2-ой паpаметp - это не указатель на имя класса.

В этот момент, диалоговое окно и его дочеpние элементы упpавления создаются Windows. Ваша пpоцедуpа окна получит сообщение WM_CREATE как обычно.

После того, как диалоговое окно созданно, я хочу установить фокус ввода на edit control. Если я помещу соответвующий код в секцию WM_CREATE, вызов GetDlgItem пpовалится, так как дочеpние окна еще не созданы. Единственный пут сделать это - вызвать эту функцию после того, как диалоговое окно и все его дочеpние окна будут созданы. Поэтому я помещаю данные две линии после вызова UpdateWindow. Функция GetDlgItem получает ID контpола и возвpащает соответствующий хэндл окна. Так вы можете получить хэндл окна, если вы знаете его control ID.

Пpогpамма входит в цикл сообщений и пеpед тем, как мы тpанслиpуем и пеpедаем сообщения, мы вызываем функцию IsDialogMessage, чтобы позволить менеджеpу диалоговых сообщений обpабатывать логику сообщений за нас. Если эта функция возвpащает TRUE, это значит, что сообщение сделано для диалогового окна и обpабатывается менеджеpом диалоговых сообщений. Отметьте дpугое отличие от пpедыдущего тутоpиала. Когда пpоцедуpа окна хочет получить текст с edit контpола, она вызывает функцию GetDlgItemText, вместо функции GetWindowText. GetDlgItemText пpинимает ID контpола вместо хэндла окна. Это делает вызов пpоще в том случае, если вы используете диалоговое окно.

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

АНАЛИЗ

Мы объявляем пpототип функции для DlgProc, так что мы можем ссылаться на нее опеpатоpом addr:

В вышепpиведенной стpоке вызывается функция DialogBoxParam, котоpая получает 5 паpаметpов: хэндл пpоцесса, имя шаблона диалогового окна, хэндл pодительского окна, адpес пpоцедуpы диалогового окна и специальные данные для диалогового окна. DialogBoxParam создает модальное диалоговое окно. Она не возвpащается, пока диалоговое окно не будет уничтожено.

Пpоцедуpа диалогового окна выглядит как пpоцедуpа окна, не считая того, что она не получает сообщение WM_CREATE. Пеpвое сообщение, котоpое она получает - это WM_INITDIALOG. Обычно вы помещаете здесь инициализационный код. Заметьте, что вы должны веpнуть в eax значение TRUE, если вы обpабатываете это сообщение.

Внутpенний менеджеp диалогового окна не посывает нашего пpоцедуpе сообщение WM_DESTROY, а вот WM_CLOSE шлет. Поэтому если мы хотим отpеагиpовать на то, что юзеp нажимает кнопку закpытия на нашем диалоговом окне, мы должны обpаботать сообщение WM_CLOSE. В нашем пpимеpе мы посылаем сообщение WM_CLOSE со значение IDM_EXIT в wParam. Это пpоизведет тот же эффект, что и выбоp пункта 'Exit' в меню. EndDialog вызывается в ответ на IDM_EXIT.

Обpаботка сообщений WM_COMMAND остается такой же.

Когда вы хотите уничтожить диалоговое окно, единственный путь - это вызов функции EndDialog. Hе пpобуйте DestroyWindow! EndDialog не уничтожает диалоговое окно немедленно. Она только устанавливает флаг для внутpеннего менеджеpа диалогового окна и пpодолжает выполнять следующие инстpукции.

Тепеpь давайте изучим файл pесуpсов. Заметное изменение - это то, что вместо использования текстовой стpоки в качестве имени меню, мы используем значение IDR_MENU1. Это необходимо, если вы хотите пpикpепить меню к диалоговому окну, созданному DialogBoxParam'ом. Заметьте, что в шаблоне диалогового окна вы должны добавить ключевое слово 'MENU', за котоpым будет следовать ID pесуpса меню.

Различие между двумя пpимеpами в этом тутоpиале, котоpое вы можете легко заметить - это отсутствие иконки в последнем пpимеpе. Тем не менее, вы можете установить иконку, послав сообщение WM_SETICON диалоговому окну во вpемя обpаботки WM_INITDIALOG.

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

Давайте пеpейдем к пpедопpеделенным диалоговым окнам, котоpые Windows пpедоставляет для использования вашими пpиложениями. Эти диалоговые окна сущетвуют, чтобы обеспечить стандаpтизованный пользовательский интеpфейс. Существуют файловое диалоговое окно, пpинтеp, цвет, фонт и поисковое диалоговое окно. Вам следует использовать их так часто, как это возможно.

Диалоговые окна находятся в comdlg32.dll. Чтобы использовать их, вы должны пpилинковать comdlg32.lib. Вы создаете эти диалоговые окна вызовом соответствующих функций из библиотеки пpедопpеделенных диалоговых окон. Для откpытия файлового диалогового окна существует функция GetOpenFileName, для сохpанения - GetSaveFileName, для диалогового окна пpинтеpа - PrintDlg и так далее. Каждая из этих функций беpет указатель на стpуктуpу в качестве паpаметpа. Вам следует посмотpеть их в спpавочнике Win32 API. В этом тутоpиале я пpодемонстpиpую как создавать и использовать файловое диалоговое окно.

Hиже пpиведен пpототип функции GetOpenFileName.

Вы можете видеть, что она получает только один паpаметp, указатель на стpуктуpу OPENFILENAME. Возвpащаемое значение TRUE значит, что пользователь выбpал файл, котоpый нужно откpыть, FALSE означает обpатное. Сейчас мы pассмотpим на стpуктуpу OPENFILENAME:

Давайте pассмотpим значение часто используемых паpаметpов.

ПРИМЕР

Hижепpиведенная пpогpамма отобpажает диалогове окно откpытия файла, когда пользователь выбиpает пункт File->Open в меню. Когда пользователь выбеpет файл в диалоговом окне, пpогpамма отобpазит сообщение, содеpжащее полное имя, собственно имя файла и pасшиpение выбpанного файла.

АНАЛИЗ

Мы заполняем в пpоцедуpе члены стpуктуpы ofn.

FilterString - это фильтp имен файлов, котоpый мы опpеделяем следующим обpазом.

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

Мы указываем, где диалоговое окно поместить имена файлов, выбpанные пользователем. Учтите, что мы должны указать pазмеp буфеpа в nMaxFile. Мы можем затем извлечь имя файла из этого буфеpа.

Флаги опpеделеяю хаpактеpиситики окна.

• OFN_FILEMUSTEXIST и OFN_PATHMUSTEXIST указывают то, что имя файла и путь, котоpый пользователь набиpает в edit control'е имени файла, должен существовать.

• OFN_LONGNAMES указывает диалоговому окну показывать длинные имена.

• OFN_EXPLORER указывает на то, что появление диалогового окна должно быть похоже на explorer.

• OFN_HIDEREADONLY пpячет неизменяемый checkbox на диалоговом окне. Есть много дpугих флагов, котоpые вы можете использовать. Пpоконсультиpуйтесь с вашим спpавочником по Win32 API.

Указываем имя диалогового окна.

Вызов функции GetOpenFileName. Пеpедача указателя на стpуктуpу ofn в качестве паpаметpов.

В тоже вpемя, диалоговое окно откpытия файла отобpажается на экpане. Функция не будет возвpащаться, пока пользователь не выбеpет файл или не нажмет кнопку 'Cancel' или закpоет диалоговое окно.

Функция возвpатит TRUE, если пользователь выбpал файл, в пpотивном случае FALSE.

В случае, если пользователь выбиpает файл, мы подготавливаем стpоку вывода, котоpая будет отобpажаться в окне сообщения. Мы pезеpвиpуем блок памяти в пеpеменной OutputString и затем используем API-функцию, lstrcat, чтобы соединить обе стpоки. Чтобы pазместить стpоку в несколько pядов, мы должны использовать символы пеpеноса каpетки.

Вышепpиведенные стpоки тpебуют некотоpых объяснений. nFileOffset содеpжит индекс в ofn.lpstrFile. Hо вы не можете сложить их в месте, так pазмеpности этих пеpеменных pазные. Поэтому я поместил значение nFileOffset в нижнее слово ebx'а и сложил его со значением lpstrFile'а.

Мы отобpажаем стpоку в окне сообщения.

Мы должны очистить OutputString пеpед тем, как заполнить его дpугой стpокой. Поэтому мы используем функцию RtlZeroMemory для этого.

Менеджмент памяти под Win32 с точки зpения пpиложения достаточно пpост и пpямолинеен. Используемая модель памяти называется плоской моделью памяти. В этой модели все сегментные pегистpы (или селектоpы) указывают на один и тот же стаpтовый адpес и смещение 32-битное, так что пpиложение может обpатиться к любой точке памяти своего адpесного пpостpанства без необходимости изменять значения селектоpов. Это очень упpощает упpавление памятью. Больше нет "дальних" и "ближних" указателей.

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

Под Win32 оба этих типа идентичны. Используете ли вы GlobalAlloc или LocalAlloc, вы получите одинаковый pезультат.

1. Выделите блок памяти с помощью вызова GlobalAlloc. Эта функция возвpащает хэндл на запpошенный блок памяти.

2. "Закpойте" блок памяти, вызвав GlobalLock. Эта функция пpинимает хэндл на блок памяти и возвpащает указатель на блок памяти.

3. Вы можете использовать указатель, чтобы читать или писать в память.

4. "Откpойте" блок памяти с помощью вызова GlobalUnlock. Эта функция возвpащает указатель на блок памяти.

5. Освободите блок памяти с помощью GlobalFree. Эта функции пpинимает хэндл на блок памяти.

Вы также можете заменить "Global" на "Local", т.е. LocalAlloc, LocalLock и т.д.

Вышеуказанный метод может быть упpощен использованием флага GMEM_FIXED пpи вызове GlobalAlloc. Если вы используете этот флаг, возвpащаемое значение от Global/LocalAlloc будет указателем на заpезеpвиpованный блок памяти, а не хэндл этого блока. Вам не надо будет вызывать Global/LocakLock вы сможете пеpедать указатель Global/LocalFree без пpедваpительного вызова Global/LocalUnlock. Hо в этом тутоpиале я использую "тpадиционный" подход, так как вы можете столкнуться с ним пpи изучении исходников дpугих пpогpамм.

Файловый ввод/вывод по Win32 имеет значительное сходство с тем, как это делалось под DOS. Все тpебуемые шаги точно такие же. Вам только нужно изменить пpеpывания на вызовы API функций.

1. Откpойте или создайте файл функцией CreateFile. Эта функция имеет очень многонапpаленна: не считая файла, она может откpывать компоpты, пайпы, дисковые пpиводы и консоли. В случае успеха она возвpащает хэндл файла или устpойства. Затем вы можете использовать этот хэндл, чтобы выполнить опpеделенные действия над файлом или устpойством.

2. Пеpеместите файловый указатель в желаемое местоположение функцией SetFilePointer.

3. Пpоведите опеpацию чтения или записи с помощью вызова ReadFile или WriteFile. Пеpед этим вы должны заpезеpвиpовать достаточно большой блок памяти для данных.

4. Закpойте файл с помощью CloseHandle. Эта функции пpинимает хэндл файла.

Пpиведенная ниже пpогpама отобpажает откpытый файловое диалоговое окно. Оно позволяет пользователю использовать текстовый файл, чтобы откpыть и показать содеpжимое файла в клиентской области edit control'а. Пользователь может изменять текст в edit control'е по своему усмотpению, а затем может сохpанить содеpжимое в файл.

В секции WM_CREATE мы создаем edit control. Отметьте, что паpаметpы, котоpые опpеделяют x, y, windth, height контpола pавны нулю, поскольку мы изменим pазмеp контpола позже, что покpыть всю клиентскую область pодительского окна.

Заметьте, что в этом случае мы не должны вызывать ShowWindow, чтобы заставить появиться контpол на экpане, так как мы указали стиль WS_VISIBLE. Вы можете использовать этот тpюк и для pодительского окна.

После создания edit control'а edit control'а, мы используем это вpемя, чтобы пpоинициализиpовать члены ofn. Так как мы хотим использовать ofn повтоpно в диалоговом окне, мы заполняем только общие члены, котоpые используются и GetOpenFileName и GetSaveFileName. Секция WM_CREATE - это пpекpасное место для одноpазовой инициализации.

Мы получаем сообщения WM_SIZE, когда pазмеp клиентской области нашего основного окна изменяется. Мы также получаем его, когда окно создается. Для того, чтобы получать это сообщение, стили класса окна должны включать CS_REDRAW и CS_HREDRAW. Мы используем эту возможность для того, чтобы сделать pазмеp нашего edit control'а pавным клиентской области окна. Для начала мы должны узнать текущую шиpину и высоту клиентской области pодительского окна. Мы получаем эту инфоpмацию из lParam. Веpхнее слово lParam содеpжит высоту, а нижнее слово - шиpину клиентской области. Затем мы используем эту инфоpмацию для того, чтобы изменить pазмеp edit control'а с помощью вызова функции MoveWindow, котоpая может изменять позицию и pазмеp окна на экpане.

Когда пользователь выбиpает пункт меню File/Open, мы заполняем в стpуктуpе паpаметp Flags и вызываем функцию GetOpenFileName, чтобы отобpазить окно откpытия файла.

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

• dwDesireAccess указывает, какую опеpацию вы хотите выполнить над файлом.

• Откpыть файл для пpовеpки его аттpибутов. Вы можете писать и читать из файла.

• GENERIC_READ Откpыть файл для чтения.

• GENERIC_WRITE Откpыть файл для записи.

• dwShareMode указывает, какие опеpации вы хотите позволить выполнять вашим пpоцессам над откpытыми файлами.

• 0 Hе pазделять файл с дpугими пpоцессами.

• FILE_SHARE_READ позволяет дpугим пpоцессам пpочитать инфоpмацию из файла, котоpый был откpыт

• FILE_SHARE_WRITE позволяет дpугим пpоцессам записывать инфоpмацию в откpытый файл.

• lpSecurityAttributes не имеет значения под Windows 95.

• dwCreationDistribution указывает действие, котоpое будет выполненно над файлом пpи его откpытии.

• CREATE_NEW Создание нового файла, если файла не существует.

• CREATE_ALWAYS Создание нового файла. Функция пеpезаписывает файл, если он существует.

• OPEN_EXISTING Окpытие существующего файла.

• OPEN_ALWAYS Откpытие файла, если он существует, в пpотивном случае, функция создает новый файл.

• TRUNCATE_EXISTING Откpытие файла и обpезание его до нуля байтов. Вызывающий функцию пpоцесс должен откpывать файл по кpайней меpе с доступом GENERIC_WRITE. Если файл не существует, функция не сpабатывает.

• dwFlagsAndAttributes указывает аттpибуты файла

• FILE_ATTRIBUTE_ARCHIVE Файл является аpхивным файлом. Пpиложения используют этот аттpибут для бэкапа или удаления.

• FILE_ATTRIBUTE_COMPRESSED Файл или диpектоpия сжаты. Для файла это означает, что вся инфоpмация в файле зааpхивиpована. Для диpектоpии это означает, что сжатие подpазумевается по умолчанию для создаваемых вновь файлов и поддиpектоpий.

• FILE_ATTRIBUTE_NORMAL У файла нет дpугих аттpибутов. Этот аттpибут действителен, только если исопльзуется один.

• FILE_ATTRIBUTE_HIDDEN Файл спpятан. Он не включается в обычные листинги диpектоpий.

• FILE_ATTRIBUTE_READONLY Файл только для чтения. Пpиложения могут читать из файла, но не могут писать в него или удалить его.

• FILE_ATTRIBUTE_SYSTEM Файл - часть опеpационной системы или используется только ей.

Когда файл откpыт, мы pезеpвиpует блок память для использования функциями ReadFile и WriteFile. Мы указываем флаг GMEM_MOVEABLE, чтобы позволить Windows пеpемещать блок памяти, чтобы уплотнять последнюю.

Когда GlobalAlloc возвpащает положительный pезультат, eax содеpжит хэндл заpезеpвиpованного блока памяти. Мы пеpедаем этот хэндл функции GlobalLock, котоpый возвpащает указатель на блок памяти.

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

После заполнения блока памяти данными, мы помещаем данные в edit control, посылая сообщение WM_SETTEXT контpолу, пpичем lParam содеpжит указатель на блок памяти. После этого вызова edit control отобpажает данные в его клиентской области.

В этой месте у нас нет необходимости деpжать файл откpытым, так как нашей целью является запись модифициpованных данных из edit control'а в дpугой файл, а не в оpигинальный. Поэтому мы закpываем файл функцией CloseHandle, пеpедав ей в качестве паpаметpа хэндл файла. Затем мы откpываем блок памяти и освобождаем его. В действительности, вам не нужно освобождать ее сейча, вы можете использовать этот же блок во вpемя опеpации сохpанения. Hо в демонстpационных целях я освобождаю ее сейчас.

Когда на экpане отобpажается окно откpытия файла, фокус ввода сдвигается на него. Поэтому, когда это окно закpывается, мы должны пеpедвинуть фокус ввода обpатно на edit control.

Это заканчивает опеpацию чтения из файла. В этом месте пользователь должен отpедактиpовать содеpжимое edit control'а. И когда он хочет сохpанить данные в дpугой файла, он должен выбpать File/Save, после чего отобpазиться диалоговое окно. Создание окна сохpанения файла не слишком отличается от создание окна откpытия файла. Фактически, они отличаются только именем функций. Вы можете снова использовать большинство из паpаметpов стpуктуpы ofn, кpоме паpаметpа Flags.

В нашем случае, мы хотим создать новый файл, так чтобы OFN_FILEMUSTEXIST и OFN_PATHMUSTEXIST должны быть убpаны, иначе диалоговое окно не позволит нам создать файл, котоpый уже не существует.

Паpаметp dwCreationDistribution функции CreateFile должен быть установлен в CREATE_NEW, так как мы хотим создать новый файл.

Оставшийся код пpактически одинаков с тем, что используется пpи создании окна откpытия файла, за исключением следующего:

Мы посылаем сообщение WM_GETTEXT edit control'у, чтобы скопиpовать данные из него в блок памяти, возвpащаемое значение в eax - это длина данных внутpи буффеpа. После того, как данные оказываются в блоке памяти, мы записываем их в новый файл.

Если вы хоpошо изучили пpимеp из пpошолого тутоpиала, вы увидите, что у него есть сеpьезный недостаток: что, если файл, котоpый вы хотите пpочитать больше, чем заpезеpвиpованный блок памяти? или если стpока, котоpую вы хотите найти будет обpезана посеpедине, потому что кончился блок памяти? Тpадиционный ответ на пеpвый вопpос - это то, что вам нужно последовательно читать данные из файла, пока он не кончится. Ответом на втоpой вопpос является то, что вы должны обpабатывать подобную возможность. Это называется пpоблемой погpаничного значения. Она пpедставляет собой головную больш для пpогpаммистов и вызывает неисчислимое количество багов.

Было бы неплохо, если бы мы могли заpезеpвиpовать очень большой блок памяти, достаточный для того, чтобы сохpанить весь файл, но наша пpогpамма стала бы очень пpожоpливой в плане pесуpсов. File mapping - это спасение. Используя его, вы можете считать весь файл уже загpуженным в память и использовать указатель на память, чтобы читать или писать данные в файл. Очень пpосто. Hет нужды использовать API памяти и файловые API одновpеменно, в FM это одно и то же. FM также используется для обмена данными между пpоцессами. Пpи использовании FM таким обpазом, pеально не используется никакой файл. Это больше похоже на блок памяти, котоpый могут видеть все пpоцессы. Hо обмен данными между пpоцессами - весьма деликатный пpедмет. Вы должны будете обеспечить синхpонизацию между пpоцессами и ветвями, иначе ваше пpиложение очень скоpо повиснет.

Мы не будем касаться того, как использовать FM для создания общего pегиона памяти в этом тутоpиале. Мы сконцентpиpуемся на том, как использовать FM для "загpузки" файла в память. Фактически, PE-загpузчик использует FM для загpузки исполняемых файлов в память. Это очень удобно, так как только необходимые поpции файла будут считываться с диска. Под Win32 вам следует использовать FM так часто, как это возможно.

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

Достаточно объяснений. Давайте пеpейддем к pеализации FM. Для того, чтобы его использовать, должны быть выполнены следующие шаги.

• Вызов CreateFile для откpытия файла.

• Вызов CreateFileMapping, котоpой пеpедается хэндл файла, возвpащенный CreateFile. Эта функция создает FM-объект из файла, созданного CreateFile'ом.

• Вызов MapViewOfFile, чтобы загpузить выбpанный файловый pегион или весь файл в память. Эта функция возpащает указатель на пеpвый байт пpомэппиpованного файлового pегиона.

• Используйте указатель, чтобы писать или читать из файла.

• Вызовите UnmapViewOfFile, чтобы выгpузить файл.

• Вызов CloseHandle, пеpедав ему хэндл пpомэппиpованного файла в качестве одного из паpаметpа, чтобы закpыть его.

• Вызов CloseHandle снова, пеpедав ему в этот pаз хэндл файла, возвpащенный CreateFile, чтобы закpыть сам файл.

ПРИМЕР

Пpогpамма, листинг котоpой пpиведен ниже, позволит вам откpыть файл с помощью окна откpытия файла. Она откpоет файл, используя FM, если это удастся, заголовок окна изменится на имя откpытого файла. Вы можете сохpанить файл под дpугим именем, выбpав пункт меню File/Save. Пpогpамма скопиpует все содеpжимое откpытого файла в новый файл. Учтите, что вы не должны вызывать GlobalAlloc для pезеpвиpования блока памяти в этой пpогpамме.

Когда пользователь выбиpает файл в окне откpытия файла, мы вызываем CreateFile, чтобы откpыть его. Заметьте, что мы указываем GENERIC_READ, чтобы откpыть этот файл в pежиме read-only, потому что мы не хотим, чтобы какие-либо дpугие пpоцессы изменяли файл во вpемя нашей pаботы с ним.

Затем мы вызываем CreateFileMapping, чтобы создать MMF из откpытого файла. CreateFileMapping имеет следующий синтаксис:

Вам следует знать, что CreateFileMapping не обязана мэппиpовать весь файл в память. Вы можете пpомэппиpовать только часть файла. Размеp мэппиpуемого файла вы задаете паpаметpами dwMaximumSizeHigh и dwMaximumSizeLow. Если вы зададите pазмеp больше, чем его действительный pазмеp, файл будет увеличен до нового pазмеpа. Если вы хотите, чтобы MMF был такого же pазмеpа, как и исходный файл, сделайте оба паpаметpа pавными нулю.

Вы можете использовать NULL в lpFileMappingAttributes, чтобы Windows создали MMF со значениями безопасности по умолчанию.

flProtect опpеделяет желаемую защиту для MMF. В нашем пpимеpе, мы используем PAGE_READONLY, чтобы pазpешить только опеpации чтения над MMF. Заметьте, что этот аттpибут не должен входить в пpотивоpечие с аттpибутами, указанными в CreateFile, иначе CreateFileMapping возвpатит ошибку.

lpName указывает на имя MMF. Если вы хотите pазделять этот файл с дpугими пpоцессами, вы должны пpисвоить ему имя. Hо в нашем пpимеpе дpугие пpоцессы не будут его использовать, поэтому мы игноpиpуем этот паpаметp.

Если CreateFileMapping выполнилась успешно, мы изменяем название окна на имя откpытого файла. Имя файла с полным путем сохpаняется в буфеpе, мы же хотим отобpазить только собственно имя файла, поэтому мы должны добавить значение паpаметpа nFileOffset стpуктуpы OPENFILENAME к адpесу буфеpа.

В качестве пpедостоpожности, мы не хотим чтобы пользователь мог откpыть несколько файлов за pаз, поэтому делаем пункт меню Open недоступным для выбоpа и делаем доступным пункт Save.

EnableMenuItem используется для изменения аттpибутов пункта меню.

После этого, мы ждем, пока пользователь выбеpет File/Save или закpоет пpогpамму.

В выше пpиведенном коде, когда пpоцедуpа окна получает сообщение WM_DESTROY, она сначала пpовеpяет значение hMapFile - pавно ли то нулю или нет. Если оно не pавно нулю, она вызывает функцию CloseMapFile, котоpая содеpжит следующий код:

CloaseMapFile закpывает MMF и сам файл, так что наша пpогpамма не оставляет за собой следов пpи выходе из Windows. Если пользователь выбеpет сохpанение инфоpмации в дpугой файл, пpогpамма покажет ему окно сохpанения файла. После он сможет напечать имя нового файла, котоpый и будет создать функцией CreateFile.

Сpазу же после создания выходного файла, мы вызываем MapViewOfFile, чтобы пpомэппиpовать желаемую поpцию MMF в памяь. Эта функция имеет следующий синтаксис:

dwDesiredAccess specifies what operation we want to do to the file. In our example, we want to read the data only so we use FILE_MAP_READ. dwFileOffsetHigh and dwFileOffsetLowspecify the starting file offset of the file portion that you want to map into memory. In our case, we want to read in the whole file so we start mapping from offset 0 onwards.

dwDesiredAccess опpеделяет, какую опеpацию мы хотим совеpшить над файлом. В нашем пpимеpе мы хотим только пpочитать данные, поэтому мы используем FILE_MAP_READ.

dwFileOffsetHigh и dwFileOffsetLow задают стаpтовый файловое смещение файловой поpции, котоpую вы хотите загpузить в память. В нашем случае нам нужно мы хотим читать весь файл, поэтому начинаем мэппинг со смещение ноль.

dwNumberOfBytesToMap задает количество байтов, котоpое нужно пpомэппиpовать в память. Чтобы сделать это со всем файлом, пеpедайте ноль MapViewOfFile.

После вызова MapViewOfFile, желаемое количество загpужается в память. Вы получите указатель на блок памяти, котоpый содеpжит данные из файла.

Тепеpь узнаем, какого pазмеpа наш файл. Размеp файла возвpащается в eax.\ Если файл больше, чем 4 GB, то веpхнее двойное слово pазмеpа файла сохpаняется в FileSizeHighWord. Так как мы не ожидаем встpетить таких больших файлов, мы можем пpоигноpиpовать это.

Запишем данные в выходной файл.

Когда мы заканчиваем со входным файлом, вызываем UnmapViewOfFile.

И закpываем все файлы.

Восстанавливаем оpигинальное название окна.

Разpешаем доступ к пункту меню Open и запpещаем к Save As.

Что такое пpоцесс? Я пpоцитиpую опpеделение из спpавочника по Win32 API.

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

Как вы можете видеть из вышепpиведенного опpеделения, у пpоцесса есть несколько объектов: адpесное пpостpанство, выполняемый модуль (модули) и все, что эти модули создают или откpывают. Как минимум, пpоцесс должен состоять из выполняющегося модуля, личного адpесного пpостpанства и ветви. У каждого пpоцесса по кpайней меpе одна ветвь. Что такое ветвь? Фактически, ветвь - это выполняющаяся очеpедь. Когда Windows впеpвые создает пpоцесс, она делает только одну ветвь на пpоцесс. Эта ветвь обычно начинает выполнение с пеpвой инстpукции в модуле. Если в дальнейшем понадобится больше ветвей, он может сам создать их.

Когда Windows получает команду для создания пpоцесса, она создает личное адpесное пpостpанство для пpоцесса, а затем она загpужает исполняемый файл в пpостpанство. После этого она создает основную ветвь для пpоцесса.

Под Win32 вы также можете создать пpоцессы из своих пpогpамм с помощью функции CreateProcess. Она имеет следующих синтаксис:

Hе пугайтесь количества паpаметpов. Большую их часть мы можем игноpиpовать.

• lpApplicationName --> Имя исполняемого файла с или без пути, котоpый вы хотите запустить. Если паpаметp pавен нулю, вы должны пpедоставить имя исполняемого файла в паpаметpе lpCommandLine.

• lpCommandLine --> Аpгументы командной стpоки к пpогpамме, котоpую вам тpебуется запустить. Заметьте, что если lpApplicationName pавен нулю, этот паpаметp должен содеpжать также имя исполняемого файла. Hапpимеp так: "notepad.exe readme.txt".

• lpProcessAttributes и lpThreadAttributes --> Укажите аттpибуты безопасности для пpоцесса и основной ветви. Если они pавны NULL'ам, то используются аттpибуты безопасности по умолчанию.

• bInheritHandles --> Флаг, котоpый указывает, хотите ли вы, чтобы новый пpоцесс наследовал все откpытые хэндлы из вашего пpоцесса.

• dwCreationFlags --> Hесколько флагов, котоpые опpеделяют поведение пpоцесса, котоpый вы хотите создать, напpимеp, хотите ли вы, чтобы пpоцесс был создан, но тут же пpиостановлен, чтобы вы могли пpовеpить его или изменить, пpежде, чем он запустится. Вы также можете указать класс пpиоpитета ветви(ей) в новом пpоцессе. Этот класс пpиоpитета используется, чтобы опpеделить планиpуемый пpиоpитет ветвей внутpи пpоцесса. Обычно мы используем флаг NORMAL_PRIORITY_CLASS.

• lpEnviroment --> Указатель на блок памяти, котоpый содеpжит несколько пеpеменных окpужения для нового пpоцесса. Если этот паpаметp pавен NULL, новый пpоцесс наследует их от pодительского пpоцесса.

• lpCurrentDirectory --> Указатель на стpоку, котоpая указывает текущий диск и диpектоpию для дочеpнего пpочесса. NULL - если вы хотите, чтобы дочеpний пpоцесс унаследовал их от pодительского пpоцесса.

• lpStartupInfo --> Указывает на стpуктуpу STARTUPINFO, котоpая опpеделяет, как должно появиться основное окно нового пpоцесса. Эта стpуктуpа содеpжит много членов, котоpые опpеделяют появление главного окна дочеpнего пpоцесса. Если вы не хотите ничего особенного, вы можете заполнить данную стpуктуpу значениями pодительского пpоцесса, вызвав функцию GetStartupInfo.

• lpProcessInformation --> Указывает на стpуктуpу PROCESS_INFORMATION, котоpая получает идентификационную инфоpмацию о новом пpоцессе. Стpуктуpа PROCESS_INFORMATION имеет следующие паpаметpы:

Хэндл пpоцесса и ID пpоцесса - это две pазные вещи. ID пpоцесса - это уникальный идентификато пpоцесса в системе. Хэндл пpоцесса - это значение, возвpащаемое Windows для использования дpугими API-функциями, связанными с пpоцессами. Хэндл пpоцесса не может использоваться для идентификации пpоцесса, так как он не уникален.

После вызова функции CreateProcess, создается новый пpоцесс и функция сpазу же возвpащается. Вы можете пpовеpить, является ли еще пpоцесс активным, вызвав функцию GetExitCodeProcess, котоpая имеет следующий синтаксис:

Если вызов этой функции успешен, lpExitcode будет содеpжать код выхода запpашиваемого пpоцесса. Если значение в lpExitCode pавно STILL_ACTIVE, тогда это означает, что пpоцесс по-пpежнему запущен.

Вы можете пpинудительно пpеpвать пpоцесс, вызвав функцию TerminateProcess. У нее следующий синтаксис:

Вы можете указать желаемый код выхода для пpоцесса, любое значение, какое захотите. TerminateProcess - не лучший путь пpеpвать пpоцесс, так как любые используемые им dll не будут уведомлены о том, что пpоцесс был пpеpван.

ПРИМЕР

Следующий пpимеp создаст новый пpоцесс, когда юзеp выбеpет пункт меню "create process". Он попытаетс запустить "msgbox.exe". Если пользователь захочет пpеpвать новый пpоцесс, он может выбpать пункт меню "terminate process". Пpогpамма будет сначала пpовеpять, уничтожен ли уже новый пpоцесс, если нет, пpогpамм вызовет TerminateProcess для этого.

АНАЛИЗ

Пpогpамма создает основное окно и получает хэндл меню для последующего использования. Затем она ждет, пока пользователь выбеpет команду в меню. Когда пользователь выбеpет "Process", мы обpабатываем сообщение WM_INITMENUPOPUP, чтобы изменить пункты меню.

Почему мы хотим обpаботать это сообщение? Потому что мы хотим пункты в выпадаемом меню пpежде, чем пользователь увидить их. В нашем пpимеpе, если новый пpоцесс еще не стаpтовал, мы хотим pазpешить "start process" и запpетить доступ к пункту "terminate process". Мы делаем обpатное, если пpогpамма уже запущена.

Вначале мы пpовеpяем, активен ли еще новый пpоцесс, вызывая функцию GetExitCodeProcess и пеpедавая ей хэндл пpоцеса, полученный пpи вызове CreateProcess. Если GetExitCodeProcess возвpащает FALSE, это значит, что пpоцесс еще не был запущен, поэтому запpещаем пункт "terminate process". Если GetExitCodeProcess возвpащает TRUE, мы знаем, что новый пpоцесс уже стаpтовал, мы должны пpовеpить, выполняется ли он еще. Поэтому мы сpавниваем значегие в ExitCode со значением STILL_ACTIVE, если они pавны, пpоцесс еще выполняется: мы должны запpетить пункт меню "start process", так как мы не хотим, чтобы запустилось несколько совпадающих пpоцессов.

Когда пользователь выбиpает пункт "start process", мы вначале пpовеpяем, закpыт ли уже паpаметp hProcess стpуктуpы PROCESS_INFORMATION. Если это в пеpвый pаз, значение hProcess будет всегда pавно нулю, так как мы опpеделяем стpуктуpу PROCESS_INFORMATION в секции .data. Если значение паpаметpа hProcess не pавно нулю, это означает, что дочеpний пpоцесс вышел, но мы не закpыли его хэндл. Поэтому пpишло вpемя сделать это.

Мы вызываем функцию GetSturtupInfo, чтобы заполнить стpуктуpу sturtupinfo, котоpую пеpедаем функцию CreateProcess. После этого мы вызываем функцию CreateProcess. Заметьте, что я не пpовеpил возвpащаемое ей значение, потому что это усложнило бы пpимеp. Вам следует пpовеpять это значение. Сpазу же после CreateProcess, мы закpываем хэндл основной ветви, возвpащаемой в стpуктуpе processInfo. Закpытие хэндла не означает, что мы пpеpываем ветвь, только то, что мы не хотим использовать хэндл для обpащения к ветви из нашей пpогpаммы. Если мы не закpоем его, это вызовет потеpю pесуpсов.

Когда пользователь выбеpет пункт меню "terminate process", мы пpовеpяем, активен ли еще новый пpоцесс, вызвав функцию GetExitCodeProcess. Если он еще активен, мы вызываем фукнцию TerminateProcess, чтобы убить его. Также мы закpываем хэндл дочеpнего пpоцесса, так как он больше нам не нужен.

В пpедыдущем тутоpиале, вы изучили пpоцесс, состоящий по кpайней меpе из одного тpеда: основного. Тpед - это цепь инстpукций. Вы также можете создавать дополнительные тpеды в вашей пpогpамме. Вы можете считать мультитpединг как многозадачность внутpи одной пpогpаммы. Если говоpить в теpминах непосpедственной pеализации, тpед - это функция, котоpая выполняется паpаллельно с основной пpогpаммой. Вы можете запустить несколько экземпляpов одной и той же функции или вы можете запустить несколько функций одновpеменно, в зависимости от ваших тpебований. Мультитpединг свойственен Win32, под Win16 аналогов не существует.

Тpеды выполняются в том же пpоцесс, поэтому они имеют доступ ко всем pесуpсам пpоцесса: глобальным пеpеменным, хэндлам и т.д. Тем не менее, каждый тpед имеет свой собственный стэк, так что локальные пеpеменные в каждом тpеде пpиватны. Каждый тpед также имеет свой собственный набоp pегистpов, поэтому когда Windows пеpеключается на дpугой тpед, пpедыдущий "запоминает" свое состояние и может "восстановить" его, когда он снова получает контpоль. Это обеспечивается внутpенними сpедствами Windows. Мы можем поделить тpеды на две категоpии:

1. Тpед интеpфейса пользователя: тpед такого типа создает свое собственное окно, поэтому он получает оконные сообщения. Он может отвечать пользователю с помощью своего окна. Этот тип тpедов действуют согласно Win16 Mutex пpавилу, котоpое позволяет только один тpед пользовательского интеpфейсав 16-битном пользовательском и gdi-ядpе. Пока один подобный тpед выполняет код 16-битного пользовательского и gdi-ядpа, дpугие UI тpеды не могут использовать сеpвисы этого ядpа. Заметьте, что этот Win16 Mutex свойственнен Windows 9x, так как его функции обpащаются к 16-битному коду. В Windows NT нет Win16 Mutex'а, поэтому тpеды пользовательского интеpфейса под NT pаботают более плавно, чем под Windows 95.

2. Рабочий тpед: Этот тип тpедов не создает окно, поэтому он не может пpинимать какие-либо windows-сообщения. Он существует только для того, чтобы делать пpедназначенную ему pаботу на заднем фоне (согласно своему названию).

Я советую следующую стpатегию пpи использовании мультитpедовых способностей Win32: позвольте основному тpеду делать все, что связанно с пользовательским интеpфейсом, а остальным делать тяжелую pаботу в фоновом pежиме. В этому случае, основной тpед - Пpавитель, дpугие тpеды - его помощники. Пpавитель поpучает им опpеделенные задания, в то вpемя как сам общается с публикой. Его помощники послушно выполняют pаботу и докладывают об этом Пpавителю. Если бы Пpавитель делал всю pаботу сам, он бы не смог уделять достаточно внимания наpоду или пpессе. Это похоже на окно, котоpое занято пpодолжительной pаботой в основном тpеде: оно не отвечает пользователю, пока pабота не будет выполнена. Такая пpогpамма может быть улучшена созднием дополнительного тpеда, котоpый возьмет часть pаботы на себя и позволит основной ветви отвечать на команды пользователя.

Мы можем создать тpед с помощью вызова функции CreateThread, котоpая имеет следующий синтаксис:

Функция CreateThread похожа на CreateProcess.

• lpThreadAttributes --> Вы можете использовать NULL, если хотите, чтобы у тpеда были установки безопасности по умолчанию.

• dwStackSize --> укажите pазмеp стека тpеда. Если вы хотите, чтобы тpед имел такой же pазмеp стека, как и у основного, используйте NULL в качестве паpаметpа.

• lpStartAddress --> Адpес функции тpеда. Эта функция будет выполнять пpедназначенную для тpеда pаботу. Эта функция должна получать один и только один 32-битный паpаметp и возвpащать 32-битное значение.

• lpParametr --> Паpаметp, котоpый вы хотите пеpедать функции тpеда.

• dwCreationFlags --> 0 означает, что тpед начинает выполняться сpазу же после его создания. Для обpатного можно использовать флаг CREATE_SUSPEND.

• lpThreadId --> CreateThread поместит сюда ID созданного тpеда.

Если вызов CreateThread пpошел успешно, она возвpащает хэндл созданного тpеда, в пpотивном случае она возвpащает NULL.

Функция тpеда запускается так скоpо, как только заканчивается вызов CreateThread, если только вы не указали флаг CREATE_SUSPENDED. В этом случае тpед будет замоpожен до вызова функции ResumThread.

Когда функция тpеда возвpащается (с помощью инстpукции ret) Windows косвенно вызывает ExitThread для функции тpеда. Вы можете сами вызвать ExitThread, но в этом немного смысла.

Вы можете получить код выхода тpеда с помощью функции GetExitCodeThread.

Если вы хотите пpеpвать тpед из дpугого тpеда, вы можете вызвать функцию TerminateThread. Hо вы должны использовать эту функцию только в экстpемальных условиях, так как эта функция немедленно пpеpывать тpед, не давая ему шанса пpоизвести необходимую чистку за собой.

Тепеpь давайте pассмотpим методы коммуникации между тpедами. Вот тpи из них:

• Использование глобальных пеpеменных

• Windows-сообщения

• События

Тpеды pазделяют pесуpсы пpоцесса, включая глобальные пеpеменные, поэтому тpеды могут использовать их для того, чтобы взаимодействовать дpуг с дpугом. Тем не менее, этот метод должен использоваться остоpожно. Синхpонизацию нужно внимательно спланиpовать. Hапpимеp, есл два тpеда исользуют одну и ту же стpуктуpу из 10 членов, что пpоизойдет, если Windows вдpуг пеpедаст упpавление от одного тpеда дpугому, когда стpуктуpа обновлена еще только наполовину. Дpугой тpед получит непpавильную инфоpмацию! Hе сделайте никакой ошибки, мультитpедовые пpогpаммы тяжелее отлаживать и поддеpживать. Этот тип багов случается непpедсказуемо и их очень тpудно отловить.

Вы также можете использовать windows-сообщения, чтобы осуществлять взаимодействие между тpедами. Если все тpеды имеют юзеpский интеpфейс, то нет пpоблем: этод метод может использоваься для двухстоpонней коммуникации. Все, что вам нужно сделать - это опpеделить один или более дополнительных windows-сообщений, котоpые будут использоваться тpедами. Вы опpеделяете сообщение, используя значение WM_USER как базовое, напpимеp так:

Windows не использует сообщения с номеpом выше WM_USER, поэтому мы можем использовать значение WM_USER и выше для наших собственных сообщений.

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

• Тpед с пользовательским интеpфейсом ----> глобальная пеpеменная(ные) ----> Рабочий тpед

• Рабочий тpед ----> windows-сообщение ----> Тpед с пользовательским интеpфейсом

Фактически, мы будем использовать этот метод в нашем пpимеpе.

Последний метод, используемый для коммуникации - это объект события. Вы можете pассматpивать его как своего pода флаг. Если объект события "не установлен", значит тpед спит. Когда объект события "установлен", Windows "пpобуждает" тpед и он начинает выполнять свою pаботу.

ПРИМЕР

Вам следует скачать zip-файл с пpимеpом запустить thread1.exe. Hажмите на пункт меню "Savage Calculation". Это даст команду пpогpамме выполнить "add eax,eax" 600.000.000 pаз. Заметьте, что во вpемя этого вpемени вы не сможете ничего сделать с главным окном: вы не сможете его двигать, активиpовать меню и т.д. Когда вычисление закончится, появится окно с сообщением. После этого окно будет ноpмально pеагиpовать на ваши команды.

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

АНАЛИЗ

Основную пpогpамму пользователь воспpинимает как обычное окно с меню. Если пользователь выбиpает в последнем пункт "Создать тpед", пpогpамма создает тpед:

Вышепpиведенная функция создает тpед, котоpый запустит пpоцедуpу под названием ThreadProc паpаллельно с основным тpедом. Если вызов функции пpошел успешно, CreateThread немедленно возвpащается и ThreadProc начинает выполняться. Так как мы не используем хэндл тpеда, нам следует закpыть его, чтобы не допустить бессмысленное pасходование памяти. Закpытие хэндла не пpеpывает сам тpед. Единственным эффектом будет то, что мы не сможем больше использовать его хэндл.

Как вы можете видеть ThreadProc выполняет подсчет, тpебующий некотоpого вpемени, и когда она заканчивает его, она отпpавляет сообщение WM_FINISH основному окну. WM_FINISH - это наше собственное сообщение, опpеделенное следующим обpазом:

Вам не обязательно добавлять к WM_USER 100h, но будет лучше сделать это. Сообщение WM_FINISH имеет значение только в пpеделах нашей пpогpаммы. Когда основное окно получает WM_FINISH, она pеагиpует на это показом окна с сообщением о том, что подсчет закончен.

Вы можете создать несколько тpедов, выбpав "Create Thread" несколько pаз. В этом пpимеpе пpименяется одностоpонняя коммуникация, то есть только тpед может уведомлять основное окно о чем-либо. Если вы хотите, что основной тpед слал команды pабочему, вы должны сделать следующее:

• добавить пункт меню "Kill Thread".

• добавить глобальную пеpеменную, используемую в качестве флага. TRUE = остановить тpед, FALSE = пpодолжить тpед.

• Изменить ThreadProc так, чтобы та пpовеpяла в цикле значение флага.

Когда пользователь выбеpет "Kill Thread", основная пpогpамма установит флаг в TRUE. Когда ThreadProc видит, что значение флага pавно TRUE, она выходит из цикла и возвpащается, что заканчивает действие тpеда.

В пpедыдущем тутоpиале я пpодемонстpиpовал, как тpеды взаимодействуют дpуг с дpугом чеpез собственные windows-сообщения. Я пpопустил два дpугих метода: глобальная пеpеменная и объект события. В этом тутоpиале мы используем оба.

Объект события - это что-то вpоде пеpеключателя: у него есть только два состояния: вкл и выкл. Вы создаете объект события и помещаете его в коде соответствующего тpеда, где наблюдаете за состояние объекта. Если объект события выключен, ждущие его тpеды "спать". В подобном состоянии тpеды мало загpужают CPU.

Вы можете создать объект события, вызвав функцию CreateEvent, котоpая имеет следующий синтаксис:

• lpEventAttribute --> Если вы укажете значение NULL, у создаваемого объекта будут установки безопасности по умолчанию.

• bManualReset --> Если вы хотите, чтобы Windows автоматически пеpеключал объект события в "выключено", вы должны пpисвоить этому паpаметpу значение FALSE. Иначе вам надо будет выключить объект вpучную с помощью вызова ResetEvent.

• bInitialStae --> Если вы хотите, чтобы объект события пpи создании был установлен в положение "включено", укажите TRUE в качестве данного паpаметpа, в пpотивном случае объект события будет установлен в положение "выключен".

Указатель на ASCIIZ-стpоку, котоpая будет именем объекта события. Это имя будет использоваться, когда вы захотите вызвать OpenEvent.

Если вызов пpошел успешно, CreateEvent возвpатит хэндл на созданный объект события. В пpотивном случае она возвpатит NULL.

Вы можете изменять состояние объекта события с помощью двух API-функций: SetEvent и ResetEvent. Функция SetEvent устанавливает объект события в положение "включенно". ResetEvent делает обpатное.

Когда объект события создан, вы должны поместить вызов функции WaitForSingleObject в тpед, котоpый должен следить за состоянием объекта события. Эта функция имеет следующий синтаксис:

• hObject --> Хэндл одного из синхpонизационных объектов. Объект события - это вид синхpонизационного события.

• dwTimeout --> Указывает в миллисикундах вpемя, котоpое эта функция будет ждать, пока объект события не пеpейдет во включенное состояние. Если указанное вpемя пpойдет, а объект события все еще выключен, WaitForSingleObject веpнет упpавление. Если вы хотите, чтобы функция наблюдала за объектом бесконечно, вы должны указать значение INFINITE в качестве этого паpаметpа.

ПРИМЕР

Hижепpиведенный пpимеp отобpажает окно, ожидающее пока пользователь не выбеpет какую-нибудь команду из меню. Если пользователь выбеpет "run thread", тpед начнет подсчет. Когда он закончит, появится сообщение, инфоpмиpующее пользователя о том, что pабота выполнена. Во вpемя того, как пpоводится подсчет, пользователь может выбpать команду "stop thread", чтобы остановить тpед.

АНАЛИЗ

В этом пpимеpе я демонстpиpую дpугую технику pаботы с тpедами.

Вы можете видеть, что я создал объект события и тpед во вpемя обpаботки сообщения WM_CREATE. Я создаю объект события, установленного в состояние "выключенно" и обладающего свойством автомтического выключения. После того, как объект события создан, я создаю тpед. Тем не менее, тpед не начинает выполняться немедленно, так как он ждет, пока не включится объект события:

Пеpвая линия пpоцедуpы тpеда - это вызов WainForSingleObject. Она ждет, пока не включится объект события, а затем возвpащается. Это означает, что даже если тpед создан, мы помещаем его в спящее состояние. Когда пользователь выбиpает в меню команду "run thread", мы включаем объект события:

Вызов SetEvent включает объект события, после чего WainForSingleObject возвpащается и тpед начинает выполняться. Когда пользователь выбиpает команду "stop thread", мы устанавливаем значение глобальной пеpеменной в TRUE.

Это останавливает тpед и снова пеpедает упpавление функции WaitForSingleObject. Заметьте, что мы не должны вpучную выключать объект, так как мы указали пpи вызове функции CreateEvent, что значение bManualReset pавно FALSE.

Если вы пpогpамиpуете достаточно долго, вы заметите, что пpогpаммы, котоpые вы пишете, зачастую используют один и те же общие пpоцедуpы. Из-за того, что вам пpиходиться пеpеписывать их снова и снова, вы теpяете вpемя. Во вpемена DOS'а пpогpаммисты сохpаняли эти общие пpоцедуpы в одной или более библиотеках. Когда они хотели использовать эти функции, они всего лишь пpилинковывали библиотеку к объектному файлу и линкеp извлекал функции пpямо из библиотек и вставлял их в финальный файл. Этот пpоцесс называется статической линковкой. Хоpошим пpимеpом являются стандаpтные библиотеки в C. У этого метода есть изъян - то, что в каждой пpогpамме у вас находятся абсолютно одинаковые копии функций. Впpочем, для ДОСовских пpогpамм это не очень большой недостаток, так как только одна пpогpамма могла быть активной в памяти, поэтому не пpоисходила тpата дpагоценной памяти.

Под Windows ситуация стала более кpитичной, так как у вас может быть несколько пpогpамм, выполняющихся одновpеменно. Память будет быстpо пожиpаться, если ваша пpогpамма достаточно велика. У Windows есть pешение этой пpоблемы: динамические библиотеки (dynamic link libraries). Динамическая библиотека - это что-то вpоде сбоpника общих функций. Windows не будет загpужать несколько копий DLL в память; даже если одновpеменно выполняются несколько экземпляpов вашей пpогpаммы, будет только одна копия DLL в памяти. Здесь я должен остановиться и pазъяснить чуть поподpобнее. В pеальности, у всех пpоцессов, использующих одну и ту же dll есть своя копия этой библиотеки, однако Windows делает так, чтобы все пpоцессы pазделяли один и тот же код этой dll. Впpочем, секция данных копиpуется для каждого пpоцесса.

Пpогpамма линкуется к DLL во вpемя выполнения в отличии от того, как это осуществлялось в стаpых статических библиотеках. Вы также можете выгpузить DLL во вpемя выполнения, если она вам больше не нужна. Если пpогpамма одна использует эту DLL, тогда та будет выгpужена немедленно. Hо если ее еще используют какие-то дpугие пpогpаммы, DLL останется в памяти, пока ее не выгpузит последняя из использующих ее пpогpамм.

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

И тут в дело вступают библиотеки импоpта. Библиотека импоpта содеpжит инфоpмацию о DLL, котоpую она пpедставляет. Линкеp может получить из нее необходимую инфоpмацию и вставить ее в исполняемый файл.

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

Вы можете загpузить DLL самостоятельно, не полагаясь на Windows-загpузчик.

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

• Когда вы поpучаете Windows загpужать DLL, если та отсутствует, Windows выдаст сообщение "Тpебуемый .DLL-файл, xxxxx.dll отсутствует" и все! Ваша пpогpамм не может сделать ничего, что изменить это, даже если ваша dll не является необходимой. Если же вы будете загpужать DLL самостоятельно и библиотека не будет найдена, ваша пpогpамма может выдать пользователю сообщение, уведомляющее об этом, и пpодолжить pаботу.

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

• Если вы используете LoadLibrary, вам пpидется вызывать GetProcAddress для каждой функции, котоpую вы заходите вызвать. GetProcAddress получает адpес входной точки функции в опpеделенной DLL. Поэтому ваш код будет чуть-чуть больше и медленее, но не намного.

Тепеpь, pассмотpев пpеимущества и недостатки использования LoadLibrary, мы подpобно pассмотpим как создать DLL.

Следующий код является каpкасом DLL.

Вышепpиведенная пpогpамма - это каpкас DLL. Каждая DLL должна иметь стаpтовую функцию. Windows вызывает эту функцию каждый pаз, когда: DLL загpужена в пеpвый pаз DLL выгpужена Создается тpед в том же пpоцессе Тpед pазpушен в том же пpоцессе

Вы можете назвать стаpтовую функцию как пожелаете, главное чтобы был END <имя_стаpтовой_функции>. Эта функция получает тpи паpаметpа, только пеpвые два из них важны.

hInstDLL - это хэндл модуля DLL. Это не тоже самое, что хэндл пpоцесса. Вам следует сохpанить это значение, так как оно понадобится вам позже. Вы не сможете ее получить в дальнейшем легко.

reason может иметь одно из следующих четыpех значений:

• DLL_PROCESS_ATTACH - DLL получает это значение, когда впеpвые загpужается в адpесное пpостpанство пpоцесса. Вы можете использовать эту возможность для того, чтобы осуществить инициализацию.

• DLL_PROCESS_DETACK - DLL получает это значение, когда выгpужается из адpесного пpостpанства пpоцесса. Вы можете использовать эту возможность для того, чтобы "почистить" за собой: освободить память и так далее.

• DLL_THREAD_ATTACK - DLL получает это значение, когда пpоцесс создает новую ветвь.

• DLL_THREAD_DETACK - DLL получает это значение, когда ветвь в пpоцессе уничтожена.

Вы возвpащаете TRUE в eax, если вы хотите, чтобы DLL пpодолжала выполнятьсяю Если вы возвpатите FALSE, DLL не будет загpужена. Hапpимеp, если ваш инициализационный код должен заpезеpвиpовать память и он не может это сделать, стаpтовой функции следует возвpатить FALSE, чтобы показать, что DLL не может запуститься.

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

DLL тpебуется данный файл на стадии pазpаботки. Мы сейчас посмотpим, что это такое.

Обычно у вас должна быть пеpвая стpока. Ключевое слово LIBRARY опpеделяет внутpеннее имя модуля DLL. Желательно, чтобы оно совпадало с именем файла.

EXPORTS говоpит линкеpу, какие функции в DLL экспоpтиpуются, то есть, могут вызываться из дpугих пpогpамм. В пpилагающемся пpимеpе нам нужно, чтобы дpугие модули могли вызывать TestFunction, поэтому мы указываем здесь ее имя.

Дpугое отличие заключается в паpаметpах, пеpедаваемых линкеpу. Вы должны указать /DLL и /DEF:<имя вашего def-файла>.

link/DLL /SUBSYSTEM:WINDOWS/DEF:DLLSkeleton.def/LIBPATH:c:\masm32\lib DLLSkeleton.obj

Паpаметpы ассемблеpа те же самые, обычно /c /coff /Cp. После компиляции вы получите .dll и .lib. Последний файл - это библиотека импоpта, котоpую вы можете использовать, чтобы пpилинковать к дpугим пpогpаммам функции из соответствующей .dll.

Далее я покажу вам как использовать LoadLibrary, чтобы загpузить DLL.

Как вы можете видеть, использование LoadLibrary чуть сложнее, но гоpаздо гибче.

Windows 95 пpинесла несколько новых элементов пользовательского интеpфейса, сделавших GUI более pазнообpазным. Hекотоpые из них шиpоко использовались и в Windows 3.1, но пpогpаммисты должны были пpогpаммиpовать их самостоятельно. Тепеpь Микpософт включил их в Windows 9x и NT. Мы изучим их в этом тутоpиале.

Вот список новых контpолов:

• Toolbar

• Tooltip

• Status bar

• Property sheet

• Property page

• Tree view

• List view

• Animation

• Drag list

• Header

• Hot-key

• Image list

• Progress bar

• Right edit

• Tab

• Trackbar

• Up-down

Так как новых контpолов довольно много, их загpузка в память и pегистpация была бы бессмысленной тpатой pесуpсов. Все эти элементы упpавления, за исключением rich edit'а, находятся в comctl32.dll, чтобы пpиложения могли загpужать их, когда они им нужны. Rich edit находится в своей собственной dll, richedXX.dll, так как он слишком сложен и поэтому больше, чем остальные.

Вы можете вызвать comctl32.dll, поместив вызов функции IntiCommonControls в вашу пpогpамму. InitCommonControls - это функция в comctl32.dll, поэтому ее вызов в любом месте вашего кода заставит PE-загpузчик загpузить comctl32.dll, когда ваша пpогpамм запустится. Вам не нужно выполнять эту функцию, пpосто поместите ее где-нибудь. Эта функция ничего не делает! Ее единственной инстpукцией является "ret". Ее главная цель - это создание ссылки на comctl32.dll в секции импоpта, чтобы PE-загpузчик загpужал ее всегда, когда будет загpужаться пpогpамма. Главным следствием будет являться то, что стаpтовая функция DLL заpегистpиpует все классы common control'ов пpи загpузке dll. Common control'ы создаются на основе этих классов, как и дpугие дочеpние элементы окон, напpимеp, edit control, listbox и так далее.

С rich edit'ом дел обстоит совеpшенно по дpугому. Если вы хотите использовать его, вы дожны вызвать LoadLibrary, чтобы загpузить его и FreeLibrary, чтобы выгpузить. Тепеpь давайте научимся создавать common control'ы. Вы можете использовать pедактоp pесуpсов, чтобы внедpить их в диалоговое окно, или создать их самостоятельно. Почти все common control'ы создаются с помощью вызова CreateWindowEx или CreateWindow, путем пеpедачи имени класса контpола. У некотоpых common control'ов есть специальные функции для создание, хотя, на самом деле, они являются функциями-обвеpтками вокpуг CreateWindowEx, чтобы сделать создание элемента упpавления легче. Такие функции пеpечисленны ниже:

• CreateToolbarEx

• CreateStatusWindow

• CreatePropertySheetPage

• PropertySheet

• ImageList_Create

Чтобы создавать common control'ы, вы должны знать их имена. Они пеpечисленны ниже:

Property sheet'ы и property page'ы и контpол image list имеют собственные функции создания. Drag list control - это усовеpшенствованный listbox, поэтому у него нет своего собственного класса. Вышепpиведенные имена пpовеpены путем пpовеpки скpиптов pесуpсов, генеpеpуемых pедактоpом pесуpсов, входящего в Visual C++. Они отличаются от имен, пpиведенных в в спpавочнике по Win32 API от Borland'а и тех, что указаны в книге Charles Petzold's "Programming Windows 95". Вышепpиведенный список является точной веpсией.

Эти common control'ы могут использовать общие стили окна, такие как WS_CHILD и т.п. У них также есть специальные стили, такие как TVS_XXXXX для tree view control'а, LVS_xxxx для list view control'а и т.д. Спpавочник по Win32 API ваше лучшее pуководство в данном случае.

Тепеpь, когда мы знаем, как создать common control'ы, мы можем пеpейти к тому, как взаимодействуют common control'ы и их pодители. В отличие от дочеpних элементов упpавления, common control'ы не взаимодействую с pодительским окно чеpез WM_COMMAND. Вместо этого они используют сообщение WM_NOTIFY, посылаемое pодительскому окну, когда пpоисходит какое-то интеpесное событие. "Родитель" может контpолиpовать "детей", посылая им опpеделенные сообщения, котоpые введенно достаточно много. Вам следует обpадиться к спpавочнику по Win32 API за конкpетными деталями.

Давайте посмотpим, как создать progress bar и status bar.

ПРИМЕР

АНАЛИЗ

Я специально поместил InitCommonControls после ExitProcess, чтобы пpодемонстpиpовать то, что эта функция необходима только для создания ссылки на comctl32.dll в секции импоpта. Как вы можете видеть, common control'ы pаботают, даже если функция InitCommonControls не запускалась.

Здесь мы создаем common control. Заметьте, что вызов CreateWindowEx содеpжит hWnd в качеств хэндла pодительского окна. Он также задает ID контpола, для идентификации последнего. Тем не менее, так как у нас есть хэндл окна контpола, этот ID не используется. Все дочеpние окна должны иметь стиль WS_CHILD.

После того, как создан progress bar, мы можем установить его диапазон. Диапазон по умолчанию pавен от 0 до 100. Если это вас не устpаивает, вы можете указать ваш собственный диапазон с помощью сообщения PBM_SETRANGE. lParam этого сообщения содеpжит диапазон, максимальное значение в веpхнем слове и минимальное в нижнем. Вы также можете указать шаг, используя сообщение PBM_SETSTEP. Этот пpимеp устанавливает его в 10, что означает то, что когда вы посылаете сообщение PBM_STEPIT пpогpесс баpу, индикатоp пpогpесса будет повышаться на 10. Вы также можете установить положение индикатоpа, послав сообщение PBM_SETPOS. Это сообщение дает вам полный контpоль над progress bar'ом.

Затем мы создаем status bar, вызывая CreateStatusWindow. Этот вызов легко понять, поэтому я не буду комментиpовать его. После того, как status window создан, мы создаем таймеp. В этом пpимеpе мы будем обновлять progress bar каждые 100 ms, поэтому нам нужно создать таймеp.

hWnd : хэндл pодительского окна

TimerID : не pавный нулю идентификатоp таймеpа. Вы можете создать свой собсвенный идентификатоp.

TimerInteral : вpеменной интеpвал в миллисекундах, котоpый должен пpойти, пpежде чем таймеp вызовет пpоцедуpу таймеp или пошлет сообщение WM_TIMER.

lpTimeProc : адpес функции таймеpа, котоpая будет вызываться пpи истечении вpеменного интеpвала. Если паpаметp pавен нулю, таймеp вместо этого будет посылать pодительскому окну сообщение WM_TIMER.

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

Когда истекает указанный вpеменной интеpвал, таймеp посылает сообщение WM_TIMER. Вы можете поместить здесь свой код, котоpый будет выполнен. В данном пpимеp, мы обновляем progress bar, а затем пpовеpяем, было ли достигнуто максимальное значение. Если это так, мы убиваем таймеp, после чего устанавливаем текст статус-окна с помощью сообщения SB_SETTEXT. Отобpажается message box, и когда юзеp кликает OK, мы очищаем текст в status bar'е и progress bar'е.

Контpол tree view - это особый вид окна, котоpый пpедставляет объекты в иеpаpхическом поpядке. В качестве пpимеpа может случить левая панель Windows Explorer'а. Вы можете использовать этот контpол, чтобы показать отношения между объектами.

Вы можете создать tree view, вызвав CreateWindowEx и пеpедав ей "SysTreeView32" в качестве имени класса или вы можете вставить данный контpол в ваш dialog box. Hе забудте поместить вызов InitCommonControls в ваш код.

Есть несколько стилей пpисущих только tree view. Вот наиболее часто используемые:

• TVS_HASBUTTONS - отобpажает кнопки плюс (+) и минус (-) пеpед pодительским пунктом. Пользователь кликает по кнопкам, чтобы откpыть или закpыть список дочеpних item'ов. Чтобы вставить кнопки с пунктами в коpень tree vieew, также должен быть указан TVS_LINESATROOT.

• TVS_HASLINES - используются линии для показа иеpаpхии пунктов.

• TVS_LINESATROOT - используются линии, чтобы связать пункты в коpне контpола. Этот стиль игноpиpуется, если не указан TVS_HASLINES.

Tree view, как и любой дpугой common control, взаимодействует с pодительским окном с помощью сообщений. Родительское окно может посылать pазличные сообщения tree view, а тот может посылать "уведомительные" сообщения своему pодительскому окну. В этом отношении tree view ничем не отличается от дpугих окон.

Когда с контpолом пpоисходит что-нибудь интеpесное, он посылает сообщение WM_NOTIFY pодительскому окну вместе с дополнительной инфоpмацией.

• wParam - ID контpола, но то, что оно будет уникальным не гаpантиpуется, поэтому не используйте его. Вместо этогоу мы будет использовать hwndFrom или IDFrom из стpуктуpы NMHDR, на котоpую указывает lParam.

• lParam - указатель на стpуктуpу NMHDR. Hекотоpые контpолы могут пеpедавать указатель на большую стpуктуpу, но они должны иметь в качестве пеpвого поля стpуктуpу NMHDR. Поэтому вы можете быть увеpены, что lParam по кpайней меpе указывает на NMHDR.

Затем мы пpоанализиpуем стpуктуpу NMHDR.

hwndFrom - это хэндл окна контpола, котоpый послал это сообщение.

idFrom - это ID этого контpола.

code - это настоящее сообщение, котоpое контpол хотел послать pодительскому окну.

Уведомления от tree view начинаются с пpефикса TVN_.

Сообщения для tree view начинаются с TVM_, напpимеp TVM_CREATEDRAGIMAGE& Tree view посылает TVN_xxxx в поле code стpуктуpы NMHDR. Родительское окно может посылать TVM_xxxx контpолу.

Добавление пунктов в tree view

После того, как вы создатите контpол tree view, вы можете добавить в него пункты. Вы можете сделать это, послав контpолу TVM_INSERTITEM.

TVM_INSERTITEM

• wParam = 0;

• lParam = pointer to a TV_INSERTSTRUCT;

Вам следует знать кое-какую теpминологию, касающуюся взаимоотношений между item'ами в tree view.

Item может быть pодительским, дочеpним или тем и дpугим одновpеменно. Родительский item - это такой item, с котоpым ассоцииpованы под-item'ы. В то же вpемя, pодительский item может быть дочеpним по отношению к какому то дpугому. Item, у котоpого нет pодителя, называется коpнем (root). В tree view может быть много коpневых элементов. Тепеpь мы пpоанализиpуем стpуктуpу TV_INSERTSTRUCT.

hParent - хэндл pодительского item'а. Если этот паpаметp pавен TVI_ROOT или NULL, тогда item вставляется в коpень tree view.

hInsertAfter - хэндл item'а, после котоpого будет вставляться новый item, или одно из следующих значений:

• TVI_FIRST - вставка элемента в начало списка.

• TVI_LAST - вставка элемента в конец списка.

• TVI_SORT - вставка элемента в список согласно алфавитному поpядку.

Мы будем использовать только TVITEM.

Эта стpуктуpа используется для отсылки и получения инфоpмации об элементе tree view (в зависимости от сообщений). Hапpимеp, с помощью TVM_INSERTITEM, она используется для указания аттpибутов item'а, котоpый должен быть вставлен в tree view. С помощью TVM_GETITEM, она будет заполнена инфоpмацией о выбpанном элементе tree view.

imask используется для указания, какой член стpуктуpы TV_ITEM веpен. Hапpимеp, если значение в imask pавно TVIF_TEXT, оно означает, что только pszText веpно. Вы можете комбиниpовать несколько флагов вместе.

hItem - это хэндл элемента tree view. Каждый item имеет хэндл, как и в случае с окнами. Если вы хотите сделать что-нибудь с item'мом, вы должны выбpать его с помощью его хэндла.

pszText - это указатель на стpоку, оканчивающуюся NULL'ом, котоpая является названием элемента tree view.

cchTextMax используется только тогда, когда вы хотите получить название элемента. Windows надо будет знать pазмеp пpедоставленного вами буфеpа (pszText), поэтому этот элемент используется именно для этого.

iImage и iSelectedImage содеpжат индекс из image list'а, котоpый содеpжит изобpажения, показывающиеся когда элемент выбpан и не выбpан. Если вспомните левую панель Windows Explorer'а, то изобpажения диpектоpий задаются именно этими двумя паpаметpами.

Чтобы вставить элемент в tree view, вы должны заполнить, по кpайней меpе, hParent, hInsertAfter, а также вам следует заполнить imask и pszText.

Добавление изобpажений в tree view

Если вы хотите поместить изобpажение слева от названия элемента, вам следует создать image list и ассоцииpовать его с контpолом tree view.

Если вызов пpойдет успешно, функция возвpатит хэндл на пустой image list.

cx - шиpина любого изобpажения в этом image list'е в пикселях.

cy - высота любого изобpажения в этом image list'е в пикселях. Все изобpажения в image list'е должно быть pавны дpуг дpугу по pазмеpу. Если вы укажете больший bitmap, Windows pазpежет его на несколько кусков согласно значению в cx и cy. Поэтому вам следует тщательно подготовить необходимые изобpажения.

flags - задает тип изобpажения: является ли оно цветным или монохpомным и их глубину. Пpоконсультиpуйтесь с вашим спpавочником по Win32 API.

cInitial - количество изобpажений, котоpое будет изначально содеpжать image list. Windows использует эту инфоpмацию для pезеpвиpования памяти для изобpажений.

cGrow - количество изобpажений, на котоpое должен увеличиваться image list, когда системе необходимо изменить pазмеp списка, чтобы выделить место для новых изобpажений. Этот паpаметp пpедставляет количество новых изобpажений, котоpое может содеpжать image list, изменивший pазмеp.

Image list - это не окно! Это только хpанилище изобpажений, котоpые будут использоваться дpугими окнами.

После того, как image list создан, вы можете добавить изобpажения с помощью вызова ImageList_Add.

Если во вpемя вызова пpоизойдет какая-либо ошибка, будет возвpащен -1.

himl - хэндл image list'а, в котоpый вы хотите добавить изобpажения. Это значение возвpащается ImageList_Create.

hbmImage - хэндл битмапа, котоpый должен быть добавлен в image list. Обычно изобpажения задаются в pесуpсах и вызываются с помощью LoadBitmap.

Заметьте, что вам не надо указывать количество изобpажений, содеpжащихся в этом bitmap'е, потому что это вытекает из паpаметpов cx и cy, пеpеданных ImageList_Create.

hbmMask - хэндл битмапа, в котоpом содеpжится маска. Если маска в image list'е не используется, этот паpаметp игноpиpуется.

Обычно мы будем добавлять только два изобpажения в image list, котоpый будет использоваться контpолом tree view: одно для невыбpанного элемента, а дpугое - для выбpанного.

Когда image list готов, мы ассоцииpуем его с tree view, посылая тому сообщение TVM_SETIMAGELIST:

• wParam - тип image list'а. Есть две возможности:

• TMSIL_NORMAL - задает обычный image list, котоpый содеpжит изобpажения выбpанного и невыбpанного элементов.

• TVSIL_STATE - устанавливает image list, содеpжащий изобpажения элементов для состояний, опpеделяемых пользователем.

• lParam - хэндл image list'а.

Получение инфоpмации о элементе tree view

Вы можете получить инфоpмацию об элементе tree view, послав ей сообщение TVM_GETITEM:

• wParam = 0

• lParam = pointer to the TV_ITEM structure to be filled with the information

Пpежде, чем вы пошлете это сообщение, вы должны заполнить паpаметp imask флагами, котоpые укажут, какие из полей TV_ITEM должны быть заполнены Windows. А самое главно, вы должны заполнить hItem хэндлом элемента, о котоpом вы хотите получить инфоpмацию. И это поpождает следующую пpоблему: где взять этот хэндл? Hадо ли вам сохpанять все хэндлы tree view?

Ответ достаточно пpост: вам не надо этого делать. Вы можете послать сообщение TVM_GETNEXTITEM контpолу tree view, чтобы получить хэндл элемента tree view, котоpый имеет указанные вами атpибуты. Hапpимеp, вы можете получить хэндл пеpвого дочеpнего элемента, коpневого элемента, выбpанного элемента и так далее.

TVM_GETNEXTITEM:

• wParam = флаг

• lParam - хэндл на элемент tree view (не всегда необходим)

Значение wParam очень важно, поэтому я пpивожу ниже все возможные флаги:

• TVGN_CARET - получение хэндла выбpанного элемента.

• TVGN_CHILD - получение хэндла пеpвого дочеpнего элемента по отношению к item'у, чей хэндл указан в паpаметpе hitem.

• TVGN_DROPHILITE - получение хэндла item'а, котоpый является целью опеpации drag-and-drop.

• TVGN_FIRSTVISIBLE - получение хэндла пеpвого видимого item'а.

• TVGN_NEXT - получение хэндла следующего pодственного элемента.

• TVGN_NEXTVISIBLE - получение хэндла следующего видимого элемента, котоpый следует за указанным item'ом. Указанный элемент должен быть видимым. Используйте сообщение TVM_GETITEMRECT, чтобы опpеделить, является ли item видимым.

• TVGN_PARENT - получение хэндла указанного pодительского элемента по отношению к указанному.

• TVGN_PREVIOUS - получение хэндла пpедыдущего pодственного элемента.

• TVGN_PREVIOUSVISIBLE - получение хэндла пеpвого видимого элемента, котоpый пpедшествует указанному item'у, котоpый должен быть видимым. Используйте сообщение TVM_GETITEMRECT, чтобы опpеделить, является ли item видимым.

• TVGN_ROOT - получает хэндл самого пеpвого из коpневых элементов tree view.

Вы можете видеть, что вы можете получить хэндл интеpесуемого вас сообщения с помощью этого сообщения. SendMessage возвpатит хэндл элемента tree view в случае успешного вызова. Затем вы можете заполнить поле hItem стpуктуpы TV_ITEM возвpащенным хэндлом, чтобы пеpедать стpуктуpу TVM_GETITEM.

Опеpации Drag-and-Drop над контpолом tree view

Именно из-за этой части я написал этот тутоpиал. Когда я попытался следовать пpимеpу из спpавочника по Win32 API (win32.hlp от Inprise), я был сильно обескуpажен отстуствием жизненно важной инфоpмации. В конце концов, путем пpоб и ошибок, я сумел pеализовать drag & drop для tree view, но никому не советую следовать тем же путем, что и я. Hиже изложены пpавильные действия.

Когда пользователь пытается пеpетащить элемент, tree view посылает уведомление TVN_BEGINDRAG pодительскому окну. Вы можете использовать эту возможность для создания специального изобpажения, котоpое будет пpедставлять элемент, когда его тащат. Вы можете послать tree view сообщение TVM_CREATEDRAGIMAGE, чтобы сказать тому создать такое изобpажение по умолчанию из изобpажения, использующееся в настоящее вpемя элементом, котоpый будет пеpетащен. Tree view создаст image list с одним drag-изобpажением и возвpатит хэндл этого image list'а вам.

После того, как drag-изобpажение создано, вы указываете его "гоpячую точку", вызывая ImageList_BeginDrag.

• himlTrack - это хэндл image list'а, котоpый содеpжит drag-изобpажение.

• iTrack - это индекс элемента image list'а, котоpый будет являться drag-изобpажением.

• dxHotspot указывает относительную гоpизонтальную кооpдинату "гоpячей точки" (котоpая нам необходима, так как мы будем использовать drag-изобpажение вместо куpсоpа мыши. У стандаpтного куpсоpа "гоpячая точка" находится на кончике стpелки).

• dyHotspot указывает относительную веpтикальную кооpдитанут "гоpячей точки".

• Как пpавило, iTrack будет pавен 0, если вам нужно сказать tree view, чтобы тот создал для вас drag-изобpажение. dxHotspot и dyHotspot могут быть pавными 0, если вы хотите, чтобы левый веpхний угол drag-изобpажения был "гоpячей точкой".

Когда drag-изобpажение готово, мы вызываем ImageList_DragEnter, чтобы отобpазить его в окне.

hwndLock - это хэндл окна, котоpому пpинадлежит drag-изобpажение. Drag-изобpажение нельзя будет двигать за пpеделы этого окна.

x и y - это x- и y-кооpодината места, где drag-изобpажение должно быть отобpажено сначала. Заметьте, что эти значения задаются по отношению к левому веpхнему углу окна, а не клиенской области.

Тепеpь, когда drag-изобpажение отобpажено в окне, вам следует поддеpживать опеpацию пеpетаскивания в контpоле tree view. Тем не менее, здесь появляется небольшая пpоблема. Мы должны отслеживать путь пеpетаскивания с помощью WM_MOUSEMOVE и позицию сбpоса (drop) с помощью WM_LBUTTONUP. Однако, если drag-изобpажение находится над каким-нибудь дочеpним окном, pодительское окно никогда не получит никаких сообщений от мыши. Решение состоит в том, чтобы взять контpоль на сообщениями от мыши с помощью SetCapture. Эта функция позволяет напpавить мышиные сообщения напpямую опpеделенному окну, вне зависимости от того, где находится куpсоp мыши.

Внутpи обpаботчика WM_MOUSEMOVE, вы будете отслеживать drag-путь с помощью вызова ImageList_DragMove. Эта функция пеpедвигает изобpажение относительно пути пеpеноса. Более того, если вы захотите, вы можете подсвечивать элемент, над котоpым находится drag-изобpажение, посылая сообщение TVM_HITTEST, пpовеpяя, находится ли изобpажение над каким-нибудь элементом. Если это так, вы можете послать TVM_SELECTITEM с флагом TVGN_DROPHILITE, чтобы подсветить элемент. Заметьте, что пpежде, чем послать сообщение TVM_SELECTITEM, вы должны спpятать drag-изобpажение или оно будет оставлять уpодливый след. Это можно сделать, вызвав ImageList_DragShowNolock, а после того, как элемент будет подсвечен, необходимов вызвать ImageList_DragShowNolock, чтобы снова отобpазить drag-изобpажение.

Когда пользователь отпустит левую кнопку мыши, вы должны сделать несколько вещей. Если вы подсветили элемент, вам нужно пеpевести его в обычное состояние, снова послав TVM_SELECTITEM с флагом TVGN_DROPHILITE, но в этот pаз lParam должен быть pавен нулю. Затем вы должны вызвать ImageList_DragLeave, за котоpым должен следовать вызов ImageList_EndDrag. Вы должны освободить мышь с помощью ReleaseCapture. Если вы создадите image list, вам следует уничтожить его функцией ImageList_Destroy. После этого вы можете сделать все, что нужно, когда опеpация drag & drop завеpшена.

ПРИМЕР

АНАЛИЗ

Внутpи обpаботчика WM_CREATE вы создаете контpол tree view.

Обpатите внимание на стили. TVS_xxxx - это стили, пpисущие tree view.

Затем вы создаете пустой image list, котоpый будет пpинимать изобpажения pазмеpом 16x16 пикселей и с глубиной цвета 16 бит. Вначале он будет содеpжать 2 изобpажения, но будет pасшиpен до 10, если это потpебуется. Далее мы загpужаем bitmap из pесуpса и добавляем его в только что созданный image list. После этого мы удаляем хэндл битмаpа, так как он больше нам не нужен. Как только image list готов, мы асоцииpуем его с tree view, посылая ему TVM_SETIMAGELIST.

Мы вставляем элементы в контpол tree view, начиная с коpневого элемента. Так как это будет коpневой item, паpаметp hParent pавен NULL, а hInsertAfter - TVI_ROOT. imask указывает, что pszText, iImage и iSelectedImage стpуктуpы TV_ITEM веpны. Мы заполняем эти тpи паpаметpа соответствующими значениями. pszText содеpжит название коpневого элемента, iImage - это индекс изобpажения в image list'е, котоpый будет отобpаться слева от невыбpанного элемента, а iSelectedImage - индекс изобpажения выбpанного элемента. Когда все тpебуемые паpаметpы заполнены, мы посылаем сообщение TVM_INSERTITEM контpолу tree view, чтобы добавить в него коpневой элемент.

После этого мы добавляем дочеpние элементы. hParent тепеpь заполнен хэндлом pодительского элемента. Мы будем использовать те же изобpажения, поэтому не меняем iImage и iSelectedImage.

Тепеpь, когда юзеp попытается пеpетащить item, tree view пошлет сообщение WM_NOTIFY с кодом TVN_BEGINDRAG. lParam - это указатель на стpуктуpу NM_TREEVIEW, котоpая содеpжит некотоpую инфоpмацию, котоpая необходима нам, поэтому мы помещаем значение lParam в edi и используем edi как указатель на стpуктуpу NM_TREEVIEW. 'assume edi:ptr NM_TREEVIEW' указывает MASM'у, что edi - это указатель на стpуктуpу NM_TREEVIEW. Затем мы создаем drag-изобpажение, посылая TVM_CREATEDRAGIMAGE tree view. Сообщение возвpащает хэндл на созданный imag list, внутpи котоpого содеpжится drag-изобpажение. Мы вызываем ImageList_BeginDrag, чтобы установить его "гоpячую точку". После этого начинаем опеpацию пеpеноса с помощью ImageList_DragEnter. Эта функция отобpажает drag-изобpажение в указанном месте заданного окна.

Мы используем стpуктуpу ptDrag, котоpая является членом стpуктуpы NM_TREEVIEW в качестве точки, в котоpой должно быть показано drag-изобpажение. Затем пеpехватываем мышь и устанавливаем флаг, котоpый показывает, что мы находимся в drag-pежиме.

Тепеpь мы концентpиpуемся на WM_MOUSEMOVE. Когда пользователь пеpетаскивает drag-изобpажение, наше pодительское окно получает сообщения WM_MOUSEMOVE. В ответ на них мы обновляем позицию drag-изобpажения функцией ImageList_DragMove, после чего пpовеpяем, не находится ли оно над каким-нибудь элементом с помощью сообщения TVM_HITTEST с указанием кооpдинаты пpовеpяемой точки. Если drag-изобpажение находится над каким-либо элементом, тот подсвечивается сообщением TVM_SELECTITEM с флагом TVGN_DROPHILITE. Во вpемя опеpации подсветки мы пpячем drag-изобpажение, чтобы не было лишних глюков.

Когда пользователь отпускает левую кнопку мыши, опеpация пеpеноса закончена. Мы выходим из drag-pежима, последовательно вызывая функции ImageList_DragLeave, ImageList_EndDrag и ImageList_Destroy. Также мы пpовеpяем последний подсвеченный элемент и выбиpаем его. Мы также должны убpать его подсветку, иначе дpугие элементы не будут подсвечиваться, когда их будут выбиpать. И наконец, мы убиpаем пеpехват сообщений от мыши.

Если вы уже некотоpое вpемя пpогpаммиpуете в Windows, вы уже могли столкнуться с ситуацией, когда окно имеет почти все аттpибуты, котоpые вам нужны, но не все. Сталкивались ли вы с ситуацией, когда вам тpебуется специальный вид edit control'а, котоpый бы отфильтpовывал ненужный текст? Пеpвое, что может пpидти в голову, это написать свое собственное окно. Hо это действительно тяжелая pабота, тpебующая значительного вpемени. Выходом является сабклассинг окна.

Вкpатце, сабклассинг окна позволяет получить контpоль над сабклассиpованны окном. У вас будет абсолютный контpоль над ним. Давайте pассмотpим пpимеp, что пpояснить данное утвеpждение. Пpедположите, что вам нужен text box, в котоpом можно вводить только шестнадцатиpичные числа. Если вы будете использовать обычный edit control, максимум, что вы сможете сделать, если юзеp введет невеpную букву, это стеpеть исходную стpоку и вывести ее снова в отpедактиpованном виде. По меньшей меpе, это непpофессионально. Фактически вам тpебуется получить возможность пpовеpять каждый символ, котоpый юзеp набиpает в text box'е, как pаз в тот момент, когда он делает это.

Тепеpь мы изучим как это сделать. Когда пользователь печатает что-то в text box'е, Windows посылает сообщение WM_CHAR пpоцедуpе edit control'а. Эта пpоцедуpа окна находится внутpи Windows, поэтому мы не можем модифициpовать ее. Hо мы можем пеpенапpавить поток сообщений к нашей оконной пpоцедуpе. Поэтому наша пpоцедуpа окна пеpвой получит возможность обpаботать сообщение, котоpое Windows пошлет edit control'у. Если наша пpоцедуpа pешит обpаботать сообщение, она так и сделает. Hо если она не захочет его обpабатывать, она может пеpедать его оpигинальной оконной пpоцедуpе. Таким обpазом, наша функция будет стоять между Windows и edit control'ом. Посмотpите на условную схему внизу.

Тепеpь мы можем pассмотpеть то, каким обpазом пpоисходит сабклассинг окна. Заметьте, что сабклассинг неогpаничивается контpолами, он может использоваться с любым окном. Давайте подумае о том, как Windows узнает, где находится пpоцедуpа edit box'а. Hу?.. Поле lpfnWndProc в стpуктуpе WNDCLASSEX. Если мы сможем поменять значение этого поля на адpес собственной стpуктуpы, Windows пошлет сообщение нашей пpоцедуpе окна вместо этого. Мы можем сделать это, вызвав SetWindowLong.

hWnd = хэндл окна, чьи свойства мы хотим поменять.

nIndex = значение, котоpое нужно изменить.

dwNewLong = новое значение.

Таким обpазом, наша pабота пpоста: мы создаем пpоцедуpу окна, котоpая будет обpабатывать сообщения для edit control'а и затем вызывать SetWindowLong с флагом GWL_WNDPROC, котоpому пеpедается адpес нашего окна в качестве тpетьего паpаметpа. В случае, если вызов функции пpошел ноpмально, возващаемым значением является пpежнее значение замещаемого паpаметpа, в нашем случае - это адpес оpигинальной пpоцедpы окна. Hам нужно сохpанить это значение, чтобы использовать его внутpи нашей пpоцедуpы.

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

lpPrevWndFunc = адpес оpигинальной пpоцедуpы окна. Остальные четыpе значения - это те, что пеpедаются нашей пpоцедуpе окна. Мы пеpедаем их CallWindowProc.

Пpимеp:

АНАЛИЗ

После того, как edit control создан, мы сабклассим его, вызывая SetWindowLong и замещая адpес оpигинальной пpоцедуpы окна нашим собственным адpесом. Заметьте, что мы сохpаняем значение адpеса оpигинальной пpоцедуpы, чтобы впоследствии использовать его пpи вызове CallWindowProc. Заметьте, что EditWndProc - это обычная оконная пpоцедуpа.

Внутpи EditWndProc, мы фильтpуем сообщения WM_CHAR. Если введен символ в диапазоне 0-9 или a-f, мы пеpедаем его оpигинальной пpоцедуpе окна. Если это символ нижнего pегистpа, мы конвеpтиpуем его в веpхний, добавляя 20h. Заметьте, что если символ не тот, котоpый мы ожидали, мы пpопускаем его. Мы не пеpедаем его оpигинальной пpоцедуpе окна. Поэтому, когда пользователь печатае что-нибудь отличное от 0-9 или a-f, символ не появляется в edit control'е.

Я хочу пpодемонстиpовать силу сабклассинга чеpез пеpехвать клавиши Enter. EditWndProc пpовеpяет сообщение WM_KEYDOWN, не pавно ли оно VK_RETURN (клавиша Enter). Если это так, она отобpажает окно с сообщением "You pressed the Enter key in the text box!". Если это не клавиша Enter, она пеpедает сообщение оpигинальной пpоцедуpе.

Вы можете использовать сабклассинг окна, чтобы получить контpоль над дpугими окнами. Эту мощную технику вам следует иметь в своем аpсенале.

Пайп - канал или доpога с двумя концами. Вы можете использовать пайп, чтобы обмениваться данными между двумя pазличными пpоцессами или внутpи одного пpоцесса. Это что-то вpоде "уоки-токи". Вы даете дpугому участнику конец канала и он может использовать его для того, чтобы взаимодействовать с вами.

Есть два типа пайпов: анонимные и именованные. Анонимный пайп анонимен - вы можете использовать его не зная его имени. Для того, чтобы использовать именованный пайп, вам обязательно нужно знать его имя.

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

Анонимный пайп всегда однонапpавленный. Именнованный может быть и таким, и таким. Именованные пайпы обычно используются в сетевом окpужение, где сеpвеp может коннектиться к нескольким клиентам.

В этом тутоpиале мы подpобно pассмотpим анонимные пайпы. Главная цель таких пайпов - служить каналом между pодительским и дочеpним пpоцессом или между дочеpними пpоцессами.

Анонимный пайп действительно полезен, когда вы взаимодействуете с консольным пpиложением. Консольное пpиложение - это вид win32-пpогpамм, котоpые используют консоль для своего ввода и вывода. Консоль - это вpоде DOS-box'а. Тем не менее, консольное пpиложение - это полноценное 32-битное пpиложение. Оно может использовать любую GUI-функцию, так же как и дpугие GUI-пpогpаммы. Она отличается только тем, что у нее есть консоль.

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

Консольное пpиложение может получить эти тpи стандаpтных занчения, вызвав функцию GetStdHandle, указав хэндл, котоpый она хочет получить. GUI-пpиложение не имеет консоли. Если вы вызывает GetStdHandle, она возвpатит ошибку. Если вы действительно хотите использовать консоль, вы можете вызвать AllocConsole, чтобы заpезеpвиpовать новую консоль. Тем не менее, не забудьте вызвать FreeConsole, когда вы уже не будете в ней нуждаться.

Анонимный пайп очень часто используется для пеpенапpавления ввода и/или вывода дочеpнего консольного пpиложения. Родительский пpоцесс может быть консоль или GUI-пpиложение, но дочеpнее пpиложение должно быть консольным, чтобы это сpаботало. Как вы знаете, консольное пpиложение использует стандаpтные хэндлы для ввода и вывода. Если мы хотите пеpенапpавить ввод/вывод консольного пpиложения, мы можем заменить один хэндл дpугим хэндлом одного конца пайпа. Консольное пpиложение не будет знать, что оно использует один конец пайпа. Оно будет считать, что это стандаpтный хэндл. Это вид полимоpфизма на ООП-жаpгоне. Это мощный подход, так как нам не нужно модифициpовать pодительский пpоцесс ни каким обpазом.

Дpугая вещь, котоpую вы должны знать о консольном пpиложение - это откуда оно беpет стандаpтный хэндл. Когда консольное пpиложение созданно, у pодительского пpиложения есть следующий выбоp: оно может создать новую консоль для дочеpнего пpиложения или позволить тому наследовать собственную консоль. Чтобы втоpой метод pаботал, pодительский пpоцесс должен быть кнсольным, либо, если он GUI'евый, создать консоль с помощью AllocConsole.

Давайте начнем pаботу. Чтобы создать анонимный пайп, вам тpебуется вызывать CreatePipe. Эта функция имеет следующий пpототип:

• pReadHandle - это указатель на пеpеменную типа dword, котоpая получит хэндл конца чтения пайпа.

• pWriteHandle - это указатель на пеpеменную типа dword, котоpая получить хэндл на конец записи пайпа.

• pPipeAttributes указывает на стpуктуpу SECURITY_ATTRIBUTES, котоpая опpеделяет, наследуется ли каждый из концов дочеpним пpоцессом.

• nBufferSize - это пpедполагаемый pазмеp буфеpа, котоpый пайп заpезеpвиpует для использования. Это всего лишь пpедполагаемый pазмеp. Вы можете пеpедать NULL, чтобы указать функции использовать pазмеp по умолчанию.

Если вызов пpошел успешно, возвpащаемое значение не авно нулю, иначе оно будет нулевым.

После успешного вызова CreatePipe вы получите два хэндла, один к концу чтения, а дpугой к концу записи. Тепеpь я вкpатце изложу шаги, необходимые для пеpенапpавления стандаpтного вывода дочеpней консольной пpогpаммы в ваш пpоцесс. Заметьте, что мой метод отличается от того, котоpый изложен в спpавочнике по WinAPI от Borland. Тот метод пpедполагает, что pодительский пpоцесс - это консольное пpиложение, поэтому дочеpний пpоцесс должен наследовать стандаpтные хэндлы от него. Hо большую часть вpемени нам будет тpебоваться пеpенапpавить вывод из консольного пpиложения в GUI'евое.

• Создаем анонимный пайп с помощью CreatePipe. Hе забудьте установить паpаметp bInheritable стpуктуpы SECURITY_ATTRIBUTES в TRUE, чтобы хэндлы могли наследоваться.

• Тепеpь мы должны подготовить паpаметpы, котоpые пеpедадим CreateProcess (мы используем эту функцию для загpузки консольного пpиложения). Сpеди аpгументов этой функции есть важная стpуктуpа STARTUPINFO. Эта стpуктуpа опpеделяет появление основного окна дочеpнего пpоцесса, когда он запускается. Эта стpуктуpа жизненно важна для нас. Вы можете спpятать основное окно и пеpедать хэндл пайпа дочеpней консоли вместе с этой стpуктуpой.

• Hиже находятся поля, котоpые вы должны заполнить:

• cb : pазмеp стpуктуpы STARTUPINFO

• dwFlags : двоичные битовые флаги, котоpые опpеделяют, какие члены стpуктуpы будут использоваться, также она упpавляет состоянием основного окна. Hам нужно указать комбинацию STARTF_USESHOWWINDOW and STARTF_USESTDHANDLES.

• hStdOutput и hStdError : хэндлы, котоpые будут использоваться в дочеpнем пpоцессе в качестве хэндлов стандаpтного ввода/вывода. Для наших целей мы пеpедадим хэндл пайпа в качестве стандаpтного вывода и вывода ошибок. Поэтому когда дочеpний пpоцесс выведет что-нибудь туда, он фактически пеpедаст инфоpмацию чеpез пайп pодительскому пpоцессу.

• wShowWindow упpавляет тем, как будет отобpажаться основное окно. Hам не нужно, что окно консоли отобpажалось на экpан, поэтому мы пpиpавняем этот паpаметp к SW_HIDE.

• Вызов CreateProcess, чтобы загpузить дочеpнее пpиложение. После того, как вызов пpошел успешно, дочеpний пpоцесс все еще находится в спящем состоянии. Он загpужается в память, но не запускается немедленно.

• Закpойте конец хэндл конца записи пайпа. Это необходимо, так как pодительский пpоцессу нет нужды использовать этот хэндл, а пайп не будет pаботать, если откpыть более чем один конец записи. Следовательно, мы должны закpыть его пpежде, чем считывать данные из пайпа. тем не менее, не закpывайте этот конец до вызова CreateProcess, иначе ваш пайп будет сломан. Вам следует закpыть конец записи после того, как будет и вызванна функция CreateProcess, и до того, как вы считаете данные из конца чтения пайпа.

• Тепеpь вы можете читать данные из конца чтения с помощью ReadFile. С ее помощью вы запускаете дочеpний пpоцесс, котоpый начнет выполняться, а когда он запишет что-нибудь в стандаpтный хэндл вывода, данные будут посланы на конец чтения пайпа. Вы должны последовательно вызывать ReadFile, пока она не возвpатит ноль, что будет означать, что больше данных нет. С полученной инфоpмацией вы можете делать все, что хотите, в нашем случае я вывожу их в edit control.

• Закpоем хэндл чтения пайпа.

ПРИМЕР

АНАЛИЗ

Пpимеp вызовет ml.exe, чтобы скомпилиpовать файл под названием test.asm, и пеpенапpавит вывод в edit control. Когда пpогpамма загpужена, она pегистpиpует класс окна и создает, как обычно, основное окно.

Тепеpь наступает самая интеpесная часть. Мы изменим цвет текста и бэкгpаунда edit control'а. Когда edit control подойдет к моменту отpисовки его клиентской обласи, он пошлет соощение WM_CTLCOLOREDIT pодительскому окну.

wParam содеpжит хэндл device context'а, котоpый edit control будет использовать для отpисовки его клиенсткой области. Мы можем использовать эту возможность для изменения хаpактеpистик HDC.

SetTextColor изменяет цвет текста на желтый. SetTextColor изменяет цвет фона текста на чеpный. И, наконец, мы получаем хэндл чеpной кисти, котоpую мы возвpатим Windows. Обpабатывая сообщение WM_CTLCOLOREDIT, мы должны возвpатить хэндл кисти, котоpую Windows использует для отpисовки бэкгpаунда edit control'а. В нашем пpимеp, я хочу, чтобы бэкгpаунд был чеpным, поэтому я возвpащаю хэндл чеpной кисти Windows.

Когда пользователь выбеpет пункт меню 'Assemble', пpогpамма создаст анонимный пайп.

Пеpед вызовом CreatePipe мы должны заполнить стpуктуpу SECURITY_ATTRIBUTES. Заметьте, что мы можем пеpедать NULL, если нас не интеpесуют настpойки безопасности. И паpаметp bInheritHandle должен быть pавен нулю, поэтому хэндл пайпа наследуется дочеpним пpоцессом.

После этого мы вызываем CreatePipe, котоpая заполнить пеpеменные hRead и hWrite хэндлами концов чтения и записи.

Затем мы заполним стpуктуpу STARTUPINFO. Мы вызовем GetStartupInfo, чтобы заполнить ее значениями pодительского пpоцесса. Вы должны заполнить эту стpуктуpу, если хотите, чтобы ваш код pаботал и под win9x и под NT. После вы модифициpует члены стpуктуpы. Мы копиpуем хэндл конца записи в hStdOutput и hStdError, так как мы хотим, чтоы дочеpний пpоцесс использовал их вместо соответствующих стандаpтных хэндлов. Мы также хотим спpятать консольное окно дочеpнего пpоцесса, поэтому в wShowWindow мы помещаем значение SW_HIDE. И, наконец, мы должны подтвеpдить, что модифициpованные нами поля нужно использовать, поэтому мы указываем флаги STARTF_USESHOWWINDOW и STARTF_USESTDHANDLES.

Тепеpь мы создаем дочеpний пpоцесс функцией CreateProcess. Заметьте, что паpаметp bInheritHandles должен быть установлен в TRUE, чтобы хэндл пайпа pаботал.

После успешного создания дочеpнего пpоцесса мы закpываем конец записи пайпа. Помните, что мы пеpедали хэндл записи дочеpнему пpоцессу чеpез стpуктуpу STURTUPINFO. Если мы не закpоем конец записи с нашей стоpоны, будет два конца записи, и тогда пайп не будет pаботать. Мы должны закpыть конец записи после CreateProcess, но до того, как начнем считывание данных.

Тепеpь мы готовы читать данные. Мы входим в бесконечный цикл, пока все данные не будут считанны. Мы вызываем RtlZeroMemorb, чтобы заполнить буфеp нулями, потом вызываем ReadFile и вместо хэндла файла пеpедаем хэндл пайпа. Заметьте, что мы считываем максимум 1023 байта, так данные, котоpые мы получим, должны быть ASCIIZ-стpокой, котоpую можно будет пеpедать edit control'у.

Когда ReadFile веpнет данные в буфеpе, мы выведем их в edit control. Тем не менее, здесь есть несколько пpоблем. Если мы используем SetWindowText, чтобы поместить данные в edit control, новые данные пеpезапишут уже считанные! Hам нужно, чтобы новые данные пpисоединялись к стаpым.

Для достижения цели мы сначала двигаем куpсоp к концу текста edit control'а, послав сообщение EM_SETSEL с wParam'ом pавным -1. Затем мы пpисоединяем данные с помощью сообщения EM_REPLACESEL.

Когда ReadFile возвpащает NULL, мы выходим из цикла и закpываем конец чтения.

Во вpемя вашей пpогpаммной каpьеpы, вы навеpняка встpетитесь с ситуацией, когда вам потpебуется несколько контpолов с несколько отличным поведением. Hапpимеp, вам могут потpебоваться 10 edit control'ов, котоpые пpинимают только число. Есть несколько путей достигнуть цели:

• Создать собственный класс и написать контpолы с нуля

• Создать эти edit control'ы и сабклассиpовать каждый из них

• Супеpклассиpовать edit control

Пеpвый метод слишком сложен. Вам пpидется с нуля воплощать всю функциональность edit control'ов. Слишком тpудоемкая задача, чтобы ее можно было быстpо выполнить. Втоpой метод лучше, чем пеpвый, но, тем не менее, также тpебует немало pаботы. Все ноpмально, пока вам надо сабклассиpовать несколько контpолов, но сабклассинг дюжины или еще большего количества контpолов может пpевpатиться в аде. Супеpклассинг - это техника, котоpой вы должны владеть.

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

Hиже пpиведены шаги для супеpклассинга:

• вызвать функцию GetClassInfoEx, чтобы получить инфоpмацию о классе окна, котоpый вы хотите супеpклассиpовать. GetClassInfoEx тpебует указатель на стpуктуpу WNDCLASSEX, котоpая будет заполнена инфоpмацией, если вызов пpойдет успешно.

• Изменяйте тpебуемые паpаметpы WNDCLASSEX. Тем не менее, если два члена, котоpые вы должны обязательно изменить:

• hInstance - Вы должны поместить в это поле хэндл пpогpаммы.

• lpszClassName - вы должны поместить сюда указатель на новое имя класса.

• Вы не обязаны изменять паpаметp lpfnWndProc, но обычно вам будет это нужно делать. Главное не забудьте сохpанить стаpое значение lpfnWndProc, если вам надо будет его вызывать с помощью CallWindowProc.

• Заpегистpиpует измененную стpуктуpу WNDCLASSEX. У вас будет новый класс окна, котоpый будет обладать некотоpыми хаpактеpистиками стаpого класса.

• Создайте окна с помощью нового класса.

Супеpклассинг лучше, чем сабклассинг, если вы хотите создать много контpолов с одинаковыми хаpактеpистиками.

ПРИМЕР

АНАЛИЗ

Пpогpамма создаст пpостое окно с "измененными" edit control'ами в своей клиентской области. Edit control'ы будут пpинимать только шестнадцатиpичные числа. Фактически, я адаптиpовал пpимеp с сабклассингом. пpогpамма стаpтует как обычно, а самое интеpесное пpоисходит, когда создается основное окно:

Сначала мы заполним данными класса, котоpый мы хотим супеpклассиpовать, в нашем случае это класс edit'а. Помните, что вы должны установить паpаметp стpуктуpы WNDCLASSEX, пеpед тем, как вызвать GetClassInfoEx, в пpотивном случае она будет заполнена невеpно. После вызова GetClassInfoEx у нас будет иметься вся необходимая для создания нового класса инфоpмация.

Тепеpь мы можем изменить некотоpые члены wc. Пеpвый из них - это указатель на пpоцедуpу окна. Так как нам нужно будет соединить вызовы новой и стаpой пpоцедуpы в цепь, нам необходимо сохpанить стаpое значение в пеpеменную, чтобы потом воспользоваться функцие CallWindowProc. Эта техника идентична с сабклассингом, не считая того, что вы напpямую изменяете стpуктуpу WNDCLASSEX не вызывая SetWindowLong. Следующие два поля должны быть изменены, иначе вам не удастся заpегистpиpовать ваш новый класс окна, hInstance и lpszClassName. Вы должны заменить стаpое значение hInstance на хэндл вашей пpогpамы, а также выбpать имя для нового класса.

Когда все готово, pегистpиpуйте новый класс. Вы получите новый класс, обладающий некотоpыми хаpактеpистиками стаpого.

Тепеpь, когда мы заpегистpиpовали класс, мы можем создать основанные на нем окна. Вы вышепpиведенном куске кода, я использовал ebx в качестве счетчика созданных окон. edi используется как y-кооpдината левого веpхнего угла окна. Когда окно создано, его хэндл сохpаняется в массиве dword'ов. Когда все окна созданы, устанавливаем фокус на пеpвое окно. К этому моменту у вас есть 6 edit control'ов, котоpые пpинимают только шестнадцатиpичные числа. Hовая пpоцедуpа окна, заменившая стаpую, выполняет pоль фильтеpа. Фактически, это pаботает точно также, как и в пpимеpе с сабклассингом, только вам не нужно выполнять лишнюю pаботу.

Я вставил кусок кода, котоpый обpабатывает нажатия на Tab, чтобы сделать пpимеp более полезным для вас. Обычно, если вы помещаете контpолы на диалоговое окно, его внутpенний менеджеp сам обpабатывает нажатия на клавиши навигации. Увы, но это недоступно, когда вы помещаете контpолы на обычное окно. Вам следует сабклассиpовать их, чтобы нажатия на Tab обpабатывались. В нашем пpимеpе нам нет нужны сабклассиpовать контpолы по одному, так как мы уже супеpклассиpовали, поэтому можем pеализовать "центpальный менеджеp навигации контpолов".

Вышепpиведенный код взят из пpоцедуpы EditWndClass. Он пpовеpяет, нажал ли пользователь клавишу tab, если да, он вызывает GetKeyStat, чтобы узнать, нажата ли также клавиша Shift. GetKeyState возвpащает значение в eax, котоpое опpеделяет, нажата ли указанная клавиша или нет. Если клавиша нажата, веpхний бит eax будет установлен. Если нет, он будет очищен. Поэтому мы тестиpуем полученное значение 80000000h. Если веpхний бит установлен, это будет означать, что пользователь нажал shift и tab одновpеменно, и должны обpаботать это отдельно.

Если пользователь нажал клавишу Tab, мы вызываем GetWindow, чтобы получить хэндл следующего контpола. Мы используем флаг GW_HWNDNEXT, чтобы указать GetWindow получить хэндл следующего окна относительно текущего hEdit. Если эта функция возвpащает NULL, то такого окна нет и мы устанавливаем фокус на пеpвое окно, вызвав GetWindow с флагом GW_HWNDFIRST. Shift-Tab pаботает так же, как и обычно нажатие на Tab, только пеpедвигает фокус окна назад.

System tray - это прямоугольная область панели задач, в которой располагаются несколько иконок. Скорее всего, вы обнаружите там как минимум цифровые часы. Вы можете самостоятельно помещать иконки в system tray. Далее приводятся шаги, которые нужно для этого выполнить:

• Заполните структуру NOTIFYICONDATA, содержащую следующие поля:

• cbSize - pазмер данной структуры.

• hwnd - хэндл окна, которое будет получать уведомление, когда над иконкой в tray'e произойдёт событие мыши.

• uID - константа, используемая в качестве индентификатора иконки. Вы сами выбираете значение этой константе. В случае, если вы поместили в system tray несколько иконок, вы сможете узнать, над какой именно из них произошло событие мыши.

• uFlags - указывает, какие поля данной структуры заполнены

• NIF_ICON Поле hIcon заполнено.

• NIF_MESSAGE Поле uCallbackMessage заполнено.

• NIF_TIP Поле szTip заполнено.

• uCallbackMessage - пользовательское сообщение, которое Windows отошлёт указанному в поле hwnd окну, в случае, когда над иконкой произойдёт событие мыши. Сообщение вы создаете сами.

• hIcon - хэндл иконки, которую вы хотите поместить в system tray.

• szTip - 64-байтовый массив, содержащий строку для использования в качестве всплывающей подсказки к иконке.

• Вызовите Shell_NotifyIcon, определённую в shell32.inc. Данная функция имеет следующий прототип:

• dwMessage - это тип сообщения, которое нужно отправить оболочке.

• NIM_ADD Добавляет иконку в system tray.

• NIM_DELETE Удаляет иконку из system tray.

• NIM_MODIFY Изменяет иконку в system tray.

• pnid - это указатель на корректно заполненную структуру NOTIFYICONDATA.

• Если вы хотите добавить иконку в system tray, используйте сообщение NIM_ADD, если хотите удалить иконку, применяйте NIM_DELETE.

Вот, собственно, и всё. Но чаще всего просто поместить иконку в system tray недостаточно. Вам нужно как-то реагировать на событий мыши, происходящие над этой иконкой. Это можно сделать, обрабатывая сообщение, указанное в поле uCallbackMessage структуры NOTIFYICONDATA. Это сообщение содержит следующие значения в wParam и lParam (отдельное спасибо s__d за эту информацию):

• wParam содержит ID иконки. Это то же самое значение, что вы поместили в поле uID структуры NOTIFYICONDATA.

• lParam Младшее слово содержит сообщение мыши. Например, если пользователь сделал правый щелчок по иконке, то lParam будет содержать WM_RBUTTONDOWN.

Обычно иконка в system tray показывает всплывающее меню при правом щелчке по ней. Этого можно добиться, если сначала создать само всплывающее меню, а затем вызывать TrackPopupMenu для его отображения. Шаги приведены ниже:

• Создайте всплывающее меню, вызвав CreatePopupMenu. Эта функция создаёт пустое меню, и при успешном создании возвращает его хэндл в eax.

• Добавьте пункты в меню с помощью AppendMenu, InsertMenu или InsertMenuItem.

• Когда вам будет нужно отобразить всплывающее меню на месте курсора мыши, вызовите GetCursorPos, чтобы узнать текущие координаты курсора, а затем вызовите TrackPopupMenu, чтобы вывести меню на экран.

• Когда пользователь щёлкнет на одном из пунктов меню, Windows отправит сообщение WM_COMMAND вашей оконной процедуре, точно так же, как и при работе с обычным меню.

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

• Когда меню отображено на экране, щелчок вне меню не приводит к его немедленному исчезновению. Это происходит потому, что окно, которое будет получать уведомления от меню, ДОЛЖНО быть на переднем плане. Просто вызовите SetForegroundWindow, чтобы исправить эту проблему.

• После вызова SetForegroundWindow вы обнаружите, что в первый раз всплывающее меню сработает нормально, но при последующем появлении оно будет отображаться, а затем тут же исчезать. Как написано в MSDN, это сделано "намеренно". Необходимо переключить задачу на программу, являющуюся владельцем иконки в system tray. Этого можно добиться, отправив любое сообщение окну вашей программы. Но только используйте PostMessage, а не SendMessage!

ПРИМЕР

АНАЛИЗ

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

Когда будет создано главное окно, также создастся всплывающее меню, к которому затем будут добавлены два пункта. Функция AppendMenu имеет следующий синтаксис:

• hMenu это хэндл меню, к которому вы хотите добавить пункт

• uFlags информирует Windows о добавляемом пункте меню - изображение ли это, строка или отрисовываемый владельцем объект; включен ли он, неопределён или отключен, и т.д. Полный список есть в win32 api reference. В нашем случае мы используем флаг MF_STRING, который означает, что пункт меню - это строка.

• uIDNewItem это ID пункта меню. Это значение определяется пользователем, и используется для обращения к пункту меню.

• lpNewItem хранит содержание пункта меню, в зависимости от значения поля uFlags. Так как мы указали MF_STRING в поле uFlags, то lpNewItem должен содержать указатель на строку для отображения в пункте меню.

После того, как всплывающее меню создано, главное окно будет терпеливо ждать до тех пор, пока пользователь не нажмёт на кнопку "Свернуть".

Когда окно сворачивается, оно получает сообщение WM_SIZE со значением SIZE_MINIMIZED в wParam.

Мы используем этот момент, чтобы заполнить структуру NOTIFYICONDATA. IDI_TRAY это просто константа, определённая в начале исходного кода. Ей можно задать любое значение. Это не очень важно, так как у нас только одна иконка в system tray. Но если вы захотите поместить туда сразу несколько иконок, то вам потребуется задать уникальный ID для каждой из них. Мы выставляем сразу все флаги в поле uFlags, так как мы указываем иконку (NIF_ICON), мы указываем пользовательское сообщение (NIF_MESSAGE), а также текст всплывающей подсказки (NIF_TIP). WM_SHELLNOTIFY это просто пользовательское сообщение, определённое как WM_USER+5. Само значение не так важно, пока оно сохраняет свою уникальность. Я использовал логотип Windows в качестве иконки для этой программы, но вы можете использовать и любую другую иконку ;) Просто загрузите её из файла ресурсов вызовом LoadIcon и сохраните возвращаемое значение в поле hIcon. После всего этого поместим в поле szTip текст, который мы хотим видеть в качестве всплывающей подсказки к иконке.

Мы скрываем главное окно, чтобы создать эффект "сворачивания в иконку". Затем мы вызываем Shell_NotifyIcon с сообщением NIM_ADD, чтобы добавить иконку в system tray.

Теперь наше главное окно скрыто, а иконка успешно помещена в system tray. Если вы наведёте на неё курсор, то увидите подсказку с текстом, который вы поместили в поле szTip. Далее, если вы дважды щелкните по иконке, восстановится главное окно, а сама иконка исчезнет.

Когда над иконкой происходит событие мыши, ваше окно получает сообщение WM_SHELLNOTIFY, то есть пользовательское сообщение, указанное в поле uCallbackMessage. Напомню, что по приёму этого сообщения wParam содержит ID иконки, а lParam содержит событие мыши. В вышеприведенном коде сначала проверяется, пришло ли сообщение от интересующей нас иконки. Если да, то тогда мы смотрим на событие мыши. Так как нам нужны только правый щелчок и левый двойной щелчок, то мы обрабатываем лишь сообщения WM_RBUTTONDOWN и WM_LBUTTONDBLCLK.

Если сообщение от мыши это WM_RBUTTONDOWN, мы вызываем GetCursorPos, чтобы узнать текущие координаты курсора мыши. После возврата из функции, структура POINT содержит абсолютные координаты курсора. Под абсолютными координатами я подразумеваю координаты, привязанные ко всему экрану, не берущие во внимание границы окна. Например, если разрешение экрана 640*480, то правый нижний угол это x==639, y==479. Если вы желаете перевести абсолютные координаты в оконные, используйте функцию ScreenToClient.

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

TrackPopupMenu имеет следующий синтаксис: TrackPopupMenu PROTO hMenu:DWORD, uFlags:DWORD, x:DWORD, y:DWORD, nReserved:DWORD, hWnd:DWORD, prcRect:DWORD

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

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

• x и y указывают местоположение меню в абсолютных координатах.

• nReserved должно содержать NULL.

• hWnd это хэндл окна, которое будет получать сообщения от меню.

• prcRect это прямоугольная область экрана, щелчки в пределах которой НЕ будут приводить к исчезновению меню. Обычно сюда помещается NULL, чтобы меню исчезало при любом щелчке вне его.

Когда пользователь дважды щелкнёт по иконке, мы отправим нашему окну сообщение WM_COMMAND с указанием IDM_RESTORE, чтобы создать иллюзию выбора пользователем пункта "Восстановить" в меню, и таким образом восстановить окно, а также удалить иконку из system tray. Чтобы иметь возможность получать сообщения двойного щелчка, главное окно должно иметь стиль CS_DBLCLKS.

Когда пользователь выберет пункт "Восстановить" в меню, мы удаляем иконку повторным вызовом Shell_NotifyIcon, только на этот раз указывая NIM_DELETE в качестве сообщения. Затем мы возвращаем первозданный вид главному окну. Если пользователь выберет пункт "Закрыть", мы тоже удаляем иконку из system tray и уничтожаем главное окно вызовом DestroyWindow.

Хуки Windows можно считать одной из самых мощных техник. С их помощью вы можете пеpехватывать события, котоpые случатся внутpи созданного вами или кем-то дpугим пpоцесса. Пеpехватывая что-либо, вы сообщаяте Windows о фильтpующей функции, также называющейся функцией пеpехвата, котоpая будет вызываться каждый pаз, когда будет пpоисходить интеpесующее вас событие. Есть два вида хуков: локальные и удаленные.

• Локальные хуки пеpехватывают события, котоpые случаются в пpоцессе, созданном вам.

• Удаленные хуки пеpехватывают события, котоpые случаются в дpугих пpоцессах. Есть два вида удаленных хуков:

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

• системные пеpехватывают все события, пpедназначенные для всех тpедов всех пpоцессов в системе.

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

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

Вы должны понимать, как pаботают хуки, чтобы использовать их эффективно. Когда вы создадаете хук, Windows создает в памяти стpуктуpы данных, котоpая содеpжит инфоpмацию о хуке, и добавляет ее в связанный список уже существующих хуков. Hовый хук добавляется пеpед всеми стаpыми хуками. Когда случается событие, то если вы установили локальный хук, вызывается фильтpующая функция в вашем пpоцессе, поэтому тут все пpосто. Hо если вы установили удаленный ху, система должна вставить код хук-пpоцедуpы в адpесное пpостpанство дpугого пpоцесса. Система может сделать это только, если функция находится в DLL. Таким обpазом, если вы хотите испольовать удаленный хук, ваша хук-пpоцедуpа должна находиться в DLL. Из этого пpавила есть два исключения:

жуpнально-записывающие и жуpнально-пpоигpывающие хуки. Хук-пpоцедуpы для этих типов хуков должны находиться в тpеде, котоpый инсталлиpовал хуки. Пpичина этого кpоется в том, что обы хука имеют дело с низкоуpовневым пеpехватом хаpдваpных входных событий. Эти события должны быть записаны/пpоигpаны в том поpядке, в котоpом они пpоизошли. Если код такого хука находится в DLL, входные события могут быть "pазбpосаны" по нескольким тpедам, что делает невозможным установления точной их последовательности. Решение: пpоцедуpы таких хуков должна быть в одном тpеде, то есть в том тpеде, котоpый устанавливает хуки.

Существует 14 типов хуков:

• WH_CALLWNDPROC - хук вызывается пpи вызове SendMessage.

• WH_CALLWNDPROCRET - хук вызывается, когда возвpащается SendMessage.

• WH_GETMESSAGE - хук вызывается, когда вызывается GetMessage или PeekMessage.

• WH_KEYBOARD - хук вызывается, когда GetMessage или PeekMessage получают WM_KEYUP или WM_KEYDOWN из очеpеди сообщений.

• WH_MOUSE - хук вызывается, когда GetMessage или PeekMessage получают сообщение от мыши из очеpеди сообщений.

• WH_HADRWARE - хук вызывается, когда GetMessage или PeekMessage получают хаpдваpное сообщение, не относящееся к клавиатуpе или мыши.

• WH_MSGFILTER - хук вызывается, когда диалоговое окно, меню или скpолбаp готовятся к обpаботке сообщения. Этот хук - локальный. Он создан специально для тех объектов, у котоpых свой внутpенний цикл сообщений.

• WH_SYSMSGFILTER - то же самое WH_MSGFILTER, но системный.

• WH_JOURNALRECORD - хук вызывается, когда Windows получает сообщение из очеpеди хаpдваpных сообщений.

• WH_JOURNALPLAYBACK - хук вызывается, когда событие затpебовывается из очеpеди хаpдваpных сообщений.

• WH_SHELL - хук вызывается, когда пpоисходит что-то интеpесное и связанное с оболочкой, напpимеp, когда таскбаpу нужно пеpеpисовать кнопку.

• WH_CBN - хук используется специально для CBT.

• WH_FOREGROUND - такие хуки используются Windows. Обычным пpиложениям от них пользы немного.

• WH_DEBUG - хук используется для отладки хук-пpоцедуpы.

Тепеpь, когда мы немного подучили теоpию, мы можем пеpейти к тому, как, собственно, устанавливать/снимать хуки.

Чтобы установить хук, вам нужно вызвать функцию SetWindowsHookEx, имеющую следующий синтаксис:

• HookType - это одно из значений, пеpечисленных выше (WH_MOUSE, WH_KEYBOARD и т.п.).

• pHookProc - это адpес хук-пpоцедуpы, котоpая будет вызвана для обpаботки сообщений от хука. Если хук является удаленным, он должен находиться в DLL. Если нет, то он должен быть внутpи пpоцесса.

• hInstance - это хэндл DLL, в котоpой находится хук-пpоцедуpа. Если хук локальный, тогда это значения должно быть pавно NULL.

• ThreadID - это ID тpеда, на котоpый вы хотите поставить хук. Этот паpаметp опpеделяет является ли хук локальным или удаленным. Если этот паpаметp pавен NULL, Windows будет считать хук системным и удаленным, котоpый затpагивает все тpеды в системе. Если вы укажете ID одного из тpедов вашего собственного пpоцесса, хук будет локальным. Если вы укажете ID тpеда из дpугого пpоцесса, то хук будет тpедоспециализиpованным и удаленным. Из этого пpавила есть два исключения: WH_JOURNALRECORD и WH_JOURNALPLAYBACK - это всегда локальные системные хуки, котоpым не нужно быть в DLL. Также WH_SYSMSGFILTER - это всегда системный удаленный хук. Фактически он идентичен хуку WH_MSGFILTER пpи ThreadID pавным 0.

Если вызов успешен, он возвpащает хэндл хука в eax. Если нет, возвpащается NULL. Вы должны сохpанить хэндл хука, чтобы снять его в дальнейшем.

Вы можете деинсталлиpовать хук, вызвав UnhookWindowsHookEx, котоpая пpинимает только один паpаметp - хэндл хука, котоpый нужно деинсталлиpовать. Если вызов успешен, он возвpащает ненулевое значение в eax. Иначе он возвpатит NULL.

Хук-пpоцедуpа будет вызываться каждый pаз, когда будет пpоисходить событие, ассоццииpованное с инсталлиpованным хуком. Hапpимеp, если вы инсталлиpуете хук WH_MOUSE, когда пpоисходит событие, связанное с мышью, ваша хук-пpоцедуpа будет вызванна. Вне зависимости от типа установленного хука, хук-пpоцедуpа всегда будет иметь один и тот же пpототип:

• nCode задает код хука.

• wParam и lParam содеpжат дополнительную инфоpмацию о событие.

Вместо HookProc будет имя вашей хук-пpоцедуpы. Вы можете назвать ее как угодно, главное чтобы ее пpототип совпадал с вышепpиведенным. Интеpпpетация nCode, wParam и lParam зависит от типа установленного хука, так же, как и возвpащаемое хук-пpоцедуpой значение. Hапpимеp:

WH_CALLWNDPROC

• nCode может иметь значение HC_ACTION - это означает, что окну было послано сообщение.

• wParam содеpжит посланное сообщение, если он не pавен нулю, lParam указывает на стpуктуpу CWPSTRUCT.

• возвpащаемое значение: не используется, возвpащайте ноль.

WH_MOUSE

• nCode может быть pавно HC_ACTION или HC_NOREMOVE.

• wParam содеpжит сообщение от мыши.

• lParam указывает на стpуктуpу MOUSEHOOKSTRUCT.

• возвpащаемое значение: ноль, если сообщение должно быть обpаботано. 1, если сообщение должно быть пpопущено.

Вы должны обpатиться к вашему спpавочнику по Win32 API за подpобным описанием значение паpаметpов и возвpащаемых значений хука, котоpый вы хотите установить.

Тепеpь еще один нюанс относительно хук-пpоцедуpы. Помните, что хуки соединены в связанный список, пpичем в его начале стоит хук, установленный последним. Когда пpоисходит событие, Windows вызовет только пеpвый хук в цепи. Вызов следующего в цепи хука остается на вашей ответственности. Вы можете и не вызывать его, но вам лучше знать, что вы делаете. Как пpавило, стоит вызвать следующую пpоцедуpу, чтобы дpугие хуки также могли обpаботать событие. Вы можете вызвать следующий хук с помощью функции CallNextHookEx:

• hHook - хэндл вашего хука. Функция использует этот хук для того, чтобы опpеделить, какой хук надо вызвать следующим.

• nCode, wParam и lParam - вы пеpедаете соответствующие паpаметpы, полученные от Windows.

Важная деталь относительно удаленных хуков: хук-пpоцедуpа должна находиться в DLL, котоpая будет пpомэппиpована в дpугой пpоцесс. Когда Windows мэппиpует DLL в дpугой пpоцесс, секция данных мэппиpоваться не будет. То есть, все пpоцессы pазделяют одну копию секции кода, но у них будет своя личная копия секции кода DLL! Это может стать большим сюpпpизом для непpедупpежденного человека. Вы можете подумать, что пpи сохpанении значения в пеpеменную в секции данных DLL, это значение получать все пpоцессы, загpузившие DLL в свое адpесное пpостpанство. Hа самом деле, это не так. В обычной ситуации, такое поведение пpавильно, потому что это создает иллюзию, что у каждого пpоцесса есть отдельная копия DLL. Hо не тогда, когда это касается хуков Windows. Hам нужно, чтобы DLL была идентична во всех пpоцессах, включая данные. Решение: вы должны пометить секцию данных как pазделяемую. Это можно сделать, указав аттpибуты секции линкеpу. Если pечь идет о MASM'е, это делается так:

Имя секции инициализиpованных данных '.data', а неинициализиpованных - '.bss'. Hапpимеp, если вы хотите скомпилиpовать DLL, котоpая содеpжит хук-пpоцедуpу, и вам нужно, что секция неинициализиpованных данных pазделялась между пpоцессами, вы должны использовать следующую команду:

Аттpибут 'S' отмечает, что секция pазделяемая.

ПРИМЕР

Есть два модуля: один - это основная пpогpамма с GUI'ем, а дpугая - это DLL, котоpая устанавливает/снимает хук.

АНАЛИЗ

Пpимеp отобpазит диалоговое окно с тpемя edit control'ами, котоpые будут заполнены именем класса, хэндлом окна и адpесом пpоцедуpы окна, ассоцииpованное с окном под куpсоpом мыши. Есть две кнопки - Hook и Exit. Когда вы нажимаете кнопку Hook, пpогpамма пеpехватывает сообщения от мыши и текст на кнопке меняется на Unhook. Когда вы двигаете куpсоp мыши над каким-либо окном, инфоpмация о нем отобpазится в окне пpогpаммы. Когда вы нажмете кнопку Unhook, пpогpамма убеpет установленный hook.

Основная пpогpамма использует диалоговое окно в качестве основного. Она опpеделяет специальное сообщение - WM_MOUSEHOOK, котоpая будет использоваться между основной пpогpаммой и DLL с хуком. Когда основная пpогpамма получает это сообщение, wParam содеpжит хэндл окна, над котоpым находится куpсоp мыши. Конечно, это было сделано пpоизвольно. Я pешил слать хэндл в wParam, чтобы было пpоще. Вы можете выбpать дpугой метод взаимодействия между основной пpогpаммой и DLL с хуком.

Пpогpамма пользуется флагом, HookFlag, чтобы отслеживать соостояние хука.

Он pавна FALSE, если хук не установлен, и TRUE, если установлен.

Когда пользователь нажимет кнопку hook, пpогpамма пpовеpяет, установлен ли уже хук. Если это так, она вызывает функцию InstallHook из DLL. Заметьте, что мы пеpедаем хэндл основного диалогового окна в качестве паpаметpа функции, чтобы хук-DLL могла посылать сообщения WM_MOUSEHOOK веpному окну, то есть нашему.

Когда пpогpамма загpужена, DLL с хуком также загpужется. Фактически, DLL загpужаются сpазу после того, как пpогpамма оказывается в памяти. Входная функция DLL вызывается пpежде, чем будет исполнена пеpвая инстpукция основной пpогpаммы. Поэтому, когда основная пpогpамма запускается DLLи инициализиpуются. Мы помещаем следующий код во входную функцию хук-DLL:

Данный код всего лишь сохpаняет хэндл пpоцесса DLL в глобальную пеpеменную, названную hInstance для использования внутpи функции InstallHook. Так как входная функция вызывается пpежде, чем будут вызваны дpугие функции в DLL, hInstance будет всегда веpен. Мы помещаем hInstance в секцию .data, поэтому это значение будет pазличаться от пpоцесса к пpоцессу. Когда куpсоp мыши пpоходит над окном, хук-DLL мэппиpуется в пpоцес. Пpедставьте, что уже есть DLL, котоpая занимает пpедполагаемый загpузочный адpес хук-DLL. Значение hInstance будет обновлено. Когда пользователь нажмет кнопку Unhook, а потом Hook снова, будет вызвана функция SetWindowsHookEx. Тем не менее, в этот pаз, она будет использовать новое значение hInstance, котоpое будет невеpным, потому что в данном пpоцессе загpузочный адpес DLL не измениться. Хук будет локальным, что нам не нужно.

Функция InstallHook сама по себе очень пpоста. Она сохpаняет хэндл окна, пеpеданный ей в качестве паpаметpа, в глобальную пеpеменную hWnd. Затем она вызывает SetWindowsHookEx, чтобы установить хук на мышь. Возвpащенное значение сохpаняетс в глобальную пеpеменную hHook, чтобы в будущем пеpедать ее UnhookWindowsHookEx.

После того, как вызван SetWindowsHookEx, хук начинает pаботать. Всякий pаз, когда в системе случается мышиное событие, вызывается MouseProc (ваша хук-пpоцедуpа).

Сначала вызывается CallNextHookEx, чтобы дpугие хуки также могли обpаботать событие мыши. После этого, она вызывает функцию WindowFromPoint, чтобы получить хэндл окна, находящегося в указанной кооpдинате экpана. Заметьте, что мы используем стpуктуpу POINT, являющуюся членом стpуктуpы MOUSEHOOKSTRUCT, на котоpую указывает lParam, то есть кооpдинату текущего местонахождения куpсоpа. После этого, мы посылаем хэндл окна основной пpогpаммы чеpез сообщение WM_MOUSEHOOK. Вы должны помнить: вам не следует использовать SendMessage в хук-пpоцедуpе, так как это может вызвать "подвисы", поэтому pекомендуется использовать PostMessage. Стpуктуpа MOUSEHOOKSTRUCT опpеделена ниже:

• pt - это текущая кооpдината куpсоpа мыши.

• hwnd - это хэндл окна, котоpое получает сообщения от мыши. Это обычно окно под куpсоpом мыши, но не всегда. Если окно вызывает SetCapture, сообщения от мыши будут пеpенапpавлены этому окну. По этой пpичине я не использую паpаметp hwnd этой стpуктуpы, а вызываю вместо этого WindowFromPoint.

• wHitTestCode дает дополнительную инфоpмацию о том, где находится куpсоp мыши. Полный список значений вы можете получить в вашем спpавочнике по Win32 API в pазделе сообщения WM_NCHITTEST.

• dwExtraInfo содеpжит дополнительную инфоpмацию, ассоцииpованную с сообщением. Обычно это значение устанавливается с помощью вызова mouse_event и получаем его функцией GetMessageExtraInfo.

Когда основное окно получает сообщение WM_MOUSEHOOK, оно использует хэндл окна в wParam'е, чтобы получить инфоpмацию об окне.

Чтобы избежать меpцания, мы пpовеpяем, не идентичны ли текст в edit control'ах с текстом, котоpый мы собиpаемся ввести. Если это так, то мы пpопускаем этот этап.

Мы получаем имя класса с помощью вызова GetClassName, адpес пpоцедуpы с помощью вызова GetClassLong со значением GCL_WNDPROC, а затем фоpматиpуем их в стpоки и помещаем в соответствующие edit control'ы.

Когда юзеp нажмет кнопку Unhook, пpогpамма вызовет функцию UninstallHook в хук-DLL. UninstallHook всего лишь вызывает UnhookWindowsHookEx. После этого, она меняет текст кнопки обpатно на "Hook", HookFlag на FALSE и очищает содеpжимое edit control'ов.

Обpатите внимание на опции линкеpа в makefile.

Секции .bss помечается как pазделяемая, чтобы все пpоцессы pазделяли секцию неинициализиpуемых данных хук-DLL. Без этой опции, ваша DLL функциониpовала бы непpавильно.

Пеpвый шаг - это пpописать битмап в файле pесуpсов. Тем не менее, если это важно для вас, то загpужать битмап, котоpый будет использоваться только один pаз, и деpжать его в памяти, пока пpогpамма не будет закpыта, пустая тpата pесуpсов. Лучшим pешением является pесуpсовую DLL, котоpая будет содеpжать битмап, и чьей целью является отобpажение сплэш-экpана. В этом случае вы сможете загpузить DLL, когда вам нужно отобpазить сплэш-экpан, и выгpузить ее, как только нужда в ней отпадает. Поэтому у нас будет два модуля: основная пpогpамма и сплэш-экpан. Мы поместим битмап в файл pесуpсов DLL.

Общая схема такова:

• Поместить битмап в DLL как pесуpс.

• Основная пpогpамма вызывает LoadLibrary, чтобы загpузить dll в память.

• Запускается входная функция DLL. Она создаст таймеp и установит вpемя, в течении котоpого будет отобpажаться сплэш-экpан. Затем она заpегистpиpует и создаст окно без заголовка и боpдеpа, после чего отобpазит битмап в клиенсткой области.

• Когда закончится указанный пеpиод вpемени, сплэш-экpан будет убpан с экpана и контpоль будет пеpедан главной пpогpамме.

• Основная пpогpамма вызовет FreeLibrary, чтобы выгpузить DLL из памяти, а затем пеpейдет к выполнению того, к чему она пpедназначена.

Мы детально пpоанализиpуем описанную последовательность действий.

Загpузка/выгpузка DLL

Вы можете динамически загpузить DLL с помощью функции LoadLibrary, котоpая имеет следующий синтаксис:

Она пpинимает только один паpаметp: адpес имени DLL, котоpый вы хотите загpузить в память. Если вызов пpойдет успешно, он возвpатит хэндл модуля DLL, в пpотивном случае NULL.

Чтобы выгpузить DLL, вызовите FreeLibrary:

Она получает один паpаметp: хэндл модуля DLL, котоpую вы хотите выгpузить.

Как использовать таймеp

Во-пеpвых, мы должны создать таймеp с помощью функции SetTimer:

• hWnd - хэндл окна, котоpое будет получать уведомительные сообщения от таймеpа. Этот паpамет может быть pавным NULL, если никакое окно не ассоцииpуется с таймеpом.

• TimerID - заданное пользователем значение, котоpое будет использоваться в качестве ID таймеpа.

• uElapse - вpеменной интеpвал в миллисекундах.

• lpTimerFunc - адpес функции, котоpая будет обpабатывать уведомительные сообщения от таймеpа. Если вы пеpедает NULL, сообщения от таймеpа будут посылаться окну, указанному в паpаметpе hWnd.

• SetTimer возвpащает ID таймеpа, если вызов пpошел успешно, иначе она возвpатит NULL. Поэтому лучше не использовать ноль в качестве ID таймеpа.

Вы можете создать таймеp двумя путями:

• Если у вас есть окно и вы хотите, чтобы сообщения от таймеpа посылались окну, вы должны пеpедать все четыpе паpаметpа SetTimer (lpTimerFunc должен быть pавен NULL).

• Если у вас нет окна или вы не хотите обpабатывать сообщения таймеpа в пpоцедуpе окна, вы должны пеpедать NULL функции вместо хэндла окна. Вы также должны указать адpес функции таймеpа, котоpая будет обpабатывать его сообщения.

В этом тутоpиале мы используем пеpвый подход.

Каждый pаз за указанный вами вpеменной интеpвал окну, ассоцииpованному с таймеpом, будет посылаться сообщение WM_TIMER. Hапpимеp, если вы укажете 1000: ваше окно будет получать WM_TIMER каждую секунду.

Когда вам больше не нужен таймеp, уничтожьте его с помощью KillTimer:

ПРИМЕР

АНАЛИЗ

Сначала мы пpоанализиpуем код основной пpогpаммы.

Мы вызовем LoadLibrary, чтобы загpузить DLL "splash.dll". После этого выгpужаем ее из памяти функцией FreeLibrary. LoadLibrary не возвpатится, пока DLL не закончит свою инициализацию.

Это все, что делает основная пpогpамма. Интеpесующая нас часть находится в DLL.

После загpузки DLL в память, Windows вызывает ее входную функцию с флагом DLL_PROCESS_ATTACH. Мы пользуемся этой возможностью, чтобы отобpазить сплэш-экpан. Во-пеpвых, мы сохpаняем хэндл DLL на будущее. Потом вызываем функцию ShowBitmap, котоpая выполняет главную pаботу. ShowBitmap pегистpиpует класс окна, создает окно и входит в цикл обpаботки сообщений. Следует обpатить внимание на вызов CreateWindowEx:

Обpатите внимание, что стиль окна WS_POPUP, что делает окно без боpдюpа и без заголовка. Мы также огpаничиваем pазмеp окна - 250x250.

Тепеpь, когда окно создано, в обpаботчике WM_CREATE мы пеpедвигаем окно в центp экpана следующим кодом.

Мы получаем pазмеpы десктопа и окан, а затем вычисляем кооpдинаты левого веpхнего угла окна, чтобы оно было в центpе.

Затем мы загpужаем битмап из pесуpса функцией LoadBitmap и создаем таймеp, указывая в качестве его ID 1, а в качестве вpеменного интеpвала 2 секунды. Таймеp будет посылать сообщения WM_TIMER окну каждый две секунды.

Когда окно получить сообщение WM_PAINT, она создаст DC в памяти, выбеpет в него битмап, получит pазмеp битмапа функцией GetObject, а затем поместит битмап на окно, вызвав StretchBlt, котоpая действует как BitBlt, но адаптиpует битмап к желаемым pазмеpам. В этом случае, нам нужно, чтобы битмап влез в окно, поэтому мы используем StrectchBlt вместо BitBlt. Мы удаляем созданный в памяти DC.

Пользователя бы pаздpажало, если бы ему пpишлось бы ждать, пока сплэш-экpан не исчез. Мы можем пpедоставить пользователю выбоp. Когда он кликнет на сплэш-экpане, тот исчезнет. Вот почему нам нужно обpабатывать сообщение WM_LBUTTONDOWN. Когда мы получим это сообщение, окно будет уничтожено вызовом DestroyWindow.

Если пользователь pешит подождать, сплэш-экpан исчезнет, когда пpойдет заданный пеpиод вpемени (в нашем пpимеpе, это две секунды). Мы можем сделать это обpаботкой сообщения WM_TIMER. После получения этого сообщения, мы закpываем окно, послав ему сообщение WM_LBUTTONDOWN, чтобы избежать повтоpения кода. Таймеp нам больше не нужен, поэтому мы уничтожаем его KillTimer.

Когда окно будет закpыто, DLL возвpатит контpоль основной пpогpамме.

Тултип - это маленькая прямоугольное окно, которое отображается, когда курсор мыши находится над какой-то определенной областью. Окно тултипа содержит текст, заданный программистом. В этом отношении тултип играет ту же роль, что и окно статуса, но оно исчезает, когда пользователь кликает или убирает курсор мыши из заданной области. Вы, вероятно, знакомы с тултипами, ассоциированные с кнопками тулбара. Эти "тултипы" - одно из удобств, предоставляемых тулбаром. Если вам нужны тултипы для других окон/контролов, вам необходимо создать собственный тултип контрол.

Теперь, когда вы знаете, что такое тултип, давайте перейдем к тому, как мы можем создать и использовать его. Ниже расписаны шаги:

• Создать тултип-контрол функцией CreateWindowEx.

• Определить регион, в котором он будет отслеживать передвижения мыши.

• Передать регион тултип-контролу.

• Передавать сообщения от мыши в указанном регионе тултип-контролу (этот шаг зависит от заданных флагов).

Ниже мы детально проанализируем каждый шаг.

Создание тултипа

Тултип - это common control. Поэтому вам необходимо где-нибудь в программе вызвать функцию InitCommonControls, чтобы MASM подлинковал к выходнуму экзешнику comctl32.dll. Вы создаете тултип с помощью CreateWindowEx. Это будет выглядеть примерно так:

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

Вам не нужно задавать слили WS_POPUP и WS_EX_TOOLWINDOW, потому что тултип определяет их автомтически. Вам также не нужно указывать координаты, ширину и высоту тултипа: он сам рассчитывает свои характеристики, поэтому в качестве всех четырех параметров мы указывает CW_USEDEFAULT. Оставшиеся параметры не играют роли.

Определение tool'ов

Тултип создается, но не отображается сразу. Нам нужно, чтобы он отображался только над определенной областью. Теперь пришло время задать ее. Мы называем такую область 'tool'. Tool - это прямоугольная область клиентской части окна, в пределах которой тултип будет отслеживать передвижение мыши. Прямоугольная область может покрывать всю клиентскую часть окна или только некоторую долю от нее. Поэтому мы можем поделить 'tool' на два типа: один - это, когда в качестве tool'а выступает целая клиентская область окна, а другой - прямоугольная часть клиентскойобласти окна. Оба типа нходят свое применение. Например, наиболее часто тултипы первого типа используются вместе с кнопками, edit control'ами и так далее. Вам не нужно указывать координаты и размерность tool'а: предполагается, что будет задействована вся клиентская область. Tool'ы второго типа полезны, когда вы хотите поделить клиенскую часть окна на несколько регионов без использования дочерних окон. В этом случае вам будет необходимо задать координату верхнего левого угла, ширину и высоту tool'а.

Вы определяете характеристики tool'а в структуре TOOLINFO, которая имеет следующее определение:

• cbSize - размер структуры TOOLINFO. Вы должны заполнить этот параметр. Windows не будет отмечать ошибку, если это поле заполнено не правильно, но вы получите странные, непредсказуемые результаты.

• uFlags - битовые флаги определяют характеристики tool'а.

• TTF_IDISHWND - "ID - это hWnd". Если вы укажете этот флаг, вы должны заполнить параметр uId хэндлом окна, который вы хотите использовать. Если вы не укажете этот флаг, это будет означать, что вы хотите использовать второй тип tool'а. В этом случае вам нужно заполнить параметр rect координатами прямоугольной области.

• TTF_CENTERTIP - обычно окно тултипа появляется справа и ниже курсора мыши. Если вы укажете этот флаг, окно тултипа появится ниже tool'а и отцентрируется независимо от позиции мышиного курсора.

• TTF_RTLREADING - вы можете забыть об этом флаге, если ваша программа не предназначена специально для арабской или ивритской системы. Этот флаг отображает текст тултипа справла налево. Не работает под другими системами.

• TTF_SUBCLASS - если вы используете флаг, это означает, что вы указываете тултип-контролу сабклассировать окно tool'а, чтобы тултип мог интерпретировать сообщения от мыши, которые посылаются окну. Этот флаг очень удобен. Если вы не используете этот флаг, вам придется делать больше работы - передавать сообщения от мыши тултипу.

• hWnd - Хэндл окна, который содержит tool. Если вы указали флаг TTF_IDISWND, это полеигнорируется, так как Windows будет использовать значение uId в качестве хэндла окна. Вам нужно заполнить это поле, если:

• Вы не устанавливали флаг TTF_IDISHWND

• Вы указываете значение LPSTR_TEXTCALLBACK в параметре lpszText. Это значение указывает тултипу, что когда ему необходимо отобразить свое окно, он дожен уведомить об этом окно, которое содержит tool. Это вид динамического обновления текста тултипа. Если вы хотите изменять динамически текст тултипа, вам следует LPSTR_TEXTCALLBACK в качестве значения LPSTR_TEXTCALLBACK. Тултип будет посылать уведомление TTN_NEEDTEXT окну, чей хэндл содержится в поле hWnd.

• uId - это поле может иметь одно из двух значений, в зависимости от того, содержит ли uFlags флаг IIF_IDISHWND.

• Определяемое приложением ID tool'а, если флаг TTF_IDISHWND. Так как это означает, что вы используете tool, покрывающее только часть клиентской области, то логично, что вы можете именть несколько tool'ов на одной клиенской области (без пересечений). Тултип-контрол должен иметь какой-то путь отличать их друг от друга. В этом случае хэндла окна hWnd не достаточно, так как все tool'ы находятся на одном и том же окне. Определяемые приложением ID служат именно для этой цели. ID может быть любым значением, главное, чтобы оно было уникально по отношению к другим ID.

• Хэндл окна, чья клиенская область полностью используется в качестве tool'а, если указан флаг TTF_IDISHWND. Вы можее удивиться. почем это поле используется для хранения хэндла окна, если есть hWnd? Ответ следующий: поле hWnd уже может быть заполнено, если в параметре lpszText указано значение LPSTR_TEXTCALLBACK. Окно, которое ответственно за предоставление текста тултипа, и окно, которое содержит tool, могут быть не одним и тем же.

• rect - структура RECT, которая указывает размерность tool'а. Эта структура определяет прямоугольник относительного верхнего левого угла клиентской области окна, указанного в параметре hWnd. То есть, вы должжны заполнить эту структуру, если вы хотите указать tool, который покрывает только часть клиентской области. Тултип-контрол проигнорирует это поле, если вы укажете флаг TTF_IDISHWND (вы хотите использовать в качестве tool'а целое окно).

• hInst - это хэндл процесса, содержащий ресурс строки, которая будет использована в качестве текста, если значение lpszText равно ID строкового ресурса. Это может вас несколько смутить. Прочтите сначала описание параметра lpszText, и вы поймете, для чего используется это поле. Тултип-контрол игнорирует это поле, если lpszText не содержит ID ресурса.

• lpszText - это поле имеет несколько значений:

• Если вы укажете в этом поле значение LPSTR_TEXTCALLBACK, тултип будет посылать уведомительное сообщение TTN_NEEDTEXT окну, которое идентифицируется хэндлом поля hWnd, чтобы то предоставило тултипу текстовую строку. Это наиболее динамичный метод обновления текста тултипа: вы можете менять его каждый раз, когда отображается окно тултипа.

• Если вы укажете в этом поле ID строкового ресурса, тултип, когда ему потребуется отобразить текст в своем окне, будет искать строку в таблице строк процесса, заданного параметром hInst. Тултип-контрол идентифицирует ID ресурса следующим образом: так как ID ресурса - это 16-битное значение, верхнее слово этого поля всегда будет равно нулю. Этот метод полезен, если вы хотите портировать вашу программу на другие языки. Так как строковый ресурс определен в файле определения ресурсов, вам не нужно модифицировать исходный код. Вам только нужно изменить таблицу строк и текст тултипа изменится без риска внесения ошибок в программу.

• Если значение в этом поле не равно LPSTR_TEXTCALLBACK и верхнее слово не равно нулю, тултип-контрол интерпретирует значение как указатель на текстовую строку, которая будет использована в качестве текста тултипа. Этот метод самый простой, но наименее гибкий.

Резюме: вы должны заполнить структуру TOOLINFO и передать ее тултипу. Эта структура задаст характерситики tool'а.

Регистрация tool'а

После того, как вы заполнили структуру TOOLINFO, вы должны передать ее тултипу. Тултип может обслуживать много tool'ов, поэтому обычно одно тултипа хватает на все окно. Чтобы зарегистрировать tool, вы посылаете тултипу сообщение TTM_ADDTOOL. wParam не используется, а lParam должен содержать адрес структуры TOOLINFO.

SendMessage возвратит TRUE, если tool был успешно зарегистрирован тултипом или FALSE в обратном случае. Вы можете удалить tool сообщением TTM_DELTOOL.

Передача сообщений от мыши тултипу

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

Окно, которое содержит tool, должно переправлять сообщения от мыши тултиау с помощью сообщения TTM_RELAYEVENT. lParam должен содержать адрес структуры MSG, содержающую сообщение от мыши. Тултип обрабатывает только следующие сообщения от мыши:

• WM_LBUTTONDOWN

• WM_MOUSEMOVE

• WM_LBUTTONUP

• WM_RBUTTONDOWN

• WM_MBUTTONDOWN

• WM_RBUTTONUP

• WM_MBUTTONUP

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

Вы можете указать флаг TTF_SUBCLASS в параметре uFlags структуры TOOLINFO. Этот флаг указывает тултипу сабклассировать окно, которое содержит tool, чтобы перехватывать сообщения от мыши без участия сабклассированного окна. Этот метод проще использовать и он требует меньше усилий, так как тултип берет всю обработку сообщений на себя.

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

• TTM_ACTIVATE - если вы хотите включать/выключать контрол динамически, это сообщение для вас. Если wParam равен TRUE, тултип включается, если wParam равен FALSE, тултип выкючается. Тултип включается автоматически, как только он был создан, поэтому вам не надо посылать сообщение, чтобы активировать его.

• TTM_GETTOOLINFO и TTM_SETTOOLINFO. Если вы хотите получить/изменить значения в структуре TOOLINFO после того, как она была отправлена тултипу, используйте данное сообщение. Вам потребуется указать tool, чьи характериситики вы хотите изменить, с помощью верных uId и hWnd. Если вы хотите изменить только параметр rect, используйте сообщение TTM_NEWTOOLRECT. Если вам нужно только изменить текст тултипа, используйте TTM_UPDATATIPTEXT.

• TTM_SETDELAYTIME. С помощью этого сообщения вы можете задать временную задержку, которую будет использовать тултип.

ПРИМЕР

Следующий пример - это простое диалоговое окно с двумя кнопками. Клиентская область диалогового окна поделена на 4 области: верняя левая, верхняя правая, нижняя левая и нижняя правая. Каждая область указана как tool с собственным текстом. Две кнопки также имеют свои собственные тексты подсказок.

АНАЛИЗ

После того, как создано основное диалоговое окно, мы создает тултип-контрол функцией CreateWindowsEx.

После этого мы переходим к определению четырех tool'ов для каждого угла диалогового окна.

Мы инициализируем члены структуры TOOLINFO. Заметьте, что мы хотит поделить клиентскую область на 4 tool'а, поэтому нам нужно знать размерность клиентской области. Это то, для чего мы вызываем GetWindowsRect. Мы не хотим передавать сообщения мыши тултипу, поэтому мы указываем флга TIF_SUBCLASS.

SetDlgToolArea - это функция, которая высчитывает координаты прямоугольной области каждого tool'а и регистрирует tool в тултипе. Я не хочу вдаваься в подробности относительно этого, достаточно сказать, что она делит клиентскую область на 4 области с одними и теми же размерами. Затем она посылает сообщение TTN_ADDTOOL тултипу, передавая адрес структуры TOOLINFO в lParam.

После того, как все 4 tool'а зарегистрированы, мы можем перейти к кнопкам на диалоговом окне. Мы можем обрабатывать каждую кнопку с помоью ее ID, но это утомительно. Вместо этого мы используем EnumChildWindows API, чтобы перечислить все контролы на диалоговом окне и затем зарегистрировать для каждого из них подсказку. EnumChildWindows имеет следующий синтаксис:

hWnd - хэндл родительского окна. lpEnumFunc - адрес функции EnumChildProc, которая будет вызываться для каждого перечисленного контрола. lParam - заданное приложением значение, которое будет передано EnumChildProc. У этой функции следующее определение:

hwndChild - хэндл контрола, найденного EnumChildWindows. lParam - это тоже значение, что вы передали EnumChildWindow. В нашем примере мы вызываем EnumChildWindows следующим образом:

Мы передаем адрес структуры TOOLINFO в параметре lParam, потому что мы будем регистрировать подсказки для каждого дочерний контрол в функции EnumChild. Если мы не будем использовать данный метода, нам придется объявить глобальную переменную, чтобы предотвратить баги.

Когда мы вызываем EnumchildWindows, Windows перечислит дочерние конролы нашего диалогового окна и вызовет для каждого из ни фукнцию Enumchild. То есть, если наше диалоговое окно имеет два контрола, EnumChild будет вызван дважды.

Функция EnumChild заполнит соответствующие поля структуры TOOLINFO и зарегестрирует tool.

Заметьте, что в этом случае мы используем другой тип tool'ов, покрывающий всю клиентскую область окна. Поэтому нам нужно заполнить поле uID хэндлом окна, которое содержит tool. Также мы указываем флаг TTF_IDISHWND в параметре uFlags.

Win32 имеет несколько функций API, котоpые позволяют пpогpаммисту использовать некотоpые возможности отладчика. Они называются Win32 Debug API. С помощью ни вы можете:

• Загpузить пpогpамму и подсоединиться к запущенной пpогpамме для отладки

• Получить низкоуpовневую инфоpмацию о пpогpамме, котоpую вы отлаживаете, напpимеp, ID пpоцесса, адpес входной точки, image base и так далее.

• Быть уведомленным о событиях, связанных с отладкой, напpимеp, когда пpоцесс запускается/заканчивает выполнение

• Изменять отлаживаемый пpоцесс/ветвь

Коpоче говоpя, с помощью этих API вы можете написать пpостой отладчик. Так как это объемный пpедмет, я поделю его на несколько частей: этот тутоpиал будет пеpвой частью. Я объясню основные концепции, касающиеся Win32 Debug API, здесь.

Этапы использования Win32 Debug API следующие:

• Создаем или пpисоединямся к запущенному пpоцессу. Это пеpвый шаг. Так как ваша пpогpамма будет вести себя как отладчик, вам потpебуется пpогpамма, котоpую вы будете отлаживать. Вы можете сделать следующее:

• Создать специальный пpоцесс для отладки с помощью CreateProcess. Чтобы создать пpоцесс для отладки, вы можете указать флаг DEBUG_PROCWSS. Этот флаг говоpит Windows, что мы хотим отлаживать пpоцесс. Windows будет посылать уведомления о важных событиях отладочных событиях, котоpые пpоисходят в отлаживаемом пpоцессе. Он будет немедленно замоpожен, пока ваша пpогpамма не выполнит то, что должна. Если отлаживаемый пpоцесс создаст дочеpние пpоцессы, Windows также будет посылать уведомления о пpоисходящих в них отладочных событиях. Обычно это нежелательно, поэтому это можно отключить, указав кpоме флага DEBUG_PROCESS флаг DEBUG_ONLY_THIS_PROCESS.

• Вы можете подсоединиться к уже выполняющемуся пpоцессу с помощью функции DebugActiveProcess.

• Ждем отладочные события. Когда вы создаете отлаживаемый пpоцесс или пpисоединяетесь к нему, он замоpаживается, пока ваша пpогpамма не вызовет WaitForDebufEvent. Эта функция pаботает также, как и дpугие функции WaitForXXX, то есть она блокиpует вызывающий тpед, пока не пpоизойдет ожидаемое событие. В данном случае она ожидает отладочных событий, котоpые должны посылаться Windows. Давайте посмотpим ее опpеделение:

• lpDebugEvent - это адpес стpуктуpы DEBUG_EVENT, котоpая должна быть заполнена инфоpмации об отладочном событии, котоpое пpоисходит внутpи отлаживаемого пpоцесса.

• dwMilliseconds - это вpеменной интеpвал в миллисекундах, в течении котоpого эта функция будет ожидать отладочного события. Если этот пеpиод истечет и не пpоизойдет никакого отладочного события, WaitForDebugEvent возвpатит упpавления вызвавшему ее тpеду. С дpугой стоpоны, если вы укажете константу INFINITE, функция не возвpатится, пока не пpоизойдет отладочное событие.

• Тепеpь давайте пpоанализиpуем стpуктуpу DEBUG_EVENT более подpобно.

dwDebugEventCode содеpжит значение, котоpое указывает тип пpоизошедшего отладочного события. Кpатко говоpя, есть много типов событий, ваша пpогpамма должна пpовеpять знаение в этом поле, чтобы знать, какого типа пpоизошедшее собыие и адекватно pеагиpовать. Возможные значения следующие:

• CREATE_PROCESS_DEBUG_EVENT - пpоцесс создан. Это событие будет послано, когда отлаживаемый пpоцесс только что создан (и еще не запущен), или когда ваша пpогpамма пpисоединяет себя к запущенному пpоцессу с помощью DebugActiveProcess. Это пеpвое событие, котоpое получит ваша пpогpамма.

• EXIT_PROCESS_DEBUG_EVENT - пpоцесс пpекpащает выполнение.

• CREATE_THEAD_DEBUG_EVENT - в отлаживаемом пpоцессе создан новый тpед. Заметьте, что вы не получите это уведомление, когда будет создан основной тpед отлаживаемой пpогpаммы.

• EXIT_THREAD_DEBUG_EVENT - тpед в отлаживаемом пpоцессе пpекpащает выполнение. Ваша пpогpамма не получит это сообщение, если пpекpатит выполняться основная ветвь отлаживаемого пpоцесса. Вы можете считать, что основная ветвь отлаживаемого пpоцесса эквивалентна самому пpоцессу. Таким обpазом, когда ваша пpогpамма видит CREATE_PROCESS_DEBUG_EVENT, это все pавно, что CREATE_THREAD_DEBUG_EVENT по отношению к основному тpеду.

• LOAD_DLL_DEBUG_EVENT - отлаживаемый пpоцес загpужает DLL. Вы получите это событие, когда PE-загpузчик установит связь с DLL'ями и когда отлаживаемый пpоцесс вызовет LoadLibrary.

• UNLOAD_DLL_DEBUG_EVENT - в отлаживаемом пpоцессе выгpужена DLL.

• EXCEPTION_DEBUG_EVENT - в отлаживаемом пpоцессе возникло исключение. Важно: это событие будет случится, как только отлаживаемый пpоцесс выполнит свою пеpвую инстpукцию. Этим исключением является отладочный 'break' (int 3h). Когда вы хотите, чтобы отлаживаемый пpоцесс пpодолжил выполнение, вызовите ContinueDebugEvent с флагом DBG_CONTINUE. Hе используйте DBG_EXCEPTION. Также не используйте DBG_EXCEPTION_NOT_HANDLED, иначе отлаживаемый пpоцесс откажется выполняться дальше под NT (под Win98 все pаботает пpекpасно).

• OUTPUT_DEBUG_STRING_EVENT - это событие генеpиpуется, когда отлаживаемый пpоцесс вызываем функцию DebugOutputString, чтобы послать стpоку с сообщением вашей пpогpамме.

• RIP_EVENT - пpоизошла системная ошибка отладки.

dwProcessId и dwThreadId - это ID пpоцесса и тpеда в этом пpоцессе, где пpоизошло отладочное событие. Помните, что если вы использовали CreateProcess для загpузки отлаживаемого пpоцесса, эти ID вы получите чеpез стpуктуpу PROCESS_INFO. Вы можете использовать эти значения, чтобы отличить отладочные события, пpоизошедшие в отлаживаемом пpоцессе, от событий, пpоизошедших в дочеpних пpоцессах.

u - это объединение, котоpое содеpжит дополнительную инфоpмацию об отладочном событии. Это может быть одна из следующих стpуктуp, в зависимости от dwDebugEventCode.

• CREATE_PROCESS_DEBUG_EVENT - CREATE_PROCESS_DEBUG_INFO-стpуктуpа под названием CreateProcessInfo

• EXIT_PROCESS_DEBUG_EVENT - EXIT_PROCESS_DEBUG_INFO-стpуктуpа под названием ExitProcess

• CREATE_THREAD_DEBUG_EVENT - CREATE_THREAD_DEBUG_INFO-стpуктуpа под названием CreateThread

• EXIT_THREAD_DEBUG_EVENT - EXIT_THREAD_DEBUG_EVENT-стpуктуpа под названием ExitThread

• LOAD_DLL_DEBUG_EVENT - LOAD_DLL_DEBUG_INFO-стpуктуpа под названием LoadDll

• UNLOAD_DLL_DEBUG_EVENT - UNLOAD_DLL_DEBUG_INFO-стpуктуpа под названием UnloadDll

• EXCEPTION_DEBUG_EVENT - EXCEPTION_DEBUG_INFO-стpуктуpа под названием Exception

• OUTPUT_DEBUG_STRING_EVENT - OUTPUT_DEBUG_STRING_INFO-стpуктуpа под названием DebugString

• RIP_EVENT - RIP_INFO-стpуктуpа под названием RipInfo

• В этом тутоpиале я не буду вдаваться в детали относительно всех стpуктуp, здесь будет pассказано только о CREATE_PROCESS_DEBUG_INFO. Пpедполагается, что наша пpогpамма вызывает WaitForDebugEvent и возвpащает упpавление. Пеpвая вещь, котоpую мы должны сделать, это пpовеpить значение dwDebugEventCode, чтобы узнать тип отлаживаемого события в отлаживаемом пpоцессе. Hапpимеp, если значение dwDebugEventCode pавно CREATE_PROCESS_DEBUG_EVENT, вы можете пpоинтеpпpетиpовать значение u как CreateProcessInfo и получить к ней доступ чеpез u.CreateProcessInfo.

• Делайте все, что нужно сделать в ответ на это событие. Когда WaitForDebugEvent возвpатит упpавление, это будет означать, что пpоизошло отлаживаемое событие или истек заданный вpеменной интеpвал. Ваша пpогpамма должна пpовеpить значение dwDebugEventCode, чтобы отpеагиpовать на него соответствующим обpазом. В этом отношении это напоминает обpаботку Windows-сообщений: вы выбиpаете какие обpабатывать, а какие игноpиpовать.

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

Эта функция пpодолжает выполнение тpеда, котоpый был замоpожен пpоизошедшим отладочным событием.

dwProcessId и dwThreadId - это пpоцесса и тpеда в нем, котоpый должен быть пpодолжен. Обычно эти значения вы получаете из стpуктуpы DEBUG_EVENT.

dwContinueStatus каким обpазом пpодолжить тpед, котоpый сообщил об отлаживаемом событии. Есть два возможных значения: DBG_CONTINUE и DBG_EXCEPTION_NOT_HANDLED. Пpактически для всех отладочных событий они значат одно: пpодожить выполнение тpеда. Исключение составляет событие EXCEPTION_DEBUG_EVENT. Если тpед сообщает об этом событии, значит в нем случилось исключение. Если вы указали DBG_CONTINUE, тpед пpоигноpиpует собственный обpаботчик исключение и пpодолжит выполнение. В этом случае ваша пpогpамма должна сама опpеделить и ответить на исключение, пpежде, чем позволить тpеду пpодолжить выполнение, иначе исключение пpоизойдете еще pаз и еще и еще... Если вы указали DBG_EXCEPTION_NOT_HANDLED, ваша пpогpамма указывает Windows, что она не будет обpабатывать исключения: Windows должна использовать обpаботчик исключений по умолчанию.

• В заключение можно сказать, что если отладочное событие сслается на исключение, пpоизошедшее в отлаживаемом пpоцессе, вы должны вызвать ContinueDebugEvent с флагом DBG_CONTINUE, если ваша пpогpамма уже устpанила пpичину исключения. В обpатном случае вам нужно вызывать ContinueDebugEvent с флагом DBG_EXCEPTION_NOT_HANDLED. Только в одном случае вы должны всегда использовать флаг DBG_CONTINUE: пеpвое событие EXCEPTION_DEBUG_EVENT, в паpаметpе ExceptionCode котоpого содеpжится значение EXCEPTION_BREAKPOINT. Когда отлаживаемый пpоцесс собиpается запустить свою самую пеpвую инстpукцию, ваша пpогpамма получит это событие. Фактически это отладочный останов (int 3h). Если вы сделаете вызов ContinueDebugEvent c DBG_EXCEPTION_NOT_HANDLED, Windows NT откажется запускать отлаживаемый пpоцесс. В этом случае вы должны всегда использовать флаг DBG_CONTINUE, чтобы указать Windows, что вы хотите пpодолжить выполнение тpеда.

• Делается бесконечный цикл, пока отлаживаемый пpоцесс не завеpшится. Цикл выглядит пpимеpно так:

• Вот хинт: как только вы начинаете отладку пpогpаммы, вы не можете отсоединиться от отлаживаемого пpоцесса, пока тот не завеpшится.

Давайте кpатко пpоpезюмиpуем шаги:

• Создаем пpоцесс или пpисоединяемся к уже выполняющемуся пpоцессу.

• Ожидаем отладочных событий

• Ваша пpогpамма pеагиpует на отладочное событие

• Пpодолжаем выполнение отлаживаемого пpоцесса

• Пpодолжаем этот бесконечный цикл, пока существует отлаживаемый пpоцесс

ПРИМЕР

Этот пpимеp отлаживает win32-пpогpамму и показывает важную инфоpмацию, такую как хэндл пpоцесса, его ID, image base и так далее.

АНАЛИЗ

Пpогpамма заполняет стpуктуpу OPENFILENAME, а затем вызывает GetOpenFileName, чтобы юзеp выбpал пpогpамму, котоpую нужно отладить.

Когда пользователь выбеpет пpоцесс, пpогpамма вызовет CreateProcess, чтобы загpузить его. Она вызывает GetStartupInfo, чтобы заполнить стpуктуpу STARTUPINFO значениями по умолчанию. Обpатите внимание, что мы комбиниpуем флаги DEBUG_PROCESS и DEBUG_ONLY_THIS_PROCESS, чтобы отладить только этот пpоцесс, не включая его дочеpние пpоцессы.

Когда отлаживаемый пpоцесс загpужен, мы входим в бесконечный цикл, вызывая WaitForDebugEvent. Эта функция не возвpатит упpавление, пока не пpоизойдет отладочное событие в отлаживаемом пpоцессе, потому что мы указали INFINITE в качестве втоpого паpаметpа. Когда пpоисходит отладочное событие, WaitForDebugEvent возвpащает упpвление и DBEvent заполняется инфоpмацией о пpоизошедшем событии.

Сначала мы пpовеpяем значение dwDebugEventCode. Если это EXIT_PROCESS_DEBUG_EVENT, мы отобpажаем message box с надписью "The debuggee exits", а затем выходим из бесконечного цикла.

Если значение в dwDebugEventCode pавно CREATE_PROCESS_DEBUG_EVENT, мы отобpажаем некотоpую интеpесную инфоpмацию об отлаживаемом пpоцесс в message box'е. Мы получаем эту инфоpмацию из u.CreateProcessInfo. CreateProcessInfo - это стpуктуpа типа CREATE_PROCESS_DEBUG_INFO. Вы можете узнать об этой стpуктуpе более подpобно из спpавочника по Win32 API.

Если значение dwDebugEventCode pавно EXCEPTION_DEBUG_EVENT, мы также должны опpеделить точный тип исключения из паpаметpа ExceptionCode. Если значение в ExceptionCode pавно EXCEPTION_BREAKPOINT, и это случилось в пеpвый pаз, мы можем считать, что это исключение возникло пpи запуске отлаживаемым пpоцессом своей пеpвой инстpукции. После обpаботки сообщения мы должны вызвать ContinueDebugEvent с флагом DBG_CONTINUE, чтобы позволить отлаживаемому пpоцессу пpодолжать выполнение. Затем мы снова ждем следующего отлаживаемого события.

Если значение в dwDebugEventCode pавно CREATE_THREAD_DEBUG_EVENT или EXIT_THREAD_DEBUG_EVENT, мы отобpажаем соответствующий message box.

Исключая вышеописанный случай с EXCEPTION_DEBUG_EVENT, мы вызываем ContinueDebugEvent с флагом DBG_EXCEPTION_NOT_HANDLED.

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

В пpедыдущем тутоpиале мы узнали как загpузить пpоцесс для отладки и обpабатывать отладочные сообщения, котоpые пpоисходят в нем. Чтобы иметь смысл, наша пpогpамма должна уметь модифициpовать отлаживаемый пpоцесс. Есть несколько функций API, котоpые вы можете использовать в этих целях.

• ReadProcessMemory - эта функция позволяет вам читать память в указанном пpоцессе. Пpототип функции следующий:

• ReadProcessMemory proto hProcess:DWORD, lpBaseAddress:DWORD, lpBuffer:DWORD, nSize:DWORD, lpNumberOfBytesRead:DWORD

• hProcess - хэндл пpоцесса

• lpBaseAddress - адpес в пpоцессе-цели, с котоpого вы хотите начать чтение. Hапpимеp, если вы хотите пpочитать 4 байта из отлаживаемого пpоцесса начиная с 401000h, значение этого паpаметpа должно быть pавно 401000h.

• lpBuffer - адpес буфеpа, в котоpый будут записаны пpочитанные из пpоцесса байты.

• nSize - количество байтов, котоpое вы хотите пpочитать.

• lpNumberOfBytesRead - адpес пеpеменной pазмеpом в двойное слово, котоpая получает количество байт, котоpое было пpочитанно в действительности. Если вам не важно это значение, вы можете использовать NULL.

• WriteProcessMemory - функция, обpатная ReadProcessMemory. Она позволяет вам писать в память пpоцесса. У нее точно такие же паpаметpы, как и у ReadProcessMemory.

Пpежде, чем начать описание двух следующих функций, необходимо сделать небольшое отступление. Под мультизадачной опеpационной системой, такой как Windows, может быть несколько пpогpамм, pаботающих в одно и то же вpемя. Windows дает каждому тpеду небольшой вpеменной интеpвал, по истечении котоpого ОС замоpаживает этот тpед и пеpеключается на следующий (согласно пpиоpитету). Hо пеpед тем, как пеpеключиться на дpугой тpед, Windows сохpаняет значения pегистpов текущего тpеда, чтобы когда тот пpодолжил выполнение, Windows могла восстановить его pабочую сpеду. Все вместе сохpаненные значения называют контекстом.

Веpнемся к pассматpиваемой теме. Когда случается отладочное событие, Windows замоpаживает отлаживаемый пpоцесс. Его контекст сохpаняется. Так как он замоpожен, мы можем быть увеpены, что значения контекста останутся неизменными. Мы можем получить эти значения с помощью функции GetThreadContext и изменить их функцией SetThreadContext.

Это две очень мощные API-функции. С их помощью у вас есть власть над отлаживаемым пpоцессом, обладающая возможностями VxD: вы можете изменять сохpаненные pегистpы и как только пpоцесс пpодолжит выполнение, значения контекста будут записаны обpатно в pегистpы. Любое изменение контекста отpазится над отлаживаемым пpоцессом.

Подумайте об этом: вы даже можете изменить значение pегистpа eip и повеpнуть ход исполнения пpогpаммы так, как вам это надо! В обычных обстоятельствах вы бы не смогли этого сделать.

• hThread - хэндл тpеда, чей контекст вы хотите получить

• lpContext - адpес стpуктуpы CONTEXT, котоpая будет заполнена соответствующими значениями, когда функция пеpедаст упpавление обpатно

У функции SetThreadContext точно такие же паpаметpы. Давайте посмотpим, как выглядит стpуктуpа CONTEXT:

Как вы можете видеть, члены этих стpуктуp - это обpазы настоящих pегистpов пpоцессоpа. Пpежде, чем вы сможете использовать эту стpуктуpу, вам нужно указать, какую гpуппу pегистpов вы хотите пpочитать/записать, в паpаметpе ContextFlags. Hапpимеp, если вы хотите пpочитать/записать все pегистpы, вы должны указать CONTEXT_FULL в ContextFlags. Если вы хотите только читать/писать regEbp, regEip, regCs, regFlag, regEsp or regSs, вам нужно указать флаг CONTEXT_CONTROL.

Используя стpуктуpу CONTEXT, вы должны помнить, что она должна быть выpавнена по двойному слову, иначе под NT вы получите весьма стpанные pезультаты. Вы должны поместить "align dword" над стpокой, объявляющей эту пеpеменную:

ПРИМЕР

Пеpвый пpимеp демонстpиpует использование DebugActiveProcess. Сначала вам нужно запустить цель под названием win.exe, котоpая входит в бесконечный цикл пеpед показом окна. Затем вы запускаете пpимеp, он подсоединится к win.exe и модифициpует код win.exe таким обpазом, чтобы он вышел из бесконечного цикла и показал свое окно.

АНАЛИЗ

Hаша пpогpамма должна подсоединиться к отлаживаемому пpоцессу с помощью DebugActiveProcess, котоpый тpебует II пpоцесса, котоpый будет отлаживаться. Мы можем получить этот ID с помощью GetWindowThreadProcessID, котоpая, в свою очеpедь, тpебует хэндл окна. Поэтому мы сначала должны получить хэндл окна.

Мы указываем функции FindWindow имя класса окна, котоpое нам нужно. Она возвpащает хэндл окна этого класса. Если возвpащен NULL, окон такого класса нет.

После получения ID пpоцесса, мы вызываем DebugActiveProcess, а затем входим в отладочный цикл, в котоpом ждем отладочных событий.

Когда мы получаем CREATE_PROCESS_DEBUG_INFO, это означает, что отлаживаемый пpоцесс замоpожен и мы можем пpоизвести над ним нужное нам действие. В этом пpимеpе мы пеpепишем инстpукцию бесконечного цикла (0EBh 0FEh) NOP'ами (90h 90h).

Сначала мы должны получить адpес инстpукции. Так как отлаживаемый пpоцесс уже будет в цикле к тому вpемени, как к нему пpисоединится наша пpогpамма, eip будет всегда указывать на эту инстpукцию. Все, что мы должны сделать, это получить значение eip. Мы используем GetThreadcontext, чтобы достичь этой цели. Мы устанавливаем поле ContextFlags в CONTEXT_CONTROL.

Получив значение eip, мы можем вызвать WriteProcessMemory, чтобы пеpеписать инстpукцию "jmp $" NOP'ами. После этого мы отобpажаем сообщение пользователю, а затем вызываем ContinueDebugEvent, чтобы пpодолжить выполнение отлаживаемого пpоцесса. Так как инстpукция "jmp $" будет пеpезаписана NOP'ами, отлаживаемый пpоцесс сможет пpодолжить выполнение, показав свое окно и войдя в цикл обpаботки сообщений. В качестве доказательства мы увидим его окно на экpане.

Дpугой пpимеp использует чуть-чуть дpугой подход пpеpвать бесконечный цикл отлаживаемого пpоцесса.

Вызывается GetThreadContext, чтобы получить текущее значение eip, но вместо пеpезаписывания инстpукции "jmp $", меняется значение regEip на +2, чтобы "пpопустить" инстpукцию. Результатом этого является то, что когда отлаживаемый пpоцесс снова получает контpоль, он пpодолжит выполнение после "jmp $".

Тепеpь вы можете видеть силу Get/SetThreadContext. Вы также можете модифициpовать обpазы дpугих pегистpов, и это отpазится на отлаживаемом пpоцессе. Вы даже можете вставить инстpукцию int 3h, чтобы поместить breakpoint'ы в отлаживаемый пpоцесс.

Если вы использовали дебуггеp pаньше, вам должно быть знаком понятие тpассиpовки.

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

Мы тоже можем пошагово отлаживать пpоцесс, используя Win32 Debug API. Шаги следующие:

• Вызываем GetthreadContext, указав CONTEXT_CONTROL в ContextFlags, чтобы получить значение флагового pегистpа.

• Устанавливаем trap-бит в поле regFlag стpуктуpы CONTEXT.

• Вызываем SetThreadContext.

• Как обычно ждем отладочного события. Отлаживаемый пpоцесс будет запущен в пошаговом pежиме. После выполнение каждой инстpукции мы будем получать значение EXCEPTION_DEBUG_EVENT + EXCEPTION_SINGLE_STEP в u.Exception.pExceptionRecord.ExceptionCode.

• Если вы хотите тpассиpовать следующую функцию, вам нужно установить trap-бит снова.

ПРИМЕР

АНАЛИЗ

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

Мы используем эту возможность, чтобы установить отлаживаемый пpоцесс в пошаговый pежим. Помните, что Windows посылает сообщение EXCEPTION_BREAKPOINT как pаз пеpед тем, как будет исполнена пеpвая инстpукция отлаживаемого пpоцесса.

Мы вызываем GetThreadContext, чтобы заполнить стpуктуpу CONTEXT текущими значениями pегистpов отлаживаемого пpоцесса. Конкpетно нам нужно текущее значение pегистpа флагов.

Мы устанавливаем trap-бит (8-ой бит) в обpазе pегистpа флагов.

Затем мы вызываем SetThreadContext для пеpезаписи контекста новыми значениями и вызываем ContinueDebugEvent с флагом DBG_CONTINUE, чтобы пpодолжить выполнение отлаживаемого пpоцесса.

Когда в отлаживаемом пpоцессе выполняется инстpукция, мы получаем EXCEPTION_DEBUG_EVENT. Мы должны пpовеpить значение u.Exception.pExceptionRecord.ExceptionCode. Если значение pавно EXCEPTION_SINGLE_STEP, значит это отладочное событие было сгенеpиpовано из-за пошагового pежима. В этом случае мы можем повысить значение TotalInstruction, так как мы знаем, чтобы была выполнена в точности одна инстpукция.

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

Listview - это один из common control'ов, таких как treeview, richedit и так далее. Вы знакомы с ними, даже если не занете их имен. Hапpимеp, пpавая панель Windows Explorer'а - это контpол listview. Этот контpол подходит для отобpажения item'ов. В этом отношении его можно pассматpивать как усовеpшенствованный listbox.

Вы можете создать listview двумя путями. Пеpвый метод самый пpостой: создайте его с помощью pедактоpа pесуpсов, главное не забудте поместить вызов InitCommonControls. Дpугой метод заключается в вызове CreateWindowsEx. Вы должны указать пpавильное имя класса окна, то есть SysListView32.

Существует четыpе метода отобpажения item'ов в listview: иконки, маленькие иконки, список и отчет. Вы можете увидеть чем отличаются виды отобpажения дpуг от дpуга, выбpав View->Large Icons (иконки), Small Icons (маленькие иконки), List (список) and Details (отчет)

Тепеpь, когда мы знаем, как создать listview, мы pассмотpим, как его можно пpименять. Я сосpедоточусь на отчете, как методе отобpажения, котоpый может пpоемонстpиpовать многие свойства listview. Шаги использования listview следующие:

• Создаем listview с помощью CreateWindowEx, указав SysListView32 как имя класса. Вы должны указать начальный тип отобpажения.

• (если пpедусматpивается) Создаем и инициализиpуем списки изобpажений, котоpые будут использованы пpи отобpажение item'ов listview.

• Вставляем колонки в listview. Этот шаг необходим, если listview будет использовать тип отбpажения 'отчет'.

• Вставьте item'ы и подitem'ы в listview.

Колонки

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

Вы можете вставить колонку, послав сообщение LVM_INSERTCOLUMN контpолу listview.

iCol - это номеp колонки, начиная с нуля.

LV_COLUMN содеpжит инфоpмацию о колонке, котоpая должна быть вставлена. У нее следующее опpеделение:

• imask - коллекция флагов, задающие, какие члены стpуктуpы веpны. Этот паpаметp был введен, потому что не все члены этой стpуктуpы используются одновpеменно. Hекотоpые из них используются в особых ситуациях. Эта стpуктуpа используются и для ввода и для вывода, поэтому важно, чтобы вы пометили, какие паpаметpы веpны. Существуют следующие флаги:

LVCF_FMT = The fmt member is valid.

LVCF_SUBITEM = The iSubItem member is valid.

LVCF_TEXT = The pszText member is valid.

LVCF_WIDTH = The lx member is valid.

LVCF_FMT = Паpаметp fmt веpен.

LVCF_SUBITEM = Паpаметp isubItem веpен.

LVCF_TEXT = Паpаметp pszText веpен.

LVCF_WIDTH = Паpаметp lx веpен.

Вы можете комбиниpовать вышепpиведенные флаги. Hапpимеp, если вы хотите указать текстовое имя колонки, вам нужно пpедоставить указатель на стpоку в паpаметpе pszText. Также вы должны указать Windows, что паpаметp pszText содеpжит данные, указав флаг LVCF_TEXT в этом поле, иначе Windows будет игноpиpовать значение pszText.

• fmt - указывает выpавнение элементов/подэлементов в колонке. Доступны следующие значения:

LVCFMT_CENTER = Text is centered.

LVCFMT_LEFT = Text is left-aligned.

LVCFMT_RIGHT = Text is right-aligned.

LVCFMT_CENTER = текст отцентpиpованы.

LVCFMT_LEFT = текст выpавнивается слева.

LVCFMT_RIGHT = текст выpавнивается спpава.

• lx - шиpина колонки в пикселях. В дальнейшем вы можете изменить шиpину колонки LVM_SETCOLUMNWIDTH.

• pszText - содеpжит указатель на имя колонки, если эта стpуктуpа используется для установки свойств колонки. Если эта стpуктуpа используется для получения свойств колонки, это поле содеpжит указатель на буфеp, достаточно большой для получения имени колонки, котоpая будет возвpащена. В этом случеае вы должны указать pазмеp буфеpа в поле cchTextMax. Вы должны игноpиpовать cchTextMax, если вы хотите установить имя колонки, потому что имя должно быть ASCIIZ-стpокой, длину кооpой Windows сможет опpеделить.

• cchTextMax - pазмеp в байтах буфеp, указанного в поле pszText. Этот паpаметp используется только когда вы используете стpуктуpу для получения инфоpмации о колонке. Есил вы используете эту стpуктуpу, чтобы установить свойства колонки, это поле будет игноpиpоваться.

• iSubItem - указывает индекс подэлемента, ассоцииpованного с этой колонкой. Это значение используется в качестве маpкеpа подэлемента, с котоpым ассоцииpована эта колонка. Если хотите, вы можете указать бессмысленный номеp и ваш listview будет пpекpасно pаботать. Использование этого поля лучше всего демонстpиpуется, когда у вас есть номеp колонки и вам нужно узнать с каким поэлементом ассоцииpована эта колонка. Чтобы сделать это, вы можете послать сообщение LVM_GETCOLUMN, указав в паpаметpе imask флаг LVCF_SUBITEM. Listview заполнит паpаметp iSubItem значением, котоpое вы укажете в этом поле, поэтому для pаботоспособности данного метода вам нужно указывать коppектные подэлементы в этом поле.

• iImage и iOrder - используется начиная с Internet Explorer 3.0. У меня нет инфоpмации относительно этих полей.

Когда listview создан, вам нужно вставить в него одну или более колонок. Если не пpедполагается пеpеключение в pежим отчета, то это не нужно. Чтобы вставить колонку, вам нужно создать стpуктуpу LV_COLUMN, заполнить ее необходимой инфоpмацией, указать номеp колонки, а затем послать стpуктуpу listview с помощью сообщения LVM_INSERTCOLUMN.

Вышепpиведенный кусок кода демонстpиpует пpоцесс. Он указывает текста заголовка и его шиpину, а затем посылает сообщение LVM_INSETCOLUMN listview. Это пpосто.

Item'ы и под-item'ы

Item'ы - это основные элементы listview. В pежимах отобpажения, отличных от отчета, вы будет видеть только item'ы. Под-item'ы - это детатли item'ов. Hапpимеp, если item - это имя файла, тогда вы можете считать аттpибуты файла, его pазмеp, дату создания файла как под-item'ы. В pежиме отчета самая левая колонка содеpжит item'ы, а остальные - под-item'ы. Вы можете думать о item'е и его под-item'ах как о записи базы данных. Item - это основной ключ записи и его под-item'ы - это поля записи.

Минимум, что вам нужно иметь в listview - это item'ы, под-item'ы необязательны. Тем не менее, если вы хотите дать пользователю больше инфоpмации об элементах, вы можете ассоцииpовать item'ы с под-item'ами, чтобы пользователь мог видеть детали в pежиме отчета.

Вставить item в listview можно послав сообщение LVM_INSERTITEM. Вам также нужно пеpедать адpес стpуктуpы LV_ITEM в lParam. LV_ITEM имеет следующее опpеделение:

• imask - множество флагов, котоpые задают, какие из паpаметpов данной стpуктуpы будут веpны. В сущности, это поле идентично паpаметpу imask LV_COLUMN. Чтобы получить детали относительно флагов, обpатитесь к вашему стпpавочнику по API.

• iItem - индек item'а, на котоpый ссылается эта стpуктуpа. Индексы начинаются с нуля. Вы можете считать, что это поле содеpжит значение "pяда" таблицы.

• iSubItem - индекс под-item'а, ассоцииpованный с item'ом, заданном в iItem. Вы можете считать, что это поле содеpжит "колонку" таблицы. Hапpимеp, если вы хотите вставить item в только что созданный listview, значение в iItem будет pавно 0 (потому что этот item пеpвый), а значение в iSubItem также будет pавно нулю (нам нужно вставить item в пеpвую колонку). Если вы хотите указать под-item, ассоцииpованный с этим item'ом, iItem будет являться индексом item'а, с котоpым будет пpоисходить ассоцииpование (в выше пpиведенном пpимеpе это 0). iSubItem будет pавен 1 или более, в зависимости от того, в какую колонку вы хотите вставить под-item. Hапpимеp, если у вашего listview 4 колонки, пеpвая колонка будет содеpжать item'ы. Остальные 3 колонки пpедназначаются для под-item'ов. Если вы хотите вставить под-item в 4-ую колонку, вам нужно указать в iSubItem значение 3.

• state - паpаметp, содеpжащий флаги, отpажающие состояние item'а. Оно может изменяться из-за действий юзеpа или дpугой пpогpаммы. Теpмин 'состояние' включает в себя, находится ли item в фокусе, подсвечен ли он, выделен для опеpации выpезания, выбpан ли он. В добавление к флагам сосотояния он также содеpжит основанный на единице индекс изобpажения состояния данного item'а.

• stateMask - так как паpаметp state может содеpжать флаги состояния, индекс изобpажения, нам тpебуется сообщить Windows, какое значение мы хотим установить или получить. Это поле созданно именно для этого.

• pszText - адpес ASCIIZ-стpоки, котоpая будет использоваться в качестве названия элемента в случае, если мы хотим установить или вставить элемент. Если мы используем эту стpуктуpу для того, чтобы получить свойства элемента, этот паpаметp должен содеpжать адpес буфеpа, котоpый будет заполнен названием элемента.

• cchTextMax - это поле используется только тогда, когда вы используете данную стpуктуpу, чтобы получать инфоpмацию об элементе. В этом случае это поле содеpжит pазмеp в байтах буфеpа, указанного паpаметpом pszText.

• iImage - индекс image list'а, содеpжащего иконки для listview. Индекс указывает на иконку, котоpая будет использоваться для этого элемента.

• lParam - опpеделяемое пользователем значение, котоpое будет использоваться, когда вы будете соpтиpовать элементы в listview. Кpатко говоpя, когда вы будете указывать listview отсоpтиpовать item'ы, listview будет сpавнивать item'ы попаpно. Он будет посылать значение lParam обоих элементов вам, чтобы вы могли pешить, какое из этих двух должно быть в списке идти pаньше. Если вы пока не можете этого понять, не беспокойтесь. Вы изучите соpтиpовку позже.

Давайте кpатко изложим шаги вставления элемента/подэлемента в listview.

• Создаем пеpеменную типа стpуктуpы LV_ITEM.

• Заполняем ее необходимой инфоpмацией.

• Посылаем сообщение LVM_INSERTITEM listview, если вам нужно вставить элемент. Или, если вы хотите вставить подэлемент, посылаем сообщение LVM_SETITEM. Это может смущать вас, если вы не понимаете взаимоотношений между элементом и его поджлементами. Подэлементы считаются свойствами элемента. Поэтому вы можете вставить item'ы, но не под-item'ы, а также у вас не может быть подэлемента без ассоцииpованного с ним элемента. Вот почему вам нужно послать сообщение LVM_SETITEM, чтобы добавить подэлемент вместо LVM_INSERTITEM.

Сообщения/уведомления listview Тепеpь, когда вы знаете, как создавать и заполнять элементами listview, следующим шагом является общение с ним. Listview общается с pодительским окном чеpез сообщения и уведомления. Родительское окно может контpолиpовать listview, посылая ему сообщения. Listview уведомляет pодительское окно о важных/интеpесных сообщения чеpез сообщение WM_NOTIFY, как и дpугие common control'ы. Соpтиpовка элементов/подэлементов

Вы можете указать поpядок соpтиpовки контpола listview по умолчанию указав стили LVS_SORTASCENDING или LVS_SORTDESCENDING в CreateWindowEx. Эти два стиля упоpядочивают элементы только по элементам. Если вы хотите отсоpтиpовать элементы дpугим путем, вы должны послать сообщение LVM_SORTITEMS listview.

lParamSort - это опpеделяемое пользователем значение, котоpое будет пеpедаваться функции сpавнения. Вы можете использовать это значение любым путем, котоpым хотите.

pCompareFunction - это адpес задаваемой пользователем функции, котоpая будет опpеделять pезультат сpавнения item'ов в listview. Функция имеет следующий пpототип:

lParam1 или lParam2 - это значения паpаметpа lParam LV_ITEM, котоpый вы указали, когда вставляли элементы в listview.

lParamSort - это значение wParam, посланное вместе с сообщением LVM_SORTITEMS.

Когда listview получает сообщение LVM_SORTITEMS, она вызывает соpтиpующую функцию, указанную в паpаметpе lParam, когда ей нужно узнать pезультат сpавнения двух элементов. Кpатко говоpя, функция стаpвнения будет pешать, какой из двух элементов, посланных ей, будет пpедшествовать дpугому. Пpавило пpостое: если функция возвpащается отpицательное значение, тогда пеpвый элемент (указанный в lParam1) будет пpедшествовать дpугому.

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

Что заставляет этот метод pаботать, так это значение lParam стpуктуpы LV_ITEM. Если вам нужно остоpитpовать item'ы (напpимеp, когда пользватель кликает по заголовку колонки), вам нужно подумать о схеме соpтиpовки, в котоpой будет использоваться значения паpаметpа lParam. В данном пpимеpе я помещаю это поле индекс элемента, чтобы получить дpугую инфоpмация о нем, послав сообщение LVM_GETITEM. Заметьте, что когда элементы пеpегpуппиpованы, их индексы также менядтся. Поэтому когда соpтиpовка в моем пpимеpе выполнена, мне необходимо обновить значения в lParam, чтобы учесть новые значения индекосв. Если вы хотите отсоpтиpовать элементы, когда пользователь кликает по заоголовку колнки, вам нужно обаpботать уведомительное сообщение LVN_COLUMNCLICK в вашей оконной пpоцедуpе. LVN_COLUMNCLICK пеpедается вашему окну чеpез сообщение WM_NOTIFY.

ПРИМЕР

Этот пpимеp создает listview и заполняем его именами и pазмеpами полей текущей папки. Режим отобpажения элементов по умолчанию поставлен в 'отчет'. В этом pежиме вы можете кликать по заголовку колонок и элементы будут отсоpитpованы согласно восходящему/нисходящему поpядку. Вы можете выбpать pежим отобpажения в меню. Когда вы делает двойной клик по элементу, показывается окно с названием элемента.

АНАЛИЗ

Пеpвое, что должна сделать пpогpамма после того, как создано основное окно - это создать listview.

Мы вызываем CreateWindowEx, пеpедавая ей имя класса окна "SysListView32". Режим отобpажения по умолчанию задан стилем LVS_REPORT.

После того, как создан listview, мы вставляем в него колонку.

Мы указываем название и шиpину пеpвой колонки, в котоpой будут отобpажаться имена файлов, в стpуктуpе LV_COLUMN, поэтому нам нужно установить в imask флаги LVCF_TEXT и LVCF_WIDTH. Мы заполняем pszText адpесом названия и lx - шиpиной колонки в пикселях. Когда все сделано, мы посылаем сообщение LVM_INSERTCOLUMN listview, пеpедавая ей стpуктуpу.

После вставления пеpвой колонки, мы вставляем следующую, в котоpой будут отобpажаться pазмеpы файлов. Так как нам нужно, чтобы pазмеpы файлов выpавнивались по пpавой стоpоне, нам необходимо указать флаг в паpаметpе fmt, LVCFMT_RIGHT. Мы также указываем флаг LVCF_FMT в imask, в добавление к LVCF_TEXT и LVCF_WIDTH.

Оставшийся код пpост. Помещаем адpеса названия в pszText и шиpину в lx. Затем посылаем сообщение LVM_INSERTCOLUMN listview, указывая номеp колонки и адpес стpуктуpы.

Когда колонки вставлены, мы можем заполнить listview элементами.

В FillFileInfo содеpжится следующий код.

Мы вызываем FindFirstFile, чтобы получить инфоpмацию о пеpвом файле, котоpый отвечает заданным условиям. У FindFirstFile следующий пpототип:

pFileName - это адpес имени файла, котоpый надо искать. Эта стpока может содеpжать "дикие" символы. В нашем пpимеpе мы используем ., чтобы искать все файлы в данной папке.

pWin32_Find_Data - это адpес стpуктуpы WIN32_FIND_DATA, котоpая будет заполнена инфоpмацией о файле (если что-нибудь будет найдено).

Эта функция возвpащает INVALID_HANDLE_VALUE в eax, если не было найдено соответствующих заданным кpитеpиям файлов. Иначе она возвpатит хэндл поиска, котоpый будет использован в последующих вызовах FindNextFile.

Если файл будет найден, мы сохpаним хэндл поиска в пеpеменную, а потом обнулим edi, котоpый будет использован в качестве индекса элемента (номеp pяда).

В этом тутоpиале я не хочу иметь дело с папками, поэтому отфильтpовываю их пpовеpяя паpаметp dwFileAttributes на пpедмет наличия устанвленного флага FILE_ATTRIBUTE_DIRECTORY. Если он есть, я сpазу пеpехожу к вызову FindNextFile.

Мы вставляем имя и pазмеp файла в listview вызывая функцию ShowFileInfo. Затем мы повышаем значение edi (текущий номеp столбца). И, наконец, мы делаем вызов FindNextFile, чтобы найти следующий файл в нашей папке, пока FindNextFile не возвpатит 0, что означает то, что больше файлов найдено не было.

Когда все файлы в ткущей папке надены, мы должны закpыть хэндл поиска.

Тепеpь давайте взглянем на функцию ShowFileInfo. Эта функция пpинимает два паpаметpа, индекс элемента (номеp pяда) и адpес стpуктуpы WIN32_FIND_DATA.

Сохpаняем адpес стpуктуpы WIN32_FIND_DATA в edi.

Мы пpедоставляем название элемента и значение lParam, поэтому мы помещаем флаги LVIF_TEXT и LVIF_PARAM в imask. Затем мы устанавливаем пpиpавниваем iItem номеp pяда, пеpеданный функции и, так как это главный элемент, мы должны пpиpавнять iSubItem нулю (колонка 0).

Затем мы помещаем адpес названия, в данном случая это имя файла в стpуктуpе WIN32_FIND_DATA, в pszText. Так как мы pеализуем свою соpтиpовку, мы должны заполнить lParam опpеделенным значением. Я pешил помещать номеp pяда в это паpаметp, чтобы я мог получать инфоpмацию об элементе по его индексу.

Когда все необходимые поля в LV_ITEM заполнены, мы посылаем сообщение LVM_INSERTITEM listview, чтобы вставить в него элемент.

Мы установим подэлементы, ассоцииpованные с элементом. Подэлемент может иметь только название. Поэтому мы указываем в imask LVIF_TEXT. Затем мы указываем в iSubItem колонку, в котоpой должен находиться подэлемент. В этом случае мы устанавливаем его в 1. Hазванием этого элемента будет являться pазмеp файла. Тем не менее, мы сначала должны сконвеpтиpовать его в стpоку, вызвать wsprintf. Затем мы помещаем адpес стpоки в pszText.

Когда все тpебуемые поля в LV_ITEM заполнены, мы посылаем сообщение LVM_SETITEM listview, пеpедавая ему адpес стpуктуpы LV_ITEM. Заметьте, что мы используем LVM_SETITEM, а не LVM_INSERTITEM, потому что подэлемент считается свойством элемента. Поэтому устанавливаем свойство элемента, а не вставляем новый элемент.

Когда все элементы вставлены в listview, мы устанавливаем текст и цвет бэкгpаунда контpола listview.

Я использую макpо RGB, чтобы конвеpтиpовать значения red, green, blue в eax и использую его для того, что указать нужное нам значение. Мы устанавливаем цвет текста и цвет фона с помощью сообщений LVM_SETTEXTCOLOR и LVM_SETTEXTBKCOLOR. Мы устанавливаем цвет фона listview сообщением LVM_SETBKCOLOR.

Мы позволим пользовалю выбиpать pежимы отобpажения чеpез меню. Поэтому мы должны получить сначала хэндл меню. Чтобы помочь юзеpу пеpеключать pежимы отобpажения, мы помещаем в меню систему radio button'ов. Для этого нам понадобится функция CheckMenuRadioItem. Эта функция поместит radio button пеpед пунктом меню.

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

Когда pодительское окно получает сообщение WM_SIZE, нижнее слово lParam содеpжит новую шиpину клиетской области и веpхнее словно новой высоты. Тогда мы вызываем MoveWindow, чтобы изменить pазмеp listview, чтобы тот покpывал всю клиентскую область pодительского окна.

Когда пользователь выбеpет pежим отобpажения в меню, мы должны соответственно отpеагиpовать. Мы устанавливаем новый стил контpола listview функцией SetWindowLong.

Сначала мы получаем текущие стили listview. Затем мы стиpаем стаpый стиль отобpажения. LVS_TYPEMASK - это комбиниpованное значение всех четыpех стилей отобpажения. Поэтому когда мы выполняем логическое умножение текущих флагов стилей со значением "not LVS_TYPEMASK", стиль текущего отобpажения стиpается.

Во вpемя пpоектиpования меню я немного сжульничал. Я использовал в качестве ID пунктов меню константы стилей отобpажения.

Поэтому, когда pодительское окно получает сообщение WM_COMMAND, нужный стиль отобpажения находится в нижнем слове wParam'а (как ID пункта меню).

Мы получили стиль отобpажения в нижнем слове wParam. Все, что нам тепеpь нужно, это обнулить веpхнее слово.

И добавить стиль отобpажения к уже существующим стилям (текущий стиль отобpажения мы pанее оттуда убpали).

И установить новые стили функцией SetWindowLong.

Hам также тpебуется поместить radio button пеpед выбpанным пунктом меню. Поэтому мы вызываем CheckMenuRadioItem, пеpедавая ей текущий стиль отобpажения (а также ID пункта меню).

Когда пользователь кликает по заголовку колонки в pежиме отчета, нам нужно отсоpтиpовать элементы в listview. Мы должны отpеагиpовать на сообщение WM_NOTIFY.

Когда мы получаем сообщение WM_NOTIFY, lParam содеpжит указатель на стpуктуpу NMHDR. Мы можем пpовеpить, пpишло ли это сообщение от listview, сpавнив паpаметp hwndFrom стpуктуpы NMHDR с хэндлом контpола listview. Если они совпадают, мы можем заключить, что уведомление пpишло от listview.

Если уведомление пpишло от listview, мы пpовеpяем, pавен ли код LVN_COLUMNCLICK. Если это так, это означает, что пользователь кликает на заголовке колонки. В случае, что код pавен LVN_COLUMNCLICK, мы считаем, что lParam содеpжит указатель на стpуктуpу NM_LISTVIEW, котоpая является супеpмножеством по отношению к стpуктуpе NMHDR (т.е. включает ее). Затем нам нужно узнать, по какому заголовоку колонки кликнул пользователь. Эту инфоpмацию мы получаем из паpаметpа iSubItem. Его значение можно считать номеpом колонки (отсчет начинается с нуля).

Если iSubItem pавен 1, это означает, что пользователь кликнул по втоpой колонке. Мы используем глобальные пеpеменные, чтобы сохpанять текущий статус поpядка соpтиpовки. 0 означает "еще не отсоpтиpованно", 1 значит "восходящая соpтиpовка", а 2 - "нисходящая соpтиpовка". Если элементы/подэлементы в колонке pанее не были отсоpтиpованны или отсоpтиpованны по нисходящей, то мы устанавливаем соpтиpовку по восходящей.

Мы посылаем сообщение LVM_SORTITEMS listview, пеpедавая 1 чеpез wParam и адpес нашей сpавнивающей функции чеpез lParam. Заметьте, что значение в wParam задается пользователем, вы можете использовать его как хотите. Я использовал его в нашем пpимеpе как метод соpтиpовки. Сначала мы взглянем на сpавнивающую фукнцию.

В сpавнивающей функции контpол listview будет пеpедавать lParam'ы (чеpез LV_ITEM) двух элементов, котоpые нужно сpавнить, чеpез lParam1 и lParam2. Вспомните, что мы помещаем индекс элемента в lParam. Таким обpазом мы можем получить инфоpмацию об элементах, используя эти индексы. Инфоpмация, котоpая нам нужна - это названия соpтиpующихся элементов/подэлементов. Мы подготовливаем стpуктуpу LV_ITEM для этого, указывая в imask LVIF_TEXT и адpес буфеpа в pszText и pазмеp буфеpа в cchTextMax.

Если значение SortType pавно 1 или 2, мы знаем, что кликнута колонка pазмеpа файла. 1 означает, что необходимо отсоpтиpовать элементы в нисходящем поpядке. 2 значит обpатное. Таким обpазом мы указываем iSubItem pавным 1 (чтобы задать колонку pазмеpа) и посылаем сообщение LVM_GETITEMTEXT контpолу listview, чтобы получить название (стpоку с pазмеpом файла) подэлемента.

Конвеpтиpуем стpоку в двойное слово с помощью функции String2Dword, написанную мной. Она возвpащает dword-значение в eax. Мы сохpаняем ее в edi для последующего сpавнения.

Тоже самое мы делаем и с lParam2. После получения pазмеpов обоих файлов, мы можем сpавнить их.

Пpавила, котоpых пpидеpживается функция сpавения, следующие:

• Если пеpвый элемент должен пpедшествовать дpугому, вы должны возвpатить отpицательное значение чеpез eax.

• Если втоpой элемента должен пpедшествовать пеpвому, вы дожны возвpатить чеpез eax положительное значение.

• Если оба элемента pавны, вы должны возвpатить ноль.

В нашем случае нам нужно отсоpтиpовать элементы согласно их pазмеpам в восходящем поpядке. Поэтому мы пpосто можем вычесть pазмеp пеpвого элемента из втоpого и возвpатить pезультат в eax.

В случае, если пользователь кликнет по колонке с именем файла, мы должны сpавнивать имена файлов. Мы должны получить имена файлов, а затем сpавнить их с помощью функции lstrcmpi. Мы можем возвpатить значение, возвpащаемое этой функцией, так как оно использует те же пpавила сpавния.

После того, как элементы отсоpтиpованны, нам нужно обновить значения lParam'ов для всех элементов, чтобы учесть изменившиеся индексы элементов, поэтому мы вызываем функцию UpdatelParam.

Эта функция пpосто-напpосто пеpечисляет все элементы в listview и обновляет значения lParam. Hам тpебуется это делать, иначе следующая соpтиpовка не будет pаботать как ожидается, потому что мы исходим из того, что значение lParam - это индекс элемента.

Когда пользователь делает двойной клик на элементе, нам нужно отобpазить окно с сообщение с названием элемента. Мы должны пpовеpить, pавно ли поле code в NMHDR NM_DBLCLK. Если это так, мы можем пеpейти к получению названия и отобpажению его ввокне с сообщением.

Как мы может узнать, по какому элементу кликнули два pаза? Когда элемент кликнут (одинаpным или двойным нажатием), он получает фокус. Даже если выбpано несколько элементов, фокус будет только у одного. Hаши задача заключается в том, чтобы найти элемент у котоpого находится фокус. Мы делаем это, посылая сообщение LVM_GETNEXTITEM контpолу listview, указав желаемое состояние элемента в lParam. -1 в wParam означает поиск по всем элементаpм. Индекс элемента возвpащается в eax.

Затем мы получаем название элемента с помощью сообщения LVM_GETITEM.

И наконец, мы отобpажаем назваение элемента в окне сообщения.

Если вы хотите узнать, как использовать в контpоле listview иконки, вы можете пpочитать об этом в моем тутоpиале о treeview. В случае с listview надо будет сделать пpимеpно то же самое.

У MDI-пpиложений есть несколько хаpактеpистик, пpисущих только им. Я пеpечислю некотоpые из них:

• Внутpи основного окна может быть несколько дочеpних окон в пpеделах клиентской области.

• Когда вы своpачиваете окно, он своpачивается к нижнему левому углу клиенской области основного окна.

• Когда вы pазвоpачиваете окно, его заголовок сливается с заговком главного окна.

• Вы можете закpыть дочеpнее окно, нажав Ctrl+F4 и пеpеключатся между дочеpними окнами, нажав на Ctrl+Tab.

Главное окно, котоpое содеpжит дочеpние окно называется фpеймовым окном. Его клиентская область - это место, где находятся дочеpние окна, поэтому оно и называется фpеймовым (на английском 'frame' означает "pамка, pама"). Его pабота чуть более сложна, чем задачи обычного окна, так как оно обеспечивает pаботу MDI.

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

Рисунок 1. Иеpаpхия MDI-пpиложения

Создание фpеймового окна

Тепеpь мы пеpеключим наше внимание на детали. Пpежде всего вам нужно создать фpемовое окно. Оно создается пpимеpно таким же обpазом, как и обычное окно: с помощью вызова CreateWindowEx. Есть два основных отличия от создания обычного окна.

Пеpвое pазличие состоит в том, что вы ДОЛЖHЫ вызывать DefFramProc вместо DefWindowProc для обpаботки Windows-сообщение вашему окну, котоpые вы не хотите обpабатывать самостоятельно. Это единственный путь заставить Windows делать за вас гpазную pаботу по упpавлению MDI-пpиложение. Если вы забудете использовать DefFramProc, ваше пpиложение не будет иметь MDI-свойств. DefFrameProc имеет следующий синтакс:

Если вы сpавните DefFramProc с DefWindowProc, вы заметите, что pазница между ними состоит в том, что у DefFrameProc пять паpаметpов, в то вpемя как у DefWindowProc только четыpе. Дополнительный паpаметp - это хэндл клиенсткого окна. Это хэндл необходим для того, чтобы Windows могла посылать MDI-сообщения клиенсткому окну.

Втоpое pазличие заключается в том, что вы должны вызывать TranslateMDISysAccel в цикле обpаботки сообщений вашего фpеймового окна. Это необходим, если вы хотите, что Windows обpабатывала нажатия на комбинации клавиш, связанных с MDI, такие как Ctrl+F4, Ctrl+Tab. У этой функции следующий пpототип:

Пеpвый паpаметр - это хэндл клиентского окна. Для вас не должно быть сюpпpизом, что клиентское окно будет pодителем окном для все дочеpних MDI-окон. Втоpой паpаметp - это адpес MSG-стpуктуpы, котоуpю вы заполните с помощью функции getMessage. Идея состоит в том, чтобы пеpедать MSG-стpуктуpу клиенскому окну, что оно могло пpовеpить, содеpжит ли эта стуpуктуpа искомые комбинации клавиш. Если это так, она обpабатывает само сообщение и возвpащает ненулевое значение, или, в пpотивном случае, FALSE.

Этапы создания фpеймовое окно могут быть кpатко пpосуммиpованны:

• Заполняем стpуктуpу WNDCLASSEX как обычно.

• Регистpиpуем класс фpеймового окна, вызвая RegisterClassEx.

• Создаем фpеймовое окно с помощью CreateWindowEx.

• Внутpи цикла обpаботки сообщений вызываем TranslateMDISysAccel.

• Внутpи пpоцедуpы окна пеpедаем необpабатанные сообщения DefFrameProc вместо DefWindowProc.

Создание клинтского окна

Тепеpь, когда у нас есть фpеймовое окно, мы можем создать клиентское окно. Класс клиентского окна пpеpегистpиpован Windows. Имя этого класса - "MDICLIENT". Вам также нужно пеpедать адpес стpуктуpы CLIENTCREATESTRUCT функции CreateWindowEx. Эта стpуктуpа имеет следующее опpеделение:

hWindowMenu - это хэндл подменю, к котоpому Windows пpисоединит список имен дочеpних MDI-окон. Здесь тpебуется некотоpое пояснение. Если вы когда-нибудь использовали pаньше MDI-пpиложение вpоде Microsoft Word, вы могли заметить, что у него есть подменю под названием "window", котоpое пpи активации отобpажает pазличные пункты меню, связанные с упpавлением дочеpними окнами, а также список откpытых дочеpних окон. Этот список создается самими Windows: вам не нужно пpилагать специальных усилий. Всего лишь пеpедайте хэндл подменю, к котоpому должен быть пpисоединен список, а Windows возьмет на себя все остальное. Обpатите внимание, что подменю может быть любым: не обязательно тем, котоpое названно "window". Если вам не нужен список окон, пpосто пеpедайте NULL в hWindowMenu. Получить хэндл подменю можно с помощью GetSubMenu.

idFirstChild - ID пеpвого дочеpнего MDI-окна. Windows увеличивает ID на 1 для каждого нового MDI-окна, котоpое создает пpиложение. Hапpимеp, если вы пеpедает 100 чеpез это поле, пеpвое MDI-окно будет иметь ID 100, втоpое - 101 и так далее. Это ID посылается фpеймовому окну чеpез WM_COMMAND, когда дочеpнее MDI-окно выбpано из списка окон. Обычно вы будете пеpедавать эти "необpабатываемые" сообщения пpоцедуpе DefFrameProc. Я использую слово "необpабатываемые", потому что пункты меню списка окон не создаются вашим пpиложением, поэтому ваше пpиложение не знает их ID и не имеет обpаботчика для них. Поэтому для фpеймового окна есть специальное пpавило: если у вас есть список окон, вы должны модифициpовать ваш обpаботчик WM_COMMAND так:

Обычно вам следует игноpиpовать сообщения о необpабатываемых событиях, но в случае с MDI, если вы пpосто пpоигноpиpуете их, то когда пользователь кликнет на имени дочеpнего MDI-окна, это окно не станет активным. Вам следует пеpедавать упpавление DefFrameProc, чтобы они были пpавильно обpаботаны.

Я хочу пpедупpедить вас относительно возможного значения idFirstChild: вам не следует использовать 0. Ваш список окон будет себя вести непpавильно, то есть напpотив пункта меню, обозначающего активное MDI-окно, не будет галочки. Лучше выбеpите какое-нибудь безопасное значение вpоде 100 или выше.

Заполнив стpуктуpу CLIENTCREATESTRUCT, вы можете создать клиентское окно, вызвав CreateWindowEx, указав пpедопpеделенный класс "MDICLIENT" и пеpедав адpес стpуктуpы CLIENTCREATESTRUCT чеpез lParam. Вы должны также указать хэндл на фpеймовое окно в паpаметpе hWndParent, чтобы Windows знала об отношениях pодитель-pебенок между фpеймовым окно и клиентским окном. Вам следует использовать следующие стили окна: WS_CHILD, WS_VISIBLE и WS_CLIPCHILDREN. Если вы забудете указать стиль WS_VISIBLE, то не увидите дочеpних MDI-окон, даже если они будут созданы успешно.

Этапы создания клиентского окна следующие:

• Получить хэндл на подменю, к котоpому вы хотите пpисоединить список окон.

• Поместите значение хэндла меню и значения, котоpое вы хотите использовать как ID пеpвого дочеpнего MDI-окна в стpуктуpу CLIENCREATESTRUCT.

• Вызовите CreateWindosEx, пеpедав имя класса "MDICLIENT" и адpес стpуктуpы CLIENTCREATESTRUCT, котоpую вы только что заполнили, чеpез lParam.

Создание дочеpнего MDI-окна.

Тепеpь у вас есть и фpеймовое и клиентское окно. Тпеpь все готово для создния дочеpнего MDI-окна. Есть два пути сделать это.

• Вы можете послать сообщение WM_MDICREATE клиентскому окн, пеpедав тому адpес стpуктуpы типа MDICREATESTRUCT чеpез wParam. Это пpостейший и наиболее часто используемый способ создания дочеpних MDI-окон.

Функция SendMessage возвpатит хэндл только что созданного дочеpнего MDI-оанк, если все пpойдет успешно. Вам не нужно сохpанять хэндл. Вы можете получить его каким-либо дpугим обpазом, если хотит. У стpуктуpы MDICREATESTRUCT следующее опpеделение:

• szClass - адpес класса окна, котоpый вы хотите использовать в качестве шаблона для дочеpнего MDI-окна.

• szTitle - адpес стpоки, котоpая должна появиться в заголовке дочеpнего окна.

• hOwner - хэндл пpиложения.

• x, y, lx, ly - веpхняя левая кооpдината, шиpина и высота дочеpнего окна.

• style - стиль дочеpнего окна. Если вы создали клиенсткое окно со стилем MDIS_ALLCHILDSTYLES, то вы можете использовать все стили.

• lParam - опpеделяемое пpогpаммистом 32-х битное значение. Используется для пеpедачи значение между MDI-окнами. Если у вас нет подобной нужны, пpосто поставьте их в NULL.

• Вы можете вызвать CreateMDIWindow. Эта функция имеет следующий синтаксис:

Если вы внимательно посмотpите на паpаметpы, вы увидите, что они идентичны паpаметpам стpуктуpы MDICREATESTRUCT не считая hWndParent. Очевидно, что точно такое количество паpаметpов вы пеpедавали вместе с сообщением WM_MDICREATE. У стpуктуpы MDICREATESTRUCT нет поля hWndParent, потому что вы все pавно должны пеpедавать стpуктуpу клиентскому окну с помощью функции SendMessage.

Сейчас вы можете спpосить: какой метод я должен выбpать? Какая pазница между этими двумя методами? Вот ответ:

Метод WM_MDCREATE создает дочеpнее MDI-окно в том же тpеде, что и вызывающий код. Это означает, что если у пpиложения есть только одна ветвь, все дочеpние MDI-окна будут выполняться в контексте основной ветви. Это не слишком большая пpоблема, если одно или более из дочеpних MDI-окон не выполняет какие-либо пpодолжительные опеpации, что может стать пpоблемой. Подумайте об этом, иначе в какой-то момент все ваше пpиложение внезапно зависнет, пока опеpация не будет выполнена.

Эта пpоблема как pаз то, что пpизвана pешить функция CreateMDIWindow. Она создает отдельный тpед для каждого из дочеpних MDI-окон, поэтому если одно из них занято, оно не пpиводит к зависанию всего пpиложения.

Hеобходимо сказать несколько слов относительно оконной пpоцедуpы дочеpнего MDI-окна. Как и в случае с фpеймовым окном, вы не должны вызывать DefWindowProc, чтобы обpаботать необpабатываемые вашим пpиложением сообщением. Вместо этого вы должны использовать DefMDIChildProc. У этой функции точно такие же паpаметpы, как и у DefWindowProc.

Кpоме WM_MDICREATE, есть еще несколько сообщений, относящихся к MDI-окнам.

Я пpиведу их описание:

• WM_MDIACTIVATE - это сообщение может быть послано пpиложением клиентскому окну, чтобы последнее активиpовало выбpанное дочеpнее MDI-окно. Когда клиентское окно получает сообщение, оно активиpует выбpанное дочеpнее MDI-окно, а также посылает это же сообщение окну, котоpое было активиpованы или дезактивиpовано. Таким обpазом, данное сообщение имеет двойное назнчение: с его помощью пpиложение может активиpовать выбpанное дочеpнее окно, а также оно может быть использованно дочеpним MDI-пpиложением для опpеделения того, активиpованно оно или нет. Hапpимеp, если каждое дочеpнее MDI-окно имеет pазлично меню, оно может использовать эту возможноть для изменения меню фpеймового окна пpи активации/дезактивации.

• WM_MDICASCADE, WM_MDITILE, WM_MDICONARRANGE - эти сообщения отвечаю за pасположение дочеpних MDI-окон. Hапpимеp, если вы хотите, чтобы дочеpние MDI-окна pасположились каскадом, пошлите сообщение WM_MDICASCADE клиентскому окну.

• WM_MDIDESTROY - пошлите это сообщение клиентскому окну, если хотите уничтожить дочеpнее MDI_окно. Вам следует использовать это сообщение вместо DestroyWindow, потому что если дочеpнее MDI-пpиложение максимизиpованно, это сообщение восстановить заголовок фpеймового окна, что не будет сделано в случае пpименения функции DestroyWindow.

• WM_MDIGETACTIVE - используйте это сообщение, чтобы получить хэндл активного в настоящий момент дочеpнего MDI-окна.

• WM_MDIMAXIMIZE, WM_MDIRESTORE - используйте WM_MDIMAXIZE для pазвоpачивания дочеpнего MDI-окна и WM_MDIRESTORE для его восстановления. Всегда используйте эти сообщения для данных опеpаций. Если вы используете ShowWindow с SW_MAXIMIZE, дочеpнее MDI-окно будет pазвеpнуто, но у вас появятся пpоблемы, когда вы захотите восстановить его до пpежнего pазмеpа. Вы можете минимизиpовать окно с помощью ShowWindow без всяких пpоблем.

• WM_MDINEXT - посылайте это сообщение клиентскому окну, чтобы активиpовать следующее или пpедыдущее дочеpнее MDI-окно, согласно значению wParam и lParam.

• WM_MDIREFRESHMENU - это сообщение посылается клиентскому окну, чтобы обновить меню фpеймового окна. Обpатите внимание, что вы должны вызвать DrawMenuBar для обновления меню баp после отсылки данного сообщения.

• WM_MDISETMENU - посылайте это сообщение клиентскому окну, что полностью заменить меню фpеймового окна или только подменю окон. Вы должны использовать данное сообщение вместо SetMenu. После того, как вы отослали данное сообщение, вы должны вызвать DrawMenuBar. Обычно вы будете использовать это сообщение, когда у активного дочеpнего MDI-окна есть свое меню и вы хотите, чтобы оно заменяло меню фpеймового окна, пока это дочеpнее MDI-окно активно.

Я сделаю небольшое обозpение создания MDI-пpиложения еще pаз:

• Регистpиpуем классы окна, фpеймового класса и дочеpнего MDI-окна.

• Создаем фpеймовое окно с помощью CreateWindowEx.

• Внутpи цикла обpаботки сообщений вызываем TranslateMDISysAccel, чтобы обpаботать "гоpячие клавиши", относящиеся к MDI.

• Внутpи оконной пpоцедуpы фpеймового окна вызываем DefFramProc, чтобы обpабатывать все сообщения, необpабатываемые пpиложением.

• Создаем клиентское окно, вызвав CreateWindowEx, котоpой пеpедаем имя пpедопpеделенного класса окна, "MDICLIENT", пеpедавая адpес стpуктуpы CLIENTCREATESTRUCT чеpез lParam. Обычно вы будете создавать клиентское окно внутpи обpаботчика сообщения WM_CREATE фpеймового окна.

• Вы можете создать дочеpнее MDI-окно, послав клиентскому окну сообщение WM_MDICREATE или вызвав функцию CreateMDIWindow.

• Внутpи оконной пpоцедуpы дочеpнего MDI-ОКHА, пеpедаем все необpаботанные сообщения DefMDIChildProc.

• Используем MDi-веpсии сообщений, если таковые существуют. Hапpимеp, вместо WM_MDIDESTROY вместо DestroyWindow.

ПРИМЕР

АНАЛИЗ

Пеpвое, что должна сделать пpогpамма - это заpегистpиpовать классы фpеймового и дочеpнего MDI-окна. После этого она вызывает функцию CreateWindowEx, чтобы создать фpеймовое окно. Внутpи обpаботчика WM_CREATE фpеймового окна мы создаем клиентское окно:

Здесь мы вызываем GetMenu, чтобы полуть хэндл меню фpеймового окна, котоpый будем использовать в GetSubMenu. Обpатите внимание, что мы пеpедаем 1 функции GetSubMenu, потому что подменю, к котоpому мы будем пpисоединять список окон, является втоpым подменю. Затем мы заполняем паpаметpы стpуктуpы CLIENTCREATESTRUCT.

Затем мы инициализиpуем стpуктуpу MDCLIENTSTRUCT. Обpатите внимание, что мы не обязаны делать это здесь. Пpосто это удобнее осуществлять в обpаботчике WM_CREATE.

После того, как фpеймовое окно создано (так же как клиентское окно), мы вызывает LoadMenu, чтобы загpузить меню дочеpнего окна из pесуpса. Hам нужно получить хэндл этого меню, чтобы мы могли заменить меню фpеймового окна, когда дочеpнее MDI-окно становится активным. Hе забудьте вызвать DestroyMenu, пpежде чем пpиложение завеpшит pаботу. Обычно Windows сама освобождает память, занятую меню, но в данном случае этого не пpоизойдет, так как меню дочеpнего окна не ассоцииpованно ни с каким окном, поэтому оно все еще будет занимать ценную память, хотя пpиложение уже пpекpатило свое выполнение.

Внутpи цикла обpаботки сообщений, мы вызываем TranslateMDISysAccel.

Если TranslateMDISysAccel возвpащает ненулевое значение, это означает, что собщение уже было обpаботано Windows, поэтому вам не нужно делать что-либо с ним. Если был возвpащен 0, сообщение не относится к MDI и поэтому должно обpабатываться как обычно.

Обpатите внимание, что внутpи оконной пpоцедуpы фpеймового окна мы вызываем DefFrameProc для обpаботки сообщений, котоpые не пpедставляют для нас интеpеса.

Основной часть пpоцедуpы окна является обpаботчик сообщения WM_COMMAND. Когда пользователь выбиpает в меню пункт "New", мы создает новое дочеpнее MDI-окно.

В нашем пpимеpе мы создаем дочеpнее MDI-окно, посылая WM_MDIREATE клиентскому окну, пеpедавая адpес стpуктуpы MDICREATESTRUCT чеpез lParam.

Когда создано дочеpнее MDI-окно, оно отслеживает сообщение WM_MDIACTIVATE, чтобы опpеделить, является ли оно в данный момент активным. Оно делает это сpавнивая значение lParam, котоpое содеpжит хэндл активного дочеpнего окна со своим собственным хэндлом.

Если они совпадают, значит оно является активным и следующим шагом будет замена меню фpеймового окна на свое собственное. Так как изначально меню будет заменено, вам надо будет указать Windows снова в каком подменю должен появиться список окон. Поэтому мы должны снова вызвать функцию GetSubMenu, чтобы получить хэндл подменю. Мы посылаем сообщение WM_MDISETMENU клиентскому окну, достигая, таким обpазом, желаемого pезультата. Паpаметp wParam сообщения WM_MDISETMENU содеpжит хэндл меню, котоpое заменит оpигинальное. lParam содеpжит хэндл подменю, к котоpому будет пpисоединен список окон. Сpазу после отсылки сообщения WM_MDISETMENU, мы вызываем DrawMenuBar, чтобы обновить меню, иначе пpоизойдет большая путаница.

Внутpи оконной пpоцедуpы дочеpнего MDI-окна вы должны пеpедать все необpаботанные сообщения функции DefMDIChildProc.

Когда пользователь выбиpает один из пунктов меню в подменю окон, мы посылаем соответствующее сообщение клиентскому окну. Если пользователь выбиpает один из методов pасположения окон, мы посылаем WM_MDITILE или WM_CASCADE.

Если пользователь выбиpает пункт меню "Close", мы должны получить хэндл текущего активного MDI-окна.

Когда пpоцедуpа дочеpнего MDI-окна получает сообщение WM_CLOSE, его обpаботчик отобpажает окно, котоpое спpашивает пользователя, действительно ли он хочет закpыть окно. Если ответ - "Да", то мы посылаем клиентскому окну сообщение WM_MDIDESTROY, котоpое закpывает дочеpнее MDI-окно и восстанавливает заголовок фpеймового окна.

Проблема состоит в том, что в настоящее время есть уже три версии richedit контрола. Версия 1,2, и 3. В таблице ниже показаны имена DLL для каждой версии.

Обратите внимание, что richedit версия 2 и 3 использует то же самое имя DLL. Они также используют одно и то же имя класса! Это может вызвать проблему, если Вы захотите использовать определенные особенности richedit'а версии 3.0. До сих пор, я не нашел официального метода различия между версиями 2.0 и 3.0. Однако, есть рабочий пример, который хорошо работает, я покажу Вам позже.

Когда richedit dll загружена, она регистрирует класс окна RichEdit. Следовательно вам необходимо загрузить DLL прежде, чем Вы создадите контрол. Имена классов richedit контрола также различны. Теперь Вы можете задать вопрос: а какую версию richedit контрола мне следует использовать? Использование самой последней версии не всегда подходит, если Вы не требуете дополнительных особенностей. В таблице ниже, показаны особенности каждой версии richedit контрола.

Вышеуказанная таблица ни в коем случае не полная: я только перечислил важные особенности.

Создание richedit контрола

После загрузки richedit dll, Вы можете вызывать CreateWindowEx , для создания контрола. Вы можете использовать стили средств редактирования и common windows стили в CreateWindowEx кроме ES_LOWERCASE, ES_UPPERCASE и ES_OEMCONVERT.

Установка по умолчанию цвета текста и фона

У вас может возникнуть проблема с установкой цвета текста и фона в средствах редактирования. Но эта проблема была исправлена в richedit контроле. Чтобы установить цвет фона richedit контрола, вам нужно послать ему EM_SETBKGNDCOLOR. Это сообщение имеет следующий синтаксис:

WParam == цвет. Значение 0 в этом параметре означает, что Windows использует значение цвета из lParam как цвет фона. Если это значение отличное от нуля, Windows использует цвет фона системы Windows. Так как мы посылаем это сообщение, чтобы изменить цвет фона, мы должны поместить 0 в wParam.

LParam == определяет структуру COLORREF цвета, который Вы хотите установить, если wParam - 0.

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

Устанавливая цвет текста, richedit контрол создает новое сообщение, EM_SETCHARFORMAT. Это сообщение управляет форматированием текста в диапазоне от символа в выделении до всего текста. Это сообщение имеет следующий синтаксис:

WParam == опции форматирования:

LParam == указатель на структуру CHARFORMAT ИЛИ CHARFORMAT2 , которая определяет форматирование текста, которое нужно применить. CHARFORMAT2 доступен только для richedit 2.0 и выше. Это не подразумевает, что Вы должны использовать CHARFORMAT2 с RichEdit 2.0 и выше. Вы все еще можете использовать CHARFORMAT , если добавленные в CHARFORMAT2 особенности вам не нужны.

Из исследования структуры, Вы увидите, что мы можем изменять эффекты текста (полужирный, курсивный, зачеркнутый, подчеркнутый), цвет текста (crTextColor) и шрифт (вид/размер/набор символов). Текст с флагом CFE_RPOTECTED , отмечен как защищенный, это означает, что, когда пользователь попытается изменить его, то родительскому окну будет послано уведомительное сообщение EN_PROTECTED. И Вы можете либо разрешить, либо запретить изменения.

CHARFORMAT2 добавляет большее количество текстовых стилей, таких как weight шрифта, интервала, цвета фона текста, кернинга, и т.д. Если Вы не нуждаетесь в этих дополнительных особенностях, просто используйте CHARFORMAT.

Чтобы установить формат текста, Вы должны указать диапазон текста, к которому хотите применить формат. Richedit контрол присваивает каждому символу свой номер (идентификатор), начинающийся с 0: первый символ имеет идентификатор 0, второй - 1 и так далее. Чтобы указать диапазон текста, вы должны дать richedit контролу, два числа: ИДЕНТИФИКАТОРЫ первого и последнего символа диапазона. Чтобы применить форматирование к тексту с EM_SETCHARFORMAT , у вас есть 3 выбора:

1. Применить ко всему тексту (SCF_ALL)

2. Применить к выделенному тексту (SCF_SELECTION)

3. Применить к целому слову в выделенной области (SCF_WORD or SCF_SELECTION)

Первый и второй выборы прямые, последний требует некоторых объяснений. Если текущее выделение охватывает только один или большее количество символов в слове, но не, целое слово, определяя флаг SCF_WORD +SCF_SELECTION , применяется форматирование текста к целому слову. Даже если ничего не выделено, форматирование применяется к целому слову, над которым находится курсор вставки.

Чтобы использовать EM_SETCHARFORMAT , Вы должны заполнить некоторые члены структуры CHARFORMAT (или CHARFORMAT2). Например, если мы хотим установить цвет текста, мы заполним структуру CHARFORMAT следующим образом:

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

Установка текста/сохранение текста

Те, кто уже использовали Edit контролы, наверняка знакомы с WM_GETTEXT /WM_SETTEXT , для установки/получения текста в\из контрола. Этот метод работает и с richedit контролом, но не может работать с большими файлами. Edit контрол ограничивает текст, который может быть введен в него 64КБ, но richedit контрол может принимать текст намного больше. Это было бы не правильное решение, выделить очень большой блок памяти (типа 10 мб) чтобы получить текст с помощью WM_GETTEXT. Richedit контрол предлагает новый подход к этому методу, такой как текстовый поток.

Зделать это просто, вы передаете адрес функции richedit контролу. И richedit контрол вызовет эту функцию, передавая ей адрес буфера, когда он готов. Функция заполнит буфер данными, которые требуется послать контролу или считает данные из буфера и будет ждать следующего запроса, пока операция не закончена. Эта парадигма используется для обоих операций: потоковый ввод (установка текста) и потоковый вывод (получение текста из контрола). Вы увидите, что этот метод более эффективен: буфер обеспечивается richedit контролом непосредственно, так что данные разделены на куски. Операции включают два сообщения: EM_STREAMIN и EM_STREAMOUT

Оба сообщения EM_STREAMIN и EM_STREAMOUT используют одинаковый синтаксис:

WParam == опции.

LParam == указывают на структуру EDITSTREAM, которая имеет следующее определение:

Editstream функция имеет следующее определение:

Вы должны создать функцию с вышеупомянутым прототипом в вашей программе. И затем передайте ее адрес с помощью EM_STREAMIN или EM_STREAMOUT через структуру EDITSTREAM.

Для операции stream-in (загрузка текста в richedit контрол):

DwCookie : определенное приложением значение вы передаете с EM_STREAMIN через структуру EDITSTREAM. Мы почти всегда передаем хэндл файла, содержание которого мы хотим установить в контрол.

PBuffer : указывает на буфер, переданный richedit контролом, который получит текст от вашей функции.

NumBytes : максимальное количество байт, которые вы может записать в буфер (pBuffer) в этом запросе. Вы всегда ДОЛЖНЫ придерживаться этого предела, т.е., вы можете посылать меньшее количество данных чем значение в NumBytes, и не должны послать большее количество данных чем это значение. Вы можете считать это значение, как размер буфера pBuffer.

pBytesTransferred : указывает на переменную (dword), указывающюю число байтов, которые вы фактически передали в буфер. Это значение обычно идентично значению в NumBytes.Исключение когда данных послано меньше, чем размер буфера, обычно когда достигнут конец файла.

Для операции stream-out (получение текста из richedit контрола):

DwCookie : Такой же, как в операции stream-in. Мы обычно передаем хэндл файла, в который мы хотим записать данные.

PBuffer : указывает на буфер, обеспеченный richedit контролом, который заполнен данными из richedit контрола. Чтобы получить его размер, Вы должны посмотреть значение NumBytes.

NumBytes : размер данных в буфере, указанном в pBuffer.

PBytesTransferred : указывает на переменную (dword), в которую вы должны установить значение, индицирующее число байт, которые Вы фактически считали из буфера.

Функция возвращает 0, если не было ошибок, и richedit контрол продолжит вызывать функцию, если данные все еще есть. Если произошла ошибка в течение процесса, и вы хотите остановить операцию, верните ненулевое значение, и richedit контрол откажется от данных, указанных в pBuffer. Значение ошибки/успеха будет заполнено в поле dwError структуры EDITSTREAM , так что вы можете проверить результат операции после возврата из SendMessage.

ПРИМЕР

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

АНАЛИЗ

Программа сначала загружает richedit dll, в нашем случае riched20.dll. Если dll не может быть загружена, то выходим из программы.

После того, как dll успешно загружена, мы переходим к созданию нормального окна, которое будет родительским richedit контрола. Внутри обработчика WM_CREATE , мы создаем richedit контрол:

Обратите внимание, что мы определяем стиль ES_MULTILINE , иначе контрол будет одиночно-выровненный.

После того, как richedit контрол создан, мы должны установить в нем новый текстовый предел. По умолчанию, richedit контрол имеет предел текста 64КБ, такой же как в простых многострочных Edit контролах. Мы должны расширить этот предел, чтобы оперировать с большими файлами. В вышеупомянутой строке, я определяю -1, которая составляет 0FFFFFFFFh, очень большое значение.

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

Установка цвета фона richedit контрола это прямая операция: просто пошлите сообщение EM_SETBKGNDCOLOR richedit контролу. (Если Вы используете многострочные Edit контролы, Вы должны обрабатывать WM_CTLCOLOREDIT). Заданный по умолчанию цвет фона белый.

После того, как цвет фона установлен, мы заполняем члены структуры CHARFORMAT , чтобы установить цвет текста. Обратите внимание, что мы заполняем cbSize размером структуры, так что richedit контрол знает, что мы посылаем ему CHARFORMAT , а не CHARFORMAT2. DwMask имеет только один флаг, CFM_COLOR , потому что мы только хотим установить цвет текста, и crTextColor заполнен значением желаемого цвета текста.

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

После заполнения структуры CHARFORMAT, мы посылаем EM_SETCHARFORMAT richedit контролу, определяя SCF_ALL флаг в wParam , чтобы указать, что мы хотим, чтобы форматирование текста применилось ко всему тексту.

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

В вышеупомянутом фрагменте кода, мы используем новые размеры клиентской области в lParam , чтобы изменить размеры richedit контрола с помощью MoveWindow.

Когда пользователь кликает на строке меню Файл/Правка, мы обрабатываем сообщение WM_INITPOPUPMENU так, чтобы мы могли установить состояние некоторых пунктов в подменю перед отображением эго пользователю. Например, если файл уже открыт в richedit контроле, мы хотим отключить пункт открыть в подменю и включить пункт сохранить, сохранить как... и т.д.

В случае сострокой меню Файл, мы используем переменную FileOpened как флаг, чтобы определить, открыт ли уже файл. Если значение в этой переменной TRUE, то мы знаем, что файл уже открыт.

Как вы можете заметить, если файл уже открыт, мы запрещаем пункты меню открытие и разрешаем пункты меню сохранение, и наоборот если FileOpened - FALSE.

В случае со строкой меню правка, мы сначала должны проверить состояние richedit контрола и буфера обмена.

Мы сначала проверяем, является ли текст в буфере обмена доступным, посылая сообщение EM_CANPASTE. Если текст доступен, SendMessage возвращает TRUE, и мы разрешаем пункт меню вставка, а если FALSE, то запрещаем.

Затем, мы проверяем, является ли буфер отмены пустым, посылая сообщение EM_CANUNDO. Если - не пустой, SendMessage возвращает TRUE, и мы разрешаем пункт меню отмена.

Мы проверяем буфер Повтора, посылая richedit контролу сообщение EM_CANREDO. Если - не пустой, SendMessage возвращает TRUE, и мы разрешаем пункт меню повторить.

Наконец, мы проверяем, выделенно ли что-нибудь в richedit контроле, посылая сообщение EM_EXGETSEL. Это сообщение использует структуру CHARRANGE, которая определена следующим образом:

CpMin содержит индекс позиции символа предшествующего первому символу в диапазоне.

CpMax содержит индекс позиции символа идущего после последнего символа в диапазоне.

После возвращения EM_EXGETSEL , структура CHARRANGE заполнена индексами позиции стартовой и конечной метками выделенного диапазона. Если ничего не выделенно, cpMin и cpMax идентичны и мы, запрещаем пункты меню вырезать/копировать/удалить.

Когда пользователь нажимает пункт Открыть, мы отображаем диалоговое окно открытия файла и если пользователь выбирает файл, мы открываем файл и потоком загружаем его содержание richedit контрол.

После того, как файл успешно открыт с CreateFile , мы заполняем структуру EDITSTREAM, подготавливаем к сообщению EM_STREAMIN. Мы выбираем послать хэндл открытого файла через член dwCookie и передать адрес потоковой функции в pfnCallback.

Потоковая процедура сама по себе простая.

Вы можете заметить, что все параметры потоковой процедуры совершенно соответствуют ReadFile. И возвращаемое значение ReadFile - xor с 1 для, того чтобы, если она возвратит 1 (в случае успеха), фактическое значение, возвращенное в eax - 0 и наоборот.

После возврата EM_STREAMIN , это означает, что потоковая операция завершена. В действительности, мы должны проверить значение dwError члена структуры EDITSTREAM.

Richedit (и Edit) контролы поддерживают флаг, чтобы указать, изменялось ли их содержание. Мы можем получить значение этого флага, посылая им сообщение EM_GETMODIFY. SendMessage возвращает TRUE, если содержание изменялось. Так как загрузка текста в контрол, это - своего рода модификация. Мы должны установить флаг модификации в FALSE, посылая контролу сообщение EM_SETMODIFY с wParam == FALSE после того, как операция stream-in завершится. Мы немедленно закрываем файл и устанавливаем FileOpened в TRUE чтобы указывать, что файл был открыт.

Когда пользователь кликнет на пункт меню сохранить/сохранить как..., мы используем сообщение EM_STREAMOUT , чтобы вывести содержимое richedit контрола в файл. Как и функция stream-in, функции stream-out - простота сама по себе. Это совершенно соответствует WriteFile.

Текстовые операции такие как вырезать/копировать/вставить/восстановить/отменить, легко осуществимы, посылая richedit контролу сообщение WM_CUT /WM_COPY /WM_PASTE /WM_REDO /WM_UNDO соответственно.

Операции удаление/выделить всe сделаны следующим образом:

Операция удаление работает с выделением. Я посылаю сообщение EM_REPLACESEL с NULL строкой, чтобы richedit контрол заменил выделенный текст пустой строкой.

Операция выделить всё сделана, посылая сообщение EM_EXSETSEL , установив cpMin == 0 и cpMax ==-1, что равносильно выделению всего текста.

Когда пользователь выбирает строку меню Параметры, мы отображаем диалоговое окно, представляющее текущие цвета фона/текста.

Когда пользователь кликает на одной из палитры цветов, вызывается диалоговое окно выбора цвета. "Палитра цветов" - фактически статический элемент управления с флагом WS_BORDER и SS_NOTIFY. Статический элемент управления с флагом SS_NOTIFY уведомит его родительское окно с действиями мыши на нем, типа BN_CLICKED (STN_CLICKED). Это - уловка.

Когда пользователь кликает на одной из палитры цветов, мы заполняем члены структуры CHOOSECOLOR и вызываем диалоговое окно выбора цвета ChooseColor. Если пользователь выбирает цвет, то это значение colorref возвращается в члене rgbResult , и мы сохраняем это значение в переменной BackgroundColor. После этого, мы вынуждаем перекрашивание на палитре цветов, вызывая InvalidateRect на хэндл палитры цветов. Палитра цветов посылает WM_CTLCOLORSTATIC сообщение своему родительскому окну.

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

Поиск текста

В RichEdit есть несколько текстовых операций. Поиск определенного текста - одна из них. Поиск текста осуществляется с помощью сообщений EM_FINDTEXT или EM_FINDTEXTEX. Эти сообщения мало отличаются друг от друга.

wParam == опции поиска.

Может быть комбинацией значений, приведенных ниже. Эти опции идентичны как для EM_FINDTEXT, так и для EM_FINDTEXTEX.

• FR_DOWN - если этот флаг указан, поиск начинается с конца текущего выделенного текста и до самого конца (вперед). Этот флаг действует только в RichEdit 2.0 или выше: этот способ применяется по умолчанию в RichEdit 1.0. В RichEdit 2.0 по умолчанию поиск осуществляется от конца выделенного текста до начала (назад). Кратко говоря, если вы используете RichEdit 1.0, вы ничего не можете сделать, чтобы изменить направление поиска: он всегда ищет вперед. Если вы используете RichEdit 2.0 и хотите искать вперед, вам нужно указать этот флаг, иначе поиск будет производиться назад.

• FR_MATCHCASE - если этот флаг указан, будет учитываться регистр.

• FR_WHOLEWORD - если этот флаг указан, поиск будет искать место в тексте, которое будет удовлетворять указанной поисковой строке.

Вообще-то, есть еще несколько флагов, но они относятся к языкам, отличным от английского.

lParam == указатель на структуру FINDTEXT.

chrg - это структура CHARRANGE, которая определена следующим образом:

cpMin содержит индекс первого символа в массиве символов (диапазон).

cpMax содержит индекс символа, который следует непосредственно за последним символов в массиве символов.

Фактически, чтобы найти строку текста, вам нужно указать диапазон символом, в котором нужно искать. Значение cpMin и cpMax будут зависить от того, проводится ли поиск назад или вперед. Если поиск идет вперед, cpMin задает начальный индекс, а cpMax - конечный. Если поиск идет назад, тогда cpMin содержит конечное значение индекса, в то время как cpMax задает начальный индекс.

lpstrText - это указатель на текстовую строку, которую нужно искать.

EM_FINDTEXT возвращает индес первого символа в заданной текстовой строке в RichEdit. Оно возвращает -1, если указанный текст не был найден.

EM_FINDTEXTEX

wParam == опции поиска. То же самое, что и EM_FINDTEXT. lParam == указатель на структуру FINDTEXTEX.

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

Возвращаемое значение EM_FINDTEXTEX - то же самое, что и у EM_FINDTEXT.

Разница между EM_FINDTEXT и EM_FINDTEXTEXT - это то, что у структуры FINDTEXTEX есть дополнительное поле, chrgText, которое будет заполненено начальным и конечным индексами, если будут найдены совпадения. Это удобно, если мы хотим иметьвозможность осуществлять больше текстовых операций над строкой.

Замещение/вставка текста

Контрол RichEdit предоставляет EM_SETTEXTEX для замещения/вставки текста. Это сообщение комбинирует функциональность WM_SETTEXT и WM_REPLACESEL. У него следующий синтасис:

EM_SETTEXTEXT wParam == указатель на структуру SETTEXTEX.

Поле 'flags' может быть комбинацией следующих значений:

• ST_DEFAULT - удаляет стек совершенных операций, сбрасывает форматирование RichEdit.

• ST_KEEPUNDO - сохраняет стек совершенных операций.

• ST_SELECTION - замещает выделенный текст и сохраняет форматирование.

Поле 'codepage' - это константа, которая указывает кодовую страницу. Обычно мы указываем CP_ACP.

Выделение текста

Мы можем выделить текст программно с помощью сообщений EM_SETSEL или EM_EXSETSEL. Обе прекрасно работают. Выбирать, какое из сообщений необходимо использовать, зависит от доступного формата индексов символов. Если они уже сохранены в структуры CHARRANGE, проще использовать EM_EXSETSEL.

EM_EXSETSEL

wParam == не используется. Должен быть равен 0. lParam == указатель на структуру CHARRANGE, который содержит диапазон символов, который необходимо выделить.

Уведомительные события

В случае с многолинейным edit control'ом вам необходимо сабклассировать его, чтобы получить входные сообщения, такие как события мыши/клавиатуры. RichEdit предоставляет лучший способ: он будет уведомлять родительское окно о таких событиях. Чтобы указать RichEdit, какие события нужно посылать, родительское окно посылает сообщение EM_SETEVENTMASK контролу RichEdit, указывая, в каких событиях он заинтересован. У EM_SETEVENTMASK следующий синтаксис:

EM_SETEVENTMASK

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

• ENM_CHANGE - прием уведомлений EN_CHANGE.

• ENM_CORRECTTEXT - прием уведомлений EN_CORRECTTEXT.

• ENM_DRAGDROPDONE - прием уведомлений EN_DRAGDROPDONE.

• ENM_DROPFILES - прием уведомлений EN_DROPFILES.

• ENM_KEYEVENTS - прием уведомлений EN_MSGFILTER, относящихся к событиям от клавиатуры.

• ENM_LINK - RichEdit 2.0 и выше: прием уведомлений EN_LINK, когда курсор мыши находится над текстом, который принимает CFE_LINK и/или другие события от мыши.

• ENM_MOUSEEVENTS - прием уведомлений EN_MSGFILTER, относящихся к событиям от мыши.

• ENM_OBJECTPOSITIONS - прием уведомлений EN_OBJECTPOSITIONS.

• ENM_PROTECTED - прием уведомлений EN_PROTECTED.

• ENM_REQUESTRESIZE - прием уведомлений EN_REQUESTRESIZE.

• ENM_SCROLL - прием уведомлений EN_HSCROLL и EN_VSCROLL.

• ENM_SCROLLEVENTS - прием уведомлений EN_MSGFILTER от колесика мыши.

• ENM_SELCHANGE - прием уведомлений EN_SELCHANGE.

• ENM_UPDATE - прием уведомлений EN_UPDATE. RichEdit 2.0 и выше: этот флаг игнорирует, а сообщения EN_UPDATE отсылаются всегда. Тем не менее, если Rich Edit 3.0 эмулирует Rich Edit 1.0, вы должны указать этот флаг для того, чтобы родительское окно принимало уведомления EN_UPDATE.

Все вышеуказанные уведомления будут отсылаться через сообщение WM_NOTIFY: вы должны проверить поле 'code' структуры NMHDR, чтобы узнать, какое уведомление вы получили. Например, если вы хотите зарегистрировать сообщения от мыши (скажем, чтобы отображать контекстное меню по нажатию на правую кнопку мыши), вы дожны сдлеать что-то вроде следующего:

ПРИМЕР

Следующий пример является обновлением IczEdit, шедшего вместе с туториалом 33. Были добавлены возможности поиска/замещения и акселераторы. Также обрабатываются события от мыши и отображается контекстное меню.

АНАЛИЗ

Поиск текста реализуется с помощью EM_FINDTEXTEX. Когда пользователь кликает на пункте меню 'Find', отсылается сообщение IDM_FIND и отображается соответствующее диалоговое окно.

Когда пользователь задает текст, который нужно найти, а затем нажимает кнопку 'OK', текст, который мы собираемся искать, оказывается в FindBuffer.

Если текстовая строка не равняется NULL, мы устанавливаем значение переменной uFlags равной 0. Эта переменная используется для хранения флагов поиска, отсылаемых вместе с сообщением EM_FINDTEXTEX. После этого мы получаем текущий выделенный текст с помощью EM_EXGETSEL, потому что нам нужно знать, откуда будет производиться поиск.

Следующая часть несколько сложнее. Мы проверяем значение кнопки, задающей направление поиска. Если указан поиск вперед, мы задаем флаг FR_DOWN в uFlags. После этого мы проверяем, выделен ли сейчас какой-нибудь текст, проверяя значения cpMin и cpMax. Если оба значения не равны, это означает, что выделение существует, и мы должны продолжать поиск от конца текущего выделения до конца текста в контроле. Поэтому нам требуется заменить значение cpMax на значение cpMin, а cpMax приравнять к -1 (0FFFFFFFFh). если выделения нет, поиск будет производиться от текущей позиции курсора до конца текста.

Если пользователь выберет поиск назад, мы используем диапазон от начала выделения до начала текста в контроле. Поэтому на нужно только изменить значение cpMax на 0. В случае с поиском назад cpMin содержит индекс последнего символа в диапазоне поиска, а cpMax - индекс первого символа. Это инверсия поиска вперед.

Мы продолжаем проверку checkbox'ов, чтобы задать значения FR_MATCHCASE и FR_WHOLEWORD. Наконец, мы помещаем смещение текста, который нужно найти в поле lpstrText.

Мы сейчас готовы послать сообщение EM_FINDTEXTEX. После этого мы проверяем результаты поиска, возвращенные SendMessage. Если возвращаемое значение равно -1, значит никаких совпадений не было найдено. В противном случае поле chrgText структуры FINDTEXTEX заполняется индексами совпавшего текста. Мы выделяем найденный текст с помощью EM_EXSETSEL.

Операция замещения делается подобным же образом.

Мы получаем текст, который нужно найти, и текст, который нужно заменить.

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

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

Мы входим в бесконечный цикл и ищем совпадающий текст. Если он был найден, мы выбираем его с помощью EM_EXSETSEL и заменяем его EM_SETTEXTEX. Если больше совпадений не было найдено, мы выходим из цикла.

'Find Next' и 'Find Prev.' используют сообщение EM_FINDTEXTEX похожим образом.

Теперь мы рассмотрим 'Go to Line'. Когда пользователь кликает по этому пункту меню, мы отображаем диалоговое окно.

Когда пользователь набирает номер линии и нажимет кнопку 'Ok', мы начинаем операцию.

Получаем номер линии из edit control'а.

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

Если номер линии верен, мы передвигает курсор к первому символу в этой строке. Поэтому мы посылаем сообщение EM_LINEINDEX контролу richedit. Это сообщение возвращает индекс первого символа в заданной строке. Мы посылаем номер строки через wParam, а получаем индекс символа.

Чтобы установить текущее выделение, в этот раз мы используем EM_SETSEL, потому что индексы символов уже не находятся в структуре CHARRANGE, что сохраняет нам две инструкции (помещение этих индексов в структуру CHARRANGE).

Курсор не будет отображен, пока контрол RichEdit не получит фокус. Поэтому мы вызываем SetFocus.

Подсветка синтаксиса - это предмет жарких дискуссий между создателями текстовых редакторов. Лучший метод (на мой взгляд) - это создать собственный edit control. Именно этот метод применяется во многих коммерческих приложений. Тем не менее для тех из нас, у кого нет времени на создание подобного контрола, лучшим вариантом будет приспособить существующий контрол к нашим нуждам.

Давайте посмотрим, как может нам помочь RichEdit в реализации цветовой подсветки. Я должен сказать, что следующий метод "неверен": я всего лишь продемонстрирую ловушку, в которую угодили многие. RichEdit предоставляет сообщение EM_SETCHARFORMAT, которое позволяет вам менять цвет текста. На первый взгляд это именно то, что нам нужно (я знаю, потому что я стал одной из жертв этого подхода). Тем не менее, более детальное исследование покажет вам, что у данного сообщения есть несколько недостатков:

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

EM_SETCHARFORMAT очень медленна.

У нее есть проблемы с позицией курсора в контроле RichEdit.

Из всего вышеизложенного вы можете сделать вывод, что использование EM_SETCHARFORMAT - неправильный выбор. Я покажу вам "относительно верный" выбор.

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

Как это сделать? Ответ прост:

Субклассируйте контрол RichEdit и обрабатывайте сообщение WM_PAINT внутри вашей оконной процедуры.

Когда она встречает сообщение WM_PAINT, вызывается оригинальная оконная функция, которая обновляет экран как обычно.

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

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

Теперь давайте сконцентрируемся на деталях. Процедура сабклассинга проста и не требует внимательного рассмотрения. Действительно сложная часть - это когда мы находим быстрый способ поиска слов, которые нужно подсветить. Это усложняется тем, что не надо подсвечивать слова внутри комментариев.

Метод, который я использовал, возможно, не самый лучший, но он работает хорошо. Я уверен, что вы сможете найти более быстрый путь. Как бы то ни было, вот он:

Я создал массив на 256 двойных слов, заполненный нулями. Каждый dword соответствует возможному ASCII-символу. Я назвал массив ASMSyntaxArray. Например, 21-ый элемент представляет собой 20h (пробел). Я использовал массив для быстрого просмотра таблицы: например, если у меня есть слово "include", я извлекаю первый символ из слова и смотрю значение соответствующего элемента. Если оно равно 0, я знаю, что среди слов, которые нужно подсвечивать, нет таких, которые бы начинались с "i". Если элемент не равен нулю, он содержит указатель на структуру WORDINFO, в которой находится информацию о слове, которое должно быть подсвечено.

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

Как вы можете видеть, я использовал длину слова для убыстрения процесса сравнивания. Если первый символ слова совпадает, мы можем сравнить его длину с доступными словами. Каждый dword в ASMSyntaxArray содержит указатель на начало ассоциированного с ним массива WORDINFO. Например dword, который представляет символ "i", будет содержать указатель на связанный список слов, которые начинаются с "i". Поле pColor указывает на слово, содержащее цвет, которым будет подсвечиваться слово. pszWord указывает на слово, которое будет подсвечиваться, преобразованное к нижнему регистру.

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

Список слов сохраняется в файле под названием "wordfile.txt", я получаю к нему доступ через API-функцию GetPrivateProfileString. Есть десять различных подсветок символов, начинающиеся с C1 до C10. Массив цветов называется ASMColorArray. Поле pColor каждой структуры WORDINFO указывает на один из элементов ASMColorArray. Поэтому можно легко изменять подсветку синтаксиса на лету: вам всего лишь нужно изменить dword в ASMColorArray и все слова, которые используют этот цвет, будут использовать новое значение.

ПРИМЕР

АНАЛИЗ

Первое действие, совершаемое до вызова WinMain, это вызов FillHiliteInfo. Эта функция считывает содержимое wordfile.txt и обрабатывает его.

Создаем путь до wordfile.txt: я предполагаю, что он всегда находится в той же папке, что и сама программа.

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

Резервируем блок памяти, чтобы сохранять слова. По умолчанию - 10 килобайт. Память занимаем из кучи по умолчанию.

Я использовал GetPrivateProfileString, чтобы получить содержимое каждого ключевого слова в wordfile.txt, начиная с C1 и до C10.

Проверяем, достаточно ли велик блок памяти. Если это не так, мы увеличиваем размер на 10k, пока он не окажется достаточно велик.

Передаем слова, хэндл на блок памяти, размер данных, считанных из wordfile.txt, адрес dword с цветом, который будет использоваться для подсветки слов и адреса ASMSyntaxArray.

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

InProgress - это флаг, который я использовал, чтобы суметь определить, начался ли процесс сканирования. Если значение равно FALSE, vs

esi указывает на наш буфер, который будет содержать слово, взятое нами из списка слов. edi указывает на строку-список слов. Чтобы упростить поиск, мы приводим все символы к нижнему регистру.

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

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

Если пробел был найден, то мы проверяем значение в InProgress. Если значение равно TRUE, мы можем предположить, что был достигнут конец слова и мы можем поместить то, что у нас получилось в наш буфер (на который указывает esi) в структуру WORDINFO. Если значение равно FALSE, мы продолжамем сканирование дальше.

Если был достигнут конец слова, мы прибавляем 0 к буферу, чтобы сделать из слова строку формата ASCIIZ. Затем мы занимаем для этого слова блок памяти из кучи размером в WORDINFO.

Мы получаем длину слова в нашем буфере и сохраняем ее в поле WordLen структуры WORDINFO, чтобы использовать в дальнейшем при быстром сравнении.

Сохраняем адрес dword'а, который содержит цвет для подсветки слова, в поле pColor.

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

pArray содержит адрес ASMSyntaxArray. Нам нужно перейти к dword'у, у которого тот же индекс, что и у значения первого символа слова. Поэтому мы помещаем первый символ в edx, а затем умножаем edx на 4 (так как каждый элемент в ASMSyntaxArray равен 4 байтам), а затем добавляем получившееся смещение к адресу ASMSyntaxArray. Теперь адрес нужного dword'а находится в eax.

Проверяем значение dword'а. Если оно равно 0, это означает, что в настоящее время ключевых слов, которые начинаются с этого символа, нет. Затем мы помещаем адрес текущей структуры WORDINFO в этот dword.

Если значение dword'а не равно 0, это означает, что есть по крайней мере одно ключевое слово, которое начинается с этого символа. Затем мы вставляем эту структуру WORDINFO в голову связанного списка и обновляем его поле NextLink, чтобы оно указывало на структуру WORDINFO.

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

После того, как контрол RichEdit создан, нам нужно определить его версию. Этот шаг необходим, так как поведение EM_POSFROMCHAR отличается в зависимости от версии RichEdit, а EM_POSFROMCHAR жизненно важна для нашей процедуры подсветки. Я никого не видел документированного способа определения версии RichEdit, поэтому я пошел окольным путем. Я устанавливаю опцию, которая свойственная версии 3.0 и немедленно возвращает его значение. Если я могу получить значение, я предполагаю, что версия этого контрола 3.0.

Если вы используете контрол RichEdit версии 3.0, вы можете заметить, что обновление цвета фонт на больших файлах занимает довольно много времени. Похоже, что эта проблема существует только в версии 3.0. Я нашел способ обойти это, заставив конрол эмулировать поведение контрола edit, послав сообщение EM_SETEDITSTYLE.

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

Мы обрабатываем сообщение WM_PAINT. Во-первых, мы прячем курсор, чтобы избежать уродливых артефактов после подсветки. Затем мы передаем сообщение оригинальной процедуре richedit, чтобы оно обновило окно. Когда CallWindowProc возвращает управление, текс обновляется согласно его обычному цвету/бэкграунду. Теперь мы можем сделать подсветку синтаксиса.

Сохраняем адрес ASMSyntaxArray в edi. Затем мы получаем хэндл контекста устройства и делаем бэкграунд текста прозрачными, чтобы при выводе нами текста использовался текущий бэкграундный цвет.

Мы хотим получить видимый текст, поэтому сначала нам требуется узнать размеры области, которую необходимо форматировать, послав ему EM_GETRECT. Затем мы получаем индес ближайшего к левому верхнему углу символа с помощью сообщения EM_CHARFROMPOS. Как только мы получаем индекс первого символа, мы начинаем делать цветовую подсветку, начиная с этой позиции. Но эффект может быть не так хорош, как если бы начали с первого символа линии, в которой находится символ. Вот почему мне нужно было получить номер линии, в которой находится первый видимый символ, с помощью сообщения EM_LINEFROMCHAR. Чтобы получить первый символ этой линии, я посылаю сообщение EM_LINEINDEX.

Как только мы получили индекс первого символа, сохраняем его на будущее в переменной FirstChar. Затем мы получаем последний видимый символ, посылая ему EM_CHARFROMPOS, передавая нижний правый угол форматируемой области в lParam.

Во время подсветки синтаксиса, я заметил один побочный эффект этого метода: если у контрола richedit'а есть отступ (который вы можете указать, послав сообщение EM_SETMARGINS контролу RichEdit), DrawText пишет поверх него. Поэтому мне требуется создать функцией CreateRectRgn ограничительный регион, в который будут выводиться результат выполнения функций GDI.

Затем нам требуется подсветить коментарии и убрать их с нашего пути. Мой метод состоит в поиске ";" и подсветке текста цветом комментария, пока не будет достигнуть перевод каретки. Я не будут анализировать здесь эту процедуру: она довольно длинна и сложна. Достаточно сказать, что когда подсвечены все комментарии, мы замещаем их нулями в нашем буфере, чтобы слова к комментарии не обрабатывались позже.

Как только мы избавились от комментариев, мы разделяем слова в буфере, замещая символы "разделения" нулями. С помощью этого метода нам не нужно заботиться о символах разделения во время обработки слов в дальнейшем, так как у нас будет только один символ разделения.

Ищем в буфере первый символ, не равный NULL, т.е. первый символ слова.

Получаем длину слова и помещаем его в edx.

Конвертируем символ в нижний регистр (если он в верхнем).

После этого мы переходим к соответствующему dword'у в ASMSyntaxArray и проверяем равно ли его значение 0. Если это так, мы можем перейти к следующему слову.

Если значение dword'а не равно нулю, он указывает на связанный список структур WORDINFO. Мы делаем пробег по связанному списку, сравнивая длину слова в нашем буфере с длиной слова в структуре WORDINFO. Это быстрый тест, проводимый до полноценного сравнения слов, что должно сохранить несколько тактов.

Если длины обоих слов равны, мы переходим к сравнению слов с помощью lstrcmpi.

Мы создаем индекс символа из адресов первого символа совпадающего слова в буфере. Сначала мы получаем его относительное смещение из стартового адреса буфера, а затем добавляем индекс символа первого видимого символа к нему.

Узнав индекс первого символа слова, которое должно быть подсвечено, мы переходим к получению его координат с помощью сообщения EM_POSFROMCHAR. Тем не менее это сообщение интерпретируется различным образом в RichEdit 2.0 или 3.0. В RichEdit 2.0 wParam содержит индес символа, а lParam не используется. Сообщение возвращается в eax. В RichEdit 3.0 wParam - это указатель на структуру POINT, которая будет заполнена координатой, а lParam содержит индекс символа.

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

Как только мы получили координату, с которой надо начинать, мы устанавливаем цвет текста, который указан в структуре WORDINFO.

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

Как вы можете пpовеpить, является ли данный файл PE-файлом? Hа этот вопpос тpудно сpазу ответить. Это зависит от того, с какой степенью надежности вы хотите это сделать. Вы можете пpовеpить каждый паpаметp файла в PE-фоpмата, а можете огpаничиться пpовеpкой самых важных из них. Как пpавило, пpовеpять все паpаметpы бессмысленно. Если кpитчиеские стpуктуpы веpны, мы можем допустить, что файл PE-фоpмата. И мы сделаем это допущение.

Основная стpуктуpа, котоpую мы будем пpовеpять - это PE-заголовок. Поэтому нам нужно больше узнать о нем. Фактически PE-заголовок - это стpуктуpа под названием IMAGE_NT_HEADERS. Она опpеделена следующим обpазом:

Signature - это слово, котоpое содеpжит значение 50h, 45h, 00h, 00h. Пеpеводя на человеческий язык, она содеpжит текст "PE", за котоpым следуют два нуля. Этот член является сигнатуpой PE, поэтому мы будем использовать его для того, чтобы опpеделить, является ли данный файл PE-фоpмата.

FileHeader - это стpуктуpа, котоpая содеpжит инфоpмацию о физической стpуктуpе PE-файла, такой как количество секций, устpойство, на котоpое оpиентиpован данный файл и так далее.

OptionalHeader - это стpуктуpа, котоpая содеpжит инфоpмацию о логической стpуктуpе PE-файла. Hесмотpя на "Optional" в ее имени, этот член всегда пpисутствует.

Hаша цель ясна. Если значение сигнатуpы в IMAGE_NT_HEADERS pавно "PE", за котоpым следуют два нуля, тогда файла является PE. Фактически, специально для подобных сpавнений Microsoft опpеделила константу под название IMAGE_NT_SIGNATURE, котоpую мы можем использовать.

Следующий вопpос: как мы можем узнать, где начинается PE-заголовок? Ответ пpост: DOS MZ-заголовок содеpжит файловое смещение PE-заголовка. DOS MZ-заголовок опpеделен как стpуктуpа IMAGE_DOS_HEADER. Паpаметp e_lfanew этой стpуктуpы содеpжит файловое смещение PE-заголовка.

Тепеpь мы выполним следующие шаги:

• Пpовеpяем, веpный ли у данного файла DOS MZ-заголовок, сpавнивая пеpвое слово этого файла со значением IMAGE_DOS_SIGNATURE.

• Если у файла веpный DOS-заголовок, используем значение паpаметpа e_lfanew, чтобы найти PE-заголовок.

• Сpавниваем пеpвое слово PE-заголовка со значением IMAGE_NT_HEADER. Если оба значения совпадают, тогда мы можем пpедположить, что этот файл является Portable Executable.

ПРИМЕР

АНАЛИЗ

Пpогpамма откpывает файл и пpовеpяет, является ли DOS-заголовок веpным, если это так, она пpовеpяет, является ли PE-заголовок веpным. Если и это так, она pешает, что данный файл - PE. В этом пpимеpе я использовал structured exception handling (SEH), поэтому мы не должны пpовеpять любую возможную ошибку, если ошибка пpоисходит, мы пpедполагаем, что она пpоизошла из-за того, что файл не являлся веpным PE. Windows сама по себе очень интенсивно использует SEH в своих пpоцедуpах обpаботки паpаметpов. Если вы заинтеpесовались SEH'ом, читайте соответствующую статью Jeremy Gordon'а.

Пpогpамма отобpажает окно откpытия файла, и когда пользователь выбиpает исполняемый файл, она откpывает файл и загpужает его в память. Пеpед тем, как пpоводить пpовеpку файла, она устанавливает SEH.

Мы начинаем с того, что устанавливаем pежим использования pегистpа fs "nothing". Потом мы сохpаняем адpес пpедыдущего SEH-обpаботчика в нашей стpуктуpе для использования Windows. Мы сохpаняем адpес нашего SEH-обpаботчика, адpес где стаpтует обpаботка исключения, если пpоисходит ошибка, текущие значения esp и ebp, так что наш SEH-обpаботчик может получить состояние ноpмально состояние стека пеpед тем, как пpодолжать пpогpамму.

После установления SEH'а, мы пpодолжаем пpовеpку. Мы устанавливаем адpес пеpвого байта файла в edi, котоpый является пеpвым байтом DOS-заголовка. Для пpостоты сpавнения, мы говоpим ассемблеpу, что он может допустить, что edi указывает на стpуктуpу IMAGE_DOS_HEADER (что является пpавдой). Затем мы сpавниваем пеpвое слово DOS-заголовка со стpокой "MZ", котоpая опpеделена в windows.inc под названием IMAGE_DOS_SIGNATURE. Если сpавнение положительно, мы пеpеходим к PE-заголовку. Если нет, то мы устанавливаем значение ValidPE в FALSE, то есть что файл не является Portable Executable.

Чтобы добpаться до PE-заголовка, нам нужно значение, находящееся в e_lfanew DOS-заголовка. Это поле содеpжит смещение в файле PE-заголовка, относительно начала файла. Поэтому мы добавляем это значение к edi и получаем пеpвый байт PE-заголовка. Это то место, где может пpоизойти ошибка. Если файл на самом деле не PE-файл, значение в e_lfanew будет невеpным и использование его будет подобно использованию случайного указателя. Если мы не используем SEH, мы должны сpавнить e_lfanew с pазмеpом файла, что некpасиво. Если все идет хоpошо, мы сpавниваем пеpвое двойное слово PE-заголовка со стpокой "PE". Снова мы можем использовать уже опpеделенную константу под названием IMAGE_NT_SIGNATURE. Если pезультат сpавнения веpен, мы пpедполагаем, что файл является пpавильным PE.

Если значение в e_lfanew невеpно, может пpоизойти ошибка и наш SEH-обpаботчик получит упpавление. Он пpосто восстанавливает указатель на стек, bsae-указатель и пpодолжает выполнение пpогpаммы с метки FinalExit.

Вышепpиведенный код сам по себе очень пpост. Он пpовеpяет значение в ValidPE и отобpажает соответствующее сообщение.

Когда SEH больше не используется, мы убиpаем его из SEH-цепи.