Getting a new tool

You know that I really have a good opinion of DEBUG.EXE and I think that it is a great software, but it cannot work with labelled addresses and this is a limit; however and honestly this is not a legitimate complaint that I do to DEBUG.EXE. Can you complain a flat-blade screwdriver not to be as good as a chisel at sculpting?
I mean that I knew that a NASM-Tool1 existed (let me say the "chisel") but I kept using DEBUG.EXE (let me say the "flat-blade screwdriver") just because I am a human being. Just to keep staying in the metaphor, it was as if I was doing some bricolage and I didn't have a chisel in my toolbox. I knew a chisel would do the job better, but I didn't have time and motivation to leave the bricolage work in standby for a while, and then jump into the car and go buying a chisel. I had then a flat-blade screwdriver just in my toolbox and I kept using it sometime as a chisel. Until the hassle of going out, buying me a chisel and learning how to use it was greater (or at least my perception of it) than the hassle of using the flat-blade screwdriver, I kept hammering on the back of the screwdriver for sculpting.
In true terms, however, the hurdle and hassle of getting NASM and learning it are really high. So high indeed that I kept misusing DEBUG.EXE for a long time, and I was quite happy with that and sometimes even proud of what I could achieve with it. However, the more the code was growing, the painful it was getting to have to fix all addresses manually: sometime multiple times in a loop until all the boundaries between 2-Bytes-Jumps and 3-Bytes-Jumps were fixed.

I have to say way in advance that I feel very insecure this time because, to me, NASM seems to be quite complicated. Or at least this is the perception I have reading the NASM documentation. Probably this is not the case. Probably the uses of some cryptic terms that belong to the technical word of software engineering, it leaves me, as mechanical engineer, a kind of uncomfortable feeling of having just partially understood what I read there. But the NASM documentation was not written for me but for professional software developers, so I have to be patient and accept that for me the learning path will be steeper and harder than that for people coming from a different background (by the way this is one of the hurdle and hassle that kept me using DEBUG.EXE for so long).

Download and install of NASM

Starting from the official NASM Website, I followed the download page and I took the topmost release (the most recent one). Inside this folder, I navigated to win32 subfolder (since I am currently using Win7 32-Bit) and I downloaded the nasm-XXX-win32.zip file (in my case XXX = 2.15.05).

Fig. A - expansion of NASM Zip-archive
Fig. A - expansion of NASM Zip-archive

Once I extracted the archive (Fig. A), I found:

  • the licence file (which is a plain text file without extension),
  • the nasm.exe file (the main program),
  • the ndisasm.exe (the disassembler),
  • the RDOFF folder.

ndisasm.exe is a disassembler that I have not used until now. The RDOFF folder contains other utilities necessary to link the RDOFF-files and produce an executable program file. The Relocatable Dynamic Object File Format (RDOFF) is the NASM object file format. I ignored this folder, but you can find out more about it in the Wikipedia and the NASM documentation at chapter 8.13.

Besides all the aforementioned files, I just took the nasm.exe one and copied it into my working folder <C:\MIK> to make my experiments and learn how to use it.

Why not MASM?

The short answer is: because I have learned how to use MASM, and I decided to try NASM to be able to compare the two. For as far as I have used NASM until now, I can tell you that I slightly prefer NASM to MASM but you should also try to learn how to use both of them and make your own opinion.

When I was considering making the step from DEBUG.EXE to a proper assembler, my first choice was MASM for the true and simple reason of intellectual inertia. I was mainly using Microsoft OS and DEBUG.EXE so I went on looking for an assembler from Microsoft. I didn't have any a priori conviction about MASM being better than NASM or vice versa. I just kept looking in the same direction where I was already walking: the Microsoft ecosystem. But I had to solve the problem of how to get MASM (and LINK). DEBUG.EXE is already there as long as you install the 32bit version of your Windows System (including Windows 10), but MASM and LINK are not available. This is one additional point that kept me running DEBUG.EXE instead of getting MASM / LINK because even if I wanted, it took me a while to understand how to get them officially from Microsoft.

MASM, unfortunately, is not the tool by itself, but just half of it. You need a second tool: the linker. Here the things get worst. It is hard to find the Microsoft 16-bit linker (but I did find it) and I couldn't find any good documentation on the linker. The best that I could do was try and error. NASM has the same problem too because both MASM and NASM are assemblers so they output the intermediate files: the object files. Likely, I found a way around this problem in NASM which I could not find in MASM. The fact that I don't have to use the linker in NASM in order to produce the SOFTWARE.BIG2 file is one of the reasons that made me prefer NASM versus MASM. With MASM I had to use the linker to produce and .EXE or .COM file from which I extracted the SOFTWARE.BIG that I needed.

NASM is an open project so it was very easy to find it and its relative documentation, but with MASM was not as easy. Talking about the documentation, to find the MASM one, you can go to the internet, use the google search and look for "MASM programmer's guide pdf" to find a PDF version of it and download. This is a PDF of a book that seems to be no longer available in printed form. I find that this PDF is much better than the official documentation provided by Microsoft on their web site. If I had to figure out how to work with MASM from the web page I would have failed for sure. So I suggest you to read and use the old good PDF copy of the book if you prefere to learn MASM on your own.



  1. The Netwide Assembler (NASM) is a widespread (thus netwide), portable (thus netwide!), very flexible and mature assembler tool with support for many output formats (thus netwide!!). You can read more about it at the Wikipedia page or at the introduction chapter of the NASM documentation. [click back]
  2. SOFTWARE.BIG is the 16-bit binary image file that, once on the root of TEST partition, is loaded in RAM and executed by my bootloader SHUTTLE2. You can read all the story about my bootloader SHUTTLE2 in the chapter VI. [click back]

<PREV.  -  ALL  -  NEXT>

Comments