Don't know if it (IAT in Directory Table) is really needed, but fasm doesn't set it in PE header. The questin - why? is it useless, playing no role field?

really not sure, but in reality it's NOT needed. just in some hacking and in untypical PEs.

looks like it's not special necessarily, but nevertheless Microsoft's linker sets this field.

fasm did't set it only because you did not told it to do so.
You create the IAT with "data 12" directive. It is required in KMD, for example.

But, Tomasz, IAT is already included in import data (section), and the IAT entry in data directory in optional header it's just a pointer the IAT in import data... according to MS linker & docs. So if PE exe har imports and import has IAT then IAT data directory entry in PE header should have be set to that addess. Arrrggg cannot explain it more simplier)

by the way your example by link is wrong according to my understanding - cuz you declare lookup table, not IAT... and in data directory - IAT is just a pointer to the same IAT in data import.

the correction is just in exchanging ImportLookup with ImportAddress. But nevertheless can FASM just put the generated IAT address by import macro and its size in data directory in optional header?

alseo can there nested data directives?
e.g

and finally data directive takes as argument numbers from 0 to 15 yes?

Yes, you can nest it. However the example I provided is correct in context of KMD, it was based on the analysis of KMD generated by Microsoft's linker.

I just anilized PE made by MS linker v7.x with Hiew and pecoff_v8.doc (provided by MS) and it the same as i said before... exactly IAT not lookup table address as placed in IAT data directory. It's not my fantasy, but reality of MS Linker.
I found that IAT data entry contains address to monolith block of IATs (one by one) of all import libraries and contains the sum of sizes of all IATs. each import entry points with its IAT member to each place in this monolith block... Lookup tables are standalone...

You're right, that sample has it reversed by mistake. It was fixed in later driver example packages.

As for the regular PEs (not drivers), they usually (not counting those made with MS tools ) have no IAT directory entry at all. Also if the IAT entries point to the same place as ILT entries, it doesn't seem to cause any problems.

Anyway, fasm leaves you free to do it any way you want. Here Joshua provided a macro that makes an IAT for you. Also other interesting approaches to creating imports are provided in that thread.

Thank, Tomasz, i would appreciate if you give me the right direction to discovering what is it (IAT data directory entry) for if it is useless and can be obtained by simple taking the appopriate field from the import data... Is it for correct work of drivers only?

The Import Lookup and Import Address entries (according to specifications) are identical in file, but when loading program into memory, the Import Address entries get replaced with the addresses of imported functions. Old variants of fasm macros did generate them pointing to the same place (practically making the Import Lookup entries lost after binding), but later it was changed to be more conforming to specifications (even though that variant was working perfectly on all versions of Windows). So now standard fasm's macros generate separate entries for Import Address, but not in continuous block, and for this reason it's impossible to pack it into one common IAT (see the Joshua's macro linked in my previous post for some interesting alternative).

Because Import Address entries are the only part of imports that gets modified, it may be actually a good idea to place them outside the import section, so the pages containing imports may be safely discarded, as only the pages containing IAT will get "dirty" status. I believe this also may be the reason why kernel drivers need to have them separated.

Biggest Thanks, Tomasz!
I adore FASM more and more)