Создание Windows приложений на ассемблере

Обоснование необходимости разработки windows приложений на ассемблере:

1. Язык ассемблера позволяет программисту полностью контролировать создаваемый им программный код и оптимизировать его по своему усмотрению.

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

3. При программировании на ассемблере сохраняется полный доступ к аппаратным ресурсам компьютера.

4. Приложение, написанное на ассемблере, быстрее загружается в оперативную память.

5. Приложение на ассемблере обладает более высокой скоростью работы и реактивностью ответа на действия пользователя.

Минимальное приложение windows состоит из 3 частей:

1. Цикл обработки сообщений

2. Оконная функция

3. Главная функция

Имея исходный файл windows приложения на языке C или C++ можно получить текст на языке ассемблера. Необходимо дисассемблировать исполняемый модуль программы. Причём сделать это нужно тем дисассемблером, который понимает интерфейс Win32API. Дисассемблированный файл можно сохранить как листинг с расширением «.lst» или как исходный текст ассемблера «.asm».Файл листинга в своей левой части содержит колонку с адресами смещения команд. Все метки и имена в дисассемблированном тексте формируются с использованием этих смещений.

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

Каркасное windows приложение на ассемблере содержит 1 сегмент данных, 1 сегмент кода, а вот сегмент стека описывать не нужно. Windows выделяет для стека объём памяти размер которого задаётся программистом в файле с расширением «.def». все символические имена в программе на ассемблере по умолчанию являются глобальными. Задание директивы locals включает в трансляторе механизм контроля областей видимости имён и позволяет использовать в программе локальные имена. К символическим именам, которые необходимо сделать локальными, должна предшествовать последовательность не менее чем из 2 символов. Эти символы задаются как параметры директивы locals. Если этого не сделать, то по умолчанию будет использоваться последовательность «@@». Блоком в пределах которого можно объявить локальные имена может быть не только функция, но и участок программы между 2 метками.

Директива.model задаёт модель сегментации flat и стиль генерации кода при входе процедуры программы и выходе из них STDCALL. Код загрузочного модуля, генерируемого с опцией flat будет работать на микропроцессорах.386 и старше. По этой причине директиве.model должна предшествовать одна из директив “.386”, “.486”, “.586”. указание этой модели памяти заставляет компоновщик создавать исполняемый файл с расширением «.exe». В программе с плоской моделью памяти используются адресация программного кода near. Параметр stdcall определяет порядок передачи параметров через стек с права налево. Функции win32API используемые в программе должны быть объявлены внешними с помощью директивы extrn. Это необходимо сделать для того, чтобы компилятор мог сгенерировать правильный код т.к. тела функций win32API содержатся в dll библиотеках системы. в соответствии с соглашениями операционной системы windows оконная функция приложения должна быть видимой за пределами приложения в котором написана. Это связанно с тем, что оконная функция вызывается самой операционной системой windows при поступлении сообщения для данного приложения. Загрузчик windows самостоятельно загружает сегментные регистры, при этом учитывается требуемая модель памяти.

Под классом окна понимается совокупность присущих ему характеристик (формы границ, стиль границ, цвет фона, наличие меню и т.д.). Характеристики окна описываются с помощью особой структуры WND CLASS. В сегменте данных определён экземпляр структуры WNDCLASSEX-wcl.

Первое поле структуры wndclasssex должно определять длину структуры.

Поле style определяет стиль границ окна и его поведение при перерисовки. Значение стиля представляет собой целочисленное значение формируемое из констант.

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

В поля hIcon и hCursor загружаются дескрипторы значка и курсора. После запуска приложения значок будет отображается на панели задач и в левом верхнем углу приложения, а курсор появится в области окна.

Поле hBrBakground должно содержать значение дескриптора кисти. Для получения такого дескриптора необходимо использовать функцию GetStockObject. В качестве параметра ей передаётся имя нужной кисти.

Поле LpszMenuName записывается указатель на ASCIIZ строку с именем меню. Если меню не используется, в поле записывается значение NULL.

Последние действие при описании класса окна – это присвоение данному классу уникального имени. Это имя описано в виде строки поля szClassName сегмента данных.

После инициализации структуры необходимо зарегистрировать класс окна в системе. Это действие выполняется с помощью функции RegisterClassExA, которой в качестве параметра передаётся указатель на структуру WNDCLASSEX. Оконная функция предназначенная для организации адекватной реакции со стороны приложения на действия пользователя и поддержания в актуальном состоянии того окна приложения сообщения которого она обрабатывает. Приложение может иметь несколько оконных функций их количество определяется количеством классов окна зарегистрированных в системе. Когда для окна windows приложения появляется сообщение, ОС windows производит вызов соответствующей оконной функции. Сообщение, в зависимости от источника их появления в оконной функции могут быть 2 типов: синхронные и асинхронные.

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

Компиляция синхронных и асинхронных сообщений обрабатывает ОС. Если рассматривать синхронное сообщение, то его извлечение производится функцией GetMessage с последующей передачей его обратно в windows функцией DispatchMessage. Асинхронное сообщение, не зависимо от источника, который инициализирует его появление, сначала попадает в windows, а затем в нужную оконную функцию. Windows требует, чтобы оконная функция сохраняла значения регистров edi, esi, ebi. Причина в том, что функция должна быть рекурсивной. Возможна ситуация, когда несколько классов окон используют одну и ту же оконную функцию для обработки сообщений, поступающих в, создание на базе этих классов, окна. Имеет смысл сохранять и другие регистры если они задействованы в оконной функции. Исходя из требования рекурсивности все переменные, используемые в оконной функции должны быть локальными.

Чтобы удовлетворить требование сохранения регистров лучше использовать соответствующее средство транслятора ассемблера – директиву uses. При её использовании транслятор вставляет в начало и в конец соответствующую последовательность команд ассемблера.

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

Дата добавления: 2015-11-26