It seems like the invoke macro doesn't work with api functions that don't accept any parameters and I have to use the call instruction instead. This is not a major issue but it means having to take time to decide which call macro I have to use. I think it would better to have one macro to call all types of functions. Is this feasible?

You can use invoke maco for APIs with no parameters. Don't you have an older version?

BTW, S.T.A.S. has came with a solution that may interest you too - there are no invokes at all see here: http://board.flatassembler.net/topic.php?t=1889

Hello!
I use this set of macroses that helps to translate Platform SDK header files easily.

macro GetMessage [arg] { common win32apicall GetMessage_,arg }
GetMessage_% = 4

macro win32apicall proc, [arg] { common invoke proc, arg }

macro invoke proc,[arg] ; invoke procedure (indirect)
{
common
if ~ arg eq
stdcall [proc],arg
else
call [proc]
end if
}

macro stdcall proc,[arg] ; call procedure
{
reverse
pushd arg
common
call proc
}

macro invoke proc,[arg]
{ common local ..count
..count = 0
if ~ arg eq
forward ..count = ..count + 1
common
end if
if defined proc#%
if ..count <> proc#%
display 0Dh,0Ah,"error: invalid count of parameters for API call.",0Dh,0Ah,0Dh,0Ah
halt
end if
end if
invoke proc,arg
}

I don't have this problem when using the fresh macros and there are some ofher nifty macros in its macro library so I think I'll continue to use it.

BTW, I wish someday Privalov and John would finally design one macro library, used by both FASM and Fresh

It's hard to satisfy everyone - maybe the "competitive" macro packages (the one from STAS is another example) are a good way to do it.

I maintain my own set of of macro libraries (taken from an older version of FASMW), it's slowly starting to change to better meet my needs. In reality, you can't satisfy everyone, so why try? Either deal with what's provided or roll your own. The advantage to doing them yourself is that you control them: they'll never change without warning

No problem with the existing call macros.

But you do it! Your strong opposition to hardcode the functionality that can be done using macros has done the work.

I try to follow the standard distribution but sometimes I need something different. For example I shall never use "invoke" in my sources (too ugly and damage the nice indentation of assembly code).

Pelaillo,

What's wrong with the invoke macro?

You just need to indent a little more.

I think that the most elegant (and proably the most commonly used here) indent method following: you press tab once, write an instrution (or some macro, like invoke or stdcall), then press tab once again, and write instruction (macro) arguments. If tab size is set to 8 spaces, this way your code looks very clear, and invokes don't break the indentation. BTW, it is used in FASM and Fresh sources. Why not to use it too?

Invoke macro contents is good. It's the name that I don't like.

Reasons:
1. I use "call" for every call: no need to diferentiate between APIs, procs with arguments, procs without arguments and normal labels.
2. I like small tabs and dislike to press more keys than needed.
3. It looks good, simpler and it works flawlessly.
4. It remembers me good old Tasm
5. I don't like anything that resembles Masm syntax

Simple macro solution.

Silkodyssey, that is really an elegant solution

Yes, that is the integrated call proposed by KevinZheng here. To make your macro work in all given cases, you will need this:

And define API.EveryFunction in the import macro.

pelaillo,

I'll try that code some time. At the moment I'm happy to just put the brackets around the api calls.