這一章來撰寫一個應用程式，FIRST_WND1.ASM，執行時在螢幕上顯示一個視窗，如右圖，標題欄是「第一個Win64程式」，視窗中還有一個「這是用組合語言寫的64位元程式。」字串及「確定」按鈕，使用者可以按「確定」按鈕結束程式。這一章來撰寫一個應用程式，FIRST_WND1.ASM，執行時在螢幕上顯示一個視窗，如右圖，標題欄是「第一個Win64程式」，視窗中還有一個「這是用組合語言寫的64位元程式。」字串及「確定」按鈕，使用者可以按「確定」按鈕結束程式。
FIRST_WND1.ASM 的內容如下：
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
17 18 19 20
21 22 23 24
25 |
OPTION CASEMAP:NONE
EXTRN MessageBoxA:PROC
EXTRN ExitProcess:PROC
INCLUDELIB \masm64\lib64\kernel32.lib
INCLUDELIB \masm64\lib64\user32.lib
MB_OK EQU 0
;*********************************************************************
.CONST
szCaption DB "第一個Win64程式",0
szText DB "這是用組合語言寫的64位元程式。",0
;*********************************************************************
.CODE
;---------------------------------------------------------------------
main PROC
sub rsp,28h
xor rcx,rcx
mov rdx,OFFSET szText
lea r8,szCaption
mov r9,MB_OK
call MessageBoxA
sub rcx,rcx
call ExitProcess
main ENDP
;*********************************************************************
END |
開啟文書處理程式，把上面內容輸入後，存成「E:\HomePage\SOURCE\Win64\FIRST_WND1.ASM」，再依底下步驟組譯、連結，最後執行它，就能見到上面的視窗。
Microsoft Windows [版本 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\wanker>masm64 →執行 MASM64.BAT，見第一章 C:\Users\wanker>path C:\Users\wanker\Documents\masm64\bin64;C:\Windows\system32; C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\; C:\Program Files (x86)\UltraEdit-32 C:\Users\wanker>set link=/subsystem:windows /entry:main C:\Users\wanker>cd E:\HomePage\SOURCE\Win64 C:\Users\wanker>E: E:\HomePage\SOURCE\Win64>cd FIRST E:\HomePage\SOURCE\Win64\FIRST>ml64 first_wnd1.asm Microsoft (R) Macro Assembler (x64) Version 14.25.28614.0 Copyright (C) Microsoft Corporation. All rights reserved. Assembling: first_wnd1.asm Microsoft (R) Incremental Linker Version 14.25.28614.0 Copyright (C) Microsoft Corporation. All rights reserved. /subsystem:windows /entry:main /OUT:first_wnd1.exe first_wnd1.obj E:\HomePage\SOURCE\Win64\FIRST>first_wnd1 →執行 FIRST_WND1.EXE 就能看見視窗了
這一章除了會牽涉到組合語言的假指令與 x64 指令之外，還會涉及 Windows API 的運作，所以篇幅不少。在介紹 Windows API 之前，先來看看如何呼叫副程式。
CALL 是呼叫副程式的指令，RET 是自副程式返回主程式的指令，其語法分別是
CALL 副程式名 RET
當 CALL 執行時，CPU 會先計算 CALL 下一行指令的位址，此位址稱為返回位址；其次是將 RSP 減八，把返回位址存入 RSP 所指位址；最後把控制權轉移到副程式所在位址上，執行副程式的指令。RET 指令做的事恰好與 CALL 相反。首先，RET 會把 RSP 所指堆疊頂端的返回位址取回，並使 RSP 加上八，然後將控制權轉移到剛剛由堆疊頂端取出的返回位址上的指令，繼續執行。
右圖是 FIRST_WND1.EXE 第 20 行，「call MessageBoxA」的想像圖。執行此令時，CALL 會把下一道指令，sub rcx,rcx，的位址推入堆疊，此位址就是返回位址，然後把控制權交給 MessageBoxA 的進入點。等 MessageBoxA 執行最後一道指令，RET，就會從堆疊頂端取回返回位址，使 RSP 加八，然後把控制權歸還給返回位址上的指令，然後繼續執行 sub rcx,rcx。
前面已介紹過宣告副程式的方法，PROC/ENDP，很多人會納悶，ENDP 不就是結束副程式嗎？為何還要有 RET 指令呢？實際上，PROC/ENDP 只是用來告訴組譯器或是讓人們閱讀方便，在 PROC/ENDP 之間的程式片段是副程式，但是真正歸還控制權給主程式的是 RET。因此 PROC/ENDP 是假指令，RET 才是讓 CPU 真正執行的指令。
其實，與其說 MessageBoxA 是副程式，不如說它是 Windows API 的其中一個函式。在 FIRST_WND1.ASM 裏，還有一個 ExitProcess 也是。它們都是 Windows API 的一部分，底下就說明什麼是 Windows API。
API 是 Application Programming Interface 的是縮寫，所以 Windows API 可以翻譯成「Windows 作業系統應用程式介面」。我們可以把 Windows API 看成是許多的副程式的集合，它們都是微軟已經撰寫好的，多達上千種的副程式，裡面包含建立視窗的副程式、開啟檔案的副程式……。微軟將它們集合起來，存放在 Windows 作業系統內的各種動態連結程式庫（dynamic-link library，縮寫為 DLL，其副檔名為「.DLL」）中。它也是 Windows 作業系統的一部分，任何程式都可以呼叫它。Windows API 在執行完畢後，將控制權歸還給主程式，並且將執行結果，也就是回傳值，存放於 RAX 通知主程式。所以，所有的 Windows API 都是函式。
Windows API 是從民國 74 年（西元 1985 年）發售的 Windows 1.0 開始，支援約 450 個函式，到現在民國 112 年已經多達上千個函式了。大致可以分成三個階段：①Windows 1.0 到 Windows 3.1 都是 16 位元的作業環境，也稱為 Win16 API。②Windows NT 3.1/Windows 95 及其後續的版本都是 32 位元的作業系統，故稱 Win32 API。③Windows XP 及其之後的 Windows 都有 32 位元與 64 位元兩種版本，其中 64 位元版的 Windows API 稱為 Win64 API。
雖然 Windows API 歷經數次更替，新增了許多函式，但是對撰寫程式的人來說，基本觀念幾乎不變，差別僅僅是參數長度及呼叫方式有所不同。而小木-偶寫的這份「Win64 組合語言」教學中，提到 Windows API，若無特別說明，都是指 Win64 API。
我們在撰寫 Win64 程式，無可避免要呼叫 Windows API 來簡化程式。如果不這麼做，可以想像得到，光是建立視窗少說就要寫數百行程式碼了。前面提過，Windows API 可以看成是微軟寫好，讓我們所撰寫的程式呼叫的副程式，可以大膽放心的用 CALL 指令呼叫它們。
在 Windows 作業系統裡，凡是牽涉到與字元有關的 Windows API 都有兩套：
⑴、ANSI 版的 Win64 API：在 Win64 API 名稱後面會多了「A」字元，用來處理 ANSI 編碼的字串。Windows 正體中文版的 BIG－5 被定義為 ANSI code page（CP950），因此 ANSI 版的 Win64 API 會依該 code page 解讀字串，進而能處理 BIG-5 編碼的中文。但是在其他不同語言版本的 Windows 上執行時，可能會產生亂碼。MessageBoxA 就是 ANSI 版的 Win64 API。
⑵、寬字元版的 Win64 API：在 Win64 API 名稱後面會多了「W」字元（W 代表寬字元的意思，用兩個或兩個以上的位元組來表示一個字元，就稱為寬字元），用來處理以萬國碼（UNICODE/UTF－16）編碼的字串。因為當初制定萬國碼時，就已考慮到要能處理全世界古往今來的文字，所以不會有亂碼的問題。也就是呼叫寬字元版的 Win64 API，不會因為在不同語言版本的 Windows 上執行，產生亂碼。例如 MessageBoxW 就是寬字元版的 Win64 API。
如果不牽涉到字元的 Win64 API，結尾就沒有「A」或「W」，也就不分 ANSI 版或寬字元版。例如 ExitProcess 就沒有分 ANSI 版或寬字元版。在前幾章，都使用 ANSI 版的 Win64 API，原因有二：①若未做任何宣告，MASM64 預設方式是呼叫 ANSI 版的 Win64 API、②要呼叫寬字元版的 Win64 API，除了要宣告之外，還得將字元轉換成萬國碼，在還未說明萬國碼之前，是無法辦到的。
雖然前幾章，使用 ANSI 版的 Win64 API，但是現代撰寫程式，應該要呼叫寬字元版的 Win64 API，除了避免亂碼以及可以簡化國際化（I18N）程式的開發之外，效率也比較高。這是因為現在的 Windows 作業系統，在處理 ANSI 版的 Win64 API 時，會先把 ANSI 字元轉換成萬國碼，然後呼叫對應的寬字元版 Win64 API。
主程式呼叫副程式時，必須把參數傳給副程式，但要如何傳呢？利用堆疊還是暫存器、前後次序是如何安排、回傳值如何傳回給主程式、主程式還是副程式清理堆疊……等問題。這些問題，主程式與副程式都必須達成一致，才能正確執行。因此要有統一的規定，這些規定稱為呼叫慣例或呼叫協定。
呼叫協定有許多種，在 Win64 API 使用的呼叫慣例稱為「FASTCALL」。但有些文獻說類似 FASTCALL，有些甚至說 FASTCALL 並沒有嚴格的定義，小木偶也不知採信哪一種，或許稱為「x64 呼叫慣例」就是最好的方式。不論如何，Win64 API 及自行撰寫的副程式都必須遵守的 x64 呼叫慣例，其規則如下：
⑴、主程式利用暫存器與堆疊將參數傳給副程式，前四個參數分別存於 RCX、RDX、R8、R9，如果超過四個，多出來的參數由堆疊傳給副程式。把參數推入堆疊時，由最右邊的參數最先推入堆疊，而往左後依次推入堆疊。所以最右邊的參數，存於最高位址；最左邊的參數，存於最低位址。。
⑵、雖然前四個參數，靠暫存器傳遞，但是主程式仍要在堆疊中預留存放參數的空間，如果參數少於四個，也要預留四個，這四個參數的空間稱為「影子空間」（shadow space）。影子空間僅僅讓副程式在必要時將傳入的 RCX、RDX、R8、R9 暫存器值儲存到堆疊上，並不負責傳遞參數。
⑶、執行 CALL 之前，RSP 所指的堆疊頂端位址必須對齊節位址（位址需對齊 16 位元組），這為了增加效率。
一個節（paragraph）的大小是 16 個位元組，對齊節位址的意思是此位址是 16 的整數倍，如果把位址換成十六進位，那麼最後一位必定是零，例如 20h、0EE3420h 都是，而 28h、EE3422h 就不是。就像十進位的 1234，個位數是 4 一樣，把十六進位的最後一位看成是個位數，個位數是零，就表示對齊節位址。如果不是的話，那麼在執行 CALL 之前必須自行調整，方法也很簡單，使 RSP 減去某個數就行。到這兒，讀者可能會有兩個問題：
①、如果沒有對齊 16 個位元組會怎樣？答案也很簡單，程式立即當掉！
②、可不可以把 RSP 加上某數而使其個位數變為零，答案是不行，因為比堆疊頂端更高位址的是有用的資料，如果破壞了，程式很有可能會當掉。
在任何情形下，程式一開始執行、或剛進入自行撰寫的副程式、或剛進入某個 Win64 API 時，RSP 的最右邊那位，也就是「個」位數，必定是「8」。原因是依據 x64 呼叫慣例，在執行 CALL 之前，RSP 個位數是零，執行 CALL 時會將返回位址推入堆疊，將減去八，因此剛進入自行撰寫的副程式、或剛進入某個 Win64 API 時，RSP 的個位數必定是 8。如果這時候還要呼叫另一個副程式或另一個 Win64 API，依據被呼叫的副程式或 Win64 API 的參數個數，可能會有底下幾種情形：
⒜、如果參數個數小於或等於四個，都必須保留四個參數做為影子空間。每個參數是 8 個位元組，加起來是 32 個位元組（即十六進位的 20h），如果 RSP 只減去 20h，那麼個位數仍然是 8。這是不行的，所以必須浪費 8 個位元組的堆疊，減去 28h，使 RSP 的個位數為零。
⒝、如果參數個數是五個，那麼影子空間加上第五個參數，總共是 28h 個位元組。如果 RSP 減去 28h 後個位數恰好是零。
⒞、如果參數個數是六個，那麼影子空間加上第五、六個參數，總共是 30h 個位元組。如果 RSP 減去 30h 後個位數是八，所以必須減去 38h，浪費八個位元組的堆疊空間。
⒟、如果參數個數是六個，那麼影子空間加上第五、六、七個參數，總共是 38h 個位元組。如果 RSP 減去 38h 後個位數恰好是零。
到此，應該可以看出規律，整理成下表：
| 表：參數個數與 RSP 保留大小 | |||
| 參數個數 | RSP 減去多少 | 參數個數 | RSP 減去多少 |
| 4 或小於 4 | 28H | 10 | 58H |
| 5 | 28H | 11 | 58H |
| 6 | 38H | 12 | 68H |
| 7 | 38H | 13 | 68H |
| 8 | 48H | 14 | 78H |
| 9 | 48H | 15 | 78H |
⑷、在副程式或 Win64 API 裏，如果要使用 RBX、RBP、RSI、RDI、RSP、R12、R13、R14、R15 九個暫存器，副程式或 Win64 API 必須負責保存，以確保在呼叫前後這九個暫存器之值不變，讓主程式能安心使用。這九個暫存器也稱為非揮發性暫存器（nonvolatile registers），或者稱為被呼叫者保存的暫存器（callee-saved registers）。而 RAX、RCX、RDX、R8、R9、R10、R11 則稱為易揮發性暫存器（volatile register），可在副程式中任意使用，因此在呼叫後，它們的數值可能會改變。
⑸、副程式或 Win64 API 結束時，回傳值放在 RAX 裡，再返回主程式。
⑹、由呼叫者負責清理堆疊。第⑶提到，主程式呼叫副程式，姑且稱為副程式甲。副程式甲也可能會呼叫另一副程式乙，所以副程式甲必須調整 RSP，使其在執行 CALL 時個位數為零，通常是使 RSP 減去一數。當退出副程式甲時，也必須使 RSP 恢復調整前的數值，方法就是加上剛剛減去的數。
舉個例子說明，對於瞭解 x64 呼叫慣例應該會有所助益。假設有個主程式要呼叫有六個參數的副程式，那麼在進入主程式後，未呼叫副程式之前，RSP 所指的堆疊頂端並未對齊節位址（2CFF38，個位數是 8），見右圖一。
六個參數共 48 個位元組（48＝30h），但是如果從現在 RSP 所指位址減去 30h 是 2CFF08，並沒有對齊節位址，不能執行 CALL 否則引起當機。如果浪費八個位元組的空間，再依序把第六、第五個參數推入堆疊，然後於堆疊上保留給 RCX、RDX、R8、R9 儲存所需的影子空間之後，RSP 所指位址就恰好是節位址邊界，見圖二。
此刻執行 CALL 指令，CALL 先把 RSP 減去八，再把返回位址存於 RSP，最後進入副程式，見圖三。
底下介紹 MessageBoxA、ExitProces 這兩個 Win64 API，但在這之前，得先說明一件事。在這整個網站所列出的 Win64 API，僅僅說明最重要的部分，畢竟小木偶的這個網站不是說明 Windows API 應用大全。所以要得到完整詳盡的說明，必須自行去微軟的網站上查閱。
MessageBoxA 是許多 Windows API 中的其中一個，它的功能是在螢幕上建立一個訊息方塊並顯現出來，其內有一段字串或圖示，也有按鈕可供使用者挑選。當使用者選擇任一個按鈕，系統會關閉此視窗，並在傳回值指出使用者按了哪個按鈕。呼叫 MessageBoxA 所需要的參數有四個，可以查閱 MSDN ，得到下面的結果：
int MessageBoxA( [in, optional] HWND hWnd, [in, optional] LPCSTR lpText, [in, optional] LPCSTR lpCaption, [in] UINT uType );
上面函式的寫法是以 C/C＋＋ 的方式表現的，可能會因為 MSDN 版本不同而略微不同，不影響不大。「int MessageBoxA」中的 int 表示回傳值的資料類型為整數（integer），在 Win64 系統中 int 的長度是四個位元組，也就是 32 位元，所以，即使 Win64 API 的回傳值都存放在 RAX 暫存器裏，但只有較低的 32 位元有效。
接下來是函式名稱，MessageBoxA，要注意大小寫。接下來，在「(……)」內有四個參數，這四個參數都是用「介面定義語言」（或原始碼標註語言）、「資料類型」、「參數名稱」為一組的方式表示。每一組的第一欄是介面定義語言，用於描述參數是僅僅提供資料，還是接收資料，詳情請見註一。對於組合語言來說，這一欄並不是非常重要。
每一組的第二欄，此欄表示其後的參數屬於哪一種資料類型。例如 HWND、LPCSTR 都是四字組長度，但前者表示視窗控制代碼，後者表示某個位址，而此位址的記憶體儲內存的 ANSI 常數字串。當你熟悉這種表示方式之後，很容易就能從資料類型中解讀參數或變數的意義，詳情見註二。
第一個參數，hWnd，是即將建立之訊息方塊的擁有者視窗控制代碼，也就是說 hWnd 是用來指定「生成的訊息方塊屬於哪個視窗」。如果此參數為 NULL（Windows 系統中，以 NULL 代表零），表示訊息方塊沒有擁有者視窗（owner window）。
第二個參數，lpText，是指「要顯示在訊息方塊內之字串」的 ANSI 字串位址，此字串須以零結尾。第三個參數，lpCaption，是「訊息方塊標題列文字」的 ANSI 字串位址，同樣需以零結尾。
第四個參數是 uType，顯示於視窗的按鈕形式或圖示，常用的數值如下表（表中的 MB_ 是 Message Box 的意思）：
| uType | 數值 | 意義 |
| MB_OK | 0h | 只顯示「確定」按鈕 |
| MB_OKCANCEL | 1h | 顯示「確定」與「取消」兩個按鈕 |
| MB_ABORTRETRYIGNORE | 2h | 顯示「終止」、「重試」、「略過」三個按鈕 |
| MB_YESNOCANCEL | 3h | 顯示「是」、「否」、「取消」三個按鈕 |
| MB_YESNO | 4h | 顯示「是」、「否」兩個按鈕 |
| MB_RETRYCANCEL | 5h | 顯示「重試」、「取消」兩個按鈕 |
| MB_CANCELTRYCONTINUE | 6h | 顯示「取消」、「重試」、「繼續」三個按鈕 |
| MB_HELP | 4000h | 顯示「確定」、「說明」兩個按鈕，如果使用者按下說明按鈕，系統會將 WM_HELP 訊息傳送給擁有者視窗 |
MessageBoxA 的 uType 參數，除了顯示按鈕之外，也可以顯示內定的圖示、指定訊息方塊的類型、指定哪個按鈕式預設的，這些都請自行查閱微軟網站，如果顯示或指定特殊功能，可以用「or」運算子連接。例如要顯示問號的圖示及「是」、「否」、「取消」三個按鈕，那麼 uType 就設定為「MB_YESNOCANCEL or MB_ICONQUESTION」。
MessageBoxA 的回傳值放在 RAX 的 0∼31 位元內，說明如下表：
| 回傳值 | 數值 | 使用者的操作 |
| IDOK | 1 | 按下「確定」按鈕 |
| IDCANCEL | 2 | 按下「取消」按鈕 |
| IDYES | 6 | 按下「是」按鈕 |
| IDNO | 7 | 按下「否」按鈕 |
| IDABORT | 3 | 按下「終止」按鈕 |
| IDCONTINUE | Bh | 按下「繼續」按鈕 |
| IDIGNORE | 5 | 按下「略過」按鈕 |
| IDRETRY | 4 | 按下「重試（R）」按鈕 |
| IDTRYAGAIN | Ah | 按下「重試（T）」按鈕 |
ExitProcess 是用來結束應用程式的，用法如下：
VOID ExitProcess( [in] UINT uExitCode );
VOID 代表 ExitProcess 沒有回傳值，理由很簡單，執行完 ExitProcess 程式就已經結束了，控制權也不會回來原本的程式，所以沒有回傳值。ExitProcess 只有一個參數，uExitCode，就是把一個數值傳給 Windows，這個數值可以給 Windows 或其他程式使用。一般而言，如果正常結束，此數值設為零；如果是因為產生錯誤，此數值可以表示錯誤編號。
EXTRN 是指示組譯器使用外部變數名稱、標記或副程式名稱，也可以寫成 EXTERN，意義相同，只不過 EXTERN 適用於新版的組譯器，其語法是：
EXTRN name:qualifiedtype[,name:qualifiedtype[,...]]
假如某個程式要使用別的程式所定義的名稱，可以在前者以 EXTRN 宣告該名稱是由別的程式所定義的，name 就是別的程式所定義的名稱。這種情形，大多發生在我們要呼叫程式開發商提供的副程式，或是製作大型程式。大型程式，例如 WORD、EXCEL 等，必定是許多人分工合作而每個人只負責其中一部分，每個人負責的那一部分的某些功能一定會跟其他人的程式有關，這就是 EXTRN 發揮功能的時候。
例如在甲原始程式沒有定義某個名稱，假設是 xyz 好了，也沒有以 EXTRN 宣告它為外部名稱；但是在乙原始程式已經定義過 xyz。這時如果直接組譯甲必定會發生錯誤。但如果在甲中有宣告 xyz 為外部名稱，將甲、乙分別組譯成目的檔都不會發生錯誤，在連結時，LINK.EXE 可以順利的將讓甲程式使用乙程式的 xyz。
上面的語法中，name 可以是變數名稱、標記或副程式名稱；qualifiedtype 可以是 BYTE、WORD、DWORD、QWORD、NEAR、FAR、PROC，前四個用於變數，第五、六個用於標記，後三個用於副程式名稱。EXTRN 可以同時宣告多個外部名稱，中間以「,」相隔。
在 FIRST_WND1.ASM 中，會呼叫 MessageBoxA 與 ExitProcess 兩個副程式，前者是用來顯示一個訊息方塊，後者用於結束程式。它們是微軟所撰寫的 Win64 API，可讓所有應用程式呼叫。在 FIRST_WND1.ASM 中完全沒有它們的程式碼，所以用 EXTRN 宣告它們是「外部」的程式。
因為 Win64 API 數量龐大，所以微軟將不同種類的 API 包裝在不同的動態連結程式庫（副檔名是 DLL）裏，而在主檔名相同的匯入程式庫（副檔名為「.LIB」）有其呼叫時所需之資料。例如查閱微軟網站或 MSDN，在「Requirements」段落裏得知 ExitProcess 在 KERNEL32.DLL 中，因此在 KERNEL32.LIB 有其呼叫時所需之資料。應用程式呼叫 ExitProcess 時，需要將匯入程式庫中的資料囊括進來，方法就是使用「INCLUDELIB」假指令。
INCLUDELIB 的語法是：
INCLUDELIB 匯入程式庫檔名
匯入程式庫檔名可以包含磁碟機名稱、路徑名。
SUB 指令是減法指令（subtract），它的語法是：
SUB 目的運算元,來源運算元
SUB 會把目的運算元裏面的數值減去來源運算元裏面的數值，再把結果存入目的運算元。因此執行完後，目的運算元之值會改變，來源運算元之值不變。目的運算元可以是變數或暫存器，來源運算元可以是常數、變數或暫存器，但是目的運算元和來源運算元不能同時為變數，而且兩者的位元數必須相同。SUB 運算後，會改變旗標暫存器。看看底下的例子：
sub rax,rcx ;正確，RAX、RCX 均為 64 位元。運算後，RCX 不變，RAX 會改變 sub rax,dx ;錯誤，RAX為 64 位元而 DX 為 16 位元
上面第一個例子是把 RAX 暫存器減去 RCX 暫存器，再把所得之差存入 RAX 裡面。
XOR 中文稱為「互斥或」（exclusive or），是邏輯運算的一種。先看看日常生活中類似的例子，例如高中二年級學生將面臨選擇社會組還是自然組，當然同個人只能選一組就讀。如果有位學生只選擇其中之一，代表他已選組完成；如果有另一位學生還未選擇，當然就還沒完成；如果還有另一位學生兩組都選，學校當然不會同意這樣的方式，也代表他還沒完成。這也是「互斥或」的名稱由來，讀社會組與讀自然組不能同時發生，是為「互斥」；而兩者只能選擇其中一種，是為「或」。
以上面高二學生選組為例，選擇某一組當做真，以「1」表示；不選某一組當做假，以「0」表示。某位學生已完成選組當做真，以「1」表示；還未完成當作假，以「0」表示。四位學生分別代表四種情形，列成一張表如下。學生甲代表他都還沒選擇，故未完成選組；學生乙代表他選社會組，已完成選組……學生丁是兩組皆選於體制不合，所以未完成選組。
| 學生 | 選社會組 | 選自然組 | 是否已完成選組 |
| 甲 | 0 | 0 | 0 |
| 乙 | 1 | 0 | 1 |
| 丙 | 0 | 1 | 1 |
| 丁 | 1 | 1 | 0 |
在電腦中要實現是否完成選組的運算，就能使用「互斥或」運算。在電腦裡，互斥或運算、且運算、或運算、非運算是四種常見的邏輯運算，電腦最擅長處理數值，尤其是二進位，因此在電腦中，常以 0 代表偽、假、否定的；以 1 代表真、是、肯定的。在許多程式中，也會宣告「TRUE」代表「1」、「FALSE」代表「0」。兩個一位元的運算元做 XOR 運算，有四種方式，如下表：
0 XOR 0＝0 1 XOR 0＝1 0 XOR 1＝1 1 XOR 1＝0
像這樣把邏輯運算列成的表格，稱為真值表。上面就是 XOR 的真值表。如果你仔細觀察，就會發現：①兩個相同的運算元作互斥或運算，結果為 0；②兩個相異運算元作互斥或運算，結果為 1。
在 x64 指令裏，XOR 的語法是：
XOR 目的運算元,來源運算元
XOR 會把目的運算元和來源算元進行互斥或運算，再把結果寫入目的運算元裏。目的運算元可以是暫存器、變數，來源運算元可以是暫存器、變數與立即值。目的運算元與來源運算元不能同時是變數，而且長度必須相同，例如都是 64 位元，而不能一個是 64 位元另一個是 16 位元。XOR 運算之後，會依據結果，變更旗標暫存器之值。
舉個例子，若 AL＝6Bh，BL＝C2h，執行「XOR AL,BL」後的結果是什麼呢？請參考右圖：（右圖已將 6Bh 與 C2h 換算成二進位數，這樣才能一個位元一個位元進行 XOR 運算）
AL 的第零位元與 BL 的第零位元作互斥或運算，即「1 XOR 0」得「1」（相異值做互斥或得 1）
AL 的第一位元與 BL 的第一位元作互斥或運算，即「1 XOR 1」得「0」（相同值做互斥或得 0）
其餘依此類推，原則就是每一位元和另一相對應的位元運算。最後結果就是「6B XOR C2＝A9」。因此「XOR AL,BL」之後，AL 變成 A9，BL 仍是 C2。
XOR 運算有兩個很奇妙的特性，那就是：①「如果某個數與自己作互斥或運算，所得結果為零」；②「某個數與同一數連做兩次互斥或運算仍得到原數」。在 FIRST_WND1.ASM 的第十六行，就是利用①的方法，使 RCX 變為零（xor rcx,rcx）。
OFFSET 運算子的語法是
OFFSET 運算元
OFFSET 是指示 ML64.EXE 組譯器在組譯的時候，把運算元的位址計算出來然後再作某些處理，此處的運算元可以是變數或標記（label）。當 ML64.EXE 組譯器計算得到其位址後，其實就是一個常數。FIRST_WND1.ASM 的第十七行，「mov rdx,OFFSET szText」，的意思是計算出 szText 字串的位址，並將其存入 RDX 暫存器裡。
LEA 指令是用來取得字串、變數或副程式的位址，其語法是
LEA 暫存器,運算元
運算元可以是字串、變數或副程式名稱，執行完 LEA 指令後，暫存器的數值就會變成其後所接字串、變數或副程式的起始位址。要注意的是，在 Win64 裏，位址是 64 位元，因此暫存器也得要用 64 位元，例如 RAX、RCX……等，不可以用 EAX、AX 這些 32 位元或 16 位元的暫存器。
「LEA」與「MOV 搭配 OFFSET」都是用來取得位址，似乎一樣其實不然。「MOV 搭配 OFFSET」只能用於組譯階段就已經確定位址的運算元；但是像外部變數、標記等，或是區域變數，都只能在執行過程中才能確定位址，這時候只能用「LEA」指令。
如果你能有耐心看到這兒，那麼離用組合語言呼叫 Win64 API 僅剩一步之遙了。剩下的這一步，來看看 FIRST_WND1.ASM 的主程式，就能完全瞭解了：
sub rsp,28h
xor rcx,rcx
mov rdx,OFFSET szText
lea r8,szCaption
mov r9,MB_OK
call MessageBoxA
為什麼上面程式的第一行要使 RSP 減去 28h 呢？原因是要保留影子空間，並使在第六行執行 CALL 之前，讓堆疊頂端能對齊節位址。第二∼五行是讓 RCX、RDX、R8、R9 之值變成呼叫 MessageBoxA 的四個參數。RCX 是訊息方塊所屬視窗的視窗控制代碼，為零，表示此訊息方塊沒有所屬視窗。
RDX、R8 都是位址，分別是印在訊息方塊內的字串位址，和訊息方塊標題欄字串的位址。此例中用兩種不同的方法去計算字串位址，但是也可以都用「MOV 搭配 OFFSET」，也可以都用「LEA」，結果都相同。最後一個參數存於 R9 中，事實上，也可以用「MOV R9D,MB_OK」，因為最後一個參數資料類型是雙字組。
ExitProcess 只有一個參數，存放在 RCX 裏。前面提過，即使參數只有一個，也要保留可以容納四個參數的影子空間。那麼，在呼叫前有沒有做這件事呢？答案是有的。前面提過，主程式必須負責清理堆疊。但是在呼叫完 MessageBoxA 之後，並沒有清除堆疊，所以這時候的 RSP 跟在呼叫 MessageBoxA 之前一樣，也就是說已經在保留了影子空間，同時 RSP 也已對齊節位址。
呼叫完 ExitProcess 之後，程式已經結束，堆疊以及所有資源都已被作業系統收回，也就沒有清理堆疊的問題了。
本章到此結束，下一章會用更簡單的方法重新撰寫 FIRST_WND1。
在微軟的文件中用介面定義語言（interface definition language，簡稱 IDL）來描述參數僅提供資料或接收資料，有時也用原始碼標註語言（source annotation language，簡稱 SAL），兩者都是描述 Win64 API 所需的參數用途，是僅僅用於提供資料給 Win64 API，還是也可以接收資料。差別在於，前者以一對中括號包住，是給人類閱讀的；後者是前後以底線夾住，通常是 C/C＋＋ 的 .h 中，是給編譯器處理的。至於常見的 IDL 有底下幾種：
| IDL | SAL | 意義 |
| [in] | _In_ | 主程式（或呼叫者，caller）提供參數，Win64 API 不會修改此參數 |
| [out] | _Out_ | 主程式須提供某個位址存於參數中，Win64 API 會把資料寫進該位址所指的記憶體內 |
| [optional] | _Opt_ | 此參數可以是 0，該 Win64 API 會自行處理這種情況。若此參數為零，也不能省略不寫 |
| [reserved] | _Reserved_ | 此參數目前沒使用，必須是 0 |
TYPEDEF 是用來宣告新的資料類型，其語法是：
新資料類型 TYPEDEF 原資料類型
這樣就能產生一個新的資料類型，此資料類型與「原資料類型」一樣。例如在 MASM64 SDK 裏，在「masm64\include64\win64.inc」中有底下的宣告：
UINT TYPEDEF DWORD
⁝
LPCSTR TYPEDEF QWORD
HWND TYPEDEF QWORD
這三行宣告了三個新的資料類型：UINT、LPCSTR、HWND，其實第一個就與 DWORD 一樣，後兩個與 QWORD 一樣。許多人，包含小木偶自己，在初學階段可能會以為，既然一樣，那為什麼還要宣告新的資料類型，這不是多此一舉嗎？先看完底下對這三個新的資料類型的解釋，可能就瞭解了。
⑴、UINT 代表長度為雙字組（DWORD）的資料類型，原文是 unsigned integer，翻譯成中文是無號整數的意思，可以是正整數或是零，但不能是負整數。
⑵、LPCSTR 代表長度為四字組（QWORD）的資料類型，原文是 long pointer to constant string，用 C/C＋＋ 的說法，LPCSTR 是 64 位元指標，指向 ANSI 常數字串；如果用組合語言的說法是，LPCSTR 代表某個位址，而此位址上的記憶體儲存的是 ANSI 常數字串（常數字串是指此字串不能修改，只能讀取）。
⑶、HWND 代表長度為四字組的資料類型，原文是 handle to a window，翻譯成中文是視窗控制代碼。
組合語言的資料類型不多，只有 BYTE、WORD……等幾種，它們只能表示幾個位元組，並沒有其他意義。如果用這些新的資料類型，可以增加可讀性。讓程式設計師一眼就能知道，這個變數的作用是什麼，是位址、控制代碼，還是無號數……。其次，Windows 作業系統本就很複雜，有許多種資料類型，MASM 有這樣的功能恰好更能與 Windows 搭配。這就是 TYPEDEF 存在的意義。
最後還有兩件事值得一提。第一件是，HWND 意思是視窗控制代碼。我們瞭解視窗，就是在桌面上大大小小的長方型區域，那什麼是控制代碼（handle）呢？在 Windows 系統運作時必定會產生許多視窗，Windows 就會給每個視窗一個獨一無二的控制代碼，這些控制代碼都是四字組的無號數，應用程式或作業系統就用這個控制代碼去處理或操控它。例如要關閉某個視窗，就得把要關閉的視窗之視窗控制代碼作為參數，呼叫關閉視窗的 Win64 API 即可。
這種情形有點類似參加大學入學考試，試務委員會給每個考生一個獨一無二的准考證號碼，而後考生去試場應試、查榜、放榜、分發都以這個號碼代替姓名。Windows 作業系統裡的控制代碼，就像是考生的准考證號碼一樣，每當系統要對視窗做什麼操作時，就得指定視窗控制代碼，然後呼叫相應的 Win64 API，即可完成。
第二件是在 win64.inc 宣告的新資料類型中，見下表：
| 新的資料類型 | 原資料類型 | 原文 | 意義 |
| LPSTR | QWORD | long pointer to string | 可寫的 ANSI 字元字串指標 |
| LPCSTR | QWORD | long pointer to constant string | 唯讀的 ANSI 字元字串指標 |
| LPWSTR | QWORD | long pointer to wide-character string | 可寫的寬字元字串指標 |
| LPCWSTR | QWORD | long pointer to constant wide-character string | 唯讀的寬字元字串指標 |
| HANDLE | QWORD | handle | 控制代碼 |
| BOOL | DWORD | boolean | 布林值 |
| VOID | QWORD | void | 通用類型 |