3 x 64

[jj2007]

Currently, we have three lines of development for 64-bit code:

- Hutch favours ML64, and is writing macros, include files and libraries for this assembler.
  main advantage: his experience with Masm32 will lead to a highly usable codebase
  main disadvantages: the code will not be usable with HJWasm and AsmC; license issues

- Habran, Johnsa and Nidud work on a Masm-compatible assembler
  main advantage: not crippled like ML64; invoke, .if ... .else ... .endif and other HLL constructs work as in Masm32
  main disadvantage: they won't have the time and experience to build a complete package

- jj has incorporated dual 64-/32-bit templates into the MasmBasic/RichMasm package
  main advantage: no extra libraries required; jinvoke allows parameter check, even with ML64
  main disadvantage: no time and not enough experience to build a complete package

This is, in a nutshell, the setup.
I don't like the situation, it smells of disaster, and would like to hear the ideas of Hutch, Habran, Johnsa and Nidud on how to avoid it...

Personally, I will either
- continue my "no libraries" approach with AsmC and HJWasm, using their HLL features
- or concentrate on 32-bit MasmBasic.

[rrr314159]

can you explain about the "license issues"? Probably there's some way around it

[hutch--]

Its not a big deal, you can share import libraries, individually written library modules are linkable across all of them and much of the actual source code is cross compatible.
The notion of "MASM" compatible means in effect ML.EXE 32 bit compatible, ML64.EXE fails this criterion as it is NOT MASM compatible in the previously understood sense. Now with ML64, its ancient macro engine appears to be much the same as any of the earlier versions from ML 6.00 onwards, bugs and all so if the Watcom forks are MASM compatible, the macros should be usable across the assemblers as well.

I have no problems with diversity, each tool should have its particular advantages depending on the features the author has written into it.
The advantages of ML64 are its crudity, having worked on it for a few months, the lack of clutter by not having to deal with prototypes has made it a lot faster to develop with.

As far as licence issues, I learnt the hard way that any dealings with "open source" is a one way transaction, they will suck the life out of you for anything they can get but all you ever get back is their PHUKING licence.
This is why I stick to the MASM32 licence to ensure anything attached to the project remains true freeware that is not beholding to some overriding control.

Now regarding MASM compatible code, apart from the main control directives specific to each assembler, the code should be cross usable.
Here is a WndProc that IS MASM compatible in the Win32 code format sense done in ML64.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

WndProc proc hWin:QWORD,uMsg:QWORD,wParam:QWORD,lParam:QWORD

    LOCAL dfbuff[260]:BYTE

    .switch uMsg
      .case WM_COMMAND
        .switch wParam
          .case 200
            invoke SendMessage,hWin,WM_SYSCOMMAND,SC_CLOSE,NULL
          .case 300
            invoke MsgboxI,hWin, \
                  "Generic 64 bit Template written with ML64.EXE", \
                  "About Generic Template",MB_OK,10
        .endsw

      .case WM_CREATE
        invoke LoadMenu,hInstance,100
        invoke SetMenu,hWin,rax
        .return 0

      .case WM_DROPFILES
        invoke DragQueryFile,wParam,0,ADDR dfbuff,260
        invoke MsgboxI,hWin,ADDR dfbuff,"Drop File Name",MB_OK,10

      .case WM_CLOSE
        invoke SendMessage,hWin,WM_DESTROY,0,0

      .case WM_DESTROY
        invoke PostQuitMessage,NULL

    .endsw

    invoke DefWindowProc,hWin,uMsg,wParam,lParam

    ret

WndProc endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

If other assemblers cannot use this code in this format, then they are not MASM compatible in the ML 32 bit sense.

[rrr314159]

Making ML64 code work with HJWasm involves almost no changes at all. Since johnsa says next version will take care of the little problem related to YMMWORD PTR, it should be even easier now. I agree that the PROTO checking can be a pain, so I rarely use it. Turn off "invoke" keyword and use an invoke macro, just as though it were ML64.

To me there's not much difference. HJWasm has little conveniences (like ASSUME), it's faster, and it doesn't have those annoying bugs, so I prefer it. However if you use HJWasm features like invoke, and habran's new stuff, it becomes a lot less compatible with ML64.

I'm lucky you guys didn't get involved with 64-bit until now, so I never knew it was difficult! A couple of years ago, I just went ahead and happily coded 64-bit with both ML64 and (H) JWasm. Used whatever libs and includes were available. Never noticed any great problems, just a few little incompatibilities to work around now and then. Ignorance is bliss.

[jj2007]

The advantages of ML64 are its crudity, having worked on it for a few months, the lack of clutter by not having to deal with prototypes has made it a lot faster to develop with.

I agree that the PROTO checking can be a pain, so I rarely use it.

It's nice to see that the two of you can agree on something, but I disagree! What we are doing is supposed to open the world of 64-bit assembly to people who are used to languages that do hold their hot little hands. Trashing the stack by forgetting one of the twelve CreateWindowEx args, or adding a NULL too much, that is the kind of situations which will drive the n00b mad and let him return to BASIC. This is why that was one of the first things I solved when writing the jinvoke macro, for ML64 but also for the others.

[rrr314159]

What we are doing is supposed to open the world of 64-bit assembly to people who are used to languages that do hold their hot little hands. Trashing the stack by forgetting one of the twelve CreateWindowEx args, or adding a NULL too much, that is the kind of situations which will drive the n00b mad and let him return to BASIC. This is why that was one of the first things I solved when writing the jinvoke macro, for ML64 but also for the others.

I just asked you, on another thread, why PROTO is so important; I guess this is your answer. Of course, I'm thinking only of my own needs, not noobs'; don't know if that's also hutch's attitude.

To make assembler attractive for the masses is a noble goal ... not sure it's realistic. But, go for it, hope you succeed. MasmBasic might do it, if anything will.
If you're really serious about that goal, you should consider releasing the source. The masses aren't going to sign up to something which is guaranteed, by immutable laws of biology, to disappear in a couple decades.

[hutch--]

Its a bit to do with the target difference, from the beginning of the MASM32 project the target was experienced programmers who already knew how to write 32 bit software in C and similar compilers. Understanding addressing and a knowledge of how to use the Windows API is the bare minimum to start on 32 bit assembler. Over years I have seen that this is correct in that inexperienced programmers almost exclusively fail to grasp the complexities of this type of development tool and often end up wasting members time asking for support and assistance on things that they should already know.

After being very tired of waiting for anyone to produce a viable tool for creating 64 bit code, I used Vasily's very good work as the basis to start working in ML64 because at its most basic, I need a reliable tool to produce 64 bit software with and while ML64 is a cranky old pig, it is what an assembler should be, a tool to screw mnemonics together into object modules. Professional tools are not "hot little hand holders" and often do not provide the "idiot proofing" necessary for consumer level software. Effectively its a case of use it the wrong way and it explodes in your face.

Someone somewhere will cater for the great unwashed wanting to try and make things that are beyond their experience range and of course it has already been done many times with visual garbage generators, the easy greasy sleazy road to bloated rubbish but for programmers with enough experience, using the real McCoy[tm] without amateur mistakes means producing high quality, high performance results in a reasonable timeframe.

[jj2007]

The old brigade with crude mnemonic crunching as some notion of purity left assembler in a shambles, near abandoned and ridiculed in the programming community. The pseudo high level stuff in MASM resurrected it from the dead and made it a living language again. Most would not write C like they did in the middle 80s yet they expect you to write assembler in the way that people cobbled together a few DOS interrupts 25 years ago.

A macro assembler is in fact a very smart tool, it allows the assembler programmer the capacity to design and build their own language while losing nothjing to fast low level code. The other factor is modern assembler programming must use operating system functions to access memory, hardware and so on so these clapped out notions of purity cannot in fact be put in place.

So, thanks to Microsoft's decision to strip ML64 from all that useless 'high level' crap, the old push push call brigade will provide us with beautiful big x64 projects, with no typos and always the right number of arguments on the stack?

[hutch--]

Nah, you don't get the Microsoft philosophy on boiler room development tools, take RC for example, make an error and it crashes and dumps a dead temp file in the current directory. It is only designed to be used the right way the first time.

Where ML.EXE was part of a consumer package (I keep the box, disks and manuals as nostalgia), ML64.EXE is true boiler room software, a bad mannered, buggy terse pig that only works well if you get it dead right the first time. It bites the hand that feeds it and spews screens of garbage for the slightest error.
It's pre-processor engine is an antique written back in about 1990 for ML.EXE version 6.00 and it retains all of the quirks and bugs that it always had.

For the dedicated and patient it has its advantages mainly through its crudity, free of pissing around with prototypes, you can move code around, rename it and use a whole host of dirty politically incorrect trickery because it is an ASSEMBLER, not a COMPILER.

Also is piggish bad manners are character building, get it right the first time or waste your time trying to find out why it went BANG !  :P

[jj2007]

Hmmm... what you write seems the ideal recipe to (quoting a famous assembler programmer) leave "assembler in a shambles, near abandoned and ridiculed in the programming community" :P

[hutch--]

The alternative with hand holding assumptions is visual garbage generators, bloated balloons and toothless terrors that don't let you make mistakes by not letting you do anything dangerous. Any brave new world is a dangerous place, x64 is no different to the changes from 16 bit DOS to 16 bit Windows to 32 bit Windows. The tools are chye, the documentation is appalling and often wrong and to change it you live dangerously. What's new ?

[jj2007]

What's new ?

What's new is that we have two compatible assemblers, AsmC and HJWasm. "Compatible" in the sense that you can use the same syntax that you and us have used for over a decade with Masm32 (note: Masm32, not MASM). For example,

Code Select Expand

.Repeat
    inc ecx
.Until ecx>=100

Looks so simple and familiar, right?

[hutch--]

A competition between the past and the future, much of MASM32 was designed in 1997 and I have been saddled with much of it since then.
The sense of MASM compatible is 32 bit ML compatibility yet it was designed in 1990.
I am pleased to see both John and Habran as well as Nidud producing working tools but since Japheth started on JWASM and made it 64 bit capable, I have yet to see a complete properly supported system, JWASM has been abandoned, HJWASM is endlessly under development and to be fair, I am not up to date on Nidud's fork.

ML64 already exists, it is updated regularly (I am using a Win 10 2015 version) and with a little effort it has a complete set of libraries, include files and an extensive set of pre-processor macros thanks to Vasily which I have added to over the last few months. As it seems that no-one in the Open Sauce area has been willing to get off their arse are produce the includes, libraries and macros and I am certainly not going to do it for a pile of open source bludgers.

With Vasily's macros and mine so far we have,
1. invoke call automation.
2. A reliable working prologue/epilogue.
3. Vasily's emulated MASM loop code.
4. A library of over 40 modules so far.
5. A complete set of import libraries.
6. A complete set of matching include files.

And much more to come as I need the capacity myself to produce 64 bit executable and DLL files.

I am under no moral imperative to use any particular tool, POASM is also a good tool and if I had the life and time I would like to have a good look at Bogdan's assembler but I only have one life so its not going to happen any time soon. I will keep using ML64 as it is Microsoft and well known with the C/C++ brigade, the reason why it still exists is simply because Microsoft need their own assembler. I will never be beholding to an open source licence and I will never need to be.

.Repeat
    inc ecx
.Until ecx>=100

Funny enough I have almost never used this type of code, I generally write my own loop code.

    mov r15, 100
    neg r15
  @@:
    conout str$(r15),lf
    add r15, 1
    jnz @B

[tolmann]

It could be argued that a "newbie" to 64 bit asembler should not use macros. If you do not fully understand 64 bit calling conventions and stack alignment, then you should not hide behind invokes, etc until you fully understand what they are doing.
In which case, verbosely writing system calls directly filling up the stack prior to the call, actually means there is little difference between ML64, JWasm and HJWasm. They are not so different.
I have written 3 commercial Windows programs using 64 bit assembly without using macros at all. They are being used by 2 leading Semiconductor manufacturers, no complaints so far ..... Working on a 4th. None use macros. (Of course the customer does not care in what language the application was written).

The one thing I would have liked, at the time, would have been the source to a complete set of 64 bit functions (like atof, dw2a, etc). These could be compatible across all assemblers. Unfortunately, like rrr314159 I was probably dabling in 64 bit a wee bit too early.

[Vortex]

The one thing I would have liked, at the time, would have been the source to a complete set of 64 bit functions (like atof, dw2a, etc). These could be compatible across all assemblers.

Hutch already started to work on a library. Maybe, you could contribute his work by sending your code to the forum :

http://masm32.com/board/index.php?topic=5631.0

Another solution is to use the functions exported by msvcrt.dll \ crtdll.dll