Hi,

the OPENFILENAMEA struc in INCLUDE/EQUATES/COMDLG64.INC is not correct. GetOpenFileNameA failed, so I tried to find the reason with the help of a little C-Program that displays offsets and sizes of the struc members.

Inside the attached file ofn.c the second comment is a copy of the output. Note that it is possible to set lStructSize to 136 (instead of 152). In this case the GetOpenFileNameA function ignores the new/extended members.

Presumably GetOpenFileNameW is incorrect as well.[/code][/quote]

there is no bug.
struct versions in fasm package are mostly universal for all windows. their version from times of win2k or winxp, so ofcource they don`t have additional members appiared in win8-10 (maybe in win7 & vista too), but most of them even work in win95.

so there are 2 correct solutions: that variant will work in any windows - and thou will be best friend of all users of thour program.

if thou had knowledge about extended size of lastmost versions of comdlg structs use this knowledge.
Users will hate thour program for that, but it will have additional functional.

BUT NEVER

hope thou see difference in all 3 cases

You are right. I had wrong offsets in MY structure after conversion from 32 to 64 bit. After I had found this bug I took a look at the structure in COMDLG64.INC and mixed things up. The only mistake in this structure is not significant:

"Wrong": lCustData dd ?,?

Correct: lCustData dq ?

As I had mentioned, one can use this structure without the new members. My bug was independent from the new members and was referring to offsets. Sorry.

its not a bug, it reserves two dwords.
there is another use for ?,? in duplicates:
dd 2 dup(12,89)
dd dup(?,?)

you maybe want to initialize them first.

In the old Windows API manuals lCustData was defined as DWORD, but later it has been changed to LPARAM type. Defining it as "dd ?,?" reserves the same space while perhaps having more backward-compatibility. Anyway, in assembly you can easily override either by using "dword [ofn.lCustData]" or "qword [ofn.lCustData]".

That is all clear to me and I already mentioned that this difference is neither significant (with assembler) nor the problem I had. I had simply made a mistake with offsets during conversion of a 32-bit tool to 64-bit and mixed things up after I found my mistake. I'm sorry that I have wasted your time with a simple confusion!
Thank you very much for your effort.

Other structs that has no structsize member are more dengerous LOGFONT, LOGPEN,LOGBRUSH and something similar because they could be part of larger structs. there is significant aligned they or not to 8 byte boundary and aligned or not their sizes.