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
It's in \masm32\macros\macros.asm.
Thank you!
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
yeah I would prefer it like that or at least change the 'rv' to something
else more readable.
It's readable and short :wink
rv : Return Value
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.
Quote from: Mark Jones on December 23, 2008, 01:46:51 PM
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
The worst scenario is macros combined with conditional assembly, as shown below :bg
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
Quote from: Mark Jones on December 23, 2008, 01:46:51 PM
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.
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
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.
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.
Quote from: MichaelW on December 24, 2008, 02:55:30 AM
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.
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.
I chuckle at the rhetoric surrounding the use of macros, the distinction is whether you are using a MACRO assembler or not, if you are, why cripple it with 1980s assumptions. I am out of the generation that coded assembler like an assembler dump in the old days and occasionally i still do for private code but with the last couple of projects I did in MASM including QE 4.0 I extensively used the masm32 library and macros because of the sheer complexity of the code and wrote a pile of new ones for it as well.
When you have the option of macros like MASM and now JWASM, you in fact choose where you use them as is appropriate to the task being performed, MASM's .IF notation is useful enough but I regularly use the SWITCH notation from the macros and its variant SWITCH$ as it allows faster coding and more flexible coding which is consistent with a MACRO assembler.
Its well and good to talk about coding in bare mnemonics and most of the old fellas have done so for years but there is more to programming than the barest code possible, sheer complexity which is often not all that speed related is better handled with properly tailored macros as it improves the logic and readability of the code. While many high level languages ape this capacity with their prebuilt macros that are part of the language, a MACRO assembler allows you to make a capacity that does exactly what you want and this makes it a more flexible and more powerful tool in many instances than a compiler.
I originally wrote QE in a basic compiler many years ago because of its excellent inline assembler but after having written 3 versions from scratch in basic, the sheer advantages in writing it in MASM justified doing it that way and that gave me the range I needed from some high level code to very low level code and this was possible because of having a developed library, macro system and the capacity to write a number of specialised macros for very complex internal components of the project.
I think the problem is that you, hutch, have an intimate knowledge of the macros (obviously heh).
Let's face it, your macros.inc is 117K, that's a lot of code to wade through.
I think of masm32 (using only macros) as being a bit like basic/vb/delphi, lots of assignments and then lots of api calls, all hidden.
(not a criticism of masm32).
The macros I use are usually the print ones, since someone here is obsessed with LAMPs :bg
Its not supposed to be all or nothing, hutch.
Using macros is fine. Over-using them isn't.
The same is true of every paradigm be it macros, oop, garbage collection, templates, and so on.
If you cannot get a grip on what state the underlying machine is in by looking at code in front of you, then quite frankly you no longer have good code. There is only so much the human mind can handle at one time. If the state of the machine is so unimportant that you can get away with being oblivious to it, then I dare say that assembler is the wrong tool for the job in front of you.
High level languages get a pass because the state of the machine isn't important. Instead its the state of the abstract machine thats important, and that abstract machine is greatly simplified where modifications to this simple state are intuitive, standardized, and enforced.
We all have our reasons for writing in assembly but they mainly boil down to a small list:
Performance
Size
Control
Necessity
Most all those macros in a monolithic macro include file do not enhance performance or size, usualy they degrade both because they have to be generic. Nor do you maintain control when you are using them since the author of that include file is the one actualy in control when you use it, and its so damn large its hard to even tell if you make a change somewhere that it wont break something else in it because all sense of dependency is lost because of how monolithic it is.
This leaves necessity, and I think most of us do not fall into that group, but I think those that do also by necessity cannot use the vast majority of such include files because they are programming for ring0 or a different OS.
I havent a clue what side effects or performance characteristics a given macro in the monolith might have, and if i'm going to bother to take the time to investigate then I might as well skip it and do without it. At least when I do without it, a month from now when I'm performing debugging/maintenance/optimization I wont again be wondering what side effects or performance characteristics that same macro might have.
> Using macros is fine. Over-using them isn't.
The problem here is that over and underuse varies with the individual programmer. If someone never learnt the .IF notation it would look strange to them if they always coded in pure mnemonics yet the programmer that uses code like.
print "Howdy Folks",13,10
has not thrown anything away, it just saves shovelling through console API calls just to dump something on the screen as a result. Macros are a form of programmer controlled automation and at least the ones in the masm32 project are documented and the source is available. It means you can just use them, use them as reference or just write your own if you don't want to code the area manually.
The main factor is for a person who does not want to learn their own or someone elses macros, they can always write the code manually but that type of code was what made assembler the laughing stock of programming 10 years ago, now thwey whinge but they don't laugh anymore. :bg