mov hInstance, rv(GetModuleHandle, NULL)

[kromag]

I have been trying to locate this method|function by tracing it down, to no avail.

Could someone please tell me where the definition for rv(...) is?

It looks like this in a test_app I created using ProStart:

mov hInstance,   rv(GetModuleHandle, NULL)
---
W.J.L III

[MichaelW]

It's in \masm32\macros\macros.asm.

[kromag]

Thank you!

[donkey]

macros - bah humbug :)

That's one of the reasons I avoid macros, they can make code difficult to understand if you don't know the macro definition or can't find it in the spaghetti of includes. Better to write clear easy to read code...

invoke GetModuleHandle, NULL
mov hInstance, eax

[kromag]

yeah I would prefer it like that or at least change the 'rv' to something
else more readable.

[AMIB]

It's readable and short  :wink
rv : Return Value

[Mark Jones]

It is readible and short, however it also introduces an extra level of ambiguity and complexity to the debugging process. Since RV is a macro, a line like this may fail assembling for many more additional reasons.

I think it is safe to say that there is a fine line between the "purists" here who do not believe in macros and want to have intricate control over every byte of their code, and everyone else.

[jdoe]

I think it is safe to say that there is a fine line between the "purists" here who do not believe in macros and want to have intricate control over every byte of their code, and everyone else.

And I'm on the good side of that "fine line".    :bdg

[jj2007]

The worst scenario is macros combined with conditional assembly, as shown below :bg

Code Select Expand

include \masm32\include\masm32rt.inc

.code
start: invoke GetTickCount
masochist = 0
if masochist
.data
rvstring db 20 dup (0)
align 4
.code
invoke dwtoa, eax, ADDR rvstring
invoke StdOut, ADDR rvstring
.data
ms db " milliseconds", 13, 10, 0
.code
invoke StdOut, ADDR ms
call ret_key
invoke ExitProcess, NULL
else
print str$(eax), " milliseconds", 13, 10
getkey
exit
endif
end start

[donkey]

I think it is safe to say that there is a fine line between the "purists" here who do not believe in macros and want to have intricate control over every byte of their code, and everyone else.

Its not that I don't believe in macros, their existence is undeniable, however I think that in most cases they simply obfuscate code and do nothing to help learn assembly language. I have seen snippets with only 1 or 2 actual assembly mnemonics in them, at some point you are no longer coding an assembly language program, you are coding in a macro command language that for some reason you call assembly. I do use macros in every program, actually 3 - invoke, RET and CoInvoke, the latter is the only one not incorporated in GoAsm and obviously used only for COM calls. 90% of my example code can be built using a generic Windows equate file and GoTools (GoAsm,GoLink and GoRC), no macro definitions are needed so assembly errors are easily tracked down using the error messages generated by GoAsm. I will grant that many of the addressing and string macros used in MASM32 are already available in GoAsm (inline strings, unicode etc...) but macros like switch/case are little more than an attempt to write C with MOV.

[Mark Jones]

I agree with everything except for switch/case. In GoASM in particular, windprocs can be rather bulky to code with individual instructions, and while actual instructions may make it arguably more like "assembler-like", the added length and complexity make the code harder (and longer) to follow. Same with .if/.while etc. That and GoASM uses a proprietary jump-label syntax, which may produce superior results, however is aready unlike traditional assembler (JMP >>, .WMCOMMAND, JMP <DOLOOP etc.) In the case of MASM32, it is nice to have the option  to use some limited higher-level constructs. (I tried to build a switch/case macro for GoASM but was unable due to its limited macro implementation -- which isn't a bad thing, just a difference.) Still, options are nice. And optional. Generally I do not use USTR$, UHEX$, or any macros like that anyways, so it's not a big deal. I make do with bulky WndProcs in GoASM because GoASM is otherwise an awesome assembler and has many benefits and features not present in other assemblers. Switch/case/if/while could be useful sometimes, but it is all personal preference anyways.

Jeremy had polled the userbase about adding these before and the topic was voted down probably 10:1 against... so apparently longer WndProcs are the norrm. :toothy

[donkey]

Actually Mark, I think the switch/case is a bit much but given the complexity of my current project (ODBC, custom controls, option rich) I would like to see an equivalent to the .IF/.THEN/.ELSE of MASM.

[MichaelW]

I think the best syntax to use depends on the focus of the code. Many of the questions here are about API programming and have little or nothing to do with the language used, so in these cases using the simplest syntax possible makes sense. Using the simplest syntax possible also makes sense for rapid prototyping. I don't know how others do this, but when I am coding for some unfamiliar API I frequently have to experiment before I can code something that actually works, and this sometimes involves a more or less total change in direction.

[Rockoon]

Using the simplest syntax possible also makes sense for rapid prototyping.

Thats what HLL's are for :)

IMHO:

A macro in an include file should not generate more than 1 instruction, and it should always be obvious which instruction that is.
A macro in an include file can generate any amount of data in the data segment, but that data should not have more than 1 label, and it should always be obvious what label that is.

This rules out things like the high level invoke for me. I do not use that, and I also do not use the high level proc methodology (I'll set up my own stack frame if I want one, which I don't)

As restrictive as this seems, it really isn't.

..and those that are learning asm are harmed when they leverage all of these mega-macros include files, learning the features of that include file instead of the language.

[Vortex]

Using macros or not is a matter of personal choice. I am happy with macros. When there is a problem, I use the echo statement to find the bugs in macros.