[solved]MessageBox() making some troubles

Index > Windows > [solved]MessageBox() making some troubles

Goto page 1, 2 Next

Author

Thread

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 27 Aug 2020, 13:39

Code:

wm_initdialog:
        jmp fortest
                ERROR_msg db 'test',0
        fortest:
                invoke          MessageBox,HWND_DESKTOP,ERROR_msg,0,MB_OK

        ; this section initialise my progressbars
        lea                             r12,[my_progressbars_tab]
        lea                             r13,[my_progressbars_tab_end]
        @@:
        mov                             r14w,[r12]
        invoke                  GetDlgItem,[hWnd],r14w
        mov                             [r12+2],rax
        invoke                  SendMessage,rax,PBM_SETRANGE,0,0x00650000
        add                             r12,12
        cmp                             r12,r13
        jl                              @B      
...

First progress bar L loses its range parameters if I call MessageBox() before the initialisation. What it doing and how? All registers looks separate of it. That never happens if some other API called between. I just want to understand how dangerous is to use that MessageBox inside my code Confused

Description:
Filesize:	34.8 KB
Viewed:	14010 Time(s)

Last edited by Overclick on 27 Aug 2020, 17:12; edited 1 time in total

27 Aug 2020, 13:39

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20423
Location: In your JS exploiting you and your system

revolution 27 Aug 2020, 13:51

We don't know what you have done. Post your code.

27 Aug 2020, 13:51

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 27 Aug 2020, 15:33

Read my first post.
Not ok for next code:

Code:

invoke          MessageBox,HWND_DESKTOP,'test',0,MB_OK

Ok for next code:

Code:

invoke          MessageBox,HWND_DESKTOP,'test',0,MB_OK
invoke          SetWindowText,[hWnd],'Surround Converter'

27 Aug 2020, 15:33

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20423
Location: In your JS exploiting you and your system

revolution 27 Aug 2020, 15:40

I doubt MessageBox is causing a problem. Something in your code is causing it.

Post some code showing the problem.

27 Aug 2020, 15:40

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 27 Aug 2020, 15:45

I've got it.
MessageBox making changes to rdx and next invoke GetDlgItem doesn't like it. Seems it happens by Invoke.

That example works correct:

Code:

invoke          MessageBox,HWND_DESKTOP,'test',0,MB_OK
xor rdx,rdx
...

I using allow_nesting macro from includes if it will help...

Description:
Filesize:	44.9 KB
Viewed:	13993 Time(s)

27 Aug 2020, 15:45

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 27 Aug 2020, 16:44

Overclick wrote:

MessageBox making changes to rdx and next invoke GetDlgItem doesn't like it.

Note that there’s no notion of any rdx usage in the code you’ve initially posted.

Overclick wrote:

Code:

wm_initdialog:
        jmp fortest
                ERROR_msg db 'test',0
        fortest:
                invoke          MessageBox,HWND_DESKTOP,ERROR_msg,0,MB_OK

        ; this section initialise my progressbars
        lea                             r12,[my_progressbars_tab]
        lea                             r13,[my_progressbars_tab_end]
        @@:
        mov                             r14w,[r12]
        invoke                  GetDlgItem,[hWnd],r14w
        mov                             [r12+2],rax
        invoke                  SendMessage,rax,PBM_SETRANGE,0,0x00650000
        add                             r12,12
        cmp                             r12,r13
        jl                              @B      
...

You’re not expected to get much help by making people guess from irrelevant code pieces.

27 Aug 2020, 16:44

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 27 Aug 2020, 17:09

Ok, searched on debugger.
invoke sends second argument of GetDlgItem to dx. High bytes not clear. Then GetDlgItem using it as edx.

Solution1: Fix fastcall macro to clear high bytes of used registers to prevent similar situations.
Solution2: Use GetDlgItem with dword value even if it uses 16 bit IDs.

Already fixed fastcall, all four registers Wink

27 Aug 2020, 17:09

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20423
Location: In your JS exploiting you and your system

revolution 28 Aug 2020, 04:11

It isn't a fault of fastcall, and it didn't need "fixing".

RDX is not on the preserved register list, so it can be absolutely anything after an API call returns.

28 Aug 2020, 04:11

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 28 Aug 2020, 10:41

It is about calling process. in 64bit mode it uses rcx,rdx,r8,r9 registers and its lower parts to send parameters. Sometimes it is difficult to get the correct size of the operands even if it works at first look. mov LowRegister,Param is covered process and I want to be sure it doesn't pass something wrong in High part of registers. Any way I don't need to hold something in this registers if it corrupted in Lower part so why not to fix it?..

Code:

...
        else if size@param = 2
         if ~ param eq cx
          xor rcx,rcx
          mov cx,param
         end if
        else if size@param = 1
         if ~ param eq cl
          xor rcx,rcx
          mov cl,param
         end if
        end if
...

28 Aug 2020, 10:41

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20423
Location: In your JS exploiting you and your system

revolution 28 Aug 2020, 11:12

You didn't show that code so we could not guess as to your problem. You shouldn't need to use any override inside invoke unless you absolutely know what you are doing.

Code:

invoke GetDlgItem, [hwnd], some_constant ; <--- don't use word, or byte override here

Last edited by revolution on 28 Aug 2020, 12:49; edited 1 time in total

28 Aug 2020, 11:12

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 28 Aug 2020, 12:05

I did, you are not attentive.

Quote:

invoke GetDlgItem,[hWnd],r14w

I was sending 16bit ID operand as it is (r14w), where it need to be 32bit for that function. It's not really clear in Microsoft docs about that. stdcall passed rubbish in high edx bytes. It fixed now. I'm ok with that.

28 Aug 2020, 12:05

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20423
Location: In your JS exploiting you and your system

revolution 28 Aug 2020, 12:22

Okay, yes I missed that.

But all fastcall parameters are 64-bit without exception. So there won't be any separate documentation about it in each function. Normally you just use r14 without any w or b suffix. So if you have 16-bit IDs, or whatever, put them into a 64-bit register.

Code:

mov r14,MY_ID

Last edited by revolution on 28 Aug 2020, 12:49; edited 2 times in total

28 Aug 2020, 12:22

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 28 Aug 2020, 12:37

It is difficult to use 64bit registers all the time when function need less even if it possible by agreement. Real used size of operands is in Microsoft docs even if not really clear as I said. stdcall parameters calculating size of operands automatically cause it's designed not for winapi only. That pease of code form stdcall demonstrate it. I added xor only to be calm.

28 Aug 2020, 12:37

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 28 Aug 2020, 13:12

This page might help you translate the WinAPI from the Microsoft docs:
https://docs.microsoft.com/en-us/cpp/build/x64-software-conventions?view=vs-2019

The C data type int is indeed 32-bit, in the current definition.

With regard to everything being 64-bit -- that is not true. The type ATOM as an example is a WORD, and the WinAPI only examines 16-bits of passed ATOMs. The macros for stdcall in fasm are correct, afaik.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

28 Aug 2020, 13:12

Furs

Joined: 04 Mar 2016
Posts: 2544

Furs 28 Aug 2020, 15:28

revolution wrote:

Okay, yes I missed that.

But all fastcall parameters are 64-bit without exception. So there won't be any separate documentation about it in each function. Normally you just use r14 without any w or b suffix. So if you have 16-bit IDs, or whatever, put them into a 64-bit register.
Code:
mov r14,MY_ID    

It should ignore it. Sounds like either a Windows bug, or documentation bug.

Their dumb ABI states:

MSDN wrote:

Integer valued arguments in the leftmost four positions are passed in left-to-right order in RCX, RDX, R8, and R9, respectively. The fifth and higher arguments are passed on the stack as previously described. All integer arguments in registers are right-justified, so the callee can ignore the upper bits of the register and access only the portion of the register necessary.

28 Aug 2020, 15:28

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 28 Aug 2020, 16:36

Furs, what is wrong with the ABI statement? It is correct. Do you have a counter-example?

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

28 Aug 2020, 16:36

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 28 Aug 2020, 17:31

bitRAKE, How High level compilators works with it if Button'sID comes from wParam as 16bit and in next step GetDlgItem takes it as 32bit? Or they convert everything to 64? Why don't they send it as it is by ignoring upper bits as ABI says? Furs is right, otherwise they will get the same situation as me. Or they can ignore up from dword only? But integer came from previous era as 16 bit value, no matter how they use it this moment to prevent create new name around ton of papers.

28 Aug 2020, 17:31

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 28 Aug 2020, 17:57

Ah, so you think the producers and consumers should use the same type?

It's just one instruction in this case and most others:

movzx edx, r8w ; convert ID to type int

It's possible that the API is layered in such a way that values using the upper 16-bits have a different meaning. We see this in other areas and I am assuming here (most certainly could be wrong). Therefore, the ABI does ignore the upper bits, but we are talking about the upper bits of a int (dword) in a 64-bit register.

Producer and consumer relationships are not 1:1, but many to many. Therefore, we need to be observant of types on both sides.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

28 Aug 2020, 17:57

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 28 Aug 2020, 21:04

Then why stdcall macro doesn't looks like this?

Code:

...
if size@param  < 4
   movzx  rcx,param      ;or even movsx
else if size@param = 4
   movzxd  rcx,param
else
   if ~param eq rcx
      mov   rcx,param  
   end if
end if
...

This code is shorter good idea Very Happy

28 Aug 2020, 21:04

bitRAKE

Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri

bitRAKE 28 Aug 2020, 21:38

movzx rdx,dword param; is implicit in the mov edx,dword param instruction.
movzx rdx,word param; is implicit in the movzx edx,word param instruction.
movzx rdx,byte param; is implicit in the movzx edx,byte param instruction.
etc.

Tomasz wanted to leave something for others' to work on? I don't know exactly - I use my own system of macros. Rolling Eyes

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

28 Aug 2020, 21:38

Goto page 1, 2 Next

< 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