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

Re: Apple Silicon compilation

by Donald Smith

I’ve also been playing with building wine on Apple Silicon (Sequoia), and though I was also able to successfully build for x86_86 (with Rosetta 2), it seems that I’m having issues with fonts that are basically making running anything with a GUI impossible. I can run cmd.exe without a problem, but things like explorer and notepad either don’t show up at all or open with an essentially blank window. If I configure and build with freetype2, I get repeated errors about not being able to find the library even though I have it installed: Wine cannot find the FreeType font library. To enable Wine to use TrueType fonts please install a version of FreeType greater than or equal to 2.0.5. http://www.freetype.org Then, eventually the following error: 0140:err:syslink:SYSLINK_SetFont Failed to create link font! Configuring without freetype still results in the above SYSLINK_SetFont error. Attempts after the I’ve found a few vague posts online from long ago about needing the 32-bit freetype2 libraries, but is that even a possibility anymore since Apple removed support for 32-bit code? I’ve also come across hints that System Integrity Protection might be getting in the way somehow, but I’m really not familiar with the details of how that works. In any case, I have just set up a spare Linux box so I can hopefully have a smoother time getting started on contributing, but I was excited about working on this in a macOS environment. After seeing Rob’s post, I figured I would chime in just in case anybody has any tips. Forgive me if I am just way off in the weeds; it has been a long time since I've compiled any C code on Linux, much less on macOS. -Don > > From: robert lippmann <robert.lippmann.development(a)gmail.com> > Subject: Apple Silicon compilation > Date: February 23, 2025 at 7:55:59 PM EST > To: wine-devel(a)winehq.org > Reply-To: wine-devel(a)winehq.org > > > Hi all, > > I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through. > > Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies > So: > > brew install lld > > Then: > PATH=`brew —prefix llvm`/bin:`brew —prefix bison`/bin:$PATH > > Then everything compiles. > > You probably don’t even need Xcode. And you probably should have Rosetta2 installed. > > I haven’t actually been able to get it to run yet, though… > > — Rob >

Feb. 27, 2025

Re: Question about `Avoid const strarray pointers in all functions' patch

by Alexandre Julliard

Mitch Wilkinson <foo.ami(a)yandex.com> writes: > Patch 0828f33e550 (tools: Avoid const strarray pointers in all functions., 2025-02-26)[1] recently landed to `Wine development'. Can anyone > explain me what motivation was behind changing type of function parameter(s)? Does this affect function inlining, or something? There's no performance improvement, it's for consistency with the other similar functions that take an strarray as input. Not passing a pointer makes it obvious that the array is not modified. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2025

Question about `Avoid const strarray pointers in all functions' patch

by Mitch Wilkinson

Feb. 27, 2025

Re: Apple Silicon compilation

by robert lippmann

> On Feb 24, 2025, at 5:55 AM, Dean Greer <gcenx83(a)gmail.com> wrote: > > At minimum Xcode Command Line Tools are required. > If you’re installing llvm, it might not be necessary since you are pulling in a whole new compiler toolchain. But, it’s not like it’s hard to install Xcode and command line tools. > > Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2. Rosetta2 should work as it is also limited to 4k page sizes. Microsoft Windows arm does something similar using “prism” for running x86 binaries. So, it couldn’t be much worse than running x86 on Windows arm :) In any case, for future reference, if anyone wants to know how to build for arm on apple silicon, the way I outlined would be how to do it.

Feb. 24, 2025

Re: Apple Silicon compilation

by Marc-Aurel Zent

> On 24. Feb 2025, at 11:55, Dean Greer <gcenx83(a)gmail.com> wrote: > > At minimum Xcode Command Line Tools are required. > > And as Stefan has pointed out your pretty much forced to build for x86_64 > > You can compile for x86_64 from an arm Terminal session but it’s simpler to build from an x86_64 Terminal session with ether an Intel brew install or MacPorts. > > Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2. > I believe stock upstream wine should run decently well under Rosetta 2 in most cases at the moment.

Feb. 24, 2025

Re: Apple Silicon compilation

by Dean Greer

At minimum Xcode Command Line Tools are required. And as Stefan has pointed out your pretty much forced to build for x86_64 You can compile for x86_64 from an arm Terminal session but it’s simpler to build from an x86_64 Terminal session with ether an Intel brew install or MacPorts. Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2. On Mon, Feb 24, 2025 at 3:39 AM Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am Montag, 24. Februar 2025, 03:55:59 Ostafrikanische Zeit schrieb robert > lippmann: > > Hi all, > > > > I tried to update the wiki to document how to compile Wine on Apple > Silicon, > > but I’m not sure if it went through. > > > Basically, you need to add lld (which pulls in llvm) in addition to the > > other build dependencies > > Generally if you want to run x86 Windows applications run both configure > and > make with arch -x86_64. Then it will all behave as if you were on an Intel > CPU > mac. You don't need to run the built wine with arch because it will be an > x86_64 only binary. > > If you want to build things for arm to run arm64 Windows binaries you are > in a > world of trouble: > > * MacOS won't allow you to map anything below 4 GB, so Wine can't place > the > KSHARED_USER_DATA at 0x7ffe0000. > > * ARM MacOS has 16 kb pages whereas Windows has 4kb ones. > > We are working on both of those issues, but running an arm64 wine is going > to > take a while. > > >

Feb. 24, 2025

Re: Apple Silicon compilation

by Stefan Dösinger

Am Montag, 24. Februar 2025, 03:55:59 Ostafrikanische Zeit schrieb robert lippmann: > Hi all, > > I tried to update the wiki to document how to compile Wine on Apple Silicon, > but I’m not sure if it went through. > Basically, you need to add lld (which pulls in llvm) in addition to the > other build dependencies Generally if you want to run x86 Windows applications run both configure and make with arch -x86_64. Then it will all behave as if you were on an Intel CPU mac. You don't need to run the built wine with arch because it will be an x86_64 only binary. If you want to build things for arm to run arm64 Windows binaries you are in a world of trouble: * MacOS won't allow you to map anything below 4 GB, so Wine can't place the KSHARED_USER_DATA at 0x7ffe0000. * ARM MacOS has 16 kb pages whereas Windows has 4kb ones. We are working on both of those issues, but running an arm64 wine is going to take a while.

Feb. 24, 2025

Apple Silicon compilation

by robert lippmann

Hi all, I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through. Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies So: brew install lld Then: PATH=`brew —prefix llvm`/bin:`brew —prefix bison`/bin:$PATH Then everything compiles. You probably don’t even need Xcode. And you probably should have Rosetta2 installed. I haven’t actually been able to get it to run yet, though… — Rob

Feb. 24, 2025

Wine staging 10.2 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.2 (350 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * vbscript: implement Join() * shdocvw: Check precisely ParseURLFromOutsideSourceX returned values in tests and make code clearer about that. * oleaut32: Fix logic for deciding whether type description follows the name * oleaut32: Implement decoding of SLTG help strings. * oleaut32: Add support for decoding SLTG function help strings. * oleaut32: Add support for decoding SLTG variable help strings. * oleaut32: OleLoadPicture should create a DIB section for a being loaded bitmap. * oleaut32: Make OleLoadPicture load DIBs using WIC decoder. * gdiplus: Add support for more image color formats. * gdiplus/tests: Add some tests for loading TIFF images in various color formats. Removed (No longer required). * None Added: * [52568] ws_ws2: Support for AF_UNIX sockets. Updated: * vkd3d-latest * win32u-NtGdiExtTextOutW-rotation 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. 22, 2025

Ask for help

by 谢威

Is there any development documentation related to wine wow64 syscall and unixcall.

Feb. 21, 2025

Re: [PATCH] ntsync: Check wait count based on byte size.

by Elizabeth Figura

On Wednesday, 19 February 2025 08:25:27 CST Greg Kroah-Hartman wrote: > On Tue, Feb 18, 2025 at 06:19:20PM -0600, Elizabeth Figura wrote: > > GCC versions below 13 incorrectly detect the copy size as being static and too > > small to fit in the "fds" array. Work around this by explicitly calculating the > > size and returning EINVAL based on that, instead of based on the object count. > > > > Reported-by: kernel test robot <lkp(a)intel.com> > > Closes: https://lore.kernel.org/oe-kbuild-all/202502072019.LYoCR9bF-lkp(a)intel.com/ > > Suggested-by: Arnd Bergmann <arnd(a)arndb.de> > > > > -- > > > > Suggested-by as per Arnd's request, but the only thing I changed was preserving > > array_size() [as noted by Geert in the linked thread]. I tested and found no > > regressions. > > You forgot to sign-off on this commit :( > > Can you resend it please with that fixed? Done, thanks. I used to have format.signOff=true but lost that somewhere...

Feb. 20, 2025

Re: [PATCH v2] ntsync: Check wait count based on byte size.

by Elizabeth Figura

On Thursday, 20 February 2025 13:23:34 CST Elizabeth Figura wrote: > GCC versions below 13 incorrectly detect the copy size as being static and too > small to fit in the "fds" array. Work around this by explicitly calculating the > size and returning EINVAL based on that, instead of based on the object count. > > Reported-by: kernel test robot <lkp(a)intel.com> > Closes: https://lore.kernel.org/oe-kbuild-all/202502072019.LYoCR9bF-lkp(a)intel.com/ > Suggested-by: Arnd Bergmann <arnd(a)arndb.de> > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > Oops, I forgot to include a reference to v1: https://lore.kernel.org/all/20250219001920.210847-1-zfigura(a)codeweavers.c…

Feb. 20, 2025

[PATCH v2] ntsync: Check wait count based on byte size.

by Elizabeth Figura

GCC versions below 13 incorrectly detect the copy size as being static and too small to fit in the "fds" array. Work around this by explicitly calculating the size and returning EINVAL based on that, instead of based on the object count. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502072019.LYoCR9bF-lkp(a)intel.com/ Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> -- Suggested-by as per Arnd's request, but the only thing I changed was preserving array_size() [as noted by Geert in the linked thread]. I tested and found no regressions. v2: Add missing sign-off --- drivers/misc/ntsync.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 586b86243e1d..24cb2f71186a 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -873,6 +873,7 @@ static int setup_wait(struct ntsync_device *dev, { int fds[NTSYNC_MAX_WAIT_COUNT + 1]; const __u32 count = args->count; + size_t size = array_size(count, sizeof(fds[0])); struct ntsync_q *q; __u32 total_count; __u32 i, j; @@ -880,15 +881,14 @@ static int setup_wait(struct ntsync_device *dev, if (args->pad || (args->flags & ~NTSYNC_WAIT_REALTIME)) return -EINVAL; - if (args->count > NTSYNC_MAX_WAIT_COUNT) + if (size >= sizeof(fds)) return -EINVAL; total_count = count; if (args->alert) total_count++; - if (copy_from_user(fds, u64_to_user_ptr(args->objs), - array_size(count, sizeof(*fds)))) + if (copy_from_user(fds, u64_to_user_ptr(args->objs), size)) return -EFAULT; if (args->alert) fds[count] = args->alert; -- 2.47.2

Feb. 20, 2025

Re: Powrprof patches

by Alexandre Julliard

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

Feb. 20, 2025

Re: Powrprof patches

by Stefan Dösinger

> 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

Feb. 20, 2025

Re: Powrprof patches

by robert lippmann

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

Feb. 19, 2025

[PATCH] ntsync: Check wait count based on byte size.

by Elizabeth Figura

GCC versions below 13 incorrectly detect the copy size as being static and too small to fit in the "fds" array. Work around this by explicitly calculating the size and returning EINVAL based on that, instead of based on the object count. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502072019.LYoCR9bF-lkp(a)intel.com/ Suggested-by: Arnd Bergmann <arnd(a)arndb.de> -- Suggested-by as per Arnd's request, but the only thing I changed was preserving array_size() [as noted by Geert in the linked thread]. I tested and found no regressions. --- drivers/misc/ntsync.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 586b86243e1d..24cb2f71186a 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -873,6 +873,7 @@ static int setup_wait(struct ntsync_device *dev, { int fds[NTSYNC_MAX_WAIT_COUNT + 1]; const __u32 count = args->count; + size_t size = array_size(count, sizeof(fds[0])); struct ntsync_q *q; __u32 total_count; __u32 i, j; @@ -880,15 +881,14 @@ static int setup_wait(struct ntsync_device *dev, if (args->pad || (args->flags & ~NTSYNC_WAIT_REALTIME)) return -EINVAL; - if (args->count > NTSYNC_MAX_WAIT_COUNT) + if (size >= sizeof(fds)) return -EINVAL; total_count = count; if (args->alert) total_count++; - if (copy_from_user(fds, u64_to_user_ptr(args->objs), - array_size(count, sizeof(*fds)))) + if (copy_from_user(fds, u64_to_user_ptr(args->objs), size)) return -EFAULT; if (args->alert) fds[count] = args->alert; -- 2.47.2

Feb. 19, 2025

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

by Elizabeth Figura

On Friday, 14 February 2025 06:28:00 CST Mike Lothian wrote: > This allows ntsync to be usuable by non-root processes out of the box > > Signed-off-by: Mike Lothian <mike(a)fireburn.co.uk> > --- > drivers/misc/ntsync.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c > index 055395cde42b..586b86243e1d 100644 > --- a/drivers/misc/ntsync.c > +++ b/drivers/misc/ntsync.c > @@ -1208,6 +1208,7 @@ static struct miscdevice ntsync_misc = { > .minor = MISC_DYNAMIC_MINOR, > .name = NTSYNC_NAME, > .fops = &ntsync_fops, > + .mode = 0666, // Setting file permissions to 0666 > }; > > module_misc_device(ntsync_misc); > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> -- The comment seems rather redundant, but otherwise this is correct and prudent.

Feb. 18, 2025

Re: Powrprof patches

by Elizabeth Figura

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.

Feb. 17, 2025

Re: Powrprof patches

by robert lippmann

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.

Feb. 17, 2025

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