Both the IMPORT32.INC and IMPORT64.INC files currently do not try to align binding call addresses. The best alignment guaranteed is to even addresses.

This can be fixed by inserting align at around line 26:

http://board.flatassembler.net/topic.php?p=107831#107831

I don't have the tools at hand not a 64-bit setup so, was the bug mentioned there fixed?

If you are asking about the alignment penalty, then, no, it appears to be still the same. Neither IMPORT??.INC file contains any alignment directives.

The PROCs without locals nor params problem which leave RSP unaligned on entry. A quick look to PROC64.INC tells me that "PUSH RBP" is avoided on such situation which could potentially keep RSP MOD 16 = 8, but maybe something else compensates that (but I can't test here).

If one is concerned about "polluting" the data area with extraneous nops then we can use this instead:

BUMP

There is this wider problem with import macros - they are left almost unchanged since the very early fasm versions for Win32. Well, that may also speak in their favor, as they had to be not so bad at all if they managed to be useful through all this time - however initially I thought that some better variants would appear when some knowledgeable user realizes he needs more that this simplest solution. For instance, one could put the import addresses table into some other section (marking the table with "data 12") and mark the import section as "discardable" then. Also, in another variant, one might create "jump gates" for imported functions to make the call instructions shorter (but then you'd have to use "stdcall" instead of "invoke" to call them). And with the new abilities of fasm's preprocessor this certainly could be done at a small cost.
On the other hand, I'm afraid that even the new project of Windows headers maintained by community would be reluctant to change the usage of import macros, as they became de facto standard for fasm during all those years...

Does your response above mean that you are not keen to change them? My suggestion won't break any existing code.

I found in the past that messing with import tables and moving them around among sections has a tendency to trigger the paranoid AVs. In general. the tiny gain one might get with using various data sections is more than offset by the loss of triggering AVs and panicking users.

[edit] BTW: There have been a number of import macro suggestions placed in this board. They never catch on though because whenever someone posts code here they have to use the "official" macros else no one else can assemble the code.

No, it is not about that. I just hoped to trigger some discussion about those macros and possible improvements. As for alignment, I can of course do it without breaking anything, but this does not solve the wider problems the import macros have, in my opinion.

Sometimes the effect may be the opposite. Since there exists some malware that was created with fasm, some AVs were looking for the "footprints" of standard fasm's way of creating programs. Changing them to some non-standard (in fasm's context) then helped to avoid the false alarm.

And that's what I'm talking about - even changing the official ones would now cause problems, because everyone is already used to assume those macros are there as if they were part of fasm's language. Well, in some sense they are.
On the other hand, I've seen sometimes programs distributed with a set of includes full of someone's own macro inventions for even the basic things - so that sometimes still happens.