当前位置：文江博客话题详情

更改 dwm 着色 - Windows 7

发布于 2024-12-22 01:30:54 字数 368 浏览 7 评论 0原文

我目前正在尝试在 VB.NET 中编写一个程序，该程序可以流畅地更改 Windows 7 中的 DWM 窗口着色颜色。

我首先尝试直接编辑注册表值，但我必须重新启动 UXSMS 服务。由于任务栏的切换，这个解决方案并不令人满意。

我现在正在 DLL 中搜索一个函数，例如 user32.dll 或 themecpl.dll，它们可以在设置窗口颜色时重现控制面板的行为。

我现在在 IDA 上寻找合适的函数（CColorCplPage::SetDwmColorizationColor 似乎不错！）。如果谁有的话请分享一下！

（如果有人需要屏幕或代码，请询问。抱歉我的英语不好。）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

你曾走过我的故事 2024-12-29 01:30:54

您的第一次尝试失败了，因为手动编辑注册表永远都不是更改系统设置的正确方法。正如您所发现的，许多 Windows 组件（以及其他应用程序！）会读取这些配置值一次并缓存它们，从而防止您的更改被传播。另一个问题（你会惊讶于我经常看到这个问题）是尝试在注册表中乱搞的应用程序通常最终会破坏东西。

相反，您应该调用记录的 API 来更改设置。几乎总是有一种记录在案的方法可以做到这一点，如果没有，那么您就不应该这样做。

这似乎就是其中之一。有一个已记录的 DwmGetColorizationColor 函数，但正如人们所期望的那样，没有相应的 DwmSetColorizationColor 函数。

原因是用户应该是唯一可以更改其着色设置的人，而不是其他应用程序。您可能承诺不会滥用此功能，并且仅根据用户的明确请求进行此类更改，但并非所有应用程序都可以信任执行此操作。很多人会恶意使用它，因此这些功能尚未被记录和公开。

但像往常一样，如果你继续努力，你通常可以找到一种未记录的做事方式。使用未记录的函数的问题是不能保证它们能够工作或继续工作。它们被故意保留为未记录，因为它们可能会在新版本的 Windows 上发生更改。您应该自行承担使用它们的风险。

在这种情况下，如果您使用 DumpBin 等程序从 DWM DLL (dwmapi.dll) 获取所有导出函数的列表，您将看到许多未记录的导出函数。

您感兴趣的是 DwmGetColorizationParameters 和 DwmSetColorizationParameters。这两个函数都采用 COLORIZATIONPARAMS 结构作为参数，其中包含它们所需的值。

因此，您需要对这些函数进行逆向工程并获得适当的定义。然后，您可以调用DwmGetColorizationParameters函数，传入COLORIZATIONPARAMS结构体来获取当前的配置设置；修改包含当前着色颜色的结构体成员；然后将该结构的修改版本传递给 DwmSetColorizationParameters 函数。

我是否提到过我不建议这样做？

Your first attempt failed because manually editing the Registry is never the correct way to change system settings. As you found out, lots of Windows components (and other applications!) read those configuration values once and cache them, preventing your changes from being propagated. Another problem (and you'd be surprised how often I see this) is applications that attempt to muck around in the Registry generally end up corrupting things.

Instead, you should call the documented API to change the settings. There's almost always a documented way of doing this, and if there isn't, well then you shouldn't be doing it.

This appears to be one of those cases. There's a documented DwmGetColorizationColor function, but there's no corresponding DwmSetColorizationColor function, as one might expect.

The reason is that the user is supposed to be the only one who can change their colorization settings, not other applications. You might promise not to abuse this, and to only make such changes at the user's explicit request, but not all applications can be trusted to do this. Lots of people would use it maliciously, so these functions have not been documented and exposed.

But as usual, if you press on, you can usually find an undocumented way of doing things. The problem with using undocumented functions is that there's no guarantee they'll work or continue to work. They've been intentionally left undocumented because they're liable to change on new versions of Windows. You should only use them at your own risk.

In this case, if you use a program like DumpBin to obtain a list of all the exported functions from the DWM DLL (dwmapi.dll), you'll see a number of undocumented exported functions.

The ones you're interested in are DwmGetColorizationParameters and DwmSetColorizationParameters. Both of these functions take a COLORIZATIONPARAMS structure as an argument that contains the values they need.

So, you need to reverse engineer these functions and obtain the appropriate definitions. Then, you can call the DwmGetColorizationParameters function, passing in a COLORIZATIONPARAMS structure to obtain the current configuration settings; modify the member of the structure that contains the current colorization color; and then pass that modified version of the structure to the DwmSetColorizationParameters function.

Did I mention that I don't recommend doing this?

回复收藏 0 原文

~没有更多了~