CrippleWare News

[hutch--]

> I am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64

And you got your response with ML64.

I did make the point with Kang Su Gatlin that ML.EXE should not be combined with a 64 bit version. ML workes well in 32 bit, no reason to mess it up with another OS environment. I would not have complained if they had have spent the development time with call automation and high level control flow directives but I can live without the and with Vasily's macros and my own, I don't have to.

msgloop proc

    LOCAL msg    :MSG
    LOCAL pmsg   :QWORD

    mov pmsg, ptr$(msg)                             ; get the msg structure address
    jmp gmsg                                        ; jump directly to GetMessage()

  mloop:
    .switch msg.message
      .case WM_KEYUP
        .switch msg.wParam
          .case VK_F1
            invoke SendMessage,hWnd,WM_COMMAND,300,0
        .endsw
    .endsw
    invoke TranslateMessage,pmsg
    invoke DispatchMessage,pmsg
  gmsg:
    test rax, function(GetMessage,pmsg,0,0,0)       ; loop until GetMessage returns zero
    jnz mloop

    ret

msgloop endp

[jj2007]

Windows.inc, line 24748:

Code: [Select]

COMP_ELEM_ALL equ (COMP_ELEM_TYPE+COMP_ELEM_CHECKED+COMP_ELEM_DIRTY+ ... +COMP_ELEM_FRIENDLYNAME)
Works fine with all 64-bit assemblers except the latest Visual Studio Community version named Microsoft (R) Macro Assembler (x64) Version 14.00.24210.0, which produces a garbled error message:

Code: [Select]

*** Assemble using \masm32\bin\ml64 /c /Zp8 /Zp8 /Fo "test64" tmp_file.asm ***
 Assembling: tmp_file.asm
** 64-bit assembly **

***********
ASCII build
***********

\Masm32\MasmBasic\Res\DualWin.inc(24748)ified size
\Masm32\MasmBasic\Res\DualWin.inc(24748) : error A2042:statement tMicrosoft (R) Macro Assembler (x64) Version 14.00.24210.0
With COMP_ELEM_ALL equ etc commented out, it builds fine, but it takes almost 14 seconds instead of 0.4 secs with the older version 10.0 (HJWasm32 and AsmC: 0.3 secs) 8)

[hutch--]

The version of "windows.inc" in the MASM32 SDK is designed for ML.EXE, not ML64.EXE. It may be OK with the Watcom forks but neither ML or the forks are ML64 compatible. You can get errors by using the wrong data for a tool any old time. Fortunately ML64 is not crippled with these limitations and simply uses its own compatible includes and libraries. If I want to write 32 bit software I use the MASM32 SDK as its a mature and reliable system with years of practice.

RE: Anyone using the MASM32 version of "windows.inc" has probably used it because they did not have to write it in the first place, it is order dependent and took a very long time to get it working properly. I am still repairing Vasily's win64.inc that made extensive use on the 32 bit version of windows.inc with complete sections of equates copied from the 32 bit version and have just untangled a mess of nested typedefs so that the data types are consistent and understandable and while I have added support for both common controls and dialogs, there is a lot more that needs to be done with structures.

The technique for maintaining windows.inc is a fully automated system that is constructed from about 50 files so its far easier to isolate individual sections if changes are needed. For anyone who wants to complain about the odd glitch in windows.inc, they can always get off their arse and write their own, its a messy and time consuming thankless task that few will undertake.

[jj2007]

The version of "windows.inc" in the MASM32 SDK is designed for ML.EXE, not ML64.EXE. It may be OK with the Watcom forks but neither ML or the forks are ML64 compatible.

Truth is that ML64 is not compatible with ML32 and the Watcom forks :P