Hi,
This is my killer macro. it takes the fn macro and expands it's capabilities quite a bit.
syntax:
run FunctionName .arg1,-arg2,"this is a silly text"silly,+result
.arg1 generates a variable called arg1 and pushes it
-arg2 generates a variable called arg2 and pushes it's offset
"this is a silly text"silly generates a byte array and gives it the name silly. the name is optional, if you wont need the string later you can leave it blank.
+result generates a variable called result and saves the return value of the funtion in it. it could be the first, last or any argument. makes no difference.
This macro also uses the two sub macros which are used by the muv macro.
for bugs xor suggestions post here.
enjoy
run MACRO FuncName:REQ,args:VARARG
LOCAL first_char,arg,var,saver
arg textequ <invoke FuncName>
FOR var,<args>
first_char substr <var>,1,1
ifidn first_char,<">
arg CATSTR arg,<,>,setstr (var)
elseifidn first_char,<.>
arg CATSTR arg,<,>,setdword (@SubStr (<var>,2))
elseifidn first_char,<->
arg CATSTR arg,<,>,<addr >, setdword (@SubStr (<var>,2))
elseifidn first_char,<+>
saver textequ setdword (@SubStr (<var>,2))
else
arg CATSTR arg,<,var>
endif
ENDM
arg
ifdef saver
mov saver,eax
endif
ENDM
setstr macro arg
LOCAL closing_quot,var_name,quoted_text
quoted_text equ <arg>
closing_quot instr 2,<arg>,<">
ifdif %(@SizeStr (arg)),%closing_quot
var_name substr <arg>,closing_quot+1
quoted_text substr <arg>,1,closing_quot
endif
.data
align 4
var_name byte quoted_text,0
.code
exitm <offset var_name>
endm
setdword macro arg
.data?
align 4
arg dword ?
.code
exitm <arg>
endm
I added the CODE tags so it coulds be read by human beings. :bg
and so the descent into cryptic coding continues.. :dazzled:
Quote from: Tedd on September 30, 2010, 12:56:09 PM
and so the descent into cryptic coding continues.. :dazzled:
Even for my taste it's too cryptic ::)
0101011101101000011000010111010000100000011000010010000001101110011001010111001001100100 :lol
Quote from: usingMasm on September 25, 2010, 08:45:10 PM
I added the CODE tags so it coulds be read by human beings. :bg
The macros are relatively easy to read and understand, it's the syntax which they are implementing what looks weird.
Personally, what I dislike most is a quoted string followed by an identifier ( "silly string" silly )
I said suggestions xor bug reports. I see none. just smart remarks. you don't want to know what I do with smart guys. :cheekygreen: :naughty: :bg
humor aside this is for people who actually write code. It will help them code faster and be more productive. you don't need to be a mechanik to drive a car, so just use them. this is NOT meant as a tutorial. so use it, if you don't like it you'll get your money back.
However if you want you can take some time to study it and understand it. it is very very simple. but you have to read it for yourself. one thing I like most about this macro is the fact that it is infinitely expandable, all the way to how you want it. I have already added a couple of more features.
so the only way for you to give appropriae feedback on this is to either use it or read it. I came here to learn something from you and now you want me to teach you the whole stuff. forget it :P
Quote from: usingMasm on October 02, 2010, 11:49:20 PM
I said suggestions xor bug reports. I see none.
Ok, then I'll be more clear. I wrote
Quote
it's the syntax which they are implementing what looks weird.
If you need this in "suggestion format", it is:
Consider to make the syntax less weird!Because, currently, your macros offer comparatively little benefit, but they make the code significantly harder to read. This is my opinion.
Quote from: japheth on October 03, 2010, 06:13:19 AM
Quote from: usingMasm on October 02, 2010, 11:49:20 PM
I said suggestions xor bug reports. I see none.
Ok, then I'll be more clear. I wrote
Quote
it's the syntax which they are implementing what looks weird.
If you need this in "suggestion format", it is: Consider to make the syntax less weird!
Because, currently, your macros offer comparatively little benefit, but they make the code significantly harder to read. This is my opinion.
Thanks for your kind words. :8)
Would you elaborate on how the syntax is weird and how to improve it?
Quote from: usingMasm on October 03, 2010, 09:20:52 AM
Would you elaborate on how the syntax is weird and how to improve it?
Yes.
First, you took some often-used operators like '+', '-' and '.' and gave them a totally different meaning. This is generally not a good idea, but it might be acceptable if those operators might give the user a faint idea what the new meaning is. However, I can't see that this is the case here.
Second, the '.' oerator seems pretty useless to me. How often do you have a need to define an uninitialized variable and use its content as an argument for a procedure? I tried hard, but failed to see a purpose for that.
Third, the '"' operator to define a string: it allows one item for the string only, so if you want your string to contain a line feed, you have bad luck. Also, the - optional - name behind the string is strange. It's virtually impossible for the reader to guess that this is meant as the name of the string. Perhaps a '=' between the string and the name might give such a hint?
Quote from: japheth on October 03, 2010, 12:07:57 PM
Quote from: usingMasm on October 03, 2010, 09:20:52 AM
Would you elaborate on how the syntax is weird and how to improve it?
Yes.
First, you took some often-used operators like '+', '-' and '.' and gave them a totally different meaning. This is generally not a good idea, but it might be acceptable if those operators might give the user a faint idea what the new meaning is. However, I can't see that this is the case here.
Second, the '.' oerator seems pretty useless to me. How often do you have a need to define an uninitialized variable and use its content as an argument for a procedure? I tried hard, but failed to see a purpose for that.
Third, the '"' operator to define a string: it allows one item for the string only, so if you want your string to contain a line feed, you have bad luck. Also, the - optional - name behind the string is strange. It's virtually impossible for the reader to guess that this is meant as the name of the string. Perhaps a '=' between the string and the name might give such a hint?
if you don't like my choice of operators you can change them to anything you want. I don't see any problems there. like I said this macro can be customized freely. One thing is sure. it takes a lot of pain out of writing code in masm.
Why not make it a bit more intuitive, I'm not a fan of useless macros but Japheth is right it is a bit weird. You could do something like...
run Result{:Size} = Function, arg1(value{:Size}), arg2(value{:Size}), arg3("string value"{:encoding})
At least it would be easier to understand. An example of its usage would be:
run Reply:DWORD = MessageBoxA, hwnd(hWin), Title("My message":ANSI), Body("This is my message":ANSI), (MB_OK:DWORD)
; in the case of the last parameter no "variable" is defined so the value is simply pushed without creating one
And if you really want to take the pain out of coding in MASM I would suggest Visual Basic or C++.
Quote from: japheth on October 03, 2010, 12:07:57 PM
Quote from: usingMasm on October 03, 2010, 09:20:52 AM
Would you elaborate on how the syntax is weird and how to improve it?
Yes.
First, you took some often-used operators like '+', '-' and '.' and gave them a totally different meaning. This is generally not a good idea, but it might be acceptable if those operators might give the user a faint idea what the new meaning is. However, I can't see that this is the case here.
Second, the '.' oerator seems pretty useless to me. How often do you have a need to define an uninitialized variable and use its content as an argument for a procedure? I tried hard, but failed to see a purpose for that.
Third, the '"' operator to define a string: it allows one item for the string only, so if you want your string to contain a line feed, you have bad luck. Also, the - optional - name behind the string is strange. It's virtually impossible for the reader to guess that this is meant as the name of the string. Perhaps a '=' between the string and the name might give such a hint?
the other two of your grudges are justified and will be implemented. first the = before the string name and the ability for complex strings.
Quote from: donkey on October 03, 2010, 02:54:50 PM
Why not make it a bit more intuitive, I'm not a fan of useless macros but Japheth is right it is a bit weird. You could do something like...
run Result{:Size} = Function, arg1(value{:Size}), arg2(value{:Size}), arg3("string value"{:encoding})
At least it would be easier to understand. An example of its usage would be:
run Reply:DWORD = MessageBoxA, hwnd(hWin), Title("My message":ANSI), Body("This is my message":ANSI), (MB_OK:DWORD)
; in the case of the last parameter no "variable" is defined so the value is simply pushed without creating one
And if you really want to take the pain out of coding in MASM I would suggest Visual Basic or C++.
No Donkey you. Donkey means thanks in German.
Quote from: usingMasm on October 03, 2010, 04:06:17 PM
No Donkey you. Donkey means thanks in German.
Donkey != Danke