CrippleWare News

[jj2007]

Have you ever seen the "invalid character in xyz.inc" bug? I see it every 3rd or 4th time I try to build a snippet with ML64.

But that one is harmless, you just hit the build all button again, and it works. Or it complains about missing angle brackets, but again, hitting build again usually helps

Here is one that was more difficult to chase down. The snippet builds without any includes, because I managed to isolate the Windows.inc struct that causes the crash:

Code: [Select]

MAPI_DIM equ 1

MAPINAMEID STRUCT
    lpguid QWORD ?
    ulKind dd ?
    union Kind
        lID dd ?
        lpwstrName QWORD ?
    ends
MAPINAMEID ENDS

SMAPIFormProp STRUCT
    ulFlags dd ?
    nPropType dd ?
    nmid MAPINAMEID <>
    pszDisplayName QWORD ?
    nSpecialType dd ?
    union u
        struct sl
            nmidIdx MAPINAMEID <>
            cfpevAvailable dd ?
            pfpevAvailable QWORD ?
        ends
     ends
SMAPIFormProp ENDS

SMAPIFormPropArray STRUCT
    cProps dd ?
    ulPad dd ?
    aFormProp SMAPIFormProp MAPI_DIM dup(<>)
SMAPIFormPropArray ENDS

.code
start proc
ret
start endp

end
Commandline: \masm32\bin\ml64 /c /Zp8 /Fo "NewWin32" tmp_file.asm

"Output":

Code: [Select]

MASM : fatal error A1016: Internal error

  Version 10.00.30319.01

  ExceptionCode            = C0000005
  ExceptionFlags           = 00000000
  ExceptionAddress         = 01332548 (01310000) "C:\masm32\bin\ml64.exe"
  NumberParameters         = 00000002
  ExceptionInformation[ 0] = 00000000
  ExceptionInformation[ 1] = 005F0053

CONTEXT:
  Eax    = 01358624  Esp    = 002EEFC8
  Ebx    = 002EF174  Ebp    = 002EF308
  Ecx    = 008A8313  Esi    = 005F0053
  Edx    = 00000001  Edi    = 002EEFE4
  Eip    = 01332548  EFlags = 00010206
  SegCs  = 00000023  SegDs  = 0000002B
  SegSs  = 0000002B  SegEs  = 0000002B
  SegFs  = 00000053  SegGs  = 0000002B
  Dr0    = 00000000  Dr3    = 00000000
  Dr1    = 00000000  Dr6    = 00000000
  Dr2    = 00000000  Dr7    = 00000000
Microsoft (R) Macro Assembler (x64) Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
Of course, it builds fine with JWasm, HJWasm and AsmC.

It also builds fine with ML64 if you don't use the -Zp8 switch, but that has other dire consequences :(

Another workaround: Comment out the nmidIdx MAPINAMEID <> line below the union u. Your code will not run with that structure, of course, but at least it will build with ML64 8)

[mineiro]

I think there's a bug on project misconception about ml64 and ml32. When they release "ends" they forgot that this means or a structure or a section ends. How can solve this ambiguous question?
If you write code with labels using latin names like "ção" ml64 report more errors than exist.
I'm still waiting for an assembler that shows exactly where error ocurred, not proximity.

[hutch--]

 

All you have told us so far is you don't understand how to write in ML64. ML64 came before the Watcom forks and the Watcom forks are not ML64 compatible so you can reasonably expect that your Watcom code will not work correctly in ML64.

It is a foolish assumption to think that I will fall into the loving arms of a pile of "Open Sauce" bludgers who won't get off their arse and actually do the work to support Branislav and John.

As far as me using ML64, I already have up and going,

console executables
UI executables
Dynamic link libraries
Dialog applications
Static libraries
Individual object modules
A reliable prologue/epilogue
over 100 macros
over 50 library modules

Fortunately ML64 is not crippled with lack of support in that Vasily's original work did most of the early heavy lifting and it has been the base for further extending support for ML64, it already has a reasonably reliable main include file and VERY reliable libraries and matching INC files. Should we hold our breath waiting for the bludgers to provide the same for the Watcom forks ?

[mabdelouahab]

Maybe it works like that, In the latter are the same, but it works

TmpStruct struct
    union u
        struct sl
          nmidIdx MAPINAMEID <>
          cfpevAvailable dd ?
          pfpevAvailable QWORD ?
        ends
     ends
TmpStruct ends

SMAPIFormProp STRUCT
    ulFlags dd ?
    nPropType dd ?
    nmid MAPINAMEID <>
    pszDisplayName QWORD ?
    nSpecialType dd ?
        TmpStruct <>
SMAPIFormProp ENDS

[jj2007]

All you have told us so far is you don't understand how to write in ML64.

The code that makes ML64 choke was written by Steve Hutchesson, see \Masm32\include\winextra.inc, line 4917.

[hutch--]

 

I wonder if you have forgotten that it was written for ML.EXE, not ML64.EXE. Neither ML.EXE nor the Watcom forks are ML64 compatible, why should your includes work when they are written for other incompatible assembler ? You may have some axe to grind about ML64 but it is distributed in its millions in VC and similar MS packages.

If I was interested in only the past, I would stick to MASM32 as it does what is needed but I am only interested in 64 bit in the future, long mode 64 bit with the linker option /LARGEADDRESSAWARE. Without this I would only write 32 bit code.

You are flogging a dead horse trying to convert me to the Watcom forks, you may have been committed to JWASM and the later forks but I have always written in MASM. I support Nidud, Branislav and John because they are hard workers and do good work but nobody leverages me to their view and I will never support "Open Sauce", they can get off their arse and do some work to provide the working support for the Watcom forks.

Everything has its advantage, with ML64, it came unconfigured so it meant you had to learn Win64 to get it going. As before,

console executables
UI executables
Dynamic link libraries
Dialog applications
Static libraries
Individual object modules
A reliable prologue/epilogue
over 100 macros
over 50 library modules

And growing by the day. 

[jj2007]

I wonder if you have forgotten that it was written for ML.EXE, not ML64.EXE. Neither ML.EXE nor the Watcom forks are ML64 compatible, why should your includes work when they are written for other incompatible assembler ?

That's right, code written for the Watcom forks will not be ML64 compatible (such code may contain strange things like invoke, .if eax>99, etc). However, in contrast to ML64, the Watcom forks are Masm32 compatible

[hutch--]

Yeah,

It really cripppling to have an "invoke" that has native text support built into it, a ".switch" system based off Greg Falen's original macro and Vasily's .IF notation and its all under user control.  :P

[jj2007]

an "invoke" that has native text support built into it

Wow, same as your old rv() macro :t Does it validate parameters, too, like the old ML 6.14 that ships with Masm32?

Btw Vasily's .IF notation seems to work only partially; when testing with your dialog example,

Code: [Select]

    .if eax
    nop
    .endif
works fine, but

Code: [Select]

    .if eax>ecx
    nop
    .endif
generates a weird error A2006:undefined symbol : eaxecx ::)

Do we all have to relearn MASM syntax to become "ML64-compatible"?

Last but not least:

It is a foolish assumption to think that I will fall into the loving arms of a pile of "Open Sauce" bludgers

Since you are the expert, can you explain, in a nutshell, what is the difference between using ML64 and the Watcom forks? I.e. when selling a project assembled with

Code: [Select]

a) ML64: Microsoft grants it for free and does not ask for any royalties
b) Mr Watcom (or Habran, Johnsa, Nidud, Japheth, ...) will charge you hefty fees ::)

[hutch--]

If you cannot read Vasily's instructions, perhaps you should take up a visual garbage generator.

     Operator      Meaning
 
     ==            Equal
     {}            Not equal
     }             Greater than
     }=            Greater than or equal to
     {             Less than
     {=            Less than or equal to
     &             Bit test (format: expression & bitnumber)
     ~             Logical NOT
     |            Bit test
     &&            Logical AND

     ||            Logical OR
 
     CARRY?        Carry bit set
     OVERFLOW?     Overflow bit set
     PARITY?       Parity bit set
     SIGN?         Sign bit set
     ZERO?         Zero bit set
     CARRY?|ZERO?   ìåíüíå èëè ðàâíî
     ~(CARRY?|ZERO?)   áîëüøå
     äëÿ ñðàâíåíèÿ ÷èñåë ñî çíàêîì
     ~ZERO?&(SIGN?==OVERFLOW?)   áîëüøå(greate than)
     SIGN?==OVERFLOW?      áîëüøå èëè ðàâíî(greate than or equal)
     SIGN?{}OVERFLOW?      ìåíüøå(less than)
     ZERO?|(SIGN?{}OVERFLOW?)      ìåíüøå èëè ðàâíî(less than or equal)

[jj2007]

Do we all have to relearn MASM syntax to become "ML64-compatible"?

Ouch, I was scared of your answer, and there it is :(

     }=            Greater than or equal to

.if eax>=ecx

.IF eax }= ecx

I hope it won't trigger reactions from the FASM & NASM communities 8)

[hutch--]

 

I am sure Microsoft sit up at night sobbing silently while wiping away the tear stains because of your dissatisfaction with ML64 when they should have anticipated back in 1990 when ML.EXE was released that it had become the new Bible for assembler language programmers. Now as you might expect, ML64 does not conform to the ALGOL specification of the 1970s either, was COBOL too radical ?

Having survived the shift from 16 bit DOS to 16 bit Windows, then to 32 bit Windows and more recently 64 bit Windows, each brave new world dumps you with a pile of crappy tools, lousy documentation and a lot of work if you are not willing to either stay with the old stuff OR get off your arse and do enough work to get the new stuff going. I have made my point long ago that "Open Sauce" is a nasty possessive licencing system that acts like a cancer on individual effort and where its adherents bludg anything they can steal and never give anything back except they PHUKING licence.

You may be saddled with an impossible task of trying to handle cross compatibility between different assemblers but it is a task of your own choosing, design a support system for the Watcom forks that actually works and see the bludgers white ant it because they were too PHUKING lazy to do it themselves. Some of the tools I am producing at the moment will be useful to folks who do get off their arse and develop a support system but there will be very few of them who bother, most want someone else to do it for them.

[jj2007]

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

No, the Redmond guys are rubbing their eyes in disbelief

They had taken the heroic decision to drop assembler as a tool for human coders, no invoke, no HLL, just plain mnemonics for some old-fashioned compilers who needed that as an input. And then comes that Australian Don Quichote who wants to convince the rest of the programming community that if arg1 }= arg2 looks better than if arg1 >= arg2 ...

Redmond lurkers, c'mon, one of you should register and give us feedback on how the situation is right now in the Crisis Room :icon14:

[rrr314159]

It's no big deal to learn that new syntax. The problem is re-using old code. Converting 32 bit code - either ML, JWasm, or asmc - to 64 is not bad with HJWasm or asmc. But it's much harder to go to ML64. Sure, you "just" change ">" to "}" - although you can't do a global change, must consider each one individually. No big deal. But how many such are there? The worst part is stripping out perfectly good code, for no good reason. My favorite example is "ASSUME". You can't merely change those specific statements, but must make a lot of little associated changes. If there were a good reason for it, you were buying some new capability this way, it would be Ok. But the opposite is true.

Similar problem arises for those of us who continue to use both 32 and 64. With HJWasm, or asmc, it's very easy once you get used to it. Most of my code works with either 32 or 64, leveraging a few obvious "IF" statements. Sometimes code makes sense only for 64, as when making extensive use of the extra registers, but that's rare. And of course you use the same assembler for both. With ML you need both old 32-bit assembler and new ML64, plus the right auxiliary files; and the syntax is quite different. Forget about "one-size-fits-all". And, BTW, every time you upgrade to the latest ML64, you're going to need a new set of auxiliary files.

If there were no alternative to ML, it would be annoying but one would take it in stride. But (I can tell you this from experience) the worst part of using ML64 is that half your time is spent asking yourself: "Why don't I just use HJWasm (or asmc)? Why am I wasting my time with this? I hate Bill Gates ..." and similar unproductive thoughts.

Oh well, hutch, I hope it works out well for you and other ML64 enthusiasts. If you can avoid the above-mentioned unproductive thoughts, because you feel there's a good reason for using it, it shouldn't be too bad. Maybe time will prove you right. Maybe Bill will create an effective anti-HJWasm-and-asmc virus.

BTW the worst part of HJWasm and asmc is having to write out "HJWasm and asmc" instead of simply "ML64".

[TWell]

As some programmers can choose tools they use, bare C compiler is handy as 'universal assembler'.
It can be used without crt etc...
It can do code optimization too.
Even MS developed it in it's last version (2015).