StrStrA,'StrStrA',\
       StrStrW,'StrStrW',\
       StrStrIA,'StrStrIA',\
       StrStrIW,'StrStrIW',\
    

IMO there should be a separate set of API macros for the various API versions. 95, 98, ME, NT, 2K, XP, Vista, 7. That way is becomes absolutely clear about which version of Windows the code is designed to support.

Since fasm itself doesn't cut you out from the instructions for processors newer than those you program for, it would not be in the same spirit to make such thing for WinAPI.

The idea is: just provide them all, programmer should know what he uses anyway.

Unfortunately this is becoming increasingly hard for the programmer to know which-CPU-supports-what. There is such a large variety now, and the variety is continually increasing. I think the best place to do the detection is by the assembler.

I had an exactly opposite impression - that nowadays processor are able to mix so many different abilities and inabilities (just look at amount of such bits that CPUID returns) that any such system would only create more trouble rather than really help. If I wanted to use any AES instruction, I would also need to remember how the AES-enabling directive is called for the environment I use in addition to knowing the instruction names (which are standard). Thats unnecessary complication in my view.

Using macros is one way to solve, but it is also very space inefficient (uses lots more memory) and makes assembling slower (up to 10 times slower in many instances).

So for the original topic here, would you be okay with having multiple sets of API macros (or some other selection method) to allow for 95, 98, etc. API separation? If so, how would someone submit that for inclusion into the fasm download? Or would it always have to be a separate download?

On second thought, I might still convince myself to implement some instruction set restrictions as an optional directives that wouldn't restrict anything unless you used them (so default would still be "everything allowed", as it is now).
However the fact that there is a set of macros that does the job well, does not encourage me to consider it as something worth effort. You know already that I love to have as much as possible implemented as macros (BTW, do you know LaTeX? ). And fasm 1.x has this flaw in its architecture that any keyword must be disallowed globally for assembly-time defined symbols (which is another reason for trying to avoid introducing new keywords [another BTW: I think it was a bad choice to introduce "note" as a keyword type of segment in ELF executable]; I myself have some programs where I had to rename the "note" label because of this).

For x86 one could use: PROCESSOR, or FEATURES? Or perhaps CAPABILITY? EXECUTIONSET? INSTRUCTIONSET?

I don't know LaTeX. Is this related to assembly instruction sets?

Without the macros the programmer has no opportunity to force fasm to create the correct jump code.

revolution wrote:

For x86 one could use: PROCESSOR, or FEATURES? Or perhaps CAPABILITY? EXECUTIONSET? INSTRUCTIONSET?

What about parameters specifying the various capabilities? I'd prefer not to use numerical values.

revolution wrote:

Without the macros the programmer has no opportunity to force fasm to create the correct jump code.

That's exagerration, it is enough to write jumps like "JE SHORT", etc.

I also considered how to make the directives use textual parameters but couldn't come up with any suitable solution.

And on these smaller CPUs space/time is usually of a premium so making all jumps as JnCC SHORT $+5/JMP LONG TARGET is not efficient. Macros are the only practical way to get efficient (and correct) jump encoding.

And the restricting directives would not help you here (as they would restrict you in the same way as if every such jump had "short" type specified)- you'd still have to write macros.

They would help because at least the programmer will get a compile error.