habran on other assemblers.

[habran]

jj2007,
HJWasm is smart and you don't need to use OPTION PROLOGUE, OPTION EPILOGUE, it will decide if it is necessary or not to write it, however, you can use it if you insist.
So, if you have locals or/and push registers, it will create PROLOGUE and EPILOGUE, otherwise it will just skip it.
You just need to write Someproc PROC FRAME 

HJWasm does so much, much, much more than any other assembler, especially ML64 (it still wears diapers, long time not changed) :P 

[hutch--]

There are 2 issues at play here, ML64 is a crude pig but it has this advantage, by the time you get to fly it, you will understand why it is like that and that is more use to you that having it spoon fed to you while covering up the underlying yukkies. It is also "blessed" with appallingly bad documentation and lack of viable examples that mean you must learn it by test piece but it depends what you want, the "Visual Basic" approach of catering for idiots or the low level approach to know why something works.

Long ago when Iczelion and I were working on the early forms of MASM32 it was even worse, the documentation was garbage, Microsoft were telling everyone that you never need assembler any longer and every idiot and their dog though they could tell you something with the C compilers. We changed all of that reasonably quickly and they shut their mouths.

I think you are doing well with your re-write of JWASM and it is looking like a good tool but it will not teach you the yukkies underlying win64, that you have to do the hard way.

ML64 was basically designed to write procedures for VC and its OK in that area, expanding it to a general purpose assembler for making EXE and DLL files is another matter. Its never going to be fun but you will learn much on the way.

[habran]

With other words more is less and good is actually bad
Reminds me on my school time when I was told: you can't get an A, your knowledge is to wide :lol:

[hutch--]

Microsoft probably see it differently, it already does the job they need it for, essentially procedures for 64 bit C compilers that don't have an inline assembler. There are two classes of people in terms of learning Win64, those who want to know how it works and those who prefer to try and keep it a secret, I opt for the former. I have yet to see what your contribution is to ML64, I am more or less immune to other people's opinions when they don't contribute to what is being done. I hope you finish the development of HJWASM but it has little to do with what I am doing with ML64.

[rrr314159]

BTW you can use H/JWasm in "low-level" mode also, if you don't want the automatic stack frame features. Previously, just don't set the advanced options; maybe now you have to tell it option:0 or something. And of course you can override the 'invoke" keyword if you want to roll your own. That way it's exactly compatible with ML64, concerning those features. There are more little differences, like ML doesn't do "assume" command. Again, just don't use those commands / abilities. In this way ML code more or less always works in H/JWasm ... except for a couple very minor things I don't remember exactly, like maybe macro nesting levels and line continuations. Going the other way, of course, is no good. If you use H/JWasm features freely, many don't work in ML64, and it will take a lot of work to convert. And, of course, you need two assemblers with ML, one for 32 and one for 64. I think it's still true that's not the case with H/JWasm, all versions (?) do both 32 and 64.

None of my posted code used the stack frame features, and I usually use my own invoke macros, but even so there are many convenient things like "assume" in it which makes it hard converting to ML64. Basically the code needs to be "crippled" in a dozen little ways. That's why I just can't get interested in converting it all to work with ML. Also why I took months wondering whether to use those H/JWasm features, I knew I was cutting myself off from easy ML64 compatibility. Decided I couldn't stand to deliberately use such an inferior program. Like shooting yourself in the foot just to make life more challenging.

[habran]

Like shooting yourself in the foot just to make life more challenging.

Nice comparison, I totally agree with you. :t
There is one more thing: Potentially write something for commercial use, can we do that with ML.exe or ML64.exe?

[jj2007]

I knew I was cutting myself off from easy ML64 compatibility. Decided I couldn't stand to deliberately use such an inferior program. Like shooting yourself in the foot just to make life more challenging.

It is not an easy decision. My macros work with ml, (h)jwasm and asmc, and it was hard to achieve that, a bit masochistic indeed. But it was worth the effort because a) everybody uses ML and b) many use JWxxx and AsmC because they are better.

The situation with ML64 is different: Microsoft has decided to cripple this software, so that it's only useful for compilers. So be it :t

When I saw OPTION DOTNAME in Vasily's files, I knew awkward things were ahead, but really, .if MACRO ::) ::) ::)

Hutch, I know this hurts your feelings, but ML64 is not a serious option. Let's get over it, and concentrate on a good set of includes and macros that work with HJWasm and Nidud's AsmC, without having to set a bunch of idiosyncratic options that require a user's manual.

[habran]

Halle*ucke*lujah jj2007  :t

[LiaoMi]

Hallo,

healthy competition is very good, I love the assembly language, so I try to write in this language, but if the task becomes easier, then I find it easier to program in assembler. It is worth remembering that changes in macro assembler, have been made due to the change of the structure of the C compiler. And as we develop programming in assembly language, then HJwasm decision is the logical continuation of the disconnect assembly from the C language.

Regards

[habran]

Very logical conclusion 8)

[hutch--]

JJ,

Hutch, I know this hurts your feelings, but ML64 is not a serious option. Let's get over it, and concentrate on a good set of includes and macros that work with HJWasm and Nidud's AsmC, without having to set a bunch of idiosyncratic options that require a user's manual.

Not at all, I pursue what I am doing for good reasons and while no-one seems to have a clue as to what needs to be done with ML64 so I will just continue to work on it as I slowly quantify bit by bit.

[rrr314159]

Everybody has a clue what needs to be done with ML64 - same thing MS decided to do with it - trash it ;)

I don't care for .if macro either. Instead of that I would just stop using .if (etc) entirely.

It's important to note that it would be a very different situation if ML64 retained the ML 32-bit capabilities (like invoke and assume, etc); and HJwasm had new better features. Then it would be similar to GoAsm, Sol assembler, MasmBasic, and other systems that their users love. One could still say you're "shooting yourself in the foot" by not using (for instance) RadAsm, ObjAsm, or EasyCode, but these involve new features one has to learn, and figure out the quirks. I don't blame anyone for sticking with what they're used to and not bothering with these types of systems, even though they may be more powerful.

But in this situation, HJwasm is the "good old" assembler. ML64 is deliberately crippled. So not only you have to learn new ways of doing things, it's a big step back. HJwasm does have some new stuff, but even the stack frame option is an attempt to make it as similar to masm32 as possible. You can really tell the difference when you convert old 32-bit code. With ML64 it often requires major surgery, whereas with HJwasm it's as smooth a transition as possible.

Note, I'm not considering logistical meta-issues like licensing, support in the future, Open Source code, and so forth, because I know next to nothing about them. I'm only talking about the programming tool. If such issues force someone to use ML64, so be it; I'm glad they don't affect me.

[hutch--]

 

I take the comment about trashing ML64 as a verification of not having a clue about how to use it. Its a little before your time here but in about 2006 we had a member from the Microsoft development team, Kang Su Gatlin who asked questions about what form a 64 bit version should take and the advice he was given was to leave ML alone and produce a stand alone 64 bit version. At that time M$ had been using NASM and YASM for writing small bits of 64 bit assembler and when they produced their own, ML64, it was about as bare bones as the former because it only needed to be able to do what they needed. Fortunately it retained the old MASM macro system which was familiar to a wide range of people.

Comments like "ML64 is deliberately crippled" are simply nonsense, Microsoft do not spend development money were they don't need to so it has never been developed as a consumer friendly easy to use toy. Its main curse is almost non existent documentation and the little they keep on MSDN would have to be described as obscure at best. Now the interesting part is that nobody has been willing to get off their arse and produce a viable set of include files, libraries and examples for most of what has been peddled as 64 bit assemblers, POASM is under documented, ML64 is little better, JWASM was a flop that was abandoned by its author with little useful support and even HJWASM has little support.

Contrast this with the work that Vasily has done and the range of examples done by Mikl__ and while my Russian is not up to scratch, at least the work has been done. Its worth noting that there are other 64 bit assemblers available, FASM has been up and going for years and Bogdan has produced his own assembler as well and of course if you like bare bones assemblers, the GNU "as" assembler (GAS) separates the men from the boys.  :P

[jj2007]

Comments like "ML64 is deliberately crippled" are simply nonsense

My take on this was a nuance softer:

Microsoft has decided to cripple this software, so that it's only useful for compilers. So be it :t

When I saw OPTION DOTNAME in Vasily's files, ...

One can argue about "deliberately", but crippled it is. If Habran and Nidud can produce an assembler that knows about .if and .endif, how much time and money would it have taken for that team of software heros in Redmond???

I fear that you might succeed: To my great surprise, the 30-year-old OPTION DOTNAME did so far not break my MasmBasic sources. But it's disgusting to be forced to accept a .if macro just because M$ thinks that assembly programmers should go to hell. Besides, we have two members, Habran and Nidud, who have control over the source of powerful 64-bit assemblers - why that desperate attempt to be friends with Micros**t? Do I have to remind you about slickhuh.asm, Hutch?

[hutch--]

 

Problem is you are not preaching to the converted, there are plenty of assemblers out there and I am not particularly committed to any of them in 64 bit.

> Besides, we have two members, Habran and Nidud, who have control over the source of powerful 64-bit assemblers

And Japheth before them. I archived his last work for any who wanted it.

RE: SlickHuh, look at POASM1k, there is a difference between bad code and low level. All assembler used to look like that once.  :P

My real beef in 64 bit Windows is with Microsoft with very poor specs of the low level aspects of calling API code.