Windows Development with MASM

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:

C:\src> ml.exe /IC:\masm32\include /coff hello.asm /link /SUBSYSTEM:WINDOWS /LIBPATH:C:\masm32\lib

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.

Windows Development with FASM

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:

SET INCLUDE=C:\fasmw\include

Can't connect to X11 window server when using docker

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.

Viewing shared dependencies with ldd

Today’s post is about the system utility ldd. ldd will show you the shared object dependencies on the program that you supply as input.

$ ldd program

I ran ldd against an executable that I’d made from a previous post on libxml2 and was given the following results:

linux-vdso.so.1 =>  (0x00007ffc6e987000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007fbbfcca7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbbfc8e2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbbfc6de000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbbfc4c5000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fbbfc2a3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbbfbf9d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbbfd00d000)

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:

NEEDED      libxml2.so.2
NEEDED      libc.so.6

Console control with readline

The GNU Readline Library is a really useful library for creating single-line input style programs at the console. From the introduction:

The GNU Readline library provides a set of functions for use by applications that allow users to edit command lines as they are typed in.

There’s some really nice stuff added on top though. Being able to use emacs or vi editing modes are just some of them. This allows you to provide your users with consistent key bindings to what they use in their text editor.

Modules

Taking a look on your file system, you can find readline’s header files under /usr/include/readline/.

chardefs.h  keymaps.h   rlconf.h  rltypedefs.h
history.h   readline.h  rlstdc.h  tilde.h

Taking a really brief tour of these headers, history.h provides the library with the ability to recount previously entered text blocks. This sort of behavior can be observed when using bash; pressing the up and down buttons allow you to scroll through previous commands. keymaps.h provides the library with the mapping abstraction to make your readline-based application behave like vi or emacs or any custom implemented map you wish.

Reading lines

The library’s purpose is to read lines of text. The function that you’ll use to do this is called readline. A simple example of this would be:

#include <stdlib.h>
#include <stdio.h>
#include <readline/readline.h>

int main() {
  char *name;

  name = readline("What is your name? ");

  printf("Hello %s!\n", name);
  free(name);

  return 0;
}

Note! The string that you’re given back from readline is allocated using malloc, so it’s your responsibility to ensure that the memory is freed using free.

Resulting with the following execution:

$ ./hello
What is your name? Joe
Hello Joe!

Historical and auto complete

You can quickly give your readline program a historical account of previously entered lines with the following sort of structure:

while (running) {
  filename = readline("Enter a filename: ");

  // add the data to the input history
  add_history(filename);

  // perform some work on "filename"

  free(filename);
}

The add_history method is available from the readline/history.h header.

Allowing your line edit to include file path auto completion is pretty easy also. You can bind this behavior to any key that you’d like; we’re all pretty used to the tab character doing this work for us though:

rl_bind_key('\t', rl_complete);