+If you define an environment variable called NASM, the program will
+interpret it as a list of extra command-line options, processed
+before the real command line. This is probably most useful for
+defining an include-file search path by putting a lot of `-i'
+options in the NASM variable.
+
+The variable's value will be considered to be a space-separated list
+of options unless it begins with something other than a minus sign,
+in which case the first character will be taken as the separator.
+For example, if you want to define a macro whose value has a space
+in it, then setting the NASM variable to `-dNAME="my name"' won't
+work because the string will be split at the space into `-dNAME="my'
+and `name"', but setting it to `|-dNAME="my name"' will be fine
+because all further operands will be considered to be separated by
+vertical bars and so the space has no special meaning.
+
+Quick Start for MASM Users
+==========================
+
+If you're used to writing programs with MASM, or with TASM in
+MASM-compatible (non-Ideal) mode, or with A86, this section attempts
+to outline the major differences between MASM's syntax and NASM's.
+If you're not already used to MASM, it's probably worth skipping
+this section.
+
+One simple difference is that NASM is case-sensitive. It makes a
+difference whether you call your label `foo', `Foo' or `FOO'. If
+you're assembling to the `obj' MS-DOS output format (or `os2'), you
+can invoke the `UPPERCASE' directive (documented below, in the
+Output Formats section) and ensure that all symbols exported to
+other code modules are forced to uppercase; but even then, _within_
+a single module, NASM will distinguish between labels differing only
+in case.
+
+There are also differences in some of the instructions and register
+names: for example, NASM calls the floating-point stack registers
+`st0', `st1' and so on, rather than MASM's `ST(0)' notation or A86's
+simple numeric `0'. And NASM doesn't support LODS, MOVS, STOS, SCAS,
+CMPS, INS, or OUTS, but only supports the size-specified versions
+LODSB, MOVSW, SCASD and so on.
+
+The _major_ difference, though, is the absence in NASM of variable
+typing. MASM will notice when you declare a variable as `var dw 0',
+and will remember that `var' is a WORD-type variable, so that
+instructions such as `mov var,2' can be unambiguously given the WORD
+size rather than BYTE or DWORD. NASM doesn't and won't do this. The
+statement `var dw 0' merely defines `var' to be a label marking a
+point in memory: no more and no less. It so happens that there are
+two bytes of data following that point in memory before the next
+line of code, but NASM doesn't remember or care. If you want to
+store the number 2 in such a variable, you must specify the size of
+the operation _always_: `mov word [var],2'. This is a deliberate
+design decision, _not_ a bug, so please could people not send us
+mail asking us to `fix' it...
+
+The above example also illustrates another important difference
+between MASM and NASM syntax: the use of OFFSET and of square
+brackets. In MASM, declaring `var dw 0' entitles you to code `mov
+ax,var' to get at the _contents_ of the variable, and you must write
+`mov ax,offset var' to get the _address_ of the variable. In NASM,
+`mov ax,var' gives you the address, and to get at the contents you
+must code `mov ax,[var]'. Again, this is a deliberate design
+decision, since it brings consistency to the syntax: `mov ax,[var]'
+and `mov ax,[bx]' both refer to the contents of memory and both have
+square brackets, whereas neither `mov ax,bx' nor `mov ax,var' refers
+to memory contents and so neither one has square brackets.
+
+This is even more confusing in A86, where declaring a label with a
+trailing colon defines it to be a `label' as opposed to a `variable'
+and causes A86 to adopt NASM-style semantics; so in A86, `mov
+ax,var' has different behaviour depending on whether `var' was
+declared as `var: dw 0' or `var dw 0'. NASM is very simple by
+comparison: _everything_ is a label. The OFFSET keyword is not
+required, and in fact constitutes a syntax error (though you can
+code `%define offset' to suppress the error messages if you want),
+and `var' always refers to the _address_ of the label whereas
+`[var]' refers to the _contents_.
+
+As an addendum to this point of syntax, it's also worth noting that
+the hybrid-style syntaxes supported by MASM and its clones, such as
+`mov ax,table[bx]', where a memory reference is denoted by one
+portion outside square brackets and another portion inside, are also
+not supported by NASM. The correct syntax for the above is `mov
+ax,[table+bx]'. Likewise, `mov ax,es:[di]' is wrong and `mov
+ax,[es:di]' is right.
+