Re: Tools in the latest build environment.

[jj2007]

And that builds with your version of ML?  ::)

In case somebody is interested, attached a tiny source including the converted MIXERCONTROLA, for testing multiple assemblers with RichMasm; just change one character in the source as follows, and hit F6 to build the "project":

OPT_64             1            ; put 0 for 32 bit, 1 for 64 bit assembly
; activate an option by eliminating the x - the last active one counts
OxPT_DebPath64     \Masm64\arkdasm\arkDasm.exe      ; default is \Masm32\x64Dbg\release\x64\x64dbg.exe
OPT_Assembler      ML            ; choose your assembler; if it's ML, make sure you got the right versions
OxPT_Assembler     AsmC          ; Nidud
OxPT_Assembler     HJWasm64      ; Habran

Note the debugger will start automatically if RichMasm discovers an int 3 that is not commented out with ";". Which means that

Code: [Select]

int 3launches the debugger

Code: [Select]

; int 3starts a normal build while

Code: [Select]

if 0
  int 3
endifcheats Richmasm to launch the debugger but no int 3 will be generated.

With OPT_64 0 (i.e. 32-bit build), \Masm32\OllyDbg\ollydbg.exe will be used; this is hard-coded, sorry

Since Microsoft has two different assemblers for 32-/64-bit code, RichMasm will use
\Masm32\bin\ml64.exe  with OPT_64 1
\Masm32\bin\ml.exe    with OPT_64 0

So if your copy of ML64 sits elsewhere, just copy it as \Masm32\bin\ml64.exe

[hutch--]

I have moved this post as the  multiple environments are not compatible with the subforum that deals specifically with ML64 development.

[jj2007]

Right :t

The test above builds identically with all assemblers (and 32-bit), but there is still a tiny glitch in your structure conversion routine. My own has similar problems with these difficult structures, I hope to get it going soon.

[hutch--]

It would only be a matter of good luck that it worked on a 32 bit assembler as it has no QWORD sized members. The tool is designed for ML64 and anything else that can use the format, most of its conversions will not work in 32 bit as many structures contain QWORD members.

[jj2007]

Of course, yours is not designed for 32-bit code. My own include files serve both platforms, therefore QWORD pointers are replaced by SIZE_P:

Code: [Select]

if @64
  SIZE_P equ <QWORD> ; int and long are 32-bit, pointer is 64-bit
else
  SIZE_P equ <DWORD> ; int, long, and pointer are 32-bit

[nidud]

deleted

[jj2007]

Of course, yours is not designed for 32-bit code. My own include files serve both platforms, therefore QWORD pointers are replaced by SIZE_P:

Code: [Select]

if @64
  SIZE_P equ <QWORD> ; int and long are 32-bit, pointer is 64-bit
else
  SIZE_P equ <DWORD> ; int, long, and pointer are 32-bit

Why not just use PTR?

Reserved word?

[nidud]

deleted

[jj2007]

I am sure your version works, too. But PVOID is C-speak for me, and a pointer to a void doesn't ring a bell with me:

Code: [Select]

adjective
not valid or legally binding
completely empty

noun
a completely empty space.
(in bridge and whist) a suit in which a player is dealt no cards.

verb
declare that (something) is not valid or legally binding.
discharge or drain away (water, gases, etc.).
Besides, using this term risks to get namespace conflicts, while hardly anybody will decide to use SIZE_P, so it remains a pretty "private" keyword 8)

[nidud]

deleted