Hi all, I’ve been looking at possibly submitting some patches for powrprof.dll and had a couple of questions/looking for guidance about some issues. Namely: 1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it. The GUIDs used appear to be the same from machine to machine for the default power stuff. Is there a way when Wine bootstraps to load these ? If the answer is no, is hardcoding permitted? 2) According to https://learn.microsoft.com/en-us/windows/win32/power/power-management-funct..., the functions implemented are for Vista and earlier. Can I (initially) stub the newer functions? 3) In the cases where the functions are trying to set values, can I just simply return success since we aren’t going to actually change the values on the host? They’re probably doing other things under the covers, but it would take me some investigation to see what. Thanks, Rob
On 2/17/25 05:45, robert lippmann wrote:
Hi all,
I’ve been looking at possibly submitting some patches for powrprof.dll and had a couple of questions/looking for guidance about some issues.
Namely:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
The GUIDs used appear to be the same from machine to machine for the default power stuff.
Is there a way when Wine bootstraps to load these ?
You can have a initialize_registry() when initializing powrprof.dll. For example, in DllMain() DLL_PROCESS_ATTACH.
If the answer is no, is hardcoding permitted?
Yes. Hardcoding is allowed. It's in wine.inf.in. However, see if you dynamically initialize them first.
2) According to https://learn.microsoft.com/en-us/windows/win32/power/power-management-funct... <https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions>, the functions implemented are for Vista and earlier. Can I (initially) stub the newer functions?
Yes, you can.
3) In the cases where the functions are trying to set values, can I just simply return success since we aren’t going to actually change the values on the host? They’re probably doing other things under the covers, but it would take me some investigation to see what.
Yes. Thanks, Zhiyi
Thanks, Rob
Thanks for the info. A couple of follow up questions: 1) The new API functions appear to have been added in Windows 10. Does there need to be #ifdefs around the code for that? 2) because of the new API functions, powrprof.h has been split into 3 separate headers. Do I need to support backwards compatibility 3) in regards to the “clean room” environment, am I allowed to reference/copy and paste from Windows SDK headers? Or do I need to go strictly from the documentation? Thanks, Rob
On Feb 16, 2025, at 8:31 PM, Zhiyi Zhang <zzhang(a)codeweavers.com> wrote:
On 2/17/25 05:45, robert lippmann wrote:
Hi all,
I’ve been looking at possibly submitting some patches for powrprof.dll and had a couple of questions/looking for guidance about some issues.
Namely:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
The GUIDs used appear to be the same from machine to machine for the default power stuff.
Is there a way when Wine bootstraps to load these ?
You can have a initialize_registry() when initializing powrprof.dll. For example, in DllMain() DLL_PROCESS_ATTACH.
If the answer is no, is hardcoding permitted?
Yes. Hardcoding is allowed. It's in wine.inf.in. However, see if you dynamically initialize them first.
2) According to https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions<https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions>, the functions implemented are for Vista and earlier. Can I (initially) stub the newer functions?
Yes, you can.
3) In the cases where the functions are trying to set values, can I just simply return success since we aren’t going to actually change the values on the host? They’re probably doing other things under the covers, but it would take me some investigation to see what.
Yes.
Thanks, Zhiyi
Thanks, Rob
On 2/17/25 11:50, robert lippmann wrote:
Thanks for the info.
A couple of follow up questions:
1) The new API functions appear to have been added in Windows 10. Does there need to be #ifdefs around the code for that?
No need.
2) because of the new API functions, powrprof.h has been split into 3 separate headers. Do I need to support backwards compatibility
Do what the latest SDK does if necessary.
3) in regards to the “clean room” environment, am I allowed to reference/copy and paste from Windows SDK headers? Or do I need to go strictly from the documentation?
"You can look at the headers but you can't copy/paste them wholesale." - Alexandre Julliard. Thanks, Zhiyi
Thanks, Rob
On Feb 16, 2025, at 8:31 PM, Zhiyi Zhang <zzhang(a)codeweavers.com> wrote:
On 2/17/25 05:45, robert lippmann wrote:
Hi all,
I’ve been looking at possibly submitting some patches for powrprof.dll and had a couple of questions/looking for guidance about some issues.
Namely:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
The GUIDs used appear to be the same from machine to machine for the default power stuff.
Is there a way when Wine bootstraps to load these ?
You can have a initialize_registry() when initializing powrprof.dll. For example, in DllMain() DLL_PROCESS_ATTACH.
If the answer is no, is hardcoding permitted?
Yes. Hardcoding is allowed. It's in wine.inf.in. However, see if you dynamically initialize them first.
2) According to https://learn.microsoft.com/en-us/windows/win32/power/power-management-funct... <https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions><https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions <https://learn.microsoft.com/en-us/windows/win32/power/power-management-functions>>, the functions implemented are for Vista and earlier. Can I (initially) stub the newer functions?
Yes, you can.
3) In the cases where the functions are trying to set values, can I just simply return success since we aren’t going to actually change the values on the host? They’re probably doing other things under the covers, but it would take me some investigation to see what.
Yes.
Thanks, Zhiyi
Thanks, Rob
Some more follow up questions: 1) Since there are a lot of new functions added, should I do an initial patch with winedump producing skeleton code, and have each function just return ERROR_CALL_NOT_IMPLEMENTED? And then do follow on patches to implement? Or just do the implementation at the same time? From a review standpoint, I imagine the first approach is better. 2) A bunch of power related GUIDs are defined in winnt.h in the Windows SDK. It seems like they should be in the power headers. Should I follow the SDK? 3) For new files I’ll need to create, do I set the copyright name to me? Or Alexandre? Thanks, Rob
Am 19.02.2025 um 23:38 schrieb robert lippmann <robert.lippmann.development(a)gmail.com>:
Some more follow up questions:
1) Since there are a lot of new functions added, should I do an initial patch with winedump producing skeleton code, and have each function just return ERROR_CALL_NOT_IMPLEMENTED? And then do follow on patches to implement? Or just do the implementation at the same time? From a review standpoint, I imagine the first approach is better.
The first approach is generally better. Make sure that every function writes a FIXME to make it obvious a stub is called.
2) A bunch of power related GUIDs are defined in winnt.h in the Windows SDK. It seems like they should be in the power headers. Should I follow the SDK?
Yeah, follow the SDK. At least in theory our headers should be a drop in replacement for Microsoft's, although in practice that doesn't get tested much.
3) For new files I’ll need to create, do I set the copyright name to me? Or Alexandre?
Yourself
Stefan Dösinger <stefandoesinger(a)gmail.com> writes:
Am 19.02.2025 um 23:38 schrieb robert lippmann <robert.lippmann.development(a)gmail.com>:
Some more follow up questions:
1) Since there are a lot of new functions added, should I do an initial patch with winedump producing skeleton code, and have each function just return ERROR_CALL_NOT_IMPLEMENTED? And then do follow on patches to implement? Or just do the implementation at the same time? From a review standpoint, I imagine the first approach is better.
The first approach is generally better. Make sure that every function writes a FIXME to make it obvious a stub is called.
Unless it's a COM interface, you don't want to add skeleton code. Just list the functions as stub in the spec file, and implement only the ones that are called by the application. -- Alexandre Julliard julliard(a)winehq.org
Some more follow up questions: The registry keys are initially created during Windows installation. So, I would add them to wine.inf.in. When is this run? Every boot where wine.inf changes? Hard to tell from the docs. If so, and I set a default power profile (it’s just a value in the registry key), will it get overwritten? Also, the existing code puts semaphores around registry access for some reason (it is 20 year old code). I assume that is no longer necessary? Thanks, Rob
Am Montag, 17. Februar 2025, 00:45:32 Ostafrikanische Zeit schrieb robert lippmann:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
What's your ultimate goal? I guess you have an application that tries to read and/or change power settings. If the application is merely reading to e.g. figure out if it is running on a laptop powered by battery you probably don't need most of the registry values, If you want to make a power management tool work then you are in for a lot of work. Powerprof would have to talk to lower level Linux components to actually apply changes to the hardware settings - that's going to be tricky.
Well, the reason I’m doing this is because Steam VR tries to change the power profile. It shouldn’t, but good luck trying to get Valve to change this. So, I want to be able to make Wine/Crossover not throw an exception since the power management APIs don’t exist. Wine shouldn’t (IMHO) actually change the power profiles on its host. It should just respond with the expected query values and any changes to those values should just be an OK (assuming the parameters are correct, then it should throw an error).
On Feb 17, 2025, at 3:51 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am Montag, 17. Februar 2025, 00:45:32 Ostafrikanische Zeit schrieb robert lippmann:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
What's your ultimate goal? I guess you have an application that tries to read and/or change power settings.
If the application is merely reading to e.g. figure out if it is running on a laptop powered by battery you probably don't need most of the registry values,
If you want to make a power management tool work then you are in for a lot of work. Powerprof would have to talk to lower level Linux components to actually apply changes to the hardware settings - that's going to be tricky.
While I could just hardcode the GUIDs and indexes for the default power schemes in Windows, it seems like the more “correct” solution is to populate and manipulate the registry like Windows does. And, as I don’t plan on fully implementing all the calls, it might make it easier down the road for someone who might.
On Feb 17, 2025, at 3:51 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am Montag, 17. Februar 2025, 00:45:32 Ostafrikanische Zeit schrieb robert lippmann:
1) Default power profiles are stored in the registry under HKLM\System\CurrentControlSet\Control\Power. The subtree is pretty huge (about a 1.5m .reg file when I exported it.
What's your ultimate goal? I guess you have an application that tries to read and/or change power settings.
If the application is merely reading to e.g. figure out if it is running on a laptop powered by battery you probably don't need most of the registry values,
If you want to make a power management tool work then you are in for a lot of work. Powerprof would have to talk to lower level Linux components to actually apply changes to the hardware settings - that's going to be tricky.
On Monday, February 17, 2025 3:52:52 AM Central Standard Time robert lippmann wrote:
While I could just hardcode the GUIDs and indexes for the default power schemes in Windows, it seems like the more “correct” solution is to populate and manipulate the registry like Windows does.
No, hardcoding things like that is typically fine.
participants (5)
-
Alexandre Julliard -
Elizabeth Figura -
robert lippmann -
Stefan Dösinger -
Zhiyi Zhang