Disease 2000, emailed me with a macro idea, which is close to what f0dder has been asking for. Here is the first product of those suggestions:

WARNING: This macro makes Elicz's includes and hutch--'s includes superfluous. :) All with a little macro.

Please take a look. :alright:

f0dder, I think you'll like this. ;)

Oh, did I forget that it supports Unicode? :)

------
Edit: New version with less bugs below. :)
Posted on 2001-09-07 21:02:35 by bitRAKE
If you've downloaded previous versions of this macro, they are no good in general use. Here is a demostration of using the macro - it is a RadASM project.
Posted on 2001-09-08 01:14:33 by bitRAKE
Hm, haven't looked closely at it yet, BUT... firts of all, do you macros
handle type checking like invoke? And second, because of the way
imports are done, I assume that "parameter checking" will be done
at link time (ie, importing a wrong symbol), which means it will be
harder to catch the source line with the problem. As I said, I haven't
looked closely at it yet, but this is just my first thoughts.

I like include files. Less things for the assembler to do at build-time,
and nice error checking.
Posted on 2001-09-08 03:52:00 by f0dder
BitRake,

sorry, this is not a new idea. In fact, i've posted a similar macro some month ago, but the idea wasn't new then either (purpose was to avoid the linker generated jump table, the superflouosity of the include files was an UNWANTED side effect!). Main disadvantage of this approach is that you "fool" the assembler but instead get linker errors which are probably more difficult to understand/find.

japheth
Posted on 2001-09-08 05:43:41 by japheth
f0dder, all the APIs take dword size parameters, so the type checking is just in the number of parameters, and this is based on the first use of a function. The includes offer only a template to insure that the the number of parameters are correct - for they are all dwords?

japheth, didn't see your macro - could you point me to it? I know the idea isn't new - this is just a fancy/condensed way to accomplish the same this, and it demostrates the power of macros. :)

Yes, it is true that the external function name is based on the number of parameters passed to the macro on the first use. Well, at least you can't have multiple wrong external functions names being referenced - this is not for the newbie. :)

Okay, in all reality the macro should be named something like '.invoke' and then after you've finished debugging switch to this macro. The functionality that it provides is something that should be used late in the development process. Therefor it is not a complete replacement for the includes, unless your an WinAPI God - haven't seem one. :)
Posted on 2001-09-08 08:40:13 by bitRAKE
bitRake, heres the link (old messageboard)

click here

just read it again. Seems you have posted to it several times. So you possibly remember :) .

japheth
Posted on 2001-09-08 11:31:14 by japheth
japheth, I sure did it the hard way. :) MASM doesn't care about the multiple externdef's or the leading comma. Silly me. Yes, I remember now. Thank you.
Posted on 2001-09-08 12:28:37 by bitRAKE
Hi fellows,

I scanned through bitRAKE .DLL macro once more
last week,
I came up with idea that everything you need to define
in PROTO statement is a Number of Posted on 2001-10-02 20:32:33 by Andycar
I'll quote myself:
or, (standard MS-type LIB call, i.e. invoke identical):

It is not identical (addr is lowercase only now), plus,
generates jumptable-free call.
Posted on 2001-10-03 12:21:24 by Andycar
Good idea, thanks for sharing.
Posted on 2001-10-03 22:48:48 by bitRAKE
Where can I get this macro and an example how to use?




Thanks,
_Shawn
Posted on 2002-01-11 05:15:37 by _Shawn
In hind-sight this macro does more than is needed, but it is complete IMO.
EliCZ also posted this on his web-site - cool guy.
Use is no different then invoke.
.DLL MACRO api,args:VARARG

LOCAL dargs,dtype

IFNDEF _PROTO_&api
dargs TEXTEQU <>
_PROTO_&api = 0
IFNB <args>
FOR arg, <args>
dargs CATSTR dargs,<,:DWORD>
_PROTO_&api = _PROTO_&api + 4
ENDM
dargs SUBSTR dargs,2 ;; Strip the first comma
ENDIF
dtype CATSTR <_PTYPE_>,%_PROTO_&api
IFNDEF %dtype
dtype TYPEDEF PROTO dargs
ENDIF
dargs CATSTR <EXTERNDEF _imp__>,<api>,<@>,%_PROTO_&api,<:PTR >,dtype
dargs
ENDIF
dargs CATSTR <_imp__>,<api>,<@>,%_PROTO_&api
IFB <args>
invoke dargs
ELSE
invoke &dargs,args
ENDIF
ENDM


;; UNICODE version for above ;)
.uDLL MACRO api,args:VARARG
IFDEF _UNICODE_
.DLL api&W,args
ELSE
.DLL api&A,args
ENDIF
ENDM


;; C Calling convention
.cDLL MACRO api,args:VARARG
.DLL api,args
add esp,_PROTO_&api
ENDM


;; UNICODE C Calling convention
.ucDLL MACRO api,args:VARARG
IFDEF _UNICODE_
.cDLL api&W,args
ELSE
.cDLL api&A,args
ENDIF
ENDM
Posted on 2002-01-11 20:27:48 by bitRAKE
OK, I'm posting my own modified version of EliCZ's APImacro.mac.

Actually, form of the calls i used has almost nothing in common with the form of macro used in his code.
Now supports 'ADDR' and 'addr' statements as well.

"iWin32@" - standart for usual 'invoke' MASM equivalent
(will link to MS link format LIBs., i.e. to import _imp__Win32API@N

Examples should be easy.
Posted on 2002-01-11 20:59:06 by Andycar