Re: [ros-dev] I think I know how uxtheme works...

[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
>