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

[rlangschultz at cox.net]

I would think that ReactOs is not anywhere near being ready for themeing partially because it needs to write much more of the system software. Themeing can always be an option later. I have mentioned an alternate filesystem, and other services, but since I have not submitted code, people on the mailing list think i can not program something of the sort. I think it is great that people are wanting to understand the process of themeing but keep in mind that loading a theme may cut down on the resources available to the opertating system or may interfere with someone elses environment.
> 
> From: Jonathan Wilson <jonwil at tpgi.com.au>
> Date: 2005/03/23 Wed PM 09:19:23 EST
> To: wine-devel at winehq.org,  ros-dev at reactos.com
> Subject: [ros-dev] I think I know how uxtheme works...
> 
> 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
>