February 2025 - Wine-Devel - list.winehq.org

Re: Powrprof patches

by robert lippmann

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.

Feb. 17, 2025

Re: Powrprof patches

by Stefan Dösinger

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.

Feb. 17, 2025

Re: Powrprof patches

by Zhiyi Zhang

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-func… <https://learn.microsoft.com/en-us/windows/win32/power/power-management-func…><https://learn.microsoft.com/en-us/windows/win32/power/power-management-func… <https://learn.microsoft.com/en-us/windows/win32/power/power-management-func…>>, 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 >

Feb. 17, 2025

Re: Powrprof patches

by robert lippmann

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-func…<https://learn.microsoft.com/en-us/windows/win32/power/power-management-func…>, 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

Feb. 17, 2025

Re: Powrprof patches

by Zhiyi Zhang

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-func… <https://learn.microsoft.com/en-us/windows/win32/power/power-management-func…>, 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 > > >

Feb. 17, 2025

Powrprof patches

by robert lippmann

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-func…, 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

Feb. 16, 2025

Re: [PATCH] ntsync: Set the permissions to be 0666

by Elizabeth Figura

On Friday, 14 February 2025 19:03:33 CST Darrick J. Wong wrote: > On Fri, Feb 14, 2025 at 04:15:25PM -0600, Elizabeth Figura wrote: > > On Friday, 14 February 2025 12:45:39 CST Darrick J. Wong wrote: > > > On Fri, Feb 14, 2025 at 12:13:03PM -0600, Elizabeth Figura wrote: > > > > On Friday, 14 February 2025 07:06:20 CST Greg Kroah-Hartman wrote: > > > > > On Fri, Feb 14, 2025 at 12:28:00PM +0000, Mike Lothian wrote: > > > > > > This allows ntsync to be usuable by non-root processes out of the box > > > > > > > > > > Are you sure you need/want that? If so, why? How did existing testing > > > > > not ever catch this? > > > > > > > > Hi, sorry, this is of course my fault. > > > > > > > > We do need /dev/ntsync to be openable from user space for it to be > > > > useful. I'm not sure what the most "correct" permissions are to have > > > > in this case (when we don't specifically need read or write), but I > > > > don't think I see a reason not to just set to 666 or 444. > > > > > > > > I originally assumed that the right way to do this was not to set the > > > > mode on the kernel file but rather through udev; I believe I was using > > > > the code for /dev/loop-control or /dev/fuse as an example, which both > > > > do that. So I (and others who tested) had just manually set up udev > > > > rules for this, with the eventual intent of adding a default rule to > > > > systemd like the others. I only recently realized that doing something > > > > like this patch is possible and precedented. > > > > > > > > I don't know what the best way to address this is, but this is > > > > certainly the simplest. > > > > > > Paranoid defaults in the kernel, and then a udev rule to relax the mode > > > at runtime. You could also have logind scripts to add add per-user > > > allow acls to the device file at user session set up time... or however > > > it is that /dev/sr0 has me on the allow list. I'm not sure how that > > > happens exactly, but it works smoothly. > > > > > > I get far less complaining about relaxing posture than tightening it > > > (==breaking things) after the fact. > > > > FWIW, it may be worth stressing that this is not a hardware device in > > any sense, it's a software driver that only lives in a char device > > (and dedicated module) for the sake of isolating the code. I can't > > imagine any reason to control access per-user, although my experience > > may not be enough to grant such imagination. > > Oh, I'm aware that ntsync is a driver for a software "device" that > implements various Windows APIs and isn't real hardware. :) > > But, you might want prevent non-root systemd services (e.g. avahi) from > being able to access /dev/ntsync if, say, someone breaches that, while > at the same time allowing access to (say) logged-in users who can run > Wine. I see the idea, though I don't know if it's applicable in this case—the individual ntsync file descriptions are also supposed to be isolated from one another, so even a rogue avahi would still have another barrier towards compromising a Wine process. Of course you may be aware of that and be advocating for the more barriers the better. I can't say what systemd will actually prefer in this case, but they do seem to have requested that the kernel change it... [1] [1] https://github.com/systemd/systemd/pull/36384

Feb. 15, 2025

Re: [PATCH] ntsync: Set the permissions to be 0666

by Elizabeth Figura

On Friday, 14 February 2025 12:45:39 CST Darrick J. Wong wrote: > On Fri, Feb 14, 2025 at 12:13:03PM -0600, Elizabeth Figura wrote: > > On Friday, 14 February 2025 07:06:20 CST Greg Kroah-Hartman wrote: > > > On Fri, Feb 14, 2025 at 12:28:00PM +0000, Mike Lothian wrote: > > > > This allows ntsync to be usuable by non-root processes out of the box > > > > > > Are you sure you need/want that? If so, why? How did existing testing > > > not ever catch this? > > > > Hi, sorry, this is of course my fault. > > > > We do need /dev/ntsync to be openable from user space for it to be > > useful. I'm not sure what the most "correct" permissions are to have > > in this case (when we don't specifically need read or write), but I > > don't think I see a reason not to just set to 666 or 444. > > > > I originally assumed that the right way to do this was not to set the > > mode on the kernel file but rather through udev; I believe I was using > > the code for /dev/loop-control or /dev/fuse as an example, which both > > do that. So I (and others who tested) had just manually set up udev > > rules for this, with the eventual intent of adding a default rule to > > systemd like the others. I only recently realized that doing something > > like this patch is possible and precedented. > > > > I don't know what the best way to address this is, but this is > > certainly the simplest. > > Paranoid defaults in the kernel, and then a udev rule to relax the mode > at runtime. You could also have logind scripts to add add per-user > allow acls to the device file at user session set up time... or however > it is that /dev/sr0 has me on the allow list. I'm not sure how that > happens exactly, but it works smoothly. > > I get far less complaining about relaxing posture than tightening it > (==breaking things) after the fact. FWIW, it may be worth stressing that this is not a hardware device in any sense, it's a software driver that only lives in a char device (and dedicated module) for the sake of isolating the code. I can't imagine any reason to control access per-user, although my experience may not be enough to grant such imagination. The only actual risk is a bug in the code itself—which is always possible—but at that point you'd presumably just want to disable it at build time or something similar.

Feb. 14, 2025

Re: [PATCH] ntsync: Set the permissions to be 0666

by Elizabeth Figura

On Friday, 14 February 2025 07:06:20 CST Greg Kroah-Hartman wrote: > On Fri, Feb 14, 2025 at 12:28:00PM +0000, Mike Lothian wrote: > > This allows ntsync to be usuable by non-root processes out of the box > > Are you sure you need/want that? If so, why? How did existing testing > not ever catch this? Hi, sorry, this is of course my fault. We do need /dev/ntsync to be openable from user space for it to be useful. I'm not sure what the most "correct" permissions are to have in this case (when we don't specifically need read or write), but I don't think I see a reason not to just set to 666 or 444. I originally assumed that the right way to do this was not to set the mode on the kernel file but rather through udev; I believe I was using the code for /dev/loop-control or /dev/fuse as an example, which both do that. So I (and others who tested) had just manually set up udev rules for this, with the eventual intent of adding a default rule to systemd like the others. I only recently realized that doing something like this patch is possible and precedented. I don't know what the best way to address this is, but this is certainly the simplest.

Feb. 14, 2025

Wine staging 10.1 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.1 (361 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [53644] vbscript: class single line multivar. * [56464] vbscript: Implement Join * [52769] mf: Add HTTP/HTTPS IMFByteStream implementation. * [26302] richedit20: Implement IRichEditOle::ImportDataObject * [53620] err:ole:com_get_class_object class IEnumObjects not registered. * [56891] Visual novel Mebae (Tanuki Soft) crashes on startup * [51139] d2d1: Implement drawing of ID2D1GeometryGroup * [56280] oleaut32: VarAnd use VT_I4 when converting VT_BSTR Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Feb. 9, 2025