assembler. Учебник для вузов_Юров В.И_2003 -637с (862834), страница 86
Текст из файла (страница 86)
int nYStart,{LPCTSTR IpString, int cbString )pushMesWindowLenpushoffset MesWindowpush100push10push@@hdccallTextOutA{освободить контекст;BOOL EndPaint( HWND hWnd, CONST PAINTSTRUCT *lpPaint )pushoffset pspush@@hdccallEndPaintmoveax, 0 {возвращаемое значение - 0jmpexit_wndprocwmdestroy :pushSND SYNC+SND FILENAMEpushNULLpushoffset playFileDestroycallPlaySoundA{послать сообщение WM_QUIT{готовим вызов VOID PostQui tMessage( int nExitCode )push0callPostQuitMessagemoveax, 0 {возвращаемое значение - 0jmpexit_wndprocdefault:{обработка по умолчанию{готовим вызов LRESULT DefWindowProc( HWND hWnd, UINT Msg,{WPARAM wParam, LPARAM IParam )push@@lparampush@@wparampush@@mespush@@hwndcallDefWindowProcAjmpexit_wndproc383<212><213><214><215><216><217><218><219><220><221><222><223><224><225><226><227><228><229>\•••<230> exit wndproc:<231>ret<232> WindowProc endp<233>end startКаркасное Windows-приложение на ассемблере содержит один сегмент данных.data и один сегмент кода .code.
Сегмент стека в исходных текстах Windows-приложений непосредственно описывать не нужно. Windows выделяет для стека объемпамяти, размер которого задан программистом в файле с расширением .def. Текстлистинга 16.4 довольно большой. Поэтому для обсуждения разобьем его коммен-384Глава 16. Создание Windows-приложений на ассемблеретариями на характерные фрагменты, каждый из которых затем поясним с необходимой степенью детализации.Строка 3. Все символические имена в программе на ассемблере по умолчаниюявляются глобальными. Задание директивы LOCALS включает в трансляторе механизм контроля областей видимости имен и позволяет использовать в программелокальные имена (см. главу 10).Строка 4. Директива .MODELsaflaeT модель сегментации (flat) и стиль генерации(см. главу 15) кода при входе в процедуры программы и выходе из них (stdcall).Модель памяти flat обозначает плоскую модель памяти.
В соответствии с этой моделью компилятор создает программу, которая содержит один 32-разрядный сегмент для данных и кода программы. Код загрузочного модуля, генерируемыйс параметром flat, будет работать на процессорах 1386 и выше. По этой причинедирективе .MODEL должна предшествовать одна из директив: .386, .486 или .586.Указание этой модели памяти заставляет компоновщик создать исполняемый файлс расширением .ехе. В программе с плоской моделью памяти используется адресация программного кода и данных типа near.
Это же касается и атрибута расстоянияв директиве PROC, который также имеет тип near. Параметр stdcall определяет порядок передачи параметров через стек так, как это принято в языке C/C++, то естьсправа налево. Этот параметр задает генерацию кода эпилога, который очищаетстек по завершении работы процедуры (в стиле языка Pascal) от аргументов, переданных в эту процедуру при вызове. Такая передача параметров очень удобна приразработке Windows-приложений: программист может помещать параметры в стекв прямом порядке, и ему не нужно заботиться об очистке стека после окончанияработы процедуры.Строка 7. Директива INCLUDE включает в программу файл windowA.inc.
Для чегонужен этот файл? Вы, наверняка, имеете некоторый опыт разработки Windowsприложений на C/C++ и знаете, что функции Win32 API в качестве передаваемыхим параметров используют множество констант и данных определенной структуры. В пакете компилятора C/C++ эти данные расположены в заголовочных файлах, совокупность которых можно рассматривать как дерево с корнем в файлеwindows.h. Для того чтобы эти описания стали доступны приложению на C/C++, в егоначало включается директива ^include <windows.h> (см.
листинг 16.1). Windowsприложение на ассемблере также использует вызовы функций Win32 API, поэтому в нем должны быть выполнены аналогичные действия по определению необходимых констант и структур. Но просто взять из пакета C/C++ и затем использоватьв программе на ассемблере файл windows.h и связанные с ним файлы напрямуюнельзя. Причина банальна: транслятор ассемблера не понимает синтаксиса C/C++.Что делать? Пакет Т ASM предоставляет в распоряжение программиста утилитыh2ash.exe и h2ash32.exe, которые должны помочь ему конвертировать содержимоевключаемых файлов на языке C/C++ во включаемые файлы ассемблера. Однако,исходя из опыта, не стоит питать особых надежд на эффективность их работы.Поэтому проще формировать ассемблерный включаемый файл с описанием констант и структур Windows самостоятельно.
Кстати, пакет TASM 5.0 предоставляет в распоряжение программиста вариант такого включаемого файла win32.inc. Егоможно найти среди прилагаемых к книге файлов в каталоге к данной главе, ноКаркасное Windows-приложение на ассемблере385пользоваться им нужно с осторожностью, так как его содержимое не совсем актуально. Например, файл Win32.inc содержит описание структуры WNDCLASS, но в немотсутствует расширенный вариант этой структуры WNDCLASSEX, который требуется в расширенном варианте функции RegisterCtassExA.
Как решить проблему актуальности описаний? Проще всего сделать это, используя включаемые файлы последних на текущий момент времени версий компилятора C/C++ (сейчас это,например, VC++ 6.0 и 7.0). Это один из основных источников подобной информации, актуальность которой к тому же гарантирована разработчиком компилятора, являющегося одновременно и создателем операционной системы Windows.Поэтому программирование на ассемблере для Windows предполагает, что вы хорошо умеете ориентироваться во включаемых файлах компилятора C/C++.
Полностью пытаться конвертировать эти файлы не имеет смысла. Более правильноизвлекать из них по мере необходимости описание нужных данных, приводить ихв соответствие требованиям синтаксиса ассемблера и после этого записывать в некоторый свой файл, который будет играть роль файла windows.h. Для Windowsприложений данной главы вам предлагается вариант такого включаемого файла — windowA.inc, который включается в текст приложения директивой i n c l u d ewindowA.inc.
Файл windowA.inc имеется среди файлов, прилагаемых к книге. Егоможно взять за основу для дальнейшей работы и наращивать по мере необходимости.Строки 9-33. Функции Win32 API, используемые в программе, должны бытьобъявлены внешними с помощью директивы EXTRN. Это необходимо для того, чтобы компилятор мог сгенерировать правильный код, так как тела функций Win32API содержатся в библиотеках DLL системы Windows.Имейте в виду, что в различных источниках встречаются разные названия, казалось бы, одной и той же функции. Необходимо правильно понимать их. Например, уже упомянутая функция RegisterClass может иметь названия RegisterClassExAили RegisterClassExW.
На самом деле две последние функции являются более современными вариантами RegisterClass. Для разрешения подобных коллизий приходитсяобращаться к первоисточникам — документации с описанием функций Win32 API(помните, что она также может оказаться устаревшей). Самый лучший источниктакой информации — включаемые файлы компилятора C/C++. Например, описание функции RegisterClass(ExA) содержится в файле winuser.h. В листинге 16.5 приведены строки из этого файла.Листинг 16.5. Фрагмент файла winuser.h (VC++ 6.0)<1> WINUSERAPI ATOM WINAPI RegisterClassA(CONST WNOCLASSA " I p W n d C l a s s ) ;<2> WINUSERAPI ATOM WINAPI R e g i s t e r C l a s s W ( C O N S T WNDCLASSW 'IpWndClass);<3> #ifdef UNICODE<4> #define R e g i s t e r C l a s s R e g i s t e r C l a s s W<S> #else<6> #define RegisterClass RegisterClassA<7> #endif // IUNICODE<8> #if(WINVER >= 0x0400)<9> WINUSERAPI ATOM WINAPI RegisterClassExA(CONST WNDCLAS5EXA *);<10>WINUSERAPI ATOM WINAPI RegisterClassExW(CONST WNDCLASSEXW *);<11>#ifdef UNICODE<12>#define Regi sterClassEx RegisterClassExW.л.продолжение &13 Ззк.
256386Глава 1 6. Создание Windows-приложений на ассемблереЛистинг 16.5 (продолжение)<14><15>#else#define RegisterClassEx RegisterClassExAtfendif// IUNICODEПоследние версии операционных систем Windows поддерживают две системыкодировки символов: однобайтную (ANSI) и двухбайтную (UNICODE). Поддержка кодировки UNICODE была введена Microsoft, чтобы облегчить локализациюпрограммных продуктов на неанглоязычном рынке.
Операционная системаWindows NT поддерживает только кодировку UNICODE. Операционная системаWindows 95/98 имеет довольно плохо скрытое наследие MS-DOS и не поддерживает в своей внутренней работе кодировку UNICODE (она поддерживается лишьна уровне функций Win32 API). Для работы с обеими кодировками программныйинтерфейс Win32 API имеет два варианта функций. Эти функции различаютсяпоследним символом в названии. Если это А, то данная функция работает в кодировке ANSI, если W, то функция работает в кодировке UNICODE. Следующиймомент, требующий пояснения, — наличие суффикса Ех в названиях функций.Объяснение этому можно найти в листинге 16.5.