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
>