Hello Tomasz,
Preambula: On the early stages of fasm blocks of its core logic traveled from one include file to another from version to version until the moment when structure of core includes become stable.

From the other hand structure of platform-specific (Windows for x86) includes was initialy stable.
But there are always present a bit strange mixing:
struct is fundamental macro.
import, export, resource macros are PE/COFF file format dependant macros for its data directories.
most of others windows dependant macros.
they all mixed together in one folder.

nonmacros entities are splited by relation to library.
Api and its paramcount of cource stong related to library, but equates & structures are not.
many different libraries share same consts & structures.

Most of all existing SDKs split includes not by library but by task what these includes resolve (I used same naming winbase,winuser etc.). (masm make it simpler - all mixed into one windows.inc file (of course it correlate with HLLs), but that is bad resolving)

In attachment fasm pacckage that output is binary same, structure & content of source & examples & tools are same, only internal structure of include differs.
naming and contents combining of includes more corellate with masm & HLLs.

Tomasz could you change official fasm (only "include" folder) to this form (from some update).

In my suggestion everithing is on its place: generic things, file format relative things and os specific things are separated. (I not extended includes to all possible equates & structures, their content remain same that original fasm has) (and size almost same)

fasmpack part 1
fasmpack part 2
[attachment in 1st post renamed & updated/ attachment to same package in following posts removed]

This should probably go into this initiative: https://board.flatassembler.net/topic.php?t=7882
The basic includes that come with fasmw were never intended to be a complete solution and they no longer get any serious modifications, they are likely to keep preserving the legacy structure and features.

If I was to make something new, I would most likely go with a fasmg-only package, dropping any backward compatibility and pushing the new macro capabilities to allow some really fancy syntactic variants. But that's another story.

Tomasz, no, no, no.
for https://board.flatassembler.net/topic.php?t=7882 I worked on much larger package with many additions in behavior, with constants set more detailed (precised), with more full list of structures, with content which more clear splittied to files & named according to MSDN,etc.
But now I just suggest restruct base one package to make it more frienly & flexible for future community member extensions.

In my suggestion all remain in fasm minimalistic style - absolutely all content remains same (absolutely same: same constants defined for every mode, same macros with absolutely same behavior, same list of structures nothing added or cuted off). Changed only includes structure: its files partialy renamed or moved to another folder, some of these files are splitted to lesser ones, some combined to bigger ones.

restructuring maked as some form of comment - entities regrouped to describe nature of its contents.
moreover headers became more friendly for newbies from HLL.
If someone wish to play with file formats: assemble music or making pictures (based on analize forexample music file); - he could place file format related things in specialy prepared for that "file formats" folder.
Any addition could be realized in common way in proper subfolder of includes but not in the same directory as project (opengl & directdraw examples builded in that (I dislike) manner - includes that could be reused by other projects not splitted and placed to proper folders for common use, but located in same folder as example).
If someone wish to cover some functionality of windows over the minimalistic package - same situation as for file formats - proper folders are ready.
Of course all of it will be usefull only in case when enthusiasts will continue to share their examples.

P.S. In described above (I dislike) manner written all linux sources & examples (no matter for fasm1 or fasmg) - that creates negative effect for any linux development as result only few tens of examples among whole forum are related to linux.

Same as initial attachment - minimalistic and fully compatibable with everithing ever created for official fasm.
Whole fasm package configured so way to work with legacy struct macro.
But legacy aproach limits us to not use unnamed fields in intuitive manner.
New macro struct fixies it.

But in this case(new struct macro) I can`t say that nothing is added - new macro added top level union definition ability.
And that can potentially chande syntax.
However this is minimalistic candidate №2.
That one is the best candidate for starting point of builing your own custom extended package.

Maybe that's nitpicking, but this is not entirely true. Any sample that used macro sets with a statement like: or maybe: or even: has the compatibility broken by restructuring.

My main issue is that I do not want to invest my time messing with the legacy macros when I can use it to work on something better, with the tools that fasmg can provide (my formats tutorial is kind of a first step in that direction, and my progress is currently very slow anyway).

struct definitions a little fixed: using (but what for thou will use it) RTL_CRITICAL_SECTION_DEBUG from official package can crash program if thou make assumption that this structure defined according to MSDN, here fields are with wrong size and with wrong offsets, correct only order of them.

includes more separated, (their set is still minimal, but all according MSDN) added x64 winsock

more MSDN clear: