flat assembler
Message board for the users of flat assembler.

Index > Windows > [solved] Bug in COMDLG64.INC

Author
Thread Post new topic Reply to topic
Oliver



Joined: 20 Apr 2020
Posts: 3
Oliver
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]


Description:
Download
Filename: ofn.c
Filesize: 3.89 KB
Downloaded: 52 Time(s)

Post 20 Apr 2020, 01:49
View user's profile Send private message Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 555
Location: Russian Federation, Sochi
ProMiNick
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:
Code:
ofn OPENFILENAMEA sizeof.OPENFILENAMEA,bla,bla,bla    
that variant will work in any windows - and thou will be best friend of all users of thour program.

Code:
ofn OPENFILENAMEA ThourStructLength,bla,bla,bla
rb ThourStructLength-sizeof.OPENFILENAMEA    
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
Code:
ofn OPENFILENAMEA ThourStructLength,bla,bla,bla    

hope thou see difference in all 3 cases
Post 20 Apr 2020, 02:26
View user's profile Send private message Send e-mail Reply with quote
Oliver



Joined: 20 Apr 2020
Posts: 3
Oliver
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.
Post 20 Apr 2020, 09:19
View user's profile Send private message Reply with quote
Ali.Z



Joined: 08 Jan 2018
Posts: 357
Ali.Z
Oliver wrote:
"Wrong": lCustData dd ?,?

Correct: lCustData dq ?


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.

_________________
Asm For Wise Humans
Post 20 Apr 2020, 10:29
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
Ali.Z wrote:
Oliver wrote:
"Wrong": lCustData dd ?,?

Correct: lCustData dq ?


its not a bug, it reserves two dwords.
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]".
Post 20 Apr 2020, 12:30
View user's profile Send private message Visit poster's website Reply with quote
Oliver



Joined: 20 Apr 2020
Posts: 3
Oliver
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.
Post 20 Apr 2020, 13:28
View user's profile Send private message Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 555
Location: Russian Federation, Sochi
ProMiNick
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.
Post 20 Apr 2020, 14:20
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.