I think I know how uxtheme works...

[Jonathan Wilson]

What I strongly suspect happens is this:
1.The themes service is always loaded and running and holds the theme data 
(and it contains details of which .msstyles file to use)
2.At some point (either at startup if the changes are global or when an app 
loads if the changes are app specific, I cant find where this bit happens 
but I suspect the themes service does this) control passes to ordinal 34 in 
uxtheme.dll (aka ThemeHooksInstall acording to uxtheme.pdb). This function 
calls an undocumented function in user32 called RegisterUserApiHooks (which 
appears to be taylor made for uxtheme to do what it needs to do).
The function hooks:
GetScrollInfo
SetScrollInfo
EnableScrollBar
SetWindowRgn
DefWindowProcW
DefWindowProcA
PreWndProc (probobly stuff that happens internally before the window 
procedure gets called)
PostWndProc (probobly stuff that happens internally after the window 
procedure gets called)
PreDefDlgProc (probobly connected to dialog boxes)
PostDefDlgProc (probobly connected to dialog boxes)
GetSystemMetrics
SystemParametersInfoA
SystemParametersInfoW
DrawFrameControl
DrawCaption
MDIRedrawFrame (probobly related to MDI frame windows)
This is what causes all apps (including non-theme-aware ones) to get themed 
non-client areas (window borders etc)
3.Apps that are theme aware have a manifest, load comctl32.dll 6.0 and 
probobly have to call InitCommonControlsEx (although I think some of the 
code in the dllmain for comctl32.dll 6.0 may also end up calling 
InitCommonControlsEx). This causes new versions of the stock classes 
(button, list box, edit, combo box etc etc etc) to be created and 
registered. A cursory examination of some of these classes shows that they 
dont seem to "pull code" from the stock implementation in user32.dll (i.e. 
anything they dont themselves handle goes back to DefWindowProc). In 
particular, it doesnt appear as though they have any knowledge of the 
classes or window procedures contained in user32.dll.
then 4.Apps that need to do something extra call into functions exported by 
uxtheme.dll to do whatever they need to do.

user32.dll seems to have no knowledge whatsoever about themeing and 
uxtheme. All that user32 has is RegisterUserApiHooks (and the matching 
UnregisterUserApiHooks) that uxtheme uses to hook into user32.dll and do stuff.

Exactly how the theme service and theme engine works "under the hood" 
doesnt matter.
But for ReactOS and WINE purposes, I suggest we implement the following:
1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks (either 
reverse engineer the MS function or write our own). This will allow uxtheme 
to hook into the global drawing for things like window borders without 
user32 needing to care about uxtheme and what uxtheme does (just like how 
MS hooks into user32 that way)
2.Whatver code is necessary to get the hooks installed right so that all 
apps get the "global" theming like on real windows
3.Support to read the manifest and load a new comctl32.dll that would be 
like the version 6 from microsoft (and would contain complete theme-aware 
implementations of the stock controls just like MS comctl32.dll 6.0 does)
and 4.All the needed uxtheme exports to make stuff run

This would be the same way Microsoft does things.
User32.dll would have no idea whatsoever about uxtheme and theming
All apps would get non-client-area themeing like on windows.
And only theme aware apps would get themed controls etc (the rest would get 
"stock" windows controls)

Oh and btw, if this "reverse engineering" is not "clean room" enough
for 
WINE and ReactOS, let me know and I will stop posting it :)

[Jonathan Wilson]

Also related to this (as pointed out in IRC) is Activation Contexts/SxS 
stuff), we need this to make sure the correct window classes are used at 
the correct time.

[Richard Campbell]

I honestly wouldn't take this approach.  While microsoft may do this, 
you can use a different approach without sacrificing compatibility 
(well, except for maybe anything from stardock.)  Microsoft's approach 
is kind of hackish/kludgy, and even worse, it's slow.

A better approach would be a plugin system.  User32/gdi32/win32k would 
pass off rendering calls to a plugin, which would be responsible for the 
actual drawing.  That way you could completely change HOW things are 
drawn, for instance, you can create an opengl accelerated windowing 
system, etc.  Hmm...maybe i could write a draft for such a system....now 
i'm wanting to code, hehe.  Granted, this would probably be better off 
as a fork or 3rd party project...but still...

Richard

Jonathan Wilson wrote:

>   What I strongly suspect happens is this:
>  1.The themes service is always loaded and running and holds the theme 
>  data (and it contains details of which .msstyles file to use)
>  2.At some point (either at startup if the changes are global or when 
>  an app loads if the changes are app specific, I cant find where this 
>  bit happens but I suspect the themes service does this) control passes 
>  to ordinal 34 in uxtheme.dll (aka ThemeHooksInstall acording to 
>  uxtheme.pdb). This function calls an undocumented function in user32 
>  called RegisterUserApiHooks (which appears to be taylor made for 
>  uxtheme to do what it needs to do).
>  The function hooks:
>  GetScrollInfo
>  SetScrollInfo
>  EnableScrollBar
>  SetWindowRgn
>  DefWindowProcW
>  DefWindowProcA
>  PreWndProc (probobly stuff that happens internally before the window 
>  procedure gets called)
>  PostWndProc (probobly stuff that happens internally after the window 
>  procedure gets called)
>  PreDefDlgProc (probobly connected to dialog boxes)
>  PostDefDlgProc (probobly connected to dialog boxes)
>  GetSystemMetrics
>  SystemParametersInfoA
>  SystemParametersInfoW
>  DrawFrameControl
>  DrawCaption
>  MDIRedrawFrame (probobly related to MDI frame windows)
>  This is what causes all apps (including non-theme-aware ones) to get 
>  themed non-client areas (window borders etc)
>  3.Apps that are theme aware have a manifest, load comctl32.dll 6.0 and 
>  probobly have to call InitCommonControlsEx (although I think some of 
>  the code in the dllmain for comctl32.dll 6.0 may also end up calling 
>  InitCommonControlsEx). This causes new versions of the stock classes 
>  (button, list box, edit, combo box etc etc etc) to be created and 
>  registered. A cursory examination of some of these classes shows that 
>  they dont seem to "pull code" from the stock implementation in 
>  user32.dll (i.e. anything they dont themselves handle goes back to 
>  DefWindowProc). In particular, it doesnt appear as though they have 
>  any knowledge of the classes or window procedures contained in 
>  user32.dll.
>  then 4.Apps that need to do something extra call into functions 
>  exported by uxtheme.dll to do whatever they need to do.
>
>  user32.dll seems to have no knowledge whatsoever about themeing and 
>  uxtheme. All that user32 has is RegisterUserApiHooks (and the matching 
>  UnregisterUserApiHooks) that uxtheme uses to hook into user32.dll and 
>  do stuff.
>
>  Exactly how the theme service and theme engine works "under the hood" 
>  doesnt matter.
>  But for ReactOS and WINE purposes, I suggest we implement the following:
>  1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks 
>  (either reverse engineer the MS function or write our own). This will 
>  allow uxtheme to hook into the global drawing for things like window 
>  borders without user32 needing to care about uxtheme and what uxtheme 
>  does (just like how MS hooks into user32 that way)
>  2.Whatver code is necessary to get the hooks installed right so that 
>  all apps get the "global" theming like on real windows
>  3.Support to read the manifest and load a new comctl32.dll that would 
>  be like the version 6 from microsoft (and would contain complete 
>  theme-aware implementations of the stock controls just like MS 
>  comctl32.dll 6.0 does)
>  and 4.All the needed uxtheme exports to make stuff run
>
>  This would be the same way Microsoft does things.
>  User32.dll would have no idea whatsoever about uxtheme and theming
>  All apps would get non-client-area themeing like on windows.
>  And only theme aware apps would get themed controls etc (the rest 
>  would get "stock" windows controls)
>
>  Oh and btw, if this "reverse engineering" is not "clean room" enough
>
>  for WINE and ReactOS, let me know and I will stop posting it :)
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Jonathan Wilson]

We need to support the following: (at some point we do anyway)
1.Manifests, SxS, Activation Contexts etc (not just for uxtheme/comctl32 
6.0 but for other stuff). This includes all the work in user32 to correctly 
support different activation contexts having different versions of the same 
window class like comctl32 6.0 does for the standard controls).
2..msstyles files.
and 3.All the known uxtheme export functions (certainly those documented in 
MSDN and called by apps anyway)
Then, all we need after that is the global hook to do non-client-area themeing

We have to implement this in the same overall way as microsoft did if we 
want to be compatible.

[Robert Köpferl]

Richard Campbell wrote:
>   I honestly wouldn't take this approach.  While
> microsoft may do this, 
>  you can use a different approach without sacrificing compatibility 
>  (well, except for maybe anything from stardock.)  Microsoft's approach 
>  is kind of hackish/kludgy, and even worse, it's slow.
>  
>  A better approach would be a plugin system.  User32/gdi32/win32k would 
>  pass off rendering calls to a plugin, which would be responsible for the 
>  actual drawing.  That way you could completely change HOW things are 
>  drawn, for instance, you can create an opengl accelerated windowing 
>  system, etc.  Hmm...maybe i could write a draft for such a system....now 
>  i'm wanting to code, hehe.  Granted, this would probably be better off 
>  as a fork or 3rd party project...but still... 
Full ACK.
When I first saw the 'super duper new luna GUI' I was disappointed what
MS did. It is hackish or set on top. I thought, when they are MS and do
have access to the src, why don't they realize some kind of plugin
system or do the theming in win32k.sys. So this is one point, where we
can do better than the original. (while theming is one of the latter
things we need)


BTW. there are manny more things we could do different and better than
MS. I often ask wether the setup2 must be so simmilar to that of w2k or
welcome.exe. It is really a copy. So far.

[Richard Campbell]

It's enough that we need to implement all of the functionality of a 
Microsoft OS.  Adding new/different features or making things behave 
differently only complicates things and makes it harder to nail down 
compatibility problems.  Theme support is 'extra' and should wait until 
closer to a 1.0 release.  The GUI itself isn't even functionally 
complete yet (radio buttons need some work, there is graphical 
corruption running certain apps like explorer, just try to scroll in 
explorer).  Resources would better be spent fixing these problems then 
adding themeing, which would almost certainly make things even more 
complex than they already are.


Robert Köpferl wrote:

>  
>
>  Richard Campbell wrote:
>
> >   I honestly wouldn't take this approach. 
> > While microsoft may do this, 
> >  you can use a different approach without sacrificing compatibility 
> >  (well, except for maybe anything from stardock.)  Microsoft's 
> >  approach is kind of hackish/kludgy, and even worse, it's slow.
> >
> >  A better approach would be a plugin system.  User32/gdi32/win32k 
> >  would pass off rendering calls to a plugin, which would be 
> >  responsible for the actual drawing.  That way you could completely 
> >  change HOW things are drawn, for instance, you can create an opengl 
> >  accelerated windowing system, etc.  Hmm...maybe i could write a draft 
> >  for such a system....now i'm wanting to code, hehe.  Granted, this 
> >  would probably be better off as a fork or 3rd party project...but 
> >  still... 
>
>  Full ACK.
>  When I first saw the 'super duper new luna GUI' I was disappointed what
>  MS did. It is hackish or set on top. I thought, when they are MS and do
>  have access to the src, why don't they realize some kind of plugin
>  system or do the theming in win32k.sys. So this is one point, where we
>  can do better than the original. (while theming is one of the latter
>  things we need)
>
>
>  BTW. there are manny more things we could do different and better than
>  MS. I often ask wether the setup2 must be so simmilar to that of w2k or
>  welcome.exe. It is really a copy. So far.
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Robert Köpferl]

Double Full ACK.
I'm questioning long time for what theming is good for. But if 
implementing those stuff - please in a clean/fundamental manner.

Richard Campbell wrote:
>   It's enough that we need to implement all of the
> functionality of a 
>  Microsoft OS.  Adding new/different features or making things behave 
>  differently only complicates things and makes it harder to nail down 
>  compatibility problems.  Theme support is 'extra' and should wait until 
>  closer to a 1.0 release.  The GUI itself isn't even functionally 
>  complete yet (radio buttons need some work, there is graphical 
>  corruption running certain apps like explorer, just try to scroll in 
>  explorer).  Resources would better be spent fixing these problems then 
>  adding themeing, which would almost certainly make things even more 
>  complex than they already are.
>  
>  
>  Robert Köpferl wrote:
>  
> >  
> >
> >  Richard Campbell wrote:
> >
> > >   I honestly wouldn't take this approach. 
> > > While microsoft may do this, 
> > >  you can use a different approach without sacrificing compatibility 
> > >  (well, except for maybe anything from stardock.)  Microsoft's 
> > >  approach is kind of hackish/kludgy, and even worse, it's slow.
> > >
> > >  A better approach would be a plugin system.  User32/gdi32/win32k 
> > >  would pass off rendering calls to a plugin, which would be 
> > >  responsible for the actual drawing.  That way you could completely 
> > >  change HOW things are drawn, for instance, you can create an opengl 
> > >  accelerated windowing system, etc.  Hmm...maybe i could write a draft 
> > >  for such a system....now i'm wanting to code, hehe.  Granted, this 
> > >  would probably be better off as a fork or 3rd party project...but 
> > >  still... 
> >
> >
> >  Full ACK.
> >  When I first saw the 'super duper new luna GUI' I was disappointed what
> >  MS did. It is hackish or set on top. I thought, when they are MS and do
> >  have access to the src, why don't they realize some kind of plugin
> >  system or do the theming in win32k.sys. So this is one point, where we
> >  can do better than the original. (while theming is one of the latter
> >  things we need)
> >
> >
> >  BTW. there are manny more things we could do different and better than
> >  MS. I often ask wether the setup2 must be so simmilar to that of w2k or
> >  welcome.exe. It is really a copy. So far.
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.com
> >  http://reactos.com:8080/mailman/listinfo/ros-dev
> >  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>