Myths about MASM

Myths About MASM

The name MASM has earlier usage as the Unisys Meta Assembler but since about 1990 when Microsoft introduce MASM version 6.0 the name MASM has normally been associated with the Microsoft Macro Assembler. MASM is a programming tool with a very long history and has been in constant development since it earliest version in 1981. Below is the copyright notice when ML.EXE version 6.14 is run from the command line.

MASM preserves the historical INTEL notation for writing x86 assembler and it is a defacto industrial standard because of the length of time it has been a premier programming tool. From the late 80s onwards it has been compatible with whatever has been the current Microsoft object file format and this has made assembler modules written in MASM directly compatible with other Microsoft languages.

The current versions of ML.EXE (The assembler in MASM) as of late 2015 is version 11 with versions 9 and 10 being current for operating system version going back to Win7 but the architecture and format of current and recent versions of ML.EXE are based on the version 6.00 that was released in 1990. The technical data published in the manuals for version 6.00 and the last seperate release of MASM 6.11d as a commercial product still mainly apply to the most recent versions.

Microsoft released version 6.11d in 1993 including 32 bit Windows operating system capacity. It is the original win 32 assembler and was supported in that release with 32 bit assembler code examples that would run on the early 32 bit versions of Windows NT.

Debunking the myths about MASM

1. MASM is no longer supported or upgraded by Microsoft.

Nobody has told this to Microsoft who supply ML.EXE 9.0 in the Win7 DDK and version 10 and 11 for later Windows versions. It has been a component of the Microsoft Visual C/Studios commercial development environment since it was made available as a processor pack in 2000 for VC98. It is upgraded on a needs basic by Microsoft noting that it has been in constant development since 1981 and does not need much done to it apart from the occasional upgrade to reflect operating system and hardware changes. It is well known that Microsoft use MASM to write critical parts of their own operating systems.

2. MASM produces bloated files that are larger than true low level assemblers.

This folklore does not fit the facts. In 16 bit code MASM can produce a 2 byte com file (int 19h) and in modern 32 bit PE (Portable Executable) files, it can produce a 1024 byte working window which is the PE specification minimum size for a PE file. Much of this folklore was invented in the middle 90s by people who could not ever write assembler code in MASM.

3. MASM is not a true low level assembler.

MASM can write at the lowest possible level in an assembler with direct DB sequences in the code section. The recent versions can write the entire Intel instruction set up to SSE4+. Many confuse the higher level simulations in MASM with the incapacity to write true low level code. MASM is the architypal MACRO assembler for the Windows platform and this macro capacity is powerful enough to emulate many forms of higher level constructions.

4. MASM is only an accessory for C programming.

Nobody seems to have told this to the hundreds of thousands of assembler programmers who write executable programs and dynamic link libraries for 32 bit Windows in MASM. In 32 bit Windows, MASM (ML.EXE) produces the identical COFF (common object file format) to Microsoft Visual C (CL.EXE) so object modules written in either MASM or Visual C are interchangable. With MASM you have the choice of writing an object module in Microsoft C and using it with a MASM application just as you can write an object module in MASM and use it with Visual C. The difference with MASM is it is powerful enough to use a C compiler as an accessory to assembler programming.

5. MASM modifies your code when it assembles it.

What you write is what you get with MASM. If you use some of the more common higher level capacities in MASM, you get the format it is written to create and this applies to the use of a stack frame for procedures and characteristics like jump length extension if a jump is too far away from the label it jumps to. In both instances you have options to change this, you can disable jump extensions if you want to and specify the jump range with SHORT or NEAR. With a procedure where you don't want a stack frame, you use a standard MASM syntax to turn the stack frame off and re-enable it after the procedure is finished. This technique is commonly used when writing reusable code for libraries where an extra register is required or where the stack overhead may slightly slow down the procedure.

6. MASM code is too complex for a beginner to learn.

This is another myth from people trying to support other assemblers that don't have the code parsing power of MASM. MASM can be used to write from very simple code to extremely complex code. The difference is that it is powerful enough to do both without the ugly and complicated syntax of some of the other assemblers around that don't have the parsing power that of MASM. Differing from some of the less powerful assemblers, MASM uses the historical Intel notation when it uses keywords like OFFSET as this correctly distinguishes between a fixed address within an executable image and a stack variable which is created at run time when a procedure is called. When MASM requires operators like BYTE PTR, it is to distinguish between ambiguous notation forms where the size of the data cannot be determined any other way.

7. MASM is really a compiler because it has high level code.

MASM is capable of writing many normal high level constructions like structures, unions, pointers and high level style procedures that have both size of parameter checking and parameter count checking but the difference again is that it is powerful enough to do this where many of the others are not. While you can write unreliable and impossible to debug code like some other assemblers must do, with MASM you have the choice to write highly reliable code that is subject to type checking.

The real problem is that such capacities are technically hard to write into an assembler and while some of the authors of other assemblers are very higly skilled programmers, an individual does not have the resources, duration or capacity of a large software corporation that has developed and maintained MASM over just over 30 years.