flat assembler
Message board for the users of flat assembler.

Index > Windows > WM_SETTEXT bug

Author
Thread Post new topic Reply to topic
moriman



Joined: 01 Apr 2006
Posts: 55
Location: Northern Ireland
moriman
Not sure if this a well known bug or not, but it had me stumped for a while Confused

I had a subroutine that returned with the direction flag cleared (CLD) and then used
Code:
invoke  SendMessage,[hWnd.re2],WM_SETTEXT,0,edi    

without any problem.

On invoking exactly the same line after another subroutine returned with the direction flag set (STD) the program kept crashing Sad
I initially thought it a problem of the 2nd subroutine but by clearing the direction flag before return the above 'invoke' works fine.
So within the SendMessage(WM_SETTEXT) routine, micro$oft haven't checked the direction flag before MOVS, STOS or something similar.
Just posted this to help others with the same problem Wink
Post 25 Apr 2006, 23:53
View user's profile Send private message Reply with quote
Vasilev Vjacheslav



Joined: 11 Aug 2004
Posts: 392
Vasilev Vjacheslav
on many text functions direction flag not checked
Post 26 Apr 2006, 07:09
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
ARGHHHHH, and I though WHY, WHY, WHY!!! I always blaimed myself. You won't believe what workarounds/hacks I needed to do :@
I usually don't set directsion anywhere and assume its always clear...

Thanks a BIG! Very Happy
Post 26 Apr 2006, 07:13
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7801
Location: Kraków, Poland
Tomasz Grysztar
This is not really a bug, the STDCALL convention requires you to clear DF when calling the function (and any STDCALL function must return with DF cleared).

Reference: MASM Manual
Post 26 Apr 2006, 07:31
View user's profile Send private message Visit poster's website Reply with quote
moriman



Joined: 01 Apr 2006
Posts: 55
Location: Northern Ireland
moriman
Thanks for the info Tomasz, I had never come across that before.
IMHO I would still class it as one of the numerous bugs in windoze. If I write code and don't check the DF (or any other flag) when necessary, if the app crashes, it's my error. If a windoze sub doesn't check it, it's their error Smile
Post 26 Apr 2006, 08:15
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7801
Location: Kraków, Poland
Tomasz Grysztar
If you provide an invalid pointer as a parameter, the app crashes too - and it's actually the same story. Since setting DF to 0 is a part of calling convention, then when you call function with DF set, it's like providing an invalid parameter.
So the only problem here is whether the API function should detect just allow an exceptions to happen on bad input, or detect all such cases and return back some error. As we can see, with both invalid pointer and invalid setting of DF the first solution has been chosen by Microsoft (so it actually leaves the parameters validity checking to the programmer).
Post 26 Apr 2006, 08:30
View user's profile Send private message Visit poster's website Reply with quote
moriman



Joined: 01 Apr 2006
Posts: 55
Location: Northern Ireland
moriman
While I understand what you are saying and completely agree with you from that perspective, my point is simply that there must be somewhere in the API call that uses MOVS, STOS CMPS etc, without checking the DF first. This is something that I (and I'm sure you also) would *never* do. A very quick

CLD
REP MOVS

or

STD
REP MOVS

is all that is required to ensure the DF flag is as you require it. This applies equally to us mere mortals and the micro$oft employees.
Post 26 Apr 2006, 10:01
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7801
Location: Kraków, Poland
Tomasz Grysztar
The code of API was probably generated by the C compiler, and the C compiler assumes everything conforms to the calling convention. Thus programmer may even have no idea that something like that happens there.
Post 26 Apr 2006, 13:40
View user's profile Send private message Visit poster's website Reply with quote
moriman



Joined: 01 Apr 2006
Posts: 55
Location: Northern Ireland
moriman
Ah! I understand now Wink

Thanks Tomasz
Post 26 Apr 2006, 16:43
View user's profile Send private message Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
Tomasz Grysztar wrote:
This is not really a bug, the STDCALL convention requires you to clear DF when calling the function (and any STDCALL function must return with DF cleared).

Reference: MASM Manual


useful link thanks

Quote:

Under STDCALL, the direction flag is clear on entry and must be returned clear.


Code:
macro stdcall proc,[arg]                ; directly call STDCALL procedure
 { common
    if ~ arg eq
   reverse
    pushd arg
   common
    end if
    call proc }
    


should this not be
Code:
macro stdcall proc,[arg]                ; directly call STDCALL procedure
 { common
    cld
    if ~ arg eq
   reverse
    pushd arg
   common
    end if
    call proc }
    


?

_________________
redghost.ca
Post 29 Apr 2006, 05:57
View user's profile Send private message AIM Address MSN Messenger 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 GitHub, YouTube, Twitter.

Website powered by rwasa.