You’ll use Nasm to reduce your assembly source code into COFF object files. Gorc will take your resource scripts and produce linkable object files from these. Finally, ALink will bind all of your object files into a windows executable.
Finally, you’re going to need a copy of the include file for the Win32 API. The API itself is huge; the number of constants and structures is mind boggling. The link above handles all of these for you.
Test program
Probably the easiest thing to accomplish, is showing a message box. You need to show the message box and then return control back to Windows. You do this with calls to MessageBoxA and ExitProcess. The “A” in MessageBoxA as we’re not dealing with the wide-char version of these functions.
Here’s the code.
%include "win32n.inc"
extern MessageBoxA
import MessageBoxA user32.dll
extern ExitProcess
import ExitProcess kernel32.dll
segment .data USE32
title db "A message for you", 0
message db "This is your first message", 0
segment .bss USE32
segment .code USE32
..start:
; show the message box
push MB_OK
push title
push message
push 0
call [MessageBoxA]
; return control back to windows
push 0
call [ExitProcess]
Functions are imported from the api using import, and are called in a very assembler-traditional fashion here. Taking a look at the definition for the MessageBox function, we can see the order of parameters:
Arguments are pushed to the stack in reverse order.
Assembling and linking
Now that you’ve got your source file, hello.asm you can produce an object file with the following:
C:\src> nasm -i c:\nasm\include -f obj hello.asm
You can now link the object file into an executable with the following:
C:\src> alink -c -oPE -subsys gui hello
Ready to go.
Making things a little more high-level
You can make your assembly code a little more high-level by using the nagoa+.inc include file. This include file provides your programs with some really handy constructs (as well as the win32 api bindings), so function invocations now look like this:
In this post, I’ll walk through the steps required to bootstrap your development experience against the Win32 API using the Microsoft’s Macro Assember.
Prerequisites
Downloading the package from the masm32.com site will be everything that you need to produce applications using assembly language. It not only includes the assember ml, but also includes all of the library, include files and linker for you.
Test program
Here’s the code to present a message box.
; #######################
.386
.model flat, stdcall
option casemap :none ; case sensitive
; #######################
include windows.inc
include user32.inc
include kernel32.inc
includelib user32.lib
includelib kernel32.lib
; #######################
.data
szTitle db "Your message", 0
szMsg db "First message box", 0
.code
start:
invoke MessageBox, 0, offset szMsg, offset szTitle, MB_OK
invoke ExitProcess, 0
end start
invoke goes a long way to cleaning up how any assembly program that is sub-routine heavy looks. The include files already do the externing of library symbols so that your code doesn’t need to explicitly declare that you’re using a particular function.
Assembling and linking
Now that you’ve got your source file, hello.asm you can produce an object file and executable with the following:
You can see that not only assembler switches are passed, but also linker switches which means you’re assembling and linking all in one step.
Conclusion
The bundle for masm32 that this article refers to is great in the amount of code that it offers you, but the provided assembler is well-dated. Microsoft have been keeping masm updated from their website with 64 bit versions available with their development tools.
In this post, I’ll walk through the steps required to bootstrap your development experience against the Win32 API using the Flat Assembler.
Prerequisites
Everything is provided for you when you download the fasmw package, including libraries, include files. fasmw even includes a linker pre-geared for windows as your target.
Test program
Here’s the code to present a message box.
include 'win32ax.inc'
.code
start:
invoke MessageBox, HWND_DESKTOP, 'This is a test', 'Hey, Hey!', MB_OK
invoke ExitProcess, 0
.end start
Everything is provided to you through win32ax.inc. This can be swapped out easily enough with a 64 bit counterpart if you’re targeting different architectures.
Assembling and linking
Now that you’ve got your source file, hello.asm you can produce an object file with the following:
C:\src> fasm hello.asm
That’s all there is to it. You’ll now have an exe available to you to run. The only gotcha is giving fasm a hint as to where your include files are, and you do this through the INCLUDE environment variable:
On some host system configurations, I’ve found that Docker containers that use the host’s X11 session to present a user interface, terminate with a dreaded:
Can't connect to X11 window server using 'unix:0.0' as the value of the DISPLAY variable
Seems that on these systems, access needs to be granted to users making connections to the X11 host. This is done using the xhost command, like so.
$ sudo xhost +
Your docker containers shouldn’t have any issues now.
A word of warning is given in the man page, when using this tool however:
In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library dependencies. Be aware, however, that n some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.
The suggestion from this manual page is to use the objdump command, as this won’t invoke anything extra to find the dependencies:
$ objdump -p program | grep NEEDED
For the same program, this gives me the following output: