64 bit macro glossary

[markallyn]

Hello everyone,

In its 32-bit incarnation MASM32 qeditor had a very helpful guide to built-in macros located in the HELP tab.  As far as I can tell, the 64-bit qeditor hasn't got the equivalent functionality.  Has anyone compiled a similar "macro guide" for 64 bits.  I know one can examine the MACROS64/macros64.inc file but this contains no descriptive material or examples. 

Thank you.
Mark Allyn

[jj2007]

What about these?
\Masm32\help64\masm64.chm
\Masm32\help64\loopcode.htm
\Masm32\help64\calling.htm
\Masm32\help64\Invoke.htm
\Masm32\help64\prologue.htm

[markallyn]

JJ-

Thanks.  Hadn't thought to look there!  I was concentrating on QEDITOR 64 bit.

Regards,
Mark

[markallyn]

JJ-

In my help64 file I find  the masm64 .chm file.  There is also a qeditor help file.  However, the remaining items on your list are not present.  I hunted around on my hard drive but couldn't find them anywhere.

Regards,
Mark

[jj2007]

No idea where I got them. Attached is also ms_ABI.asc - open in RichMasm or Wordpad.

[markallyn]

 Thanks, JJ.  I'll look at  the zip file.

Mark

[hutch--]

 

Mark,

Its the expectation that does not fit the situation, I am one person, the pay is lousy ($0.00), the hours are endless and there is no end on the horizon. I produce what I can within the time limits I have and that involves the base architecture that is very reliable, over 100 library modules, a working set of pre-processor macros and a part finished help file. QE does the job, it has template generators to make starter code for projects, a number of tools from the 32 bit version and some more that were tweaked to work with 64 bit code.

I am happy enough to share the stuff I write with our members as I have a use for 64 bit code myself but if you want to do things differently you need to enter the world that I did a bit over a year ago, absolute CHYTE documentation, much of which is wrong, no useful help files whatsoever, no viable example code and a mountain of half baked bullsh*t from an array of illiterates who don't produce viable working code.

What you are stuck with is the need for a disassembler, debugger if you can be bothered and a mountain of test pieces to ensure that anything you get up and running fully complies with the Microsoft ABI and can manage properly aligned data for the > 64 bit data types. Once you have it all up and running you then produce the libraries that you need, all of the pre-processor macros that you want to support and the help files to document all of these things.

[aw27]

What you are stuck with is the need for a disassembler, debugger

One day they will figure that out by themselves.  :t

[jj2007]

Search for arkdasm x64dbg and you are fine.

[markallyn]

Good afternoon / evening, Hutch,

I do hope you don't interpret my post as critical of the work you have done and are doing.  It was certainly not intended to be negative, merely curious.   I for one have been astounded at the extent of your achievement.  I became aware over a period of a year or so that you were the person behind the magic and that this whole effort was a labor of love.  I have been lucky indeed to be able to use what you have produced and I can only imagine I speak for many others.  I wish only that I could point to an achievement of my own that is equally significant.

There is something else I'd like to say and it goes beyond your technical accomplishment.  You  have managed to create and inspire what is, in my experience, the most cordial, respectful, and generous forum I've ever participated in .  The level of sharing and bonhomie is remarkable and I believe it is because of your care and example.

Very best regards from snowy, cold south eastern pennsylvania, USA.

Mark

[markallyn]

JJ-

I found a couple of 64 bit debuggers, one of which I've been using a lot.  X64dbg is what I've been using.  I've also played with Windbg but I don't care for the gui.  Plus it is pretty much character oriented and comes with a raft of fairly non-intuitive commands.  Somewhere on the forum I believe I read that x64dbg was somehow a "knockoff" of someone else's work, but I don't know any details or if it's even true at all.

I also got a copy of arkdasm and worked a bit with it, but slowly adopted x64dbg as kind of my unofficial "go-to" program.

Mark

[ragdog]

x64dbg is bloated and has to many senseless function ::)

[jj2007]

x64dbg was somehow a "knockoff" of someone else's work

Somebody else is Oleh Yuschuk, and his baby is called OllyDbg.
Both Olly and X64Dbg can be set as just-in-time debuggers, meaning that when a program crashes, Olly (32-bit) or X64Dbg (64-bit) jump in and point you straight at the problem. Extremely handy in case of unknown problems (and yes, X64 is bloated, but it works).

In case of known problems, Integrated debugging is better.

I believe it is because of your care and example

Yes, Hutch has become old and wise. Nowadays it's almost incorrect to call him a grumpy old bastard ;)

[markallyn]

JJ-

Thanks for the info.  I guess that explains why the two have a similar look and feel.  I liked OLLY a lot and was disappointed to discover that Oleh Yuschuk had not made it 64 bits. 
x64dbg is definitely bloated but it is quite usable.  I settled in on a few of its many "bloats" and ignore the rest.  As you say, it works.

Mark

[aw27]

I've also played with Windbg but I don't care for the gui.

This is back-fence talk, the gui is fully configurable  (I have not said easily  ).



The other debuggers simply hook on the Windbg engine, they don't bring anything new except cosmetics. They lag behind or don't support lots of features. If you don't know which features then you will be all right with them.