correct comctl32 implementation

[Nikolay Sivov]

On 3/12/2011 09:54, Andrew Green wrote:
> Thank you for the quick reply.
> so is it the case is that multiple dll's versions will be generated to
> be used by SxS(as WinSxS contains multiple comctl32.dll)?
Again, we don't want to keep multiple versions, so we need a way to work 
with single one.
> I know uxtheme draws primitives. What I meant to ask was will any work
> have to be done in uxtheme(apart from maybe the occasional bug fix,
> not a new implementation of it or anything like that)?
Sure, bugs are possible, especially since uxtheme is not widely used.
> The last point about window class redirection I'm a bit confused
> about. I really don't know anything about it. This patch exists so it
> sounds like it is supported.
> http://osdir.com/ml/wine-patches/2009-12/msg00871.html
> So would it just be that case that comctl32(version 6) re-registers
> the controls that are normally in user32?
No, it's not supported. As I said here 
http://www.mail-archive.com/wine-devel@winehq.org/msg59786.html
we also need some ntdll improvements for activation contexts to support 
this stuff better. FindActCtxSectionString()
shouldn't be hard to improve but you need to figure out closed data 
structures format, at least some useful
fields (without disassembler, wine test suite only).

> If anyone could provide me with any information or reading material. I
> would be very thankful.
I don't think it's documented, I mean loading process itself to replace 
registered classes.
You can't try to search for "<windowClass></windowClass>" entry 
description for SxS manifests.

As I remember I failed to find any explanation for that, so this needs 
extensive tests in a first place.
Also be sure to test only behaviour without looking inside any MS modules.