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.