Edit control messages through Comctl32 v6 module

André Hentschel nerv at dawncrow.de
Tue Dec 15 06:41:45 CST 2009


Nikolay Sivov schrieb:
> 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).

of course that would only be a problem if they both export the same class with their manifest, maybe that will lead to a loader error.

> 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.

can you zip me a bundle of your sources and binaries please?
You made a great step with this. congratulations!

-- 

Best Regards, André Hentschel



More information about the wine-devel mailing list