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@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