In this and the following chapter, we will start assembly coding in Windows. As with Linux, it is best to install a Windows virtual machine. You can download a license for a 90-day Windows 10 trial here: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise . Install the trial version of Windows 10, and do the updates, which can take a while.
Getting Started
Microsoft has developed its own assembler, called MASM , and it is included in Visual Studio. Being able to use Visual Studio is certainly an advantage, because it is a comprehensive development tool. The assembler instructions used in MASM are the same as those in NASM, but the assembler directives are very different. Configuring and learning to work with Visual Studio has a learning curve, depending on your previous experience as a Windows developer.
To soften the culture shock, in this book we will use NASM on Windows and use the CLI. We already know NASM on Linux from the previous chapters, which gives us a head start. However, making the switch to MASM should not be too difficult to do on your own.
If you want to develop for Windows, learning to use Visual Studio is worth the effort. On the Internet you can even find how to use NASM with Visual Studio.
Windows 10 environment path variable
We will also use a version of MinGW (Minimalist GNU for Windows) , which is a set of Linux development tools ported to Windows. MinGW will allow us to use the tools make and GCC, which we have used often in the previous chapters of the book. The version you have to install is MinGW-w64. Before you start downloading and installing, if you plan to use SASM on Windows, be aware that SASM installs NASM and some MinGW-w64 tools in its own subdirectories (except make). If you manually install SASM and MingGW-w64, you will end up with double installations. In the SASM settings, you can configure SASM to use your installed versions of NASM and GCC instead of the older versions that come with SASM.
Currently you will find the download files for MinGW-w64 here: http://mingw-w64.org/doku.php/download . Choose MingW-W64-builds, download and install it, and choose x86_64 in the installation window.
Go to the Windows environment variables, and add the path to the MinGW-W64 bin folder to the environment variable path, shown in Figure 39-1. The bin folder contains GCC. After updating the path variable, go to the PowerShell CLI and type gcc -v to verify the installation.
Download the win64 version of SASM ( https://dman95.github.io/SASM/english.html ), and if you want SASM to use the new versions of NASM and GCC, modify the build settings to your freshly installed NASM and GCC. Do not forget to update the Windows environment path variable with an entry for SASM.
If you do not have a preferred text editor on Windows, install Notepad++. It is simple and provides syntax highlighting for a large number of programming languages, including assembly. And you can easily set the encoding to UTF-8, UTF-16, and so on. You can find the assembly language setting on the menu bar under Language.
Save the file in UTF-8 format in the MinGW-W64 bin folder.
To open an application as administrator, right-click the application icon, and choose the option Run as administrator.
It is always handy to have easy access to PowerShell, the Windows CLI. To open it, type PowerShell in the search field on the taskbar at the bottom and then click Open. A PowerShell icon will appear on the taskbar; right-click this icon and choose Pin to taskbar.
In a window that shows icons for files or directories, press Shift and right-click at the same time, and on the menu that pops up, you can select Open PowerShell window here.
To show hidden files and directories, click the File Explorer icon on the taskbar. Open the View menu item and select Hidden items.
To find the environment variables, type environment variables in the search field on the taskbar.
Writing Some Code
hello.asm
makefile
There is nothing spectacular here, right? Or is there?
Well, first there is sub rsp,32 , which in Linux we used to create stack variables. With this instruction, we create shadow space on the stack before calling a function. More on that later. After the printf function executes, we restore the stack with add rsp,32, which in this case is not strictly necessary because the stack will be restored by the leave instruction. The registers we use to pass arguments to printf are different from the ones used in Linux. That is because the calling conventions in Windows are different from the calling conventions in Linux. Windows requires you to use the Microsoft x64 calling convention, while Linux wants you to use System V Application Binary Interface, also called System V ABI.
Integer arguments are passed in rcx, rdx, r8, and r9, in that order.
If you want to pass more arguments, you push them onto the stack.
Floating-point arguments are passed in the xmm0-xmm3 registers; further arguments are passed using the stack.
Registers rcx, rdx, r8, r9, and, additionally, rax, r10, r11, xmm4, and xmm5 are volatile, meaning that the caller has to save them if needed. The other registers are callee saved.
The caller needs to provide a 32-byte space on the stack (shadow space) for four function arguments to be passed to the callee, even if the callee does not take that many arguments.
As in Linux, the stack must be 16-byte aligned.
hello.asm output
Debugging
This means that GDB is of limited use here! However, SASM comes to the rescue. SASM does not seem to have this problem. In our makefile we still include the debug flags; maybe in a future version of GDB this will be solved. In the makefile we specify cv8 (Microsoft CodeView 8) as the debugging format.
Syscalls
In our example code, we used printf instead of a syscall as we did with our first Linux assembly program. There is a reason for that: you do not use syscalls in Windows. Windows has syscalls, but they are for “internal” use only. You need to use the Windows API when you want to access system resources. Of course, you can dig around in the Windows code or on the Internet to find out what the Windows syscalls are, but know that newer versions of Windows can change the use of syscalls, and that can break your code if you use them.
Summary
How to install and use NASM, SASM, and Linux development tools in Windows
That calling conventions in Windows are different from those in Linux
That it’s better not use syscalls