wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: How to use AddressSanitizer with Wine?
by Bernhard Übelacker 07 May '25

07 May '25

Am 28.04.25 um 11:55 schrieb Yuxuan Shui: > Hi, > > I heard you were talking about ASan :) > > Just want to say that I happen to be working on ASan as well. Bernhard did > amazing work getting llvm's ASan runtime to work with Wine, however I am doing > a different approach. I want to be able to intrument the entirity of Wine, not > just PE. This has some challenges, created by e.g. the PE/Unix split, WoW64, > etc. I don't think any ASan runtimes can handle this yet, so I am working on > a special runtime for Wine. This is a lot of work, but on the flip side, this > should make running Wine under ASan much smoother, and rid us of the dependency > on compiler-rt. > > Ask me anything if this sounds interesting. Hopefully this idea doesn't sound > completely crazy to you ^^; > > Best, > Yuxuan Hello Yuxuan, this sounds interesting :-) I wondered if it would be possible to use PE and unix side with ASan enabled, and guessed this might need some changes in synchronising both to access a single Shadow memory, but never tried something into this direction. Kind regards, Bernhard

2 1

How do I determine which functions are unimplemented?
by zhengxianwei 07 May '25

07 May '25

When a function is commented out and the application calls it, the application crash silently . I dont know which function caused this. Is there any way to quickly determine which functions are unimplemented ? eg: https://github.com/wine-mirror/wine/blob/226a7eeabbc13345e49da1ff8c018d6f06…

3 3

Why, in Wine, are some unimplemented APIs not marked as stubs but instead commented out?
by zhengxianwei 06 May '25

06 May '25

This results in a situation where, due to the missing API, the program doesn't report an error but instead directly aborts; whereas if it were marked as a stub, it would produce a clear error eg: https://github.com/wine-mirror/wine/blob/226a7eeabbc13345e49da1ff8c018d6f06… Does this involve some of wine's development philosophy?

3 3

Wine staging 10.7 release
by Alistair Leslie-Hughes 03 May '25

03 May '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.7 (347 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * win32u: Fix return value of ScrollWindowEx for invisible windows. Removed (No longer required). * d3dx9_36-DDS (fixed upstream) Added: * None Updated: * vkd3d-latest * odbc32-fixes 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

Announcing WineConf 2025
by Alexandre Julliard 24 Apr '25

24 Apr '25

Folks, It's been a while, so it's time for another WineConf! Given that a large proportion of the Wine devs are working for CodeWeavers, we thought that we'd do WineConf right after our annual company meeting, to take advantage of most people being in town already. So the plan is to hold WineConf on Saturday September 27, 2025. The location is The Hague, Netherlands. In fact it will be the exact same venue as WineConf 2018, which I'm sure many of you remember fondly ;-) You can find all the details here: https://gitlab.winehq.org/wine/wine/-/wikis/WineConf/WineConf-2025 Please note that we ask people to register so that we can get a headcount for the hotel. Attending is free of charge, and travel sponsorship is available. Looking forward to seeing many of you there! -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine staging 10.6 release
by Alistair Leslie-Hughes 21 Apr '25

21 Apr '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.6 (333 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * user32: Call UpdateWindow() during DIALOG_CreateIndirect. * Send WM_NCPOINTERUP on focus regain. * cryptext: Implement CryptExtOpenCER. Removed (No longer required). * d3dx9_36-DDS (fixed upstream) Added: * None Updated: * vkd3d-latest * odbc32-fixes 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

Upcoming vkd3d 1.16 release
by Henri Verbeet 15 Apr '25

15 Apr '25

Hi all, The planned release date for vkd3d 1.16 is May 20. That means the public API will become frozen a week from now on April 22, and features will be frozen two weeks before the release, on May 6. This (of course) does not mean that development should slow down or stop; after making sure that we're in good shape to release, this would be the ideal time to make sure any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 1.17 is August 21. Regards, Henri

1 0

Apple Silicon compilation
by robert lippmann 10 Apr '25

10 Apr '25

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

5 8

Wine staging 10.5 release
by Alistair Leslie-Hughes 06 Apr '25

06 Apr '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.5 (336 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Add support for _NET_ACTIVE_WINDOW. * user32: Before asking a WM to activate a window make sure that the window is in foreground and not minimized. * shell32: Added stub for IEnumObjects interface. * shell32: Added stub for IObjectCollection interface. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * ntdll-Syscall_Emulation * ntdll-ForceBottomUpAlloc 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

Re: Troubleshooting openSUSE's packaging process
by Alexander Leithner 05 Apr '25

05 Apr '25

Am 04.04.25 um 15:44 schrieb Alexandre Julliard: > Alexander Leithner <aleithner(a)level101.at> writes: >> Shouldn't GCC provide support for -mabi=ms out of the box? > > Yes, there must be something else going on. Is the config.log file > available? OK, I've managed to extract config.log from a local OBS build. The section relevant to -mabi=ms reads: configure:20674: checking for working -mabi=ms configure:20693: gcc -m64 -c -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -mabi=ms conftest.c >&5 conftest.c: In function 'a': conftest.c:165:79: error: control reaches end of non-void function [-Werror=return-type] 165 | int a(int b, ...) { __builtin_ms_va_list list; __builtin_ms_va_start(list,b); } | ^ cc1: some warnings being treated as errors configure:20693: $? = 1 Indeed, the build script on OBS exports a bunch of additional flags before configuring Wine as seen above, including setting -Werror=return-type. Running configure with CFLAGS='-Werror=return-type ' also is enough to reproduce OBS' config.log output locally on my machine. Is this a bug in -mabi=ms detection or should OBS not set -Werror=return-type? As a side note, OBS also enables Fortify. Isn't this subsequently disabled by configure anyway? If so, I imagine OBS could just not enable it in the first place, right? Thanks for your help! Best, Alexander Leithner

2 2

Wine with 64 bit prefix and databases
by Ilya Sokolov 04 Apr '25

04 Apr '25

Hello It may be not the best place to send the question to this list, but I have tried it on different forums and got no answer. I have a windows C++ application, which should be run in x64 environment due to a memory consumption. One of users of the application requires it run on Linux. The application is rather big and uses some windows-specific features, like COM interfaces, so it would be hard to make it cross-platform. Therefore it was decided to try running the application under Wine. The application uses an MS Access database , which contains some parameters and settings for calculations. The application successfully runs under WINE until it tries to connect to the database, because there is no ADO data provider available. I have tried installing MDAC via winetricks, downloading and installing Access Runtime 2010 and 2016, but all with ho success. Could you tell me what is the proper way of setting up the access ADO driver in WINE in x64? If it is not possible now, could you tell me if any database works on wine in 64 bit prefix, so I will change the database type in the application. Thank you! Best Regards, Ilia Sokolov

2 1

Troubleshooting openSUSE's packaging process
by Alexander Leithner 03 Apr '25

03 Apr '25

Hi all, back in October [1] I asked for advice on building Winelib DLLs because I was unable to compile 64-bit DLLs on my openSUSE Tumbleweed machine. I've since opened bug 1231820 [2] on openSUSE's Bugzilla that has yet to be resolved (which I understand, given that developing Wine-only applications is pretty niche, I reckon). While I can now (with Wine 10.0 from openSUSE's repositories) compile 32-bit Winelib DLLs without having to explicitly specify the library search path, 64-bit DLLs still don't work. This is because the packages are missing the relevant archive files (*.a) for 64-bit ELF; that is, all the libraries (*.so) are present in /usr/lib64/wine/x86_64-unix, but the corresponding *.a files are not. I was trying to troubleshoot this earlier today but I'm now lost (since I cannot, for the life of me, reproduce the build process behaviour) and would be grateful for any discussion of what I might be misunderstanding/doing wrong or what might be going wrong with the packaging process. The first noteworthy observation is that the RPM spec file [3, see lines 367-449] excludes all archive files when the package built is not the "-devel" variant, which is fine, but only includes the i386-unix archives when "-devel" is built. That is probably an oversight, but not the main problem, I reckon. Namely: The x86_64-unix *.a files do not show up in the build logs [4] at all (Ctrl-F for "unix/libwinecrt0.a", for example). Even more, RPM itself complains that the files it should exclude are not found when building the non-devel variant of the package (Ctrl-F for "not found", messages around the 999s mark). This, to me, indicates that the files aren't even built. As can be seen in the logs, openSUSE uses the following ./configure command line to build 64-bit Wine: ../configure --host=x86_64-suse-linux --build=x86_64-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --enable-win64 --verbose (I've omitted prefix- and dir-related switches). I've built Wine from source with the following command line: ../configure [...] --build=x86_64-suse-linux --build=x86_64-suse-linux --enable-win64 (I've omitted --prefix only here). This produces an environment which can correctly build both 32-bit as well as 64-bit Winelib DLLs (without needing to set -L explicitly, as expected). I can see install-sh calls, as expected, for the *.a files in lib64/x86_64-unix, which are absent from the OBS build logs. My commandline generates lib64/x86_64-unix and lib64/x86_64-windows. On the other hand, the openSUSE build log for wine-devel-32bit [5] shows the i386-unix archive files being generated and installed. For 32-bit, they're using: ../configure --host=i586-suse-linux --build=i586-suse-linux --program-prefix= [...] --with-x --with-wayland --with-gstreamer --verbose Since I don't expect --with-x --with-wayland --with-gstreamer --verbose to change anything on whether archive files are built, how come the 64-bit build on OBS is not providing these *.a for x86_64-unix? I posted some more commandlines which don't seem to work correctly to the linked Bugzilla issue [2] back in December. I'm unsure if any of those I've tried there should be expected to produce correct results, so I'm focused on understanding of what's wrong with the 64-bit OBS build. Thanks for any insight, advice, pointers, or corrections you might have for me. Regards, Alexander Leithner [1]: https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/thre… [2]: https://bugzilla.opensuse.org/show_bug.cgi?id=1231820 [3]: https://build.opensuse.org/projects/openSUSE:Factory/packages/wine/files/wi… [4]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/wi… [5]: https://build.opensuse.org/public/build/openSUSE:Factory/standard/i586/wine…

2 1

Question about `wineboot: Create section objects for known dlls' patch
by Mitch Wilkinson 03 Apr '25

03 Apr '25

2 1

Transition of power
by Alex Henrie 03 Apr '25

03 Apr '25

Loyal vintners and vintresses, It is necessary to call your attention to the current state of the regression leaderboard: Rémi Bernon is up to 20 regressions.[1] In an email dated 14 November 2024, our esteemed Principal Oenologist, Alexandre Julliard, stated:[2] > As with the regressions page, the goal should be to *not* be number one on the list. The plain meaning is that being Sommelier-in-Chief is a thankless job that no one in their right mind should aspire to. Nonetheless, it is an indisputable fact that Rémi's Julliard Rank is now 33% higher than Julliard himself.[3] (Before the Wine 10.0 code freeze Elizabeth Figura was the heir presumptive,[4] but her rising star has since fallen to third place.) Rémi has far and away proved his greater worthiness. Therefore, by law and custom, Alexandre must step down and make room for a new leader. A coronation will be held at the next WineConf, with light refreshments following. Sincerely, The High Council of the International Monarchist League [1] https://source.winehq.org/regressions [2] https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/thre… [3] https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/thre… [4] https://web.archive.org/web/20240915073049/https://source.winehq.org/regres…

3 4

Wine staging 10.4 release
by Alistair Leslie-Hughes 22 Mar '25

22 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.4 (341 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9: Implement d3dx_effect_SetRawValue. * d3dx9/tests: Implement tests for d3dx_effect_SetRawValue(). * winex11.drv: Don't use MWM_DECOR_RESIZEH, window resizing is controlled by MWM_FUNC_RESIZE. * winex11.drv: Don't add MWM_DECOR_BORDER to windows without a caption. * winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. Removed (No longer required). * None Added: * msxml3: Correct regression when looping element properties. Updated: * vkd3d-latest * Staging 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

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

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