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