Edit control messages through Comctl32 v6 module
Hi. Yesterday I looked at XP introduced messages for Edit controls (EM_SETCUEBANNER/EM_GETCUEBANNER). This definitely doesn't work without v6 module loaded. Does someone have any idea how this supposed to work? Any comments are welcome as usual. P.S. Yes, I know that comctl32 does subclass user32 control but only if theming is active (I mean Wine behavior), anyway this subclass procedure only cares about painting messages, control specific messages require control data manipulation, and this isn't a preferable of course.
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls (EM_SETCUEBANNER/EM_GETCUEBANNER). This definitely doesn't work without v6 module loaded.
Does someone have any idea how this supposed to work? Any comments are welcome as usual.
P.S. Yes, I know that comctl32 does subclass user32 control but only if theming is active (I mean Wine behavior), anyway this subclass procedure only cares about painting messages, control specific messages require control data manipulation, and this isn't a preferable of course.
From what I understood comctl32 doesn't subclass user32 controls but it has its own implementations. Upon loading user32 calls RegisterClassNameW when a manifest is around to have comctl32 register the classes. Perhaps it is possible to verify this behavior using a test but I really believe no subclassing is performed. Alexandre said that if this is really the case we have to duplicate code at some point.
Roderick
On 12/13/2009 13:08, Roderick Colenbrander wrote:
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov<bunglehead(a)gmail.com> wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls (EM_SETCUEBANNER/EM_GETCUEBANNER). This definitely doesn't work without v6 module loaded.
Does someone have any idea how this supposed to work? Any comments are welcome as usual.
P.S. Yes, I know that comctl32 does subclass user32 control but only if theming is active (I mean Wine behavior), anyway this subclass procedure only cares about painting messages, control specific messages require control data manipulation, and this isn't a preferable of course.
From what I understood comctl32 doesn't subclass user32 controls but it has its own implementations. Upon loading user32 calls RegisterClassNameW when a manifest is around to have comctl32 register the classes. Perhaps it is possible to verify this behavior using a test but I really believe no subclassing is performed. So current theming code doesn't fit and all theme painting should be integrated in 'its own implementation'. This is something new to me, but it's better to start to test it cause we know enough.
Also I'd like to invite Andre to this thread cause it wrote a test for that some months ago. Andre, is it something wrong with tests, why patch wasn't accepted? http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html
Alexandre said that if this is really the case we have to duplicate code at some point.
Ok. Probably I missed that discussion.
Roderick
On Sun, Dec 13, 2009 at 11:48 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 12/13/2009 13:08, Roderick Colenbrander wrote:
On Sun, Dec 13, 2009 at 10:40 AM, Nikolay Sivov<bunglehead(a)gmail.com> wrote:
Hi.
Yesterday I looked at XP introduced messages for Edit controls (EM_SETCUEBANNER/EM_GETCUEBANNER). This definitely doesn't work without v6 module loaded.
Does someone have any idea how this supposed to work? Any comments are welcome as usual.
P.S. Yes, I know that comctl32 does subclass user32 control but only if theming is active (I mean Wine behavior), anyway this subclass procedure only cares about painting messages, control specific messages require control data manipulation, and this isn't a preferable of course.
From what I understood comctl32 doesn't subclass user32 controls but it has its own implementations. Upon loading user32 calls RegisterClassNameW when a manifest is around to have comctl32 register the classes. Perhaps it is possible to verify this behavior using a test but I really believe no subclassing is performed.
So current theming code doesn't fit and all theme painting should be integrated in 'its own implementation'. This is something new to me, but it's better to start to test it cause we know enough.
Also I'd like to invite Andre to this thread cause it wrote a test for that some months ago.
Correct the current theming code is broken like hell and needs to be rewritten. It is possible to write some tests but it will mostly be tests that won't make it into Wine itself. The easy test is just to test whether a control is redirected or not for a specific version of comctl32 v6.x (in newer versions more controls are implemented in comctl32). 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. Myself I didn't have time to look at this but Andre tried to do this but had some issues, so this is not done. Roderick
On 12/13/2009 14:27, Roderick Colenbrander wrote:
Correct the current theming code is broken like hell and needs to be rewritten.
So as I thought.
It is possible to write some tests but it will mostly be tests that won't make it into Wine itself. The easy test is just to test whether a control is redirected or not for a specific version of comctl32 v6.x (in newer versions more controls are implemented in comctl32).
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?
Myself I didn't have time to look at this but Andre tried to do this but had some issues, so this is not done.
Roderick
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
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. Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome. 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?
No, actually this calls are just introduced in v6, that's what this article is about. Maybe controls use it but it doesn't matter now.
Roderick
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov <bunglehead(a)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.
Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome.
In this case Alexandre just wants to know how Windows is doing the stuff. I believe this test doesn't have to be added to Wine.
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?
No, actually this calls are just introduced in v6, that's what this article is about. Maybe controls use it but it doesn't matter now.
I think it would be useful to call GetWindowSubclass on the redirected classes. I think that can prove whether subclassing is used or not. Roderick
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov <bunglehead(a)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. Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome.
In this case Alexandre just wants to know how Windows is doing the stuff. I believe this test doesn't have to be added to Wine.
As i understood the testcase should look like: A programm with manifest which depends on a dll with e.g. a button-class A dll with a manifest that tells it provides a own button-class and a RegisterClassNameW function that maybe only prints out "Yeah, i got called!" That should run on Windows and produce that message. Alexandre told me, that he just wants to see that this test works, but its not necessary to add it to wine. I ran into to some issues where windows needed a signed dll to use a manifest with it. I dont know how to manage that correctly, so i got stuck -- Best Regards, André Hentschel
On 12/14/2009 18:19, André Hentschel wrote:
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov<bunglehead(a)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.
Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome.
In this case Alexandre just wants to know how Windows is doing the stuff. I believe this test doesn't have to be added to Wine.
As i understood the testcase should look like: A programm with manifest which depends on a dll with e.g. a button-class A dll with a manifest that tells it provides a own button-class and a RegisterClassNameW function that maybe only prints out "Yeah, i got called!"
That should run on Windows and produce that message.
Yes, that's exactly what I tried to do yesterday.
Alexandre told me, that he just wants to see that this test works, but its not necessary to add it to wine. I ran into to some issues where windows needed a signed dll to use a manifest with it. I dont know how to manage that correctly, so i got stuck
What you mean saying signed dll? I've stuck too after a first try cause I'm not able to load application at all, a kind of loader error produced, which is related to dependency dll specified with manifest. After a failure I tried to place a dll into a shared manifest directory in WinSxS/Manifests (or something like that). It didn't help. Did you try an embedded manifest for dll or an external xml?
Nikolay Sivov schrieb:
On 12/14/2009 18:19, André Hentschel wrote:
Roderick Colenbrander schrieb:
On Sun, Dec 13, 2009 at 1:46 PM, Nikolay Sivov<bunglehead(a)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.
Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome.
In this case Alexandre just wants to know how Windows is doing the stuff. I believe this test doesn't have to be added to Wine.
As i understood the testcase should look like: A programm with manifest which depends on a dll with e.g. a button-class A dll with a manifest that tells it provides a own button-class and a RegisterClassNameW function that maybe only prints out "Yeah, i got called!"
That should run on Windows and produce that message.
Yes, that's exactly what I tried to do yesterday.
Alexandre told me, that he just wants to see that this test works, but its not necessary to add it to wine. I ran into to some issues where windows needed a signed dll to use a manifest with it. I dont know how to manage that correctly, so i got stuck
What you mean saying signed dll? I've stuck too after a first try cause I'm not able to load application at all, a kind of loader error produced, which is related to dependency dll specified with manifest. After a failure I tried to place a dll into a shared manifest directory in WinSxS/Manifests (or something like that). It didn't help.
Did you try an embedded manifest for dll or an external xml?
Looks like the Problem i ran into, too. I think i got a error-message on the console on winxp. after some internetsearch i read at msdn about it, and they told to use "signed"(whatever) dlls. There are some tools in Visual Studio, i tried but they won't sign my dll... i guess i used http://msdn.microsoft.com/en-us/library/aa375649%28VS.85%29.aspx and i just found that: http://social.msdn.microsoft.com/Forums/de-DE/Vsexpressvcs/thread/4b2c9202-a... i have no access to a win-machine atm with the right environment, so i will concentrate on my ARM-port, but ask me if you have further questions. -- Best Regards, André Hentschel
On 12/14/2009 19:56, André Hentschel wrote:
Nikolay Sivov schrieb:
Alexandre told me, that he just wants to see that this test works, but its not necessary to add it to wine. I ran into to some issues where windows needed a signed dll to use a manifest with it. I dont know how to manage that correctly, so i got stuck
What you mean saying signed dll? I've stuck too after a first try cause I'm not able to load application at all, a kind of loader error produced, which is related to dependency dll specified with manifest. After a failure I tried to place a dll into a shared manifest directory in WinSxS/Manifests (or something like that). It didn't help.
Did you try an embedded manifest for dll or an external xml?
Looks like the Problem i ran into, too. I think i got a error-message on the console on winxp. after some internetsearch i read at msdn about it, and they told to use "signed"(whatever) dlls. There are some tools in Visual Studio, i tried but they won't sign my dll... i guess i used http://msdn.microsoft.com/en-us/library/aa375649%28VS.85%29.aspx and i just found that: http://social.msdn.microsoft.com/Forums/de-DE/Vsexpressvcs/thread/4b2c9202-a...
Oh crap. Didn't know about that. Looks like VS 2003 doesn't provide this miraculous mt.exe tool. I probably should try with some express editions like 2008, what version did you try?
On 12/13/2009 01:46 PM, Nikolay Sivov wrote:
Could you suggest a best way to generate dll on runtime, maybe it's possible to place in into resourse? Any examples are welcome.
dlls/kernel32/tests/file.c has create_fake_dll() and dlls/kernel32/tests/loader.c has test_Loader(), maybe that's of use? -- Cheers, Paul.
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.
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
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov <bunglehead(a)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
Manually you should copy dll to exe directory. To update manifest I used: - 'mt -manifest DLL.dll.manifest -hashupdate' - update required cause your binary could differ obviously; - embed manifest to dll with 'mt -manifest DLL.dll.manifest -outputresource:DLL.dll;2' 2 means resource id for DLL (1 for exe) Public token has a dummy value but it's ok, it doesn't work without it if I don't miss something. P.S. hope nobody will be angry receiving attachment from this list today, it's rather tiny.
On 12/15/2009 15:52, Roderick Colenbrander wrote:
On Tue, Dec 15, 2009 at 11:08 AM, Nikolay Sivov<bunglehead(a)gmail.com> wrote:
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.
I'm looking at FindActCtxSectionStrin() call, looks like it does what I want. But it's not clear for me how to get dependent dll HMODULE handle to get register procedure. QueryActCtxW() doesn't provide it as I see. Any thoughts?
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
On 12/15/2009 15:52, Roderick Colenbrander wrote:
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.
Yesterday I started with it, you may find current helper in attached patch. It doesn't work yet, the only thing I finished is to find a context and module name that redirects specified class, that part works ok with some problems in existing context code: --- /* query_index.ulAssemblyIndex = key_data.ulAssemblyRosterIndex; */ --- at this point returned index doesn't pass parameter validation in next QueryActCtxW() call, but it's not a stopper for now and I forced it to 1 (2 was returned). The main problem is that I still can't get module handle to this SxS library. It's even worse, testing on Windows I'm not able to GetModuleHandle() for this library with full path explicitly hardcoded. It's a bit strange. After some testing on Windows I found that DllMain for mine library is called only after attempt to CreateWindow() with redirectable classname and the following sequence produced: --- DLL_PROCESS_ATTACH call to RegisterClassNameW DLL_PROCESS_DETACH /* disregarding that return value from registration call was success or not */ --- That's all done during CreateWindow() call. I'd like to see some comments from kernel-knowledge developers - is it ok that SxS module load is delayed and how properly replicate this outside kernel32 (inside user32 for this case). Thanks.
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.
True, this could be easily tested, but it's next part of the problem, first of load I need to register classes.
Roderick
participants (4)
-
André Hentschel -
Nikolay Sivov -
Paul Vriens -
Roderick Colenbrander