Edit control messages through Comctl32 v6 module

[Nikolay Sivov]

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?

P.S. If somebody wants a bunch of dull sources to build this testcase 
let me know.