Edit control messages through Comctl32 v6 module

[Roderick Colenbrander]

On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov <bunglehead at gmail.com> wrote:
> On 12/13/2009 15:15, Roderick Colenbrander wrote:
>>>>
>>>> The main test which AJ suggested would be to 'force' native user32 to
>>>> call RegisterClassNameW. There would be a dummy dll containing a
>>>> RegisterClassNameW to which lets say the Button control would be
>>>> redirected using a manifest.
>>>>
>>>
>>> If I got it right you're talking about a dummy dll with compiled in (or
>>> separate doesn't matter) manifest with
>>> 'windowclass' entry (and without to check it's actually used) to Button,
>>> after that we trigger test application reload
>>> and dump this RegisterClassNameW call someway?
>>>
>>>
>>
>> Yeah that's the idea. I'm quite certain that this mechanism is used to
>> register the class. I just searched some more this morning and found
>> stuff I didn't fnd before about subclassing. Read this
>> http://msdn.microsoft.com/en-us/library/bb773183%28VS.85%29.aspx  It
>> talks about four new subclassing related functions which were
>> introduced in XP, so it might mean that the controls are subclassed
>> after all?
>>
>> Roderick
>>
>
> Looks like it's definitely the way it works. Finally I'm able to reproduce
> that. That's what I've done:
> 1) a DLL with a call:
> ---
> BOOL RegisterClassNameW(WCHAR *name)
> {
>   wprintf(L"%s\n", name);
>   return FALSE;
> }
> ---
> 2) an executable with main like that:
> ---
> int _tmain(int argc, _TCHAR* argv[])
> {
>    HWND button;
>
>    button = CreateWindowW(L"Button", NULL, WS_VISIBLE, 0, 0, 10, 10, NULL,
>                           NULL, NULL, NULL);
>    printf("%s, %p\n", "blah", button);
>    DestroyWindow(button);
>
>    return 0;
> }
> ---
> 3) A generated a hash for DLL with mt.exe and updated a DLL manifest with it
> 4) After that embedded a dll manifest to dll module
> 5) Looks like publicKeyToken attribute is necessary for this to work - I
> defaulted it to  publicKeyToken="1111111111111111".
>
> The final output for .exe is:
> ---
> Button
> blah, 00000000
> ---
>
> So as an additional "feature" - user32 doesn't attempt for register default
> classes if a custom RegisterClassNameW() fails.
>
> Now I'm not sure what's next step. It seems that another test is about more
> than 1 dll with exported RegisterClassNameW loaded
> with same application (what dll will be called to register class isn't
> obvious at all).
>
> Another question here is current Wine's actctx support ready for such
> tricks?

Great that you got it working. Regarding actctx, this should work fine
with our manifest support. Not much has to happen at all. Basically in
user32 it needs to be checked whether a window class (lets say the
Button one) is redirected or not. If it is redirected at dll init,
just call RegisterClassNameW.

The only thing I'm still interested in is whether Microsoft really
isn't subclassing the controls as I think Microsoft might have added
those calls because of theming. It would be trivial to call
GetWindowSubclass on a comctl32 v6 button.

Roderick