wine-devel

wine-devel@winehq.org

1 participants
84478 discussions

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 15 Mar '25

15 Mar '25

On Saturday, 15 March 2025 04:39:46 CDT Dan Carpenter wrote: > On Fri, Mar 14, 2025 at 05:13:50PM -0500, Elizabeth Figura wrote: > > On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > > > On 2025/3/14 17:21, Dan Carpenter wrote: > > > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > > > >> When 'manual=false' and 'signaled=true', then expected value when using > > > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > > >> > > > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > > > >> --- > > > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> index 3aad311574c4..bfb6fad653d0 100644 > > > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> @@ -968,7 +968,7 @@ TEST(wake_all) > > > >> auto_event_args.manual = false; > > > >> auto_event_args.signaled = true; > > > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > > > >> - EXPECT_EQ(0, objs[3]); > > > >> + EXPECT_LE(0, objs[3]); > > > > It's kind of weird how these macros put the constant on the left. > > > > It returns an "fd" on success. So this look reasonable. It probably > > > > won't return the zero fd so we could probably check EXPECT_LT()? > > > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > > > I can send a v2 patchset with this change if there is no more other > > > suggestions. > > > > I personally think it looks wrong to use EXPECT_LT(), but I'll certainly > > defer to a higher maintainer on this point. > > I'm not sure I understand what you are saying. Are you saying that we > should allow zero as an expected file descriptor here? I don't have > strong feelings about that either way. Yes, my apologies for the ambiguous wording. That is, EXPECT_LE looks more correct to me than EXPECT_LT per se. > Putting variables on the right, Yoda speak is. Unnatural is. Yes, I certainly agree with this. I wrote it this way in the first place because I was following some other example, I forget which. > I did a git grep and the KUNIT_EXPECT_LT() just calls the parameters > left and right instead of "expected" and "seen". Expected is wrong > for LT because we expect it to be != to the expected value. It's > the opposite. We're expecting the unexpected! It would be better > to just call them left and right. > > regards, > dan carpenter >

1 0

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > On 2025/3/14 17:21, Dan Carpenter wrote: > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > >> When 'manual=false' and 'signaled=true', then expected value when using > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > >> > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > >> --- > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> index 3aad311574c4..bfb6fad653d0 100644 > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> @@ -968,7 +968,7 @@ TEST(wake_all) > >> auto_event_args.manual = false; > >> auto_event_args.signaled = true; > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > >> - EXPECT_EQ(0, objs[3]); > >> + EXPECT_LE(0, objs[3]); > > It's kind of weird how these macros put the constant on the left. > > It returns an "fd" on success. So this look reasonable. It probably > > won't return the zero fd so we could probably check EXPECT_LT()? > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > I can send a v2 patchset with this change if there is no more other > suggestions. I personally think it looks wrong to use EXPECT_LT(), but I'll certainly defer to a higher maintainer on this point.

1 0

Re: [PATCH 4/4] docs: ntsync: update NTSYNC_IOC_*
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:54 CDT Su Hui wrote: > Some macros in the document do not match the code and the header files, > correct these macros according to the definitions in the code. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > Documentation/userspace-api/ntsync.rst | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst > index 25e7c4aef968..969774bf4c60 100644 > --- a/Documentation/userspace-api/ntsync.rst > +++ b/Documentation/userspace-api/ntsync.rst > @@ -152,9 +152,9 @@ The ioctls on the device file are as follows: > > The ioctls on the individual objects are as follows: > > -.. c:macro:: NTSYNC_IOC_SEM_POST > +.. c:macro:: NTSYNC_IOC_SEM_RELEASE > > - Post to a semaphore object. Takes a pointer to a 32-bit integer, > + Release a semaphore object. Takes a pointer to a 32-bit integer, > which on input holds the count to be added to the semaphore, and on > output contains its previous count. > > @@ -186,7 +186,7 @@ The ioctls on the individual objects are as follows: > unowned and signaled, and eligible threads waiting on it will be > woken as appropriate. > > -.. c:macro:: NTSYNC_IOC_SET_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_SET > > Signal an event object. Takes a pointer to a 32-bit integer, which on > output contains the previous state of the event. > @@ -194,12 +194,12 @@ The ioctls on the individual objects are as follows: > Eligible threads will be woken, and auto-reset events will be > designaled appropriately. > > -.. c:macro:: NTSYNC_IOC_RESET_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_RESET > > Designal an event object. Takes a pointer to a 32-bit integer, which > on output contains the previous state of the event. > > -.. c:macro:: NTSYNC_IOC_PULSE_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_PULSE > > Wake threads waiting on an event object while leaving it in an > unsignaled state. Takes a pointer to a 32-bit integer, which on > @@ -213,7 +213,7 @@ The ioctls on the individual objects are as follows: > afterwards, and a simultaneous read operation will always report the > event as unsignaled. > > -.. c:macro:: NTSYNC_IOC_READ_SEM > +.. c:macro:: NTSYNC_IOC_SEM_READ > > Read the current state of a semaphore object. Takes a pointer to > struct :c:type:`ntsync_sem_args`, which is used as follows: > @@ -225,7 +225,7 @@ The ioctls on the individual objects are as follows: > * - ``max`` > - On output, contains the maximum count of the semaphore. > > -.. c:macro:: NTSYNC_IOC_READ_MUTEX > +.. c:macro:: NTSYNC_IOC_MUTEX_READ > > Read the current state of a mutex object. Takes a pointer to struct > :c:type:`ntsync_mutex_args`, which is used as follows: > @@ -242,7 +242,7 @@ The ioctls on the individual objects are as follows: > ``EOWNERDEAD``. In this case, ``count`` and ``owner`` are set to > zero. > > -.. c:macro:: NTSYNC_IOC_READ_EVENT > +.. c:macro:: NTSYNC_IOC_EVENT_READ > > Read the current state of an event object. Takes a pointer to struct > :c:type:`ntsync_event_args`, which is used as follows: > @@ -255,7 +255,7 @@ The ioctls on the individual objects are as follows: > - On output, contains 1 if the event is a manual-reset event, > and 0 otherwise. > > -.. c:macro:: NTSYNC_IOC_KILL_OWNER > +.. c:macro:: NTSYNC_IOC_MUTEX_KILL > > Mark a mutex as unowned and abandoned if it is owned by the given > owner. Takes an input-only pointer to a 32-bit integer denoting the > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 3/4] selftests: ntsync: update config
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:53 CDT Su Hui wrote: > ntsync should be tested when CONFIG_NTSYNC is setting rather than > CONFIG_WINESYNC, correct this. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/config b/tools/testing/selftests/drivers/ntsync/config > index 60539c826d06..0aa68de147af 100644 > --- a/tools/testing/selftests/drivers/ntsync/config > +++ b/tools/testing/selftests/drivers/ntsync/config > @@ -1 +1 @@ > -CONFIG_WINESYNC=y > +CONFIG_NTSYNC=y > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 2/4] selftests: ntsync: avoid possible overflow in 32-bit machine
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:52 CDT Su Hui wrote: > When using '-m32' flag to compile this test with gcc, there are some > errors when running test: > > ntsync.c:785:wake_any:Expected ETIMEDOUT (110) == ret (0) > ntsync.c:823:wake_any:Expected (1) (1) == __count (0) > ... > FAILED: 7 / 11 tests passed. > Totals: pass:7 fail:4 xfail:0 xpass:0 skip:0 error:0 > > There is an overflow about 'timeout'. 'timespec->tv_sec' is 4 bytes in > 32-bit machine. And 'timeout.tv_sec * 1000000000' causing the overflow > problem, adding a cast to avoid this problem. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index bfb6fad653d0..ded83dc58e6b 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -103,7 +103,7 @@ static int wait_objs(int fd, unsigned long request, __u32 count, > > clock_gettime(CLOCK_MONOTONIC, &timeout); > > - args.timeout = timeout.tv_sec * 1000000000 + timeout.tv_nsec; > + args.timeout = (__u64)timeout.tv_sec * 1000000000 + timeout.tv_nsec; > args.count = count; > args.objs = (uintptr_t)objs; > args.owner = owner; > @@ -729,7 +729,7 @@ static __u64 get_abs_timeout(unsigned int ms) > { > struct timespec timeout; > clock_gettime(CLOCK_MONOTONIC, &timeout); > - return (timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > + return ((__u64)timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > } > > static int wait_for_thread(pthread_t thread, unsigned int ms) > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all
by Elizabeth Figura 14 Mar '25

14 Mar '25

On Friday, 14 March 2025 02:14:51 CDT Su Hui wrote: > When 'manual=false' and 'signaled=true', then expected value when using > NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index 3aad311574c4..bfb6fad653d0 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -968,7 +968,7 @@ TEST(wake_all) > auto_event_args.manual = false; > auto_event_args.signaled = true; > objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > - EXPECT_EQ(0, objs[3]); > + EXPECT_LE(0, objs[3]); > > wait_args.timeout = get_abs_timeout(1000); > wait_args.objs = (uintptr_t)objs; > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

1 0

Testbot since the weekend not reachable
by Bernhard Übelacker 11 Mar '25

11 Mar '25

Hello, is someone else also experiencing issues when accessing testbot.winehq.org? This seems to have caused missing results for the Friday tests run. Today in my browser still no results get shown. Querying via wget it shows data gets delivered after 3 minutes. The resulting page looks like at Friday got 5900 jobs queued (151728 to 157632). These jobs are all prefixed with [wine-devel], like if there was a jam in the patch submission? Kind regards, Bernhard $ LANG=C wget -O testbot.html https://testbot.winehq.org/ 2>&1 | ts '%Y-%m-%d %H:%M:%S:' 2025-03-11 09:55:15: --2025-03-11 09:55:15-- https://testbot.winehq.org/ 2025-03-11 09:55:15: Resolving testbot.winehq.org (testbot.winehq.org)... 104.130.219.87, 2001:4801:7828:101:be76:4eff:fe10:1727 2025-03-11 09:56:20: Connecting to testbot.winehq.org (testbot.winehq.org)|104.130.219.87|:443... connected. 2025-03-11 09:58:00: HTTP request sent, awaiting response... 200 OK 2025-03-11 09:58:00: Length: unspecified [text/html] 2025-03-11 09:58:00: Saving to: 'testbot.html' 2025-03-11 09:58:00: 2025-03-11 09:58:00: 0K .......... .......... .......... .......... .......... 187K 2025-03-11 09:58:00: 50K .......... .......... .......... .......... .......... 236K ... 2025-03-11 09:58:11: 2350K .......... .......... .......... .......... .......... 349K 2025-03-11 09:58:13: 2400K .......... .......... 8.99K=13s 2025-03-11 09:58:13: 2025-03-11 09:58:13: 2025-03-11 09:58:13 (188 KB/s) - 'testbot.html' saved [2478249] 2025-03-11 09:58:13:

2 2

Powrprof patches
by robert lippmann 11 Mar '25

11 Mar '25

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

5 11

Wine compatibility checking tool
by robert lippmann 10 Mar '25

10 Mar '25

Hi all, I had an idea for something that might be useful and wanted to know everyone’s thoughts. Basically, create a program that will take a Windows executable/dll, find all the imports and check Wine’s .spec files to see if the imports are stubs or don’t exist. Obviously could also go recursive through imports of other dlls down to the win32 sdk level too. It might help figure out some “why is this program crashing” issues. Thoughts? Rob

4 5

Wine staging 10.3 release
by Alistair Leslie-Hughes 08 Mar '25

08 Mar '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.3 (347 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * oleaut32/tests: Add some tests for loading and saving EMF using IPicture interface. * oleaut32: Add support for loading and saving EMF to IPicture interface. * oleaut32: Implement a better stub for IPicture::SaveAsFile. * oleaut32: Implement SaveAsFile for PICTYPE_ENHMETAFILE. * d3dx9_36: Filter out D3DCompile warning messages that are not present with D3DCompileShader. * setupapi: Rewrite DiskSpaceList logic using lists. * setupapi: Implement SetupAddToDiskSpaceList. * setupapi: Implement SetupQueryDrivesInDiskSpaceList. * setupapi: Ignore deletion of added files in SetupAddToDiskSpaceList. * setupapi: ImplementSetupAddSectionToDiskSpaceList. * setupapi: Implement SetupAddInstallSectionToDiskSpaceList. Removed (No longer required). * server-Realtime_Priority Added: * [21940] msxml: Improve support for the whitespace value. Updated: * vkd3d-latest * d3dx9_36-DDS 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.

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
8448
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel