Yesterday, I tried to use DirectMusic from fasm code, and although I finally succeeded, it took me much time, due to the difficulty translating C\C++ typedefs, pointers, variable sizes etc. Anyway, after finishing my demo, I got so happy that I composed (a not so successful) midi file:( Executable, source with simple 'dmusic.inc', and midi included in archive.

I really don't want anybody else to experience the same difficulty, so I am suggesting a DirectX include standart to be used with fasm. DirectMusic deals with many GUID's, and the definition of each is 32-bytes long, in order to define only the ones that are needed by the coder, I came up with this macro:

macro DEFINE_GUID guidname,double1,word1,word2,[bytes]
{
common
if used guidname
guidname:
.data1 dd double1
.data2 dw word1
.data3 dw word2
.data4:
forward
db bytes
common
end if
}

So in the include file you would have many times things like:
DEFINE_GUID KSDATAFORMAT_SUBTYPE_MIDI, 0x1D262760, 0xE957, 0x11CF, 0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00
but only the GUID's that are used will be defined, simple yet effective. Another idea behind the macro is that it is easily converted from C source where it appears as:
DEFINE_GUID(KSDATAFORMAT_SUBTYPE_MIDI, 0x1D262760, 0xE957, 0x11CF, 0xA5, 0xD6, 0x28, 0xDB, 0x04, 0xC1, 0x00, 0x00);

So my suggestion mainly to Privalov is to include the INTERFACE,COMCALL, and this DEFINE_GUID macro somewhere in win32a.inc or another general include file that comes with the fasmw package, and then the user can simply include multiple directx include files(ddraw.inc, dsound.inc, etc) without overdefinition of the macros. The main idea is to stop seeing different variations of the comcall like INVOKEDDSURF4 or DDCall , or whatnot, since the DX includes won't contain any definitions of macros and take these 3 macros as a standart. Thus, it also would be easier for different Fasm DirectX coders to 'communicate' with each other.

P.S. If you don't agree with me about the define_guid macro, at least you should admit that it is reasonably logical to include the comcall (and therefore interface) macro where the various srdcall, invokes,ccall are defines,since you would need comcall not only for DX but everytime you deal with COM.

I've already made a COM macros with GUID macro, too:
http://board.flatassembler.net/topic.php?t=553
It's a bit different from the current standard - the current "comcall" becomes "cominvk" in the final version, read that thread to see why.
If we agree on some final standard that is clean and universal enough, I will put it into official includes.

Your idea of adding "if used" to a GUID macro is good, but it still doesn't resolve a problem with defining a GUIDs in the headers, since they have to be put in data section.
Maybe some kind of GUID macro for use in headers combined with another GUIDs macro to be put in data section, which would define data for those GUIDs defined in header, that are used in code?

I dont see a solution without another seperate include in the data section for the guid problem. About the 'cominvk' & 'comcall' in that post, I really like it since it follows the logic of the normal invokes and calls.
I agree with these 'cominvk' & 'comcall', but define 'we' in this case, should we make a poll or something like that?

Let's say the ones that have suggested some kind of standard, like you in this case. I see we are agreed about the "cominvk" and "comcall", what about the GUID macros? Surely the "if used" is a must there, what about parameters (the convention used by your macro is very different from the one I used, mine might look a bit strange, but I made it in way that allows to easily adapt the standard string form of GUID, there is also a possibility of making a macro that would accept just a quoted string containing the text definition of GUID.

I don't care about the parameters, what is important is that the user does not bother defining the guids he uses (just like in C++).
Unfortunately, the only somewhat decent solution to the data-in-header definition problem is that a separate data section is defined:

macro DEFINE_GUID guidname,<params>
{
common
if used guidname
if GDATA = 0
section '.gdata' data readable
GDATA = 1
end if
guidname:
-define the guid according to <params>
end if
}

As I proposed, the macros in header can just store all the labels and values for defining them later, you can have additional macro like "GUIDs_data" which you would have to put somewhere in your data section, where you want all your GUIDs to be placed. And the macro would take all the definitions collected by "GUID" macros in header and declare the ones that are used in code.

OK, this sounds good, I agree with you. I see it won't be possible without that that additional macro. And after all it sounds fair since the user is the one who decides where the data of the guids is declared. Do you have an idea of the code of these macros?

cannot the GUIDs be anywhere? do they have to be in array or something like that?