В этой статье я покажу как написать приложение для windows на ассемблере. В качестве IDE будет привычная Visual Studio 2019 со своими плюшками - подсветка кода, отладка и привычный просмотр локальных переменных и регистров. Собирать приложение будет MASM, а значит, у нас будут и чисто масмовские плюшки. Приложением будет игра в пятнашки. С одной стороны это просто, но не так чтобы совсем хелловорлд (впрочем хелловорлд мы тоже увидим во время настройки VS). С другой стороны это будет полноценное оконное приложение с меню, иконкой, отрисовкой, выводом текста и обработкой мыши с клавиатурой. Изначально у меня была мысль сделать что-нибудь поинтереснее пятнашек, но я быстро передумал. Сложность и размер статьи увеличивается значительно, а она и так получилась немаленькая. Новой же информации сильно больше не становится. Статья рассчитана на тех, кто имеет хотя бы начальные знания ассемблера, поэтому здесь не будет всяких мелочей из разряда как поделить одно число на другое или что делает команда mov. Иначе объем пришлось бы увеличить раза в три.
Заранее постараюсь ответить на вопрос - зачем это нужно, если на ассемблере сейчас уже никто не пишет? Есть пара объективных причин и одна субъективная. Из объективного - написание подобных программ позволяет понять внутреннее устройство windows и как в конечном итоге наш код исполняется на процессоре. Далеко не всем это действительно надо, но для некоторых вещей это обязательное знание. Вторая причина это то, что позволяет взглянуть на разработку немного под другим углом. Примерно так же как попробовать функциональное программирование полезно даже если не писать ничего в функциональном стиле. К примеру я слушал лекции Мартина Одерски вовсе не потому что решил перейти с C# на Scala. Полезно посмотреть на привычную разработку под другим углом. Субъективная же причина - для меня это было просто интересно, отойти от коммерческой разработки, этого цикла задач, спринтов, митингов, сроков и заняться тем, что интересно именно тебе.
Так получилось что у меня появилось много свободного времени, часть из которого я потратил на то, что называется пет-проектами. Это не стало какими-то production-ready вещами, скорее какие-то идеи интересные лично мне, что-то на что вечно не хватало времени. Одна из этих идей это ассемблер в современной IDE. Давно хотел этим заняться, но все не было времени. Мне было очень интересно со всем этим разбираться, надеюсь читателям тоже понравится.
Шаг первый - настраиваем VS
Тут я немного схитрил. Точнее так уж получилось, что здесь все уже сделано за нас. Есть пошаговая инструкция и даже готовый пустой проект. Можно воспользоваться пошаговой инструкцией, а я просто скачал пустой проект и переименовал SampleASM в FifteenAsm. Единственное, что надо сделать помимо переименования, это установить SubSystem : Windows в свойствах проекта (properties > Linker > System > SubSystem : Windows). Далее выбираем x86, нажимаем F5 (либо кликаем мышкой) и видим вот такое сообщение:
Теперь о подсветке синтаксиса. Тут есть разные пути, и я решил поискать что есть готового. Готового оказалось немного, я установил Asm-Dude. Также попробовал ChAsm, но внешний вид меня не порадовал. Впрочем внешний вид это дело вкуса, я остановился на Asm-Dude. Тут правда есть такой нюанс - Asm-Dude не поддерживает VS 2022, самая старшая версия VS 2019. Вот так выглядит все в сборе - дебаг, просмотр переменных, в т.ч. нормальное отображение структур, мнемоника для ассемблера.
Теперь еще одна вещь, о которой хочется рассказать, прежде чем приступить к основной части. Это MASM SDK. Это совсем необязательная вещь, но очень полезная. Там есть готовые inc файлы для WinAPI, а еще есть много примеров самых разных приложений на ассемблере. Но проект из этой статьи будет работать и без него.
Шаг второй - оконное приложение
Для того чтобы создать окно средствами WinAPI нужно немного. Заполнить специальную структуру с описанием этого окна, зарегистрировать класс окна, потом это окно создать. Вот практически и все. Еще нам нужна так называемая оконная процедура, или процедура обработки сообщений, называют ее по разному. Суть этой процедуры в обработке сообщений которые приходят в наше приложение. Клики мышкой, команды меню, отрисовка и вообще все специфическое поведение нашего приложения будет там. Со всеми подробностями написано здесь.
О вызове функций вообще и WinAPI в частности
Чтобы вызвать функцию, ее надо объявить. Ниже разные способы это сделать.
extern MessageBoxA@16 : PROC
MessageBoxA PROTO, hWnd:DWORD, pText:PTR BYTE, pCaption:PTR BYTE, style:DWORD
MessageBoxW PROTO, :DWORD,:DWORD,:DWORD,:DWORD
Объявление со списком параметров более понятно. Хотя именовать параметры и необязательно. Объявлением с extern я пользоваться не буду, оставим это для любителей разгадывать ребусы. Что такое A(или W) в имени функции? Это указание на тип строк, A - ANSI, W - Unicode. Для простоты дела я решил не связываться с юникодом и везде использовал ANSI версии. Обычно же применяют дефайн примерно такого вида:
#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif
Теперь о вызовах функций, "стандартный" для ассемблера вызов выглядит так
push 0
push offset caption
push offset text
push 0
call MessageBoxA
Существует мнемоническое правило для порядка аргументов - слева направо - снизу вверх. Иными словами первый аргумент в объявлении функции (здесь это хендл окна hWnd:DWORD) будет в самом нижнем push. К счастью в MASM есть очень удобная вещь - invoke. Вот так выглядит вызов той же самой функции.
invoke MessageBoxA, 0, offset howToText, offset caption, 0
Одна строчка вместо пяти. На мой взгляд invoke удобнее за редкими исключениями типа большого числа аргументов. В дальнейшем практически везде я буду пользоваться invoke.
Сигнатура, описание и примеры использования функций WinAPI легко гуглятся по их названию. На примере MessageBoxA мы увидим вот это
int MessageBoxA(
[in, optional] HWND hWnd,
[in, optional] LPCSTR lpText,
[in, optional] LPCSTR lpCaption,
[in] UINT uType
);
Осталось перевести все эти HWND и LPCSTR в соответствующие типы для ассемблера. Тип данных LPCSTR будет DWORD, ведь это просто ссылка. Олдфаги с легкостью узнают венгерскую нотацию, а название типа расшифровывается как Long Pointer Const String. HWND тоже будет просто DWORD, ведь HWND, как и LPCSTR по своей сути просто ссылка. Ну а UINT это DWORD просто по определению. В некотором роде сигнатура функций на ассемблере даже проще, ссылка здесь это просто ссылка, нет кучи разных типов.
Отсюда следует важный вывод - нет никаких специальных "ассемблерных" функций, это то же самое WinAPI !. Нам достаточно знать как решается нужная нам задача средствами WinAPI, неважно на каком языке они будут вызываться. Поэтому задача "вывести текст в окно средствами ассемблера" на самом деле будет "вывести текст в окно средствами WinAPI", а уж информации по WinAPI полно. Обратное тоже верно, зная как что-то сделать средствами WinAPI это можно сделать на практически любом языке. А это уже часто бывает полезно при написании скриптов.
Создаем простое окно
Перед созданием окна я сделал три inc-файла. Один с прототипами WinAPI, другой с константами приложения (ширина окна, заголовок, цвет заливки и все в таком же духе) и третий, со структурами WinAPI и целой кучей винапишных констант. Теперь можно писать NULL или TRUE/FALSE. Или MB_OK вместо 0, как в примере выше с MessageBoxA. Никаких специфических действий не нужно, просто Add - New Item - Text File и не забываем include filename. Файлики назвал WinApiProto.inc, WinApiConstants.inc, AppConstants.inc. Пример содержимого показан ниже.
Вот так теперь выглядит наш код
.386
.model flat, stdcall
.stack 4096
include WinApiConstants.inc
include WinApiProto.inc
.data
include AppConstants.inc
.code
main PROC
;...more code
Небольшое отступление про строки. Вот пример строковых констант
szClassName db "Fifteen_Class", 0
howToText db "The first line", CR , LF , "The second.", 0
Запятая означает конкатенацию, db это define byte, CR LF определены в WinApiConstants.inc (13 и 10 соответственно), ноль на конце это null-terminated строка. В итоге строки это никакой не специальный тип данных, а просто массивы байт с нулем на конце. В случае с юникодом возни было бы больше, но я решил не усложнять себе жизнь и использовать везде ANSI строки.
Вот мы и добрались до создания окна. Для этого нам надо
-
заполнить структуру WNDCLASSEX (объявлена в WinApiConstants)
-
зарегистрировать класс окна
-
создать процедуру главного окна
-
создать окно
Кода вышло уже почти на 200 строк, поэтому я покажу самые интересные куски, целиком можно посмотреть на гитхабе.
Объявление и заполнение WNDCLASSEX, как видим все как в языках высокого уровня. Ну, почти все - автодополнения со списком полей структуры нет.
WNDCLASSEX STRUCT
cbSize DWORD ?
style DWORD ?
lpfnWndProc DWORD ?
WNDCLASSEX ENDS
mov wc.cbSize, sizeof WNDCLASSEX
mov wc.style, CS_BYTEALIGNWINDOW
mov wc.lpfnWndProc, offset WndProc
При создании окна весьма важный параметр WS_EX_COMPOSITED. Без него при перерисовке будет мерзкий flickering. Очень хорошо что это работает - реализовывать двойную буферизацию самостоятельно желания не было.
push WS_EX_OVERLAPPEDWINDOW or WS_EX_COMPOSITED
call CreateWindowExA
Теперь немного чудесных директив MASM. Вот так вот просто организован цикл обработки сообщений
; Loop until PostQuitMessage is sent
.WHILE TRUE
invoke GetMessageA, ADDR msg, NULL, 0, 0
.BREAK .IF (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessageA, ADDR msg
.ENDW
А вот так без них
StartLoop:
push 0
push 0
push 0
lea eax, msg
push eax
call GetMessageA
cmp eax, 0
je ExitLoop
lea eax, msg
push eax
call TranslateMessage
lea eax, msg
push eax
call DispatchMessageA
jmp StartLoop
ExitLoop:
А вот как все просто в оконной процедуре. Никаких тебе cmp uMsg, WM_DESTROY, кучи меток, простой IF
.IF uMsg == WM_DESTROY
invoke PostQuitMessage, NULL
xor eax, eax
ret
.ENDIF
Вот как делается подтверждение на закрытие окна
.IF uMsg == WM_CLOSE
invoke MessageBoxA, hwin, ADDR exitConfirmationText, ADDR caption, MB_YESNO
.IF eax == IDNO
xor eax, eax
ret
.ENDIF
.ENDIF
Обещанный хелловорлд готов.
Добавляем иконку и меню
Иконка и меню в мире windows относятся к ресурсам. Поэтому добавляем к нашему проекту файл ресурсов - Add - Resource - Menu. Дальше можно воспользоваться встроенным редактором VS, я просто взял и отредактировал свежий файл FifteenAsm.rc в блокноте. Получилось вот так
500 ICON MOVEABLE PURE LOADONCALL DISCARDABLE "FIFTEENICON.ICO"
600 MENUEX MOVEABLE IMPURE LOADONCALL DISCARDABLE
BEGIN
POPUP "&File", , , 0
BEGIN
MENUITEM "&New Game", 1100
MENUITEM "&Exit", 1000
END
POPUP "&Help", , , 0
BEGIN
MENUITEM "&How to play", 1800
MENUITEM "&About", 1900
END
END
Обратите внимание на магические числа 500 и 600. Это идентификаторы ресурсов, совсем скоро мы увидим зачем они нужны. Также обратите внимание на магические числа 1000, 1100, 1800, 1900. Это идентификаторы команд, мы тоже увидим зачем они нужны, но чуть позже. Чуть не забыл про сам файл иконки, нарисовал я ее в каком-то онлайн редакторе. Дизайнер из меня так себе, поэтому что получилось, то получилось. Добавляем в проект под именем Fifteenicon.ico, тут главное назвать точно как в файле ресурсов. Дальше все просто. Иконка добавляется на этапе заполнения структуры WNDCLASSEX, тут у нас магическое число 500
push 500
push hInst
call LoadIconA
mov wc.hIcon, eax
Меню добавляется после создания окна, здесь магическое число 600
call CreateWindowExA
mov hWnd,eax
push 600
push hInst
call LoadMenuA
push eax
push hWnd
call SetMenu
А вот так обрабатываются команды меню, тут остальные магические числа 1000, 1100, 1800, 1900. Вообще с использованием MASM код не особо отличается от кода на тех же плюсах.
.IF uMsg == WM_COMMAND
.IF wParam == 1000
invoke SendMessageA, hwin, WM_SYSCOMMAND, SC_CLOSE, NULL
.ENDIF
.IF wParam == 1100
invoke MessageBoxA, hwin, ADDR newGameConfirmationText, ADDR caption, MB_YESNO
.IF eax == IDYES
;call InitTilesData
.ELSEIF eax == IDNO
xor eax, eax
ret
.ENDIF
.ENDIF
.IF wParam == 1800
invoke MessageBoxA, hwin, ADDR howToText, ADDR caption, MB_OK
.ENDIF
.IF wParam == 1900
invoke MessageBoxA, hwin, ADDR aboutText, ADDR caption, MB_OK
.ENDIF
.ENDIF
У приложения появилась иконка и есть меню. Ради интереса посмотрел на размер исполняемого файла, всего 6656 байт.
Шаг третий - игра
Создали окно, пора заняться самой игрой. Здесь я тоже покажу только самые интересные места.
Инициализация данных и начальная перетасовка
Данные о положении тайлов будут храниться в массиве из 16 байт. Ноль будет положением пустого тайла, значения от 1 до 15 соответствующие тайлы. Нумерация индексов тайлов слева направо, сверху вниз. Теперь надо их перетасовать и тут встает вопрос, откуда брать случайные числа? RDRAND и RDSEED появились достаточно поздно, а мне хотелось сделать код в "классическом" стиле. Сгоряча я даже думал реализовать Вихрь Мерсенна, но потом решил что это перебор. Поэтому честно нашел простенький ГПСЧ буквально в десяток команд, для seed использовал системное время. Идея начальной перетасовки простая, сначала заполняем массив по порядку (приводим в конечное состояние), а потом случайным образом двигаем тайлы. Тайлы двигаются по правилам, значит их всегда можно будет собрать в конечное положение. Если заполнять тайлы совсем рандомно, то надо проверять можно ли вообще собрать такую комбинацию. По опыту уже 100 итераций перемешивает тайлы вполне нормально.
local randSeed : DWORD
invoke GetTickCount
mov randSeed, eax
xor eax, eax
xor ebx, ebx
xor ebx, ebx
.WHILE ebx < initialSwapCount
mov eax, 4; random numbers count, i.e. from 0 to 3
push edx
imul edx, randSeed, prndMagicNumber
inc edx
mov randSeed, edx
mul edx
mov eax, edx
pop edx
add al, VK_LEFT
push ebx
invoke ProcessArrow, NULL, al; move a tile
pop ebx
inc ebx
.ENDW
ret
Отрисовка
Добавляем обработку WM_PAINT в оконной процедуре
LOCAL Ps :PAINTSTRUCT
LOCAL hDC :DWORD
.IF uMsg == WM_PAINT
invoke BeginPaint, hWin, ADDR Ps
mov hDC, eax
invoke PaintProc, hWin, hDC
invoke EndPaint, hWin, ADDR Ps
.ENDIF
Отрисовка тайлов. Из интересного здесь организация двойного цикла с использованием директив MASM WHILE и передача указателя на RECT в процедуре CalculateTileRect.
LOCAL Rct : RECT
invoke CreateSolidBrush, tileBackgroundColor
mov hBrush, eax
invoke SelectObject, hDC, hBrush
;fill tiles with background color
mov vert, 0
.WHILE vert < 4
mov hor, 0
.WHILE hor < 4
invoke CalculateTileRect, ADDR Rct, hor, vert
invoke RoundRect, hDC, Rct.left, Rct.top, Rct.right, Rct.bottom,
tileRoundedEllipseSize, tileRoundedEllipseSize
inc hor
.ENDW
inc vert
.ENDW
invoke DeleteObject, hBrush
CalculateTileRect proc rct :DWORD, hor:BYTE, vert:BYTE
mov edx, rct
invoke CalculateTileRectPos, hor, 0
mov (RECT PTR [edx]).left, eax
ret
CalculateTileRect endp
Обратите внимание на эту строчку. Структура передана по ссылке, смещение на left вычисляется автоматически.
mov (RECT PTR [edx]).left, eax
А вот как работает IntToStr (почти что честный) на ассемблере. Писать честный IntToStr мне не хотелось, поэтому я тут схитрил. Завел массив из 3 байт под строку, второй и третий байты сразу обнуляются. Числа бывают от 1 до 15, поэтому если число было меньше 10, то к значению прибавляем магическое число 48 (ASCII код для нуля) и получаем нужный первый байт буфера. Получается тоже самое что и на Си, когда пишем c = '0' + i. Поскольку второй байт уже нулевой у нас получается готовая null-terminated строка, неважно что буфер из 3 байт. Если число больше 9, то первая цифра всегда 1, а вторая это остаток от деления на 10. Тут уже третий байт играет роль конца строки.
mov [buffer+1], 0
mov [buffer+2], 0
.IF bl < 10
add bl, asciiShift
mov [buffer], bl
sub bl, asciiShift
.ELSEIF bl > 9
mov al, asciiShift
inc al
mov [buffer], al
xor ax, ax
mov al, bl
mov cl, 10
div cl
add ah, asciiShift
mov [buffer+1], ah
.ENDIF
Вот так выглядит игровое поле
Добавляем интерактив
Для управления можно пользоваться курсором или кликать мышкой по тайлу, который надо переместить, благо вариант перемещения только один. Перемещение сводится к тому чтобы в массиве тайлов поменять местами перемещаемый и нулевой тайл. Смещение нулевого тайла будет +1/-1 для перемещений вправо/влево и +4/-4 для перемещения вверх/вниз. Путь у тайла только один, поэтому надо только проверить выход за диапазон и поменять местами два элемента в массиве тайлов. Если тайл переместился, то перерисовать окно. Добавим вот такие обработчики в нашу оконную процедуру.
.IF uMsg == WM_KEYDOWN
.if wParam == VK_LEFT
invoke ProcessArrow, hWin, wParam
.elseif wParam == VK_RIGHT
invoke ProcessArrow, hWin, wParam
.elseif wParam == VK_UP
invoke ProcessArrow, hWin, wParam
.elseif wParam == VK_DOWN
invoke ProcessArrow, hWin, wParam
.endif
.ENDIF
.IF uMsg == WM_LBUTTONUP
invoke ProcessClick, hWin, lParam
.ENDIF
Сначала посмотрим как реализовано перемещение тайлов курсором. Вот немного укороченная версия процедуры ProcessArrow. FindEmptyTileIndex возвращает в регистре eax индекс пустого тайла . В зависимости от нажатой клавиши проверяем выход за границы диапазона, т.е. можно ли переместить тайл в данной позиции в данном направлении. Если нельзя, уходим на метку pass в конец процедуры, если можно, то вызываем последовательно SwapTiles, RedrawWindow и ProcessPossibleWin.
ProcessArrow proc hWin:DWORD, key:DWORD
call FindEmptyTileIndex
.IF key == VK_UP
cmp eax, 12
ja pass
;when tile goes up, new empty tile index (ETI) will be ETI+4,
mov ebx, eax
add ebx, 4
.ENDIF
.IF key == VK_RIGHT
;empty tile shouldnt be on 0, 4, 8, 12 indexes
cmp eax, 0
je pass
cmp eax, 4
je pass
cmp eax, 8
je pass
cmp eax, 12
je pass
;when tile goes right, new empty tile index (ETI) will be ETI-1,
mov ebx, eax
dec ebx
.ENDIF
invoke SwapTiles, eax, ebx
.IF hWin != NULL ;little trick to simplify initial random data
invoke RedrawWindow, hWin, NULL, NULL, RDW_INVALIDATE
invoke ProcessPossibleWin, hWin
.ENDIF
pass:
ret
ProcessArrow endp
Для перемещения тайла от кликов мышью нужно понять по какому тайлу кликнули и проверить, можно ли его перемещать. Для этого в цикле (двойной цикл организован через директиву MASM .WHILE) вызываем CalculateTileRect и проверяем находится ли курсор мыши внутри прямоугольника. Принцип проверки тот же, что и в ProcessArrow - cmp в ряд, только команды условного перехода другие. Внутри ProcessArrow je (jump equal), а тут ja jb (jump above jump below). Дальше все тоже самое что и с курсором, только наоборот. Смотрим разницу между индексами пустого и кликнутого тайла и вызываем процедуру ProcessArrow (наверное не самое удачное название) с нужными аргументами. Сокращенная версия процедуры.
ProcessClick proc hWin:DWORD, lParam:DWORD
local rct : RECT
movsx ebx, WORD PTR [ebp+12] ; x coordinate
movsx ecx, WORD PTR [ebp+14] ; y coordinate
mov vert, 0
.WHILE vert < 4
mov hor, 0
.WHILE hor < 4
invoke CalculateTileRect, ADDR Rct, hor, vert
cmp ebx, Rct.left
jb next
cmp ebx, Rct.right
ja next
cmp ecx, Rct.top
jb next
cmp ecx, Rct.bottom
ja next
; the idea is that tile can be moved only if there is a particular diff
; between its index and empty tile index
; -1, +1 ,-4, +4 for different directions, similar to ProcessArrow proc
call FindEmptyTileIndex
.IF index > al
sub index, al
.IF index == 1
invoke ProcessArrow, hWin, VK_LEFT
.ELSEIF index == 4
invoke ProcessArrow, hWin, VK_UP
.ENDIF
.ENDIF
next:
inc hor
.ENDW
inc vert
.ENDW
ret
ProcessClick endp
Вспомогательные процедуры типа проверки на окончание игры, или смены местами значений в массиве я приводить не буду, т.к. они банальны, а статья и так разрослась. Теперь, когда все готово, в итоге получилось 587 строк в Main.asm и 8192 байта исполняемый файл. Размер екзешника меня приятно порадовал - 8 килобайт это и для прежних времен немного, а сейчас и подавно. Полный код приложения можно увидеть в гитхабе.
Заключение
Наша игра готова. Мы увидели как это делается в привычной IDE, узнали откуда брать сигнатуры и как вызывать функции WinAPI, поняли что надо сделать чтобы создать полноценное оконное приложение, использовали директивы MASM для упрощения кода. Хоть я никогда и не использовал ассемблер в коммерческой разработке, но интерес к нему был с юных лет. Начиная с изучения ассемблера для Z80, знаменитого Спектрума и его многочисленных клонов. Писать пусть и очень простую, но полноценную игру на ассемблере мне по-настоящему понравилось. Надеюсь читателям тоже было интересно!
Автор:
piton_nsk
