how can i compile in MASM 64

[RBator]

Hello : haw can i compile in Masm 64 . I save in notepad file  *asm ; and kind of order will compile it ?

[qWord]

are you using ml64.exe? - as said in this thread, use jwasm. It is an masm compatible assembler which extens the lame ml64.exe.

[RBator]

I start in ml64.exe . I have not any literature . I want use 64 bit asembler , therefore i choice masm 64 . If You could , give me links from documentation on masm 64 .
I do not know , how can i compile in masm . How can i debugging ? I  run ml64.exe and i do not know what  i ought to do  ?

[Ficko]

Hi RBator!

I think you didn't fully get "qWord"'s point. :wink

"JWASM" is better than MASM - especialy the 64-bit part of it - and more or less compatible.

There is no tailor-made literature for "ml64" but you can use the 32-bit manuals and "MSDN" tells you what is not implemented in the 64-bit assembler.

Furthermore here is the manual for JWASM - hopefully "Japheth" will not sue me for it -  :toothy

JWasm Manual

    0.    Contents

    1.    About
    2.    Commandline Options
    3.    Syntax Extensions
     3.1  Directive INCBIN
     3.2  FASTCALL Register Calling Convention
     3.3  IDs enclosed in Back Quotes
     3.4  Floating-Point Immediates in Instructions
     3.5  Directive OPTION FIELDALIGN
     3.6  Directive OPTION PROCALIGN
     3.7  Directive OPTION MZ
     3.8  Directive OPTION ELF
     3.9  Directive OPTION WIN64
     3.10 Directive OPTION FRAME
     3.11 Directive OPTION RENAMEKEYWORD
     3.12 Directives PUSHCONTEXT/POPCONTEXT ALIGNMENT
     3.13 Directive .X64
     3.14 Directive INVOKE in Win64
     3.15 Attribute LABEL for first Macro Parameter
     3.16 Masm v8 Extensions
     3.17 Other Differences
       a) Numeric constant __JWASM__
       b) Operating System Argument for .MODEL
       c) Accepted Parameters for IF[N]DEF Directive
       d) Visibility of Procedures
    4.    Instruction Sets
    5.    Code Generation Differences
    6.    Win64 Structured Exception Handling (SEH)
    7.    Errors and Warnings
    8.    Masm Bugs fixed in JWasm
    9.    Known Bugs and missing Features


    1. About

    This document lists the differences between JWasm and Masm, as far as
    the user interface is concerned.

    When Masm is mentioned, then usually Masm v6.15 is meant, unless stated
    otherwise. However, for 64-bit, Masm v8 is used for comparisons, which
    was the first Masm version supporting 64-bit (ML64.EXE).

    The Masm documentation itself can be found on numerous places in the web,
    in plain text, HTML, PDF and Windows Help format.


    2. Commandline Options

    Entering 'JWasm -?' or 'JWasm -h' will make JWasm display the options
    it understands. A lot of them exist in both Masm and JWasm, but some
    are valid for JWasm only; OTOH, a few options are missing in JWasm.

    -<0|1|..|10>: selects cpu/instruction set. Most values correspond to
     cpu directives: 0=.8086, 1=.186, 2=.286, 3=.386, 4=.486, 5=.586,
     6=.686. The rest is:
      7 = P2 (.686 + .MMX)
      8 = P3 (.686, MMX + SSE instructions )
      9 = P4 (.686, MMX, SSE and SSE2 instructions )
     10 = x86-64 cpu

    -bin: Selects output format BIN. The output module's default file
     extension will be changed from .OBJ to .BIN. The contents of the file
     are just the raw data bytes emitted by the assembler, no header,
     relocations or symbol tables are generated. If a listing file is
     produced, a binary map will be added, which shows the file and
     memory layout of the image.

    -djgpp: Selects Djgpp's variant of COFF as output format. Since it is
     rarely used nowadays, this option isn't activated in the precompiled
     binaries. See 9.3c how to enable it.

    -elf: Selects output format ELF. JWasm will produce an object module
     in 32-bit Elf format.

    -elf64: Selects output format ELF64. JWasm will produce an object module
     in 64-bit Elf format. Additionally, this option will set cpu to x86-64
     and model to flat.

    -eq: suppress displaying error messages on the screen. They are still
     written into an error file.

    -FPi: "inline FP instructions with emulation". This will make JWasm
     to create fixups for floating-point instructions if code is 16bit.
     If supported by the linker or the OS, the FP instructions can then
     be replaced by calls to an FP emulator if no coprocessor exists.

    -m<t|s|m|c|l|h|f>: generates a line containing a .MODEL directive to
     select model tiny, small, medium, compact, large, huge or flat.

    -mz: output format MZ will write a binary in DOS MZ format. The
     module's default file extension will be changed from .OBJ to .EXE. All
     symbols in the module must resolve internally, no externals are allowed.
     Some values in the "MZ" header can be adjusted by directive OPTION MZ
     (see below).

    -nc=<name>: sets the code segment's class name if simplified
     segment directives are used (default:CODE).

    -n<d|t>=<name>: -nt/-nd will set the name of the code/data segments
     if simplified segment directives are used (default:_TEXT/_DATA).

    -nm=<name> sets the module name (default:filename without extension).

    -win64: this option makes JWasm produce an object module for Win64.
     Additionally, the option will set cpu to x86-64, model to FLAT and
     default calling convention to FASTCALL. This is to make JWasm compatible
     with Masm64 (ML64.EXE).

    -Zd: generates line number debug information for OMF and COFF output
     format. For other formats, this option is ignored. Line number
     information allows a debugger to trace the binary on the source code
     level. Debuggers which have been verified to work with this option:
     MS CodeView, CDB, WinDbg, MS VC++ EE 2008, OW WD/WDW, PellesC IDE.

    -zf<0|1>: these options select the FASTCALL calling convention type
     for 16- and 32-bit code. The default value 0 is MS VC style, while
     value 1 activates the Open Watcom fastcall type.

    -Zg: this option makes JWasm try an exact copy of Masm's code
     generation, which results in the following changes:
      - the default prologue for procedures will use
        "add [e]sp, - localsize" instead of "sub [e]sp, localsize".
      - the default epilogue for procedures will always prefer to use
        opcode "leave" if possible.
      - expressions '<reg> == 0' and 'reg != 0' will generate code
        'or <reg>,<reg>' instead of 'cmp <reg>,0'.
      - if invoke must extend an argument's size from word to dword,
        register eax remains unchanged.
      - the segment value of FAR externals will always be assumed unknown,
        no matter whether the external is defined inside or outside of a
        segment block. Thus those labels are excluded from "far call
        optimization".

    -Zi: generates symbolic debugging info in CodeView V4 style for OMF and
     COFF output format. For other formats, this option is accepted, but
     ignored. Debuggers which have been verified to work with this option:
     MS CodeView, CDB, WinDbg, MS VC++ EE 2008, OW WD/WDW, PellesC IDE.

    -zlc, -zld, -zlf, -zls: these options reduce size of the output module.
     They might be useful if lots of - small - modules are to be assembled
     and put into a static library. Also, the OMF coment records written
     if -zlc or -zld is NOT set may not be accepted by all linkers.

    -Zm: this option (or setting OPTION M510) will do:
      - set OPTION OLDSTRUCTS
      - set OPTION DOTNAME
      - set OPTION SETIF2:TRUE
      - set OPTION OFFSET:SEGMENT (if no model is set)
      - set OPTION NOSCOPED (if no model with language is set)
      - allow to define data items behind code labels
      - allow "invalid" use of REP/REPE/REPNE instruction prefixes
     Other Masm v5.1 compatibility options aren't implemented yet.

    -Zne: this option will disable syntax extensions which aren't supported
     by Masm. Currently these are:
      - directive INCBIN
      - FASTCALL calling convention
      - IDs enclosed in backquotes
      - floating-point immediate operands in instructions
      - directive OPTION FIELDALIGN
      - directive OPTION PROCALIGN
      - directive OPTION MZ
      - directive OPTION ELF
      - directive OPTION WIN64
      - directive OPTION RENAMEKEYWORD
      - directives PUSHCONTEXT/POPCONTEXT ALIGNMENT
      - attribute LABEL for first macro parameter
      - integer initializer values for items of type [X]MMWORD
      - parameters for IF[N]DEF directive
      - name argument for .DATA, .DATA? and .CONST directives

    -zt<n>: "Set name decoration for STDCALL symbols". Options "-zt0" will
     make object modules compatible to ALINK + Win32.lib.

    -Zv8: this option changes handling of procedure visibility to the
     way done by Masm v8+. See Visibility of Procedures
     for details.

    -zze: this option suppresses name decoration for procedures with
     the EXPORT attribute (exported name only).

    -zzs: this option is kind of a workaround for a WLink incompatibility.
     It's useful to be set if 1) the source module has a starting address,
     2) output format is COFF AND 3) WLink is to be used as linker.

    When starting, JWasm will search for environment variable JWASM
    and handle it similar to the way Masm handles variable ML.


    3. Syntax Extensions

    3.1 Directive INCBIN

    This directive allows to include the contents of a file into
    the object module. Syntax is

      INCBIN filename [, starting offset[, max size]]

    The filename should be enclosed in <> or double quotes.


    3.2 FASTCALL Register Calling Convention.

    In 16- and 32-bit mode, one may use either the Microsoft or the
    Watcom register calling convention. It's selected by option -zf.

    The Microsoft FASTCALL convention uses registers (E)CX and (E)DX for
    the first 2 parameters which are small enough to fit into a register.

    The Open Watcom fastcall convention uses up to four registers ( E/AX,
    E/DX, E/BX, E/CX ).

    In 64-bit mode, FASTCALL means the standard Windows 64 ABI if option
    -win64 was given and it is the default then. For -elf64, there is
    currently no FASTCALL support.


    3.3 IDs enclosed in Back Quotes

    IDs can be enclosed in back quotes (`) and thus they can contain
    characters not allowed in "normal" IDs.


    3.4 Floating-Point Immediates in Instructions

    Floating-point immediate values are accepted as instruction operands
    ("mov eax,1.0").


    3.5 Directive OPTION FIELDALIGN

    OPTION FIELDALIGN sets the default value for structure alignment. The
    default value is 1 or the value set by cmdline switch -Zp. Syntax is:

      OPTION FIELDALIGN:<1|2|4|8|16|32>

    The current default value can be saved/restored with directives
    PUSHCONTEXT/POPCONTEXT ALIGNMENT,


    3.6 Directive OPTION PROCALIGN

    With OPTION PROCALIGN parameter it's possible to automatically
    align procedures. Syntax is:

      OPTION PROCALIGN:<1|2|4|8|16|32>


    3.7 Directive OPTION MZ

    Directive OPTION MZ allows to fine-tune the values written to the
    MZ header if output format MZ is selected. For other output formats,
    this option has no effect. The syntax for the directive is:

      OPTION MZ:[start_fixups][,header_align][,heap_min][,heap_max]

    The parameters are:
    - start_fixups: offset within the header where segment fixups will start.
      The size of the header will always be at least this value, even if there
      are no fixups at all. Default - and minimum - value is 1Eh.
    - header_align: alignment of the header (including segment fixups).
      Value must be a power of 2, 10h is the default and minimum.
    - heap_min: the additional space (in paragraphs) which is needed by
      the binary to run. Default is the total of the sizes of the
      uninitialized BSS and STACK segments.
    - heap_max: space (in paragraphs) which the binary would like to have.
      Default is FFFFh.


    3.8 Directive OPTION ELF

    Directive OPTION ELF allows to fine-tune the values written to the
    ELF header if output format ELF is selected. For other output formats,
    this option has no effect. The syntax for the directive is:

      OPTION ELF:osabi

    The only argument, osabi, will be copied to the ELF header field EI_OSABI.
    It's a numeric constant, a list of valid values for this field can be found
    in the elf specs, the default value is 3 ( = ELFOSABI_LINUX ).


    3.8 Directive OPTION WIN64

    Directive OPTION WIN64 allows to set parameters for the Win64 output
    format if this format is selected. For other output formats,
    this option has no effect. The syntax for the directive is:

      OPTION WIN64: store_register_params

    accepted values for store_register_params are:
     - 0: Nothing is done, the "home locations" (also sometimes called
          "shadow space") of the first 4 register  parameters are
          uninitialized. This is the default setting.
     - 1: register contents of the PROC's first 4 parameters (RCX, RDX,
          R8 and R9 ) will be copied to the "home locations" within
          a PROC's prologue.


    3.10 Directive OPTION FRAME

    This option affects 64-bit only. It allows to make JWasm automatically
    generate prologues and epilogues for procedures with the FRAME attribute.
    Thus the code complies to the rules of Win64 SEH (Structured Exception
    Handling). Syntax is

        OPTION FRAME:<AUTO | NOAUTO>

    AUTO will enable this feature, NOAUTO (which is default) disables it.

    The unwind information which is generated is "complete", that is, it
    contains the ".endprologue" pseudo-op already. To allow to save all
    non-volatile registers in the prologue, the "USES" phrase is more
    capable in this mode and will accept XMM registers to be saved and
    restored.


    3.11 Directive OPTION RENAMEKEYWORD

    This option allows to rename a keyword, so it can be used under a
    different name. Syntax:

       OPTION RENAMEKEYWORD:<current_name>, new_name

     The current name must be enclosed in angle brackets, the new name
    must be a valid identifier.
     If a keyword is to be renamed, it should be done at the beginning
    of the source, and a keyword shouldn't be renamed multiple times.


    3.12 Directives PUSHCONTEXT/POPCONTEXT ALIGNMENT

    The PUSHCONTEXT/POPCONTEXT directives understand new qualifier
    ALIGNMENT, which saves/restores current values of FIELDALIGN and
    PROCALIGN options.


    3.13 Directive .X64

     This selects a 64-bit (x86-64) cpu. Usually this directive isn't needed,
    because the output formats WIN64 and ELF64 select this cpu as default,
    but for mixed-model binaries it may be useful (see example Dos64.asm).

     When the cpu is set to 64-bit, the SEGMENT directive accepts a new
    'size' value: USE64. It tells the assembler that this segment's offset
    is 64-bit wide and uses 64-bit instructions.
     The SYSCALL calling convention is renamed to SYSCALL_ when 64-bit is on,
    because there exists a SYSCALL instruction mnemonic in this mode.


    3.14 Directive INVOKE in Win64

    The 64-bit version of Masm doesn't support INVOKE anymore. JWasm still
    does, but please be aware of some restrictions:

    - in theory, using INVOKE requires the FRAME attribute for PROC. It will
      work without FRAME, but Win64 SEH won't be happy with it then.
    - the implementation in 64-bit is very simple: for each INVOKE rsp is
      reduced by the space required for the arguments, then the call is issued
      and last rsp is increased again.
    - there is no additional check that the stack is aligned to 16 byte. The
      PROC's FRAME attribute ensures that the stack is correctly aligned after
      the prologue is done. However, it's the programmers responsibility that
      the stack is still aligned when the code generated by INVOKE starts.


    3.15 Attribute LABEL for first Macro Parameter

    The LABEL attribute for the first macro parameter allows access to a
    label which is assigned to the macro. Syntax is:

    <macro_name> MACRO <param_name>:LABEL [,<param_name>[, ...]]

    The LABEL attribute is accepted for the first parameter only. A macro
    with such a parameter can be invoked in the following way:

    <label> <macro_name> [<argument>, ...]

    Example:

    foo macro lbl:LABEL, first, second
    lbl  db first
         dw second
    endm

    usage of foo:

    data1 foo 1,1000
    data2 foo 2,2000


    3.16 Masm v8 Extensions

    Masm v8 introduced several extensions which are also supported by JWasm:

    - directive .SAFESEH
    - types SQWORD and OWORD
    - operators IMAGEREL and SECTIONREL
    - segment attribute ALIGN(n)
    - segment characteristics INFO, READ, WRITE, EXECUTE, SHARED, NOPAGE,
      NOCACHE, DISCARD.
    - data types MMWORD and XMMWORD.

     For data items of types MMWORD or XMMWORD, JWasm will accept integer
    values for initialization. This differs from Masm - Masm accepts just
    floating-point initializers for such data items ( it's even worse, since
    floating-point initializers are silently ignored for data items with
    sizes != 4, 8 and 10 ).


    3.17 Other Differences

    a) Numeric constant __JWASM__

    __JWASM__ is a predefined symbol, its value is the current JWasm
    version * 100, that is, for v1.9 the value is 190. The predefined text
    equate @Version won't contain JWasm's version, for compatibility reasons
    it has value <615>.

    b) Operating System Argument for .MODEL

    The .MODEL directive has an optional "operating system" argument. Masm
    accepts value OS_DOS only, JWasm accepts values OS_DOS and OS_OS2.
    This setting will affect the generated code of directives .STARTUP and
    .EXIT for 16-bit memory models.

    c) Accepted Parameters for IF[N]DEF Directive

    Masm's IF[N]DEF directive accepts user-defined symbols and registers,
    but fails for instructions, directives and other reserved words. JWasm's
    IF[N}DEF implementation accepts those symbols as well. OTOH, JWasm is
    a bit more picky and will display a warning if more than one item is
    found behind the directive (Masm just takes the first and silently skips
    the rest).

    d) Visibility of Procedures

    When a PROTO or EXTERNDEF directive for a symbol is located in a module
    before a matching PROC directive, the visibility of this Procedure
    ( "public" vs "private", or "external" vs. "static" ) is handled
    differently in Masm v6 or 7 and Masm v8 or newer:

    Since Masm v8, a PROTO or EXTERNDEF for a symbol which is later defined
    as a PROC will make the procedure public, no matter what a possible
    visibility attribute of the PROC itself - or the default one set with
    OPTION PROC - is telling.

    OTOH, with Masm v6/7, both the visibility attribute of the PROC directive
    and the current default setting of OPTION PROC will affect ths symbol's
    visibility.

                Masm6 Masm8 JWasm JWasm+Zv8
      -------------------------------------
      On,E,P            x             x
      On,E,Pn           x             x
      On,E,Pp     x     x      x      x
      Op,E,P      x     x      x      x
      Op,E,Pn     x     x             x
      Op,E,Pp     x     x      x      x

      On = OPTION PROC:PRIVATE
      Op = OPTION PROC:PUBLIC
      E  = PROTO or EXTERNDEF before PROC
      P  = PROC without visibility attribute
      Pn = PROC with PRIVATE visibility attribute
      Pp = PROC with PUBLIC visibility attribute
      x  = procedure will be public

    As default, JWasm more or less copies the Masm v6/7 behavior. The
    difference is that an explicite visibility attribute behind PROC has
    the highest priority for JWasm. However, since v2.04, there's an
    additional cmdline option -Zv8 which will make JWasm behave like Masm v8+.

    It should be noted that without a PROTO/EXTERNDEF before PROC, there
    are no differences between Masm v6, v8 and JWasm, and the -Zv8 switch
    also has no effect then.


    4. Instruction Sets

    JWasm supports all instructions sets supported by Masm v8. These are

    - the instructions implemented by 8086, 80186, 80286, 80386, 80486.
    - the Pentium and Pentium Pro instructions.
    - the MMX and K3D instruction set extensions.
    - the SSE, SSE2, SSE3 and SSSE3 instruction set extensions.
    - the x86-64 64-bit instruction set (implemented by ML64.EXE).

    Additionally, the SSE4.1 and SSE4.2 instruction sets have been implemented
    in JWasm v2.01. These instructions aren't supported by Masm v8, but
    require Masm v9.


    5. Code Generation Differences

    JWasm might generate slightly different code than Masm on some occasions.
    Commandline option -Zg should eliminate most of these differences.
    However, some differences are due to fixed Masm bugs (see below), in
    which case option -Zg won't have any effect.


    6. Win64 Structured Exception Handling (SEH)

    SEH in Win64 differs significantly from the implementation in Win32.
    It's very well possible to ignore Win64 SEH for assembly. However,
    if an assembly routine wants to comply to these rules, a thorough
    understanding of the Win64 ABI is necessary. Masm ( the 64-bit
    version ) supplies some "primitives" for SEH support (.ALLOCSTACK,
    .PUSHREG, .SAVEREG, ...), along with a new FRAME attribute for the
    PROC directive. These features are also supported by JWasm. See sample
    Win64_3.asm how the "primitives" are to be used for SEH support. The big
    disadvantage is that using the FRAME keyword in Masm "disables" most
    of the other high level features combined with PROC (function parameters,
    locals and registers saved with USES) because no function prologues and
    epilogues are generated anymore. Additionally, the implementation
    in some Masm versions seems to be a bit buggy.

    Because of this and to ease the usage of SEH in Win64 there is a new
    directive implemented in JWasm: OPTION FRAME:AUTO. If this option
    is set, JWasm will create Win64 SEH-compatible prologues and epilogues.
    If the option is off, JWasm will behave Masm-compatible, that is, FRAME
    found in a PROC directive will disable automatic prologue/epilogue
    generation. See sample Win64_3e.asm how this option is supposed to be
    used.

    As for the PROC syntax: The Masm documentation states that FRAME can be
    used in combination with USES and procedure parameters and must be
    located behind all parameters. However, this syntax isn't accepted by
    any Masm version. The only syntax which Masm will accept without being
    confused is FRAME as the one and only parameter for PROC. Therefore
    JWasm doesn't follow the Masm documentation in this point: the optional
    FRAME keyword is expected *before* the procedure parameters. The syntax
    in JWasm is:

    procname PROC [public] FRAME[:exc_handler] [USES <reglist>] [parameters]

    The SEH "primitives" will generate some additional data in segments
    .pdata and .xdata. This data is somewhat hidden, but JWasm will display
    the corresponding data definitions in the listing if option -Sg is set.


    7. Errors and Warnings

    The warning and error numbers emitted by JWasm differ from Masm's.
    However, the texts of the messages are pretty much identical. There
    are a few messages which deserve a more detailed explanation:

    - 'Text macro was used before definition': this is a warning only.
    However, using text macros before they have been defined will force
    JWasm to do a full second path, which increases assembly time.

    - 'IF[n]DEF expects a plain symbol as argument': this is a warning.
    Masm accepts any expression as argument for these directives, but
    the result probably isn't always what has been expected.


    8. Masm bugs fixed in JWasm

    - the infamous "invoke" bug: using invoke with variables of type BYTE
      (or WORD in 32bit code) causes bad code to be generated in Masm.
    - Masm does align structure members if requested, but it doesn't pad
      bytes at the end of the structure, as C compilers do.
    - PROTOs contained twice in the source caused an EXTDEF entry to be
      generated in the object module.
    - "TYPE xmm0" will return 10 in Masm v6 and v7, JWasm returns 16, same
      as Masm v8.
    - a nested structure might cause a GPF in Masm if the embedded STRUCT's
      starting offset has to be adjusted due to alignment.
    - defining huge arrays in Masm is very slow and might even cause a
      deadlock if COFF has been selected as output format.
    - for Masm v6 and v7, if an array > 64 kB is defined and output
      format OMF is selected, the array's size will be mod 0x10000 only.
    - Masm doesn't flag invalid numbers in struct/array initializer strings.
    - if an ALIAS is defined somewhere in the source and the symbol table
      is listed, a 'General Failure' error occurs in Masm if output format
      is OMF.
    - Type "coerces" for DWORD data items defined in a 32bit segment are
      ignored by Masm, i.e., "dd far16 ptr <symbol>" will generate a
      near32 fixup instead of a far16 one.
    - if the ALIGN directive has to add 5 bytes in 32bit code segments,
      Masm includes an "add eax,0" opcode, which isn't a no-op because
      flags are modified.
    - silent truncation of immediate constants: Masm v6 and v7 will accept
      line "mov [word_variable],12345h" without error.
    - preprocessed output with option -EP may erroneously contain text
      macros and macro function calls if the macros are located in the
      initialization string of a structured variable.
    - Masm generates wrong code if a conditional jump is coupled with a
      type coercion which modifies offset magnitude. Examples: "jz near32
      ptr ..." in 16bit code or "jz near16 ptr ..." in 32bit code).
    - if the arguments given to Masm end with an option which expects
      a parameter (i.e. "ml -c -Fo"), a 'General Failure' may occur.
    - floating-point data items in Masm can be followed by any suffix
      (example: REAL4 1.0foo, 2.0bar). JWasm won't accept this.
    - If a local is defined inside a macro, Masm will create a unique name
      for it. The name is constructed by using '??' as prefix, followed by
      a hexadecimal number with 4 digits. There is no check for overflow,
      however, so if the total of locals in all macros exceeds 65536,
      strange errors will occur.

    It's slightly dangerous to fix old Masm bugs, since some code might
    work only if the bugs exists. So no, JWasm won't achieve 100% Masm
    compatibility.


    9. Known Bugs and missing Features

    a) Bugs which are known but not fixed yet:

    There are currently no known bugs.

    b) Features which aren't implemented yet:

    - directives PAGE, TITLE, SUBTITLE, SUBTTL.
      the directives are ignored and a warning (level 3) is displayed.
    - the following parameters of the OPTION directive:
      - OLDMACROS
      - EXPR16
      - READONLY
    - optional parameter NONUNIQUE for structures is ignored.
    - operators LOW32, HIGH32 (Masm v8+).
    - commandline option -Zd for ELF output format.
    - commandline option -Zi for ELF output format.

    c) Features which aren't active in the precompiled binaries:

    - support for Djgpp's variant of COFF. [ -DDJGPP_SUPPORT ]

    You'll have to recompile the sources with the appropriate macros
    defined ( see the values within [] above ) to enable these features.

    d) Missing features which most likely won't be implemented:

    - %OUT directive
    - syntax "mm(n)" and "xmm(n)" (supported by Masm v6 and v7 only)


    Japheth

[RBator]

Thank You .
I give for it .

Best Days

Rafał Bator