About Me

Welcome to my blog! This is where I collect my observations and notes on programming and technology. The main subjects range from implementation details to broader ideas about programming.

Main Topics

• Engineering Projects: Exploring implementation details and how technical systems work.
• C/C++: Notes on language features and programming techniques.
• The Programmer’s Perspective: Ideas about developing a career and a way of thinking as a programmer.

For more, visit the categories page.

Contact

If you have questions or would like to discuss something, please get in touch through the About page.

Thank you for reading and for your support. I hope these notes help you on your own technical journey!

Assembly Environments and Conventions Used in This Blog

MASM and NASM

While working through x86-32 examples, I reorganized my toolchain and decided to state the environment more clearly in future posts. Earlier examples followed the MASM conventions used in my DOS exercises, including structures such as:

1
2
3
4
5
6
7
8
9
10
11

assume cs:code ds:data
data segment
	...
data ends
code segment
start:
	...
    mov ax,4c00h
    int 21h
code ends
end start

Those directives belong to that assembler and output workflow. They are not instructions that every assembly program on every toolchain must contain. A different assembler expects its own syntax and declarations.

I first used MASM under MS-DOS and DOSBox, then NASM with experiments in VirtualBox and later on CentOS, Ubuntu, Kali, and Debian. MASM is Microsoft’s assembler; NASM is available across multiple platforms and can be installed on Linux. It is not guaranteed to be preinstalled with every Linux distribution.

Future examples will primarily use NASM, with some MASM examples retained. Each program should state the assembler and execution environment so readers know how the author built and ran it.

A small flat-binary example

Consider an .asm file containing only these two instructions:

1
2

mov ax,cs
   mov ds,ax

In the recorded MASM workflow, this produces missing-segment and missing-end diagnostics:

NASM’s flat-binary workflow can assemble it directly:

The processor can execute the resulting bytes when they are loaded in a suitable environment. What happens after the two instructions depends on the following bytes and control flow. An example can deliberately halt or loop instead of using a DOS process-termination sequence.

This direct binary output is convenient for boot-sector work. The original claim that MASM cannot produce any such boot code is too strong: other assembler/linker workflows can produce suitable binaries as well. The practical preference here is NASM’s straightforward support for the experiments I am writing.

Editing and execution environments

I initially wrote source in DOS, later used a Windows text editor and an .asm extension, and eventually moved editing to Ubuntu to become more comfortable with Linux. The editor’s host OS need not match the target execution environment.

Bare-metal examples that manipulate hardware and privileged state need an appropriate environment; ordinary user-space assembly does not automatically require unrestricted hardware access. A virtual machine is useful for the boot and protected-mode exercises because it provides an isolated machine in which to run the binary.

I accidentally deleted the virtual-disk images while reconfiguring my environment. Many small experimental programs lived only inside those images. They were too large for the recycle-bin workflow I expected, so I could not simply restore them there. My response was to start again. The experience also makes keeping source outside a single VM image especially valuable.

What follows

The unfinished sequence beginning with Displaying a Number on Screen will need a rewritten second experiment using the NASM environment. Both missing source and the change of assembler affect that continuation.

Future titles may say x86-16 or x86-32 instead of x86-8086. In these introductory posts, x86-16 sometimes refers to the 8086-style environment, but the terms are not universally interchangeable: later processors also run 16-bit code and provide additional instructions. I will state the actual CPU and mode requirements where they matter.

• ← Previous Post
• Next Post →