Чем отличаются SendMessageA и SendMessageW и др. подобные?

[arthur2]

И есть ли вообще какая-нибудь разница?
Они ведь не занимаются обработкой строк, а только рассылают сообщения? И любое окно - хоть уникодное, хоть неуникодное - принимает сообщения от SendMessageA. И если при этом в сообщении передаётся указатель на уникодную строку, строка тоже нормально прочитывается.

В общем - есть ли смысл менять А на W, или в данном случае можно оставить как было

[alibek]

SendMessage передает не только dword-значения.
Он может передавать и указатель. В том числе и на структуру. В том числе и со строками.

[arthur2]

В том-то и дело, что

И если при этом в сообщении передаётся указатель на уникодную строку, строка тоже нормально прочитывается.

[Хакер]

Функции умные.

[Twister]

SendMessage передает не только dword-значения.
Он может передавать и указатель.

А указатель не DWORD?

Функции умные.

Хех.
Вообще, когда возникают такие вопросы, я бы рекомендовал лезть в IDA - там написано много такого, чего нет в документации. В частности там можно прочитать, что экспортируемый A-вариант в конце концов вызовет неэкспортируемый W-вариант.

[arthur2]

В общем, на сколько я понял, в данном случае, поровну, и можно оставить А-вариант Я правильно понял?

[alibek]

А указатель не DWORD?

Акцент был не на "dword", а на "значения".

[Antonariy]

И любое окно - хоть уникодное, хоть неуникодное

Может я чего-то не догоняю, но как окно может быть или не быть уникодным? Это же окно, а не текст.

[jangle]

И есть ли вообще какая-нибудь разница?

Да разница есть

Они ведь не занимаются обработкой строк, а только рассылают сообщения?

WM_SETTEXT в TextEdit, когда посылаешь в текстовое поле UNICODE строку, используй SendMessageW, в противном случае в текстовом поле отобразятся вопросительные знаки.

[arthur2]

Может я чего-то не догоняю, но как окно может быть или не быть уникодным? Это же окно, а не текст.

Если создать окно с помощью CreateWindowExA (тот же Edit, например), то такое окно не будет понимать уникода. Это я и имел ввиду

jangleДа, ты оказался прав
Хотя уникодный заголовок для диалога открытия файлов у меня отлично передала и обычная SendMessageA (откуда, собственно, вопрос и возник), но по WM_SETTEXT, действительно, А-версия передать уникодный текст не смогла.

Интересно, а почему? Мне казалось, что эта функция просто передаёт значения в оконную процедуру, а окно уже само решает, что с ними делать... выходит, всё не так просто?

[Twister]

Если создать окно с помощью CreateWindowExA (тот же Edit, например), то такое окно не будет понимать уникода

Товарищи, вы заблудились в трех соснах. Простая логика подсказывает, что раз из ядра для создания окон на нас смотрит всего один сервис (NtUserCreateWindowEx), то и окна будут создаваться все одинаковые с точки зрения наличия юникода. Я же говорю, есть вопрос - загляни в IDA. Я заглянул и вот что там увидел:

Это код CreateWindowExA

Код: Выделить всё

.text:77D1E18A                 mov     edi, edi
.text:77D1E18C                 push    ebp
.text:77D1E18D                 mov     ebp, esp
.text:77D1E18F                 push    40000001h       ; int
.text:77D1E194                 push    [ebp+lpParam]   ; int
.text:77D1E197                 push    [ebp+hInstance] ; int
.text:77D1E19A                 push    [ebp+hMenu]     ; int
.text:77D1E19D                 push    [ebp+hWndParent] ; int
.text:77D1E1A0                 push    [ebp+nHeight]   ; int
.text:77D1E1A3                 push    [ebp+nWidth]    ; int
.text:77D1E1A6                 push    [ebp+Y]         ; int
.text:77D1E1A9                 push    [ebp+X]         ; int
.text:77D1E1AC                 push    [ebp+dwStyle]   ; int
.text:77D1E1AF                 push    [ebp+lpWindowName] ; int
.text:77D1E1B2                 push    [ebp+lpClassName] ; hMenu
.text:77D1E1B5                 push    [ebp+dwExStyle] ; int
.text:77D1E1B8                 call    __CreateWindowEx@52 ; _CreateWindowEx(x,x,x,x,x,x,x,x,x,x,x,x,x)
.text:77D1E1BD                 pop     ebp
.text:77D1E1BE                 retn    30h

А это CreateWindowExW

Код: Выделить всё

.text:77D20E51                 mov     edi, edi
.text:77D20E53                 push    ebp
.text:77D20E54                 mov     ebp, esp
.text:77D20E56                 push    40000000h       ; int
.text:77D20E5B                 push    [ebp+lpParam]   ; int
.text:77D20E5E                 push    [ebp+hInstance] ; int
.text:77D20E61                 push    [ebp+hMenu]     ; int
.text:77D20E64                 push    [ebp+hWndParent] ; int
.text:77D20E67                 push    [ebp+nHeight]   ; int
.text:77D20E6A                 push    [ebp+nWidth]    ; int
.text:77D20E6D                 push    [ebp+Y]         ; int
.text:77D20E70                 push    [ebp+X]         ; int
.text:77D20E73                 push    [ebp+dwStyle]   ; int
.text:77D20E76                 push    [ebp+lpWindowName] ; int
.text:77D20E79                 push    [ebp+lpClassName] ; hMenu
.text:77D20E7C                 push    [ebp+dwExStyle] ; int
.text:77D20E7F                 call    __CreateWindowEx@52 ; _CreateWindowEx(x,x,x,x,x,x,x,x,x,x,x,x,x)
.text:77D20E84                 pop     ebp
.text:77D20E85                 retn    30h

Как говорится, найдите 10 отличий А отличие всего одно - это флаги , передающиеся во внутреннюю _CreateWindowEx(). Я предположил, что единичка в младшем слове говорит о том, что работа сейчас идет с ANSI-строкой заголовка и её нужно будет преобразовать к юникоду. Проверим предположение, заглянем внутрь _CreateWindowEx():

Код: Выделить всё

.text:77D20DC9                 mov     ebx, [ebp+arg_30] <-- Флаги ложатся в ebx
.text:77D20DCC                 and     [ebp+arg_8], 0
.text:77D20DD0                 test    bl, 1 <-- Проверяется младшее слово
.text:77D20DD3                 jnz     loc_77D1E1C1

Если флаги говорят об использовании ANSI-строки, то управление передается по адресу 77D1E1C1. Что там у нас?

Код: Выделить всё

.text:77D1E1C1 loc_77D1E1C1:                           ; CODE XREF: _CreateWindowEx(x,x,x,x,x,x,x,x,x,x,x,x,x)+62j
.text:77D1E1C1                 or      [ebp+arg_0], 80000000h
.text:77D1E1C8                 test    edi, 0FFFF0000h
.text:77D1E1CE                 jz      short loc_77D1E1DF
.text:77D1E1D0                 push    1
.text:77D1E1D2                 push    edi
.text:77D1E1D3                 lea     eax, [ebp+var_28]
.text:77D1E1D6                 push    eax
.text:77D1E1D7                 call    _RtlCaptureLargeAnsiString@12 ; RtlCaptureLargeAnsiString(x,x,x)
.text:77D1E1DC                 mov     edi, [ebp+var_1C]
.text:77D1E1DF
.text:77D1E1DF loc_77D1E1DF:                           ; CODE XREF: _CreateWindowEx(x,x,x,x,x,x,x,x,x,x,x,x,x)-2BA3j
.text:77D1E1DF                 test    esi, esi
.text:77D1E1E1                 jz      loc_77D20DF8
.text:77D1E1E7                 cmp     byte ptr [esi], 0FFh
.text:77D1E1EA                 jz      loc_77D54314
.text:77D1E1F0                 push    0FFFFFFFFh
.text:77D1E1F2                 push    esi
.text:77D1E1F3                 lea     eax, [ebp+var_14]
.text:77D1E1F6                 push    eax
.text:77D1E1F7                 call    _RtlInitLargeAnsiString@12 ; RtlInitLargeAnsiString(x,x,x)
.text:77D1E1FC                 jmp     loc_77D20E88

Хоть функции, что мы видим, и недокументированы, но по их названиям и этому коду можно понять, что тут происходит преобразование ANSI-строки в UNICODE. Т.е. мы приходим к выводу, что разница в W и A вариантах этих функций практически отсутствует и заключается лишь в дополнительном преобразовании строк.

А теперь домашнее задание: опровергните слова jangle и докажите аналогичным методом, что A и W вариант функции SendMessage ведут себя абсолютно одинаково.

ЗЫ.:

Хотя уникодный заголовок для диалога открытия файлов у меня отлично передала и обычная SendMessageA (откуда, собственно, вопрос и возник), но по WM_SETTEXT, действительно, А-версия передать уникодный текст не смогла.

Почему текст не установился с помощью WM_SETTEXT сказать не могу, кода не видел. Но вот то, что A-вариант прекрасно передает и юникодные строки - правда чистой воды, ибо SendMessage вообще не знает что она передает, указатель на строку или просто число. Все зависит только от приемщика сообщения!!!

[SLIM]

Нехило....поработал как говорится ))

[jangle]

Интересно, а почему? Мне казалось, что эта функция просто передаёт значения в оконную процедуру, а окно уже само решает, что с ними делать... выходит, всё не так просто?

Ответ же очевиден. UNICODE строка содержит большее количество байтов.

[jangle]

А теперь домашнее задание: опровергните слова jangle и докажите аналогичным методом, что A и W вариант функции SendMessage ведут себя абсолютно одинаково.

Домашнее задание сделал. И доказал, что A и W вариант функции SendMessage ведут себя по разному. Самые лучшие доказательства - факты!
В этом исходнике, стока "Привет мир!" переводится в UNICODE, а потом копируется в верхний текстбокс функцией SendMessageA а в нижний текстбокс функцией SendMessageW.

Код: Выделить всё

#Compile Exe
#Dim All
#Include "WIN32API.INC"
Declare Function SendMessageA Lib "USER32.DLL" Alias "SendMessageA" (ByVal hWnd As Dword, ByVal dwMsg As Dword, ByVal wParam As Dword, ByVal lParam As Long) As Long
Declare Function SendMessageW Lib "USER32.DLL" Alias "SendMessageW" (ByVal hWnd As Dword, ByVal dwMsg As Dword, ByVal wParam As Dword, ByVal lParam As Long) As Long
%IDD_DIALOG1  =  101
%IDC_TEXTBOX1 = 1001
%IDC_TEXTBOX2 = 1002

Function PBMain()
    Local hDlg  As Dword
    Local hTxt1 As Dword
    Local hTxt2 As Dword
    Local stroka As String

    Dialog New 0, "Тестирование функции SendMessage", 215, 156, 201, 121, %WS_Popup Or _
        %WS_Border Or %WS_DlgFrame Or %WS_Caption Or %WS_SysMenu Or _
        %WS_ClipSiblings Or %WS_Visible Or %DS_ModalFrame Or %DS_3DLook Or _
        %DS_NoFailCreate Or %DS_SetFont, %WS_Ex_ControlParent Or %WS_Ex_Left _
        Or %WS_Ex_LtrReading Or %WS_Ex_RightScrollbar, To hDlg
    Control Add TextBox, hDlg, %IDC_TEXTBOX1, "", 33, 21, 114, 18
    Control Add TextBox, hDlg, %IDC_TEXTBOX2, "", 33, 54, 117, 18
    Control Handle hDlg,%IDC_TEXTBOX1 To hTxt1
    Control Handle hDlg,%IDC_TEXTBOX2 To hTxt2
   

    stroka=UCode$("Привет мир!") 'Преобразуем строку в UNICODE
   
    SendMessageA  hTxt1, %WM_SETTEXT, 0,   StrPtr(stroka)
    SendMessageW  hTxt2, %WM_SETTEXT, 0,   StrPtr(stroka)

    Dialog Show Modal hDlg
End Function

В итоге получаем такой результат.

Почему текст не установился с помощью WM_SETTEXT сказать не могу, кода не видел. Но вот то, что A-вариант прекрасно передает и юникодные строки - правда чистой воды, ибо SendMessage вообще не знает что она передает, указатель на строку или просто число. Все зависит только от приемщика сообщения!!!

А вот эта неправда. ANSI-вариант SendMessage не передает UNICODE строки, что и было показано выше. И от приемника сообщений тут ничего не зависит. По итогам домашнего задания Twister получает двойку?

P.S. В аттаче исходник и скомпилированный exe примера.

[arthur2]

ибо SendMessage вообще не знает что она передает, указатель на строку или просто число. Все зависит только от приемщика сообщения!!!

Вот и я так думал:

Мне казалось, что эта функция просто передаёт значения в оконную процедуру, а окно уже само решает, что с ними делат

Код: Выделить всё

Option Explicit
Private Declare Function CreateWindowExW Lib "user32" (ByVal dwExStyle As Long, ByVal lpClassName As Long, ByVal lpWindowName As Long, ByVal dwStyle As Long, ByVal x As Long, ByVal y As Long, ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As Long, ByVal hMenu As Long, ByVal hInstance As Long, lpParam As Any) As Long
Private Const WS_VISIBLE = &H10000000
Private Const WS_CHILD = &H40000000
Private Const WS_BORDER = &H800000

Private Declare Function SendMessageW Lib "user32" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Private Declare Function SendMessageA Lib "user32" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Dim hwndEdit As Long
Dim HeloWorld As String

Private Sub Form_Load()
hwndEdit = CreateWindowExW(0, StrPtr("Edit"), StrPtr(""), WS_BORDER Or WS_CHILD Or WS_VISIBLE Or &H4&, 10, 10, 150, 50, Me.hwnd, 0, App.hInstance, 0)
HeloWorld = "Привет, мир!"
End Sub

Private Sub cmANSI_Click()
SendMessageA hwndEdit, WM_SETTEXT, 0&, ByVal StrPtr(HeloWorld)
End Sub

Private Sub cmUnicode_Click()
SendMessageW hwndEdit, WM_SETTEXT, 0&, ByVal StrPtr(HeloWorld)
End Sub


[Twister]

Да, чёрт возьми! Тут я лохонулся и jangle прав. Сам же советовал заглянуть в IDA и сам же не заглянул

Вот кусок кода SendMessageA:

Код: Выделить всё

.text:77D1CC62                 push    1               ; int
.text:77D1CC64                 push    [ebp+hMem]      ; hMem
.text:77D1CC67                 push    dword ptr [ebp+WideCharStr] ; WideCharStr
.text:77D1CC6A                 push    esi             ; int
.text:77D1CC6B                 push    eax             ; int
.text:77D1CC6C                 call    _SendMessageWorker@20 ; SendMessageWorker(x,x,x,x,x)

А вот SendMessageW:

Код: Выделить всё

.text:77D27686                 push    0               ; int
.text:77D27688                 push    [ebp+hMem]      ; hMem
.text:77D2768B                 push    dword ptr [ebp+WideCharStr] ; WideCharStr
.text:77D2768E                 push    esi             ; int
.text:77D2768F                 push    eax             ; int
.text:77D27690                 call    _SendMessageWorker@20 ; SendMessageWorker(x,x,x,x,x)

Опять видим все тот же флаг, который говорит внутренним функциям о том, что работа идет с ANSI-строками. И дальше по коду (не буду приводить асм-листинг, слишком много и неинтересно) наблюдаем проверки строк на юникодность и вызов RtlMBMessageWParamCharToWCS(), либо RtlWCSMessageWParamCharToMB(). Т.е. преобразование идет не только в юникод, но и обратно, в том случае еслы вызван A-вариант со входной unicode-строкой.

Так что сорри если кого-то на время дезинформировал. Но зато хоть с окнами внес ясность

[arthur2]

А как она узнаёт, указатель на строку ей передан, или просто число? Она по-разному обрабатывает значения в зависимости от сообщения? То есть, для определённых сообщений типа WM_SETTEXT данные обрабатываются, а для остальных - числа передаются как есть? Так что ли?

И вопрос вдогонку: раз окна не бывают W и A, может тогда есть способ заставить стандартный бейсиковский эдит работать с уникодом?

[Twister]

Она по-разному обрабатывает значения в зависимости от сообщения?

Да, примерно так. Правда мне так и не удалось додебажить до этого места - вызов SendMessageA с ANSI-строкой ушел в ядро вот в этом месте, до этого не произведя никаких преобразований:

Код: Выделить всё

.text:77D22CE5                                         ; SendMessageWorker(x,x,x,x,x)+40j ...
.text:77D22CE5                 push    [ebp+bAnsi]     ; int
.text:77D22CE8                 push    2B1h            ; int
.text:77D22CED                 push    0               ; int
.text:77D22CEF                 push    [ebp+hMem]      ; int
.text:77D22CF2                 push    dword ptr [ebp+WideCharStr] ; WideCharStr
.text:77D22CF5                 push    esi             ; int
.text:77D22CF6                 push    [ebp+var_8]     ; int
.text:77D22CF9                 cmp     esi, 400h
.text:77D22CFF                 jnb     short loc_77D22D17
.text:77D22D01                 movzx   eax, ds:_MessageTable[esi]
.text:77D22D08                 and     eax, 3Fh
.text:77D22D0B                 call    ds:_gapfnScSendMessage[eax*4] ; NtUserMessageCall(x,x,x,x,x,x,x)

Дальше мне уже дебажить влом, надо дела делать

Кстати, по поводу моих слов:

Т.е. преобразование идет не только в юникод, но и обратно, в том случае еслы вызван A-вариант со входной unicode-строкой.

Мне так и не удалось попасть на этот код, не могу сказать в каких случаях он отрабатыват. Да и при вызове W-варианта с ANSI-строкой никакого преобразования я не увидел, голимые иероглифы. Так что тут бабушка надвое сказала, возможно из юзермода в ядро и обратно просто путешествует параметр, который я позволил себе назвать bAnsi, и никаких преобразований не происходит. В таком случае где-то я был прав, говоря что все зависит от приемщика сообщения. Конкретно - от оконной процедуры.

раз окна не бывают W и A, может тогда есть способ заставить стандартный бейсиковский эдит работать с уникодом?

Ну тут нужно внести ясность. Заголовок окна и текст в нем это абсолютно разные вещи. Я говорил про заголовок, он может быть только UNICODE, это можно посмотреть в самой оконной структуре tagWND. А вот текст в окне... Обычный TextBox и ReachEdit, к примеру, имеют абсолютно разные механизмы обработки такого текста, один не завистит от другого. А бейсиковский TextBox - это, скорее всего, обертка над стандартным виндовым классом, хотя возможно в нем есть какие-то свои навороты. Поэтому почему он не поддерживает юникод я сказать не могу, тут надо звать Хакера, он хорошо знает внутренности бэйсика, а я на нем уже сто лет не пишу и не ковыряюсь в нем.

[Хакер]

Поэтому почему он не поддерживает юникод я сказать не могу, тут надо звать Хакера, он хорошо знает внутренности бэйсика, а я на нем уже сто лет не пишу и не ковыряюсь в нем.

Он не поддерживает юникод потому, что устроен так, как если бы система не поддерживала юникод вообще. Всё юникодное на входе он конвертирует в текущую локаль ANSI и с помощью A-вариантов функций и сообщений помещает этот текст в EDIT.

[Twister]

Всё юникодное на входе он конвертирует в текущую локаль ANSI и с помощью A-вариантов функций и сообщений помещает этот текст в EDIT.

А как же он тогда обрабатывает SendMessage? Что-то мне подсказывает, что никак

[Хакер]

Как кто обрабатывает SendMessage?

[Хакер]

Проверил, на всякий случай (а то неблагоприятная неделя: гуру делают ошибки), всё так и есть.

Научить встроенный TextBox понимать юникод ( = вырезать WideCharToMultiByte, заменить вызов SetWindowTextA на SetWindowTextW) будет сложнее, чем написать свою обёртку над стандартным EDIT-ом.

З.Ы. Twister, фича в OllyDbg, которая рисует стрелочки, это базовая фича или плагиновая? Если базовая, нигде не могу найти её «включатель».

[Twister]

сложнее, чем написать свою обёртку над стандартным EDIT-ом

Мы, кажись, друг-друга не поняли. Понятно, что по Text1.Text = "unicode_string" произойдет преобразование в ANSI, я спрашивал какой механизм может запретить использовать такую конструкцию: SendMessageW(Text1.hWnd, WM_SETTEXT, 0, lpUnicodeStringPointer) ?

Twister, фича в OllyDbg, которая рисует стрелочки, это базовая фича или плагиновая?

Неделя, и правда, мозговыносная получилась. Никак не могу понять о каких стрелочках речь. Если о тех, которые рисуются слева и кажут вверх или вниз, когда ты стоишь на инструкции перехода, то эта фича, вроде, включена по умолчанию. Если ты о каких-то стрелочках из приведенных мной листингов, то это IDA и стрелочки нарисованы мной.
Но так или иначе - "стандартую" Ольку с сайта производителя я никогда не юзал, всю жизнь пользовался вот этой сборкой с кряклаба, как-то она более дружественно выглядит. Может стрелочки только в ней?
Кстати, эта сборка Ольки без плясок с бубном никак не хочет "кушать" pdb. Приходится ставить WinDbg, копировать с заменой все dll'ки из его bin-директории в папку с Олькой, ложить pdb в папку с отлаживаемой прогой/библиотекой и только после этого можно лицезреть символы в отладчике. Со стандартным комплектом тоже все так запущено?

[Хакер]

Мы, кажись, друг-друга не поняли. Понятно, что по Text1.Text = "unicode_string" произойдет преобразование в ANSI, я спрашивал какой механизм может запретить использовать такую конструкцию: SendMessageW(Text1.hWnd, WM_SETTEXT, 0, lpUnicodeStringPointer) ?

Ну, вообще, в оригинале используется SetWindowText, так что возможно (хоть и маловероятно), что окно не обрабатывает WM_TEXT. Какие косяки могут быть: сложно сказать. Однако строка конвертируется в ANSI не перед самым засовываем в EDIT, а наоборот в самом налаче (а потом ещё по 4—5 функциям блуждает в ANSI-виде). Да и толку от такого TB, если всё придётся руками делать. Уж точно проще свой написать.

Никак не могу понять о каких стрелочках речь. Если о тех, которые рисуются слева и кажут вверх или вниз, когда ты стоишь на инструкции перехода, то эта фича, вроде, включена по умолчанию. Если ты о каких-то стрелочках из приведенных мной листингов, то это IDA и стрелочки нарисованы мной.

Нет, иду я терпеть не могу, её мерзкий интерфейс вызывает головную боль у меня. Конечно я об OllyDbg и стрелках, визуализирующих переходы. Оригинальную олли убил касперский: я из старого же архива достал её же, но стрелок нет. И настройка на находится. Сделал вывод что стрелки присуще вовсе не оригиналу, а являются результатом добавления какого-то мода. Командную строку, кстати, надо тоже вернуть, а то жутко неудобно.

Добавлено:
Нашёл всё-таки опцию. Вкладка «CPU» параметр «Show jump pathes».

[Twister]

Нет, иду я терпеть не могу, её мерзкий интерфейс вызывает головную боль у меня

Согласен, но при суровом реверсинге без нее никак, Олька не спасет. Особенно рекомендую заценить мощь плагинчика HexRays