SendMessageW doubt/bug with ANSI LPARAM.

[victor martinez]

> The Total Commander comboboxes for the left and right drive list
> are Unicode. However, Total Commander calls
> SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> to add items as ANSI text. This seems to work, but it's adding some
> extra text at the end.

If I understand correctly, Total Commander is calling SendMessage, which in
this case is translated to SendMessageW (as the comboboxes are Unicode).

So TC is calling SendMessageW to append an ANSI string to a Combobox.
Let's give a look to SendMessageW  implementation thanks to Doxygen:
http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88d...

02161   Result = NtUserMessageCall( Wnd,
02162                               KMMsg.message, 
02163                               KMMsg.wParam,
02164                               KMMsg.lParam,
02165                              (ULONG_PTR)&Result,
02166                               FNID_SENDMESSAGE,
02167                               FALSE);

Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall.

But in this case the BOOL ANSI should be TRUE as the string is really ANSI.
So since this moment we are treating TC call ( SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); )
in the same way as we would be treating SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext);
This seems a bug for me.

Feel free to correct me, but seems that SendMessageW is able to set both kind
of strings ANSI and UNICODE in Windows, while we are forcing to our
SendMessageW implementation to treat them as UNICODE always.
Am I wrong? 
This could be a big potential issue as this could affect to all the SendmessageW calls.

This is all just a guess, so please feed me with your knowledge.
Thanks a lot!

Write a testcase.

Regards

On Wednesday, November 16, 2011 3:12 PM, "victor martinez" [e-mail] wrote:
> > The Total Commander comboboxes for the left and right drive list
> > are Unicode. However, Total Commander calls
> > SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> > to add items as ANSI text. This seems to work, but it's adding some
> > extra text at the end.
>
> If I understand correctly, Total Commander is calling SendMessage, which
> in
> this case is translated to SendMessageW (as the comboboxes are Unicode).
>
> So TC is calling SendMessageW to append an ANSI string to a Combobox.
> Let's give a look to SendMessageW  implementation thanks to Doxygen:
> http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88d...
>
> 02161   Result = NtUserMessageCall( Wnd,
> 02162                               KMMsg.message, 
> 02163                               KMMsg.wParam,
> 02164                               KMMsg.lParam,
> 02165                              (ULONG_PTR)&Result,
> 02166                               FNID_SENDMESSAGE,
> 02167                               FALSE);
>
> Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall.
>
> But in this case the BOOL ANSI should be TRUE as the string is really
> ANSI.
> So since this moment we are treating TC call (
> SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); )
> in the same way as we would be treating
> SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext);
> This seems a bug for me.
>
> Feel free to correct me, but seems that SendMessageW is able to set both
> kind
> of strings ANSI and UNICODE in Windows, while we are forcing to our
> SendMessageW implementation to treat them as UNICODE always.
> Am I wrong? 
> This could be a big potential issue as this could affect to all the
> SendmessageW calls.
>
> This is all just a guess, so please feed me with your knowledge.
> Thanks a lot!
>  	   		  
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
With best regards
Caemyr

[Timo Kreuzer]

Am 16.11.2011 16:12, schrieb victor martinez:
> > The Total Commander comboboxes for the left and right drive list
> > are Unicode. However, Total Commander calls
> > SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> > to add items as ANSI text. This seems to work, but it's adding some
> > extra text at the end.
>
> If I understand correctly, Total Commander is calling SendMessage, which in
> this case is translated to SendMessageW (as the comboboxes are Unicode).

No, the fact that the combo boxes are unicode, doesn't mean TC is 
calling SendMessageW, It could very well call SendMessageA and pass an 
ansi string.
If it passes an ANSI string to SendMessageW then it's doing it wrong.
The message is supposed to be translated accordingly when it's passed to 
the recevier, based on whether the receiving window is ANSI or unicode.

The problem also doesn't seem to be ANSI vs unicode, but the "extra text 
at the end".
First thought: someone forgot that UNICODE_STRINGs are not neccessarily 
0 terminated.

Timo

[victor martinez]

Thanks Timo for your explanation.
So let me see if I understood correctly.
When TC calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); it could be translated to SendMessageW or to SendMessageA accordingly to the window(*) that receives the message:
-If the receiving window is ANSI the SendMessage is translated to SendMessageA and the Lparam is converted to ANSI(in this case there isn't needed any translation as it was originally ANSI).
-If the receiving window is UNICODE the SendMessage is translated to SendMessageW and the Lparam is converted(**),in this case, from ANSI to UNICODE, so SendMessageW is receiving an UNICODE string instead the original ANSI one.
Feel free to correct me if I am wrong.
My doubts are:
(*)When talking about the receiving "Window"...Which Window are we talking about in this particular case?Isn't the SendMessage supposed to be sent to the ComboBox window?
(**)If I understood correctly, the LParam originally ANSI is translated to UNICODE before being sent to the SendMessageW. Which function/macro does this translation?Just curious...
So the problem maybe is in the **p*rintf function that prints the line in the Combobox?

Thanks again for your time
Víctor

Date: Wed, 16 Nov 2011 21:14:07 +0100
From: [e-mail]
To: [e-mail]
Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.

Am 16.11.2011 16:12, schrieb victor martinez:

>The Total Commander comboboxes for the left and right drive list
> are Unicode. However, Total Commander calls
> SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> to add items as ANSI text. This seems to work, but it's adding some
> extra text at the end.

If I understand correctly, Total Commander is calling SendMessage, which in
this case is translated to SendMessageW (as the comboboxes are Unicode).

No, the fact that the combo boxes are unicode, doesn't mean TC is
    calling SendMessageW, It could very well call SendMessageA and pass
    an ansi string.

If it passes an ANSI string to SendMessageW then it's doing it
    wrong.

The message is supposed to be translated accordingly when it's
    passed to the recevier, based on whether the receiving window is
    ANSI or unicode.

The problem also doesn't seem to be ANSI vs unicode, but the "extra text at the end".

First thought: someone forgot that UNICODE_STRINGs are not
      neccessarily 0 terminated.

Timo

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev

[Giannis Adamopoulos]

Hi,
this is still not correct. SendMessage is not a function but a macro. When the PROGRAM is compiled as unicode SendMessage is translated to SendMessageW and otherwise it is translated to SendMessageA.
Now regarding the convertion fron ansi to unicode or unicode to ansi, this is done when win32k calls user32 in the receiving process here: 
http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/wind...
and 
http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/wind...

ReactOS Development List [e-mail] wrote on Thu, November 17th, 2011, 3:09 AM:
> Thanks Timo for your explanation.
> So let me see if I understood correctly.
> When TC calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); it could be translated to SendMessageW or to SendMessageA accordingly to the window(*) that receives the message:
> -If the receiving window is ANSI the SendMessage is translated to SendMessageA and the Lparam is converted to ANSI(in this case there isn't needed any translation as it was originally ANSI).
> -If the receiving window is UNICODE the SendMessage is translated to SendMessageW and the Lparam is converted(**),in this case, from ANSI to UNICODE, so SendMessageW is receiving an UNICODE string instead the original ANSI one.
> Feel free to correct me if I am wrong.
> My doubts are:
> (*)When talking about the receiving "Window"...Which Window are we talking about in this particular case?Isn't the SendMessage supposed to be sent to the ComboBox window?
> (**)If I understood correctly, the LParam originally ANSI is translated to UNICODE before being sent to the SendMessageW. Which function/macro does this translation?Just curious...
> So the problem maybe is in the **p*rintf function that prints the line in the Combobox?
>
> Thanks again for your time
> Víctor
>
> Date: Wed, 16 Nov 2011 21:14:07 +0100
> From: [e-mail]
> To: [e-mail]
> Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.
> Am 16.11.2011 16:12, schrieb victor martinez:
>
>
>
>     >The Total Commander comboboxes for the left and right drive list
> > are Unicode. However, Total Commander calls
> > SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> > to add items as ANSI text. This seems to work, but it's adding some
> > extra text at the end.
>
> If I understand correctly, Total Commander is calling SendMessage, which in
> this case is translated to SendMessageW (as the comboboxes are Unicode).
> No, the fact that the combo boxes are unicode, doesn't mean TC is
> calling SendMessageW, It could very well call SendMessageA and pass
> an ansi string.
>
> If it passes an ANSI string to SendMessageW then it's doing it
> wrong.
>
> The message is supposed to be translated accordingly when it's
> passed to the recevier, based on whether the receiving window is
> ANSI or unicode.
>
>
>
> The problem also doesn't seem to be ANSI vs unicode, but the "extra text at the end".
>
>   First thought: someone forgot that UNICODE_STRINGs are not
>   neccessarily 0 terminated.
>
>
>
>   Timo
>
>
>
>
>
>
>
>
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[victor martinez]

Hi Giannis!So I will check if the MsgiAnsiToUnicodeMessage is being called at all(I've tracked down the code from SendMessageW and SendMessageA and  I didnt find any call to this function,yet), if so, I will check if  507             RtlCreateUnicodeStringFromAsciiz(&UnicodeString, (LPSTR)AnsiMsg->lParam);is behaving correctly just comparing the UnicodeString vs the AnsiLparam one.Thanks a lot!Debugging time!
> From: [e-mail]
> To: [e-mail]
> Date: Thu, 17 Nov 2011 11:53:41 +0100
> Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.
>
> Hi,
> this is still not correct. SendMessage is not a function but a macro. When the PROGRAM is compiled as unicode SendMessage is translated to SendMessageW and otherwise it is translated to SendMessageA.
> Now regarding the convertion fron ansi to unicode or unicode to ansi, this is done when win32k calls user32 in the receiving process here: 
> http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/wind...
> and 
> http://git.reactos.org/?p=reactos.git;a=blob;f=reactos/dll/win32/user32/wind...
>
> ReactOS Development List [e-mail] wrote on Thu, November 17th, 2011, 3:09 AM:
> > Thanks Timo for your explanation.
> > So let me see if I understood correctly.
> > When TC calls SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); it could be translated to SendMessageW or to SendMessageA accordingly to the window(*) that receives the message:
> > -If the receiving window is ANSI the SendMessage is translated to SendMessageA and the Lparam is converted to ANSI(in this case there isn't needed any translation as it was originally ANSI).
> > -If the receiving window is UNICODE the SendMessage is translated to SendMessageW and the Lparam is converted(**),in this case, from ANSI to UNICODE, so SendMessageW is receiving an UNICODE string instead the original ANSI one.
> > Feel free to correct me if I am wrong.
> > My doubts are:
> > (*)When talking about the receiving "Window"...Which Window are we talking about in this particular case?Isn't the SendMessage supposed to be sent to the ComboBox window?
> > (**)If I understood correctly, the LParam originally ANSI is translated to UNICODE before being sent to the SendMessageW. Which function/macro does this translation?Just curious...
> > So the problem maybe is in the **p*rintf function that prints the line in the Combobox?
> >
> > Thanks again for your time
> > Víctor
> >
> > Date: Wed, 16 Nov 2011 21:14:07 +0100
> > From: [e-mail]
> > To: [e-mail]
> > Subject: Re: [ros-dev] SendMessageW doubt/bug with ANSI LPARAM.
> > Am 16.11.2011 16:12, schrieb victor martinez:
> >
> >
> >
> >     >The Total Commander comboboxes for the left and right drive list
> > > are Unicode. However, Total Commander calls
> > > SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext);
> > > to add items as ANSI text. This seems to work, but it's adding some
> > > extra text at the end.
> >
> > If I understand correctly, Total Commander is calling SendMessage, which in
> > this case is translated to SendMessageW (as the comboboxes are Unicode).
> > No, the fact that the combo boxes are unicode, doesn't mean TC is
> > calling SendMessageW, It could very well call SendMessageA and pass
> > an ansi string.
> >
> > If it passes an ANSI string to SendMessageW then it's doing it
> > wrong.
> >
> > The message is supposed to be translated accordingly when it's
> > passed to the recevier, based on whether the receiving window is
> > ANSI or unicode.
> >
> >
> >
> > The problem also doesn't seem to be ANSI vs unicode, but the "extra text at the end".
> >
> >   First thought: someone forgot that UNICODE_STRINGs are not
> >   neccessarily 0 terminated.
> >
> >
> >
> >   Timo
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev