[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 at reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
>