- wine-devel - winehq.org

Wine staging 10.10 release
by Alistair Leslie-Hughes 14 Jun '25

14 Jun '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.10 (348 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * None 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.

1 0

Is it normal that the COM vtbl structure cannot be aligned between Windows and Wine
by zhengxianwei 11 Jun '25

11 Jun '25

In wine, Visual2Vtbl ``` typedef struct IDCompositionVisual2Vtbl { BEGIN_INTERFACE /*** IUnknown methods ***/ HRESULT (STDMETHODCALLTYPE *QueryInterface)( IDCompositionVisual2 *This, REFIID riid, void **ppvObject); ULONG (STDMETHODCALLTYPE *AddRef)( IDCompositionVisual2 *This); ULONG (STDMETHODCALLTYPE *Release)( IDCompositionVisual2 *This); /*** IDCompositionVisual methods ***/ HRESULT (STDMETHODCALLTYPE *SetOffsetX)( IDCompositionVisual2 *This, float offset_x); HRESULT (STDMETHODCALLTYPE *SetOffsetXAnimation)( IDCompositionVisual2 *This, IDCompositionAnimation *animation); HRESULT (STDMETHODCALLTYPE *SetOffsetY)( IDCompositionVisual2 *This, float offset_y); ``` setOffsetX (float *) at offset 0x18 [image: visual2vtbl.png] But in windows 0x18 is setOffsetX (Animation *) Is this correct?

2 4

Mismatch Between win32syscalls.h and Windows System Call Numbers
by zhengxianwei 05 Jun '25

05 Jun '25

The APIs and call numbers in win32syscalls.h don't seem to match those in the Windows system. NtGdiAlphaBlend is listed as 4 in win32syscalls.h, but in reality, it's 0x1075 in win32u.dll on Windows 11. So are these values user-defined?

6 7

How to implement
by zhengxianwei 03 Jun '25

03 Jun '25

Hello, I would like to implement part of the logic within dcomp.dll in order to properly support applications that depend on it. I found that Zhiyi Zhang has implemented some data structures and interface stubs: https://gitlab.winehq.org/zhiyi/wine/-/commits/directcomposition?ref_type=h… Among these, the only method with actual logic appears to be IDCompositionDevice::Commit. However, after reviewing the implementation, I suspect there may be an issue with the current approach. It seems that Zhiyi Zhang starts a separate thread for each IDCompositionDevice, and this thread runs at a fixed refresh rate. But this approach appears to introduce a problem: from the window's (HWND) perspective, there are now *two threads* concurrently updating its device context. This results in a frame sequence similar to the following (note: the frame intervals are illustrative only): gdi_frame | dcomp_frame | gdi_frame | gdi_frame | dcomp_frame In this model, GDI-generated frames and DComp-generated frames are interleaved. Is my understanding correct? If so, I believe this method may lead to *inaccurate rendering results*, although I am not entirely certain about the exact consequences (as I am not an expert in this area). Therefore, I have decided to pursue an approach that produces a *standardized frame stream* like the following: gdi_mix_dcomp_frame | gdi_mix_dcomp_frame | gdi_mix_dcomp_frame In other words, I plan to merge GDI and DComp content before presenting each frame, ensuring consistency in the final output. I’ve reviewed the normal GDI frame refresh process, and it seems to follow this path: --> flush_window_surfaces --> window_surface_flush --> x11drv_surface_flush I’m planning to insert the following logic inside x11drv_surface_flush: if (is_hwnd_bind_to_dcomp(hwnd)) { struct Surface *final = get_comp_surface(hwnd); blend_dcomp_surface_over_gdi(dest_surface, final); } However, there’s still a question regarding *how to access the DComp data* inside x11drv_surface_flush. One option is to do the composition inside IDCompositionDevice::Commit() like this: void IDCompositionDevice_Commit() { composite_proc(); ... ... push_frame_to_x11drv(); } Another option is to *directly call into DComp APIs from within x11drv* to retrieve the surface data on demand. However, *both approaches feel somewhat unnatural*, and from what I can tell, Windows seems to establish some kind of *internal channel* to pass the composed content to the compositor. Is there a better or more canonical way to do this? Any suggestions or guidance would be greatly appreciated.

3 5

Wine staging 10.9 release
by Alistair Leslie-Hughes 01 Jun '25

01 Jun '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.9 (342 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * [44931] kernel32: Limit old exe to 3MB available space 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.

1 0

IRandomAccessStream doesn't belong in windows.storage
by light gray 21 May '25

21 May '25

Hi devs! I've recently noticed that there's a new `windows.storage` WinRT library within Wine, and the library houses a stubbed implementation for `IRandomAccessStream`. There's an issue however. Looking at Windows registry keys to see which libraries register which runtime classes, it appears `shcore` houses the implementation for `IRandomAccessStream`. Not `windows.storage`. While inherently this isn't a problem since applications acquire runtime classes via `RoGetActivationFactory`, this could pose an issue later down the line when more WinRT interfaces get implemented within Wine. Mainly with how different classes are registered at compile time. Not only that, it would also make implementing functions such as `CreateRandomAccessStreamOnFile` a bit more complicated. As a reference, the following is my own experimental implementation of `IRandomAccessStream`: https://github.com/Weather-OS/WineCoreUAP/commit/318d3b8ecb036f04dcf6365235… Best wishes, Weather.

3 3

irc.libera.chat ?
by zhengxianwei 19 May '25

19 May '25

May I ask, what's the difference between asking questions on irc.libera.chat and asking here? Will this place gradually be phased out, with activity gradually shifting over there?

2 2

How to use AddressSanitizer with Wine?
by Alex Henrie 18 May '25

18 May '25

Dear oenologists, I would like to use GCC's AddressSanitizer [1] to investigate a memory corruption bug in Wine. There must be a way to do it because I see multiple references to "ASan" in the Wine commit log in commits from this year.[2] I found some instructions on the WineHQ wiki,[3] but I get a myriad of linker errors when I try to follow them. What Linux distributions can successfully compile Wine with libasan? Are there special steps not mentioned in the wiki? Does AddressSanitizer work with MinGW, or only with non-PE builds? I'd love to get AddressSanitizer working myself, but even if I can't, thanks to Bernhard and Nikolay for using it to fix a lot of bugs already. -Alex [1] https://github.com/google/sanitizers/wiki/AddressSanitizer [2] https://gitlab.winehq.org/wine/wine/-/commits/master?search=ASan [3] https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#memory--address-c…

2 4

How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?
by zhengxianwei 18 May '25

18 May '25

Hello, I'm planning to add the following line to apisetschema.spec: *api-ms-win-power-setting-l1-1-1 = powrprof.dll* However, this causes a hash conflict with the existing line: *apiset api-ms-win-power-setting-l1-1-0 = powrprof.dll* May I ask how you usually resolve such conflicts? I'm concerned that removing version 1-0 might cause some older applications to stop working. Would it be possible to delete the router for 1-0 and instead add a new line like this? *ln -s powrprof.dll api-ms-win-power-setting-l1-1-0*

3 3

Wine staging 10.8 release
by Alistair Leslie-Hughes 17 May '25

17 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.8 (344 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * odbc32: SQLColAttributesW accept field id SQL_COLUMN_NAME. Removed (No longer required). * None 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

Pre-commit
by robert lippmann 16 May '25

16 May '25

Hi all, I was looking in the docs, and came across this (https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#removing-trai…): "It fixes whitespace on all the commits that you've made. I think it's pretty good about merge conflicts due to whitespace as well. I don't know of a way of doing this at commit time though.” Well, actually there is. Pre-commit (https://pre-commit.com/). Actually fixing whitespace is a built in rule, I believe. And there are various others tailored to different languages. It’s used pretty extensively in Python development, but doesn’t need Python. Since it runs in node, there’s a VSCode extension for it. So, I was wondering if there was any interest in perhaps adding the yaml configurations to the wine source tree, and figuring out what rules might be useful to implement. Thanks, Rob

1 0

Gitlab workflow question
by robert lippmann 16 May '25

16 May '25

Hi all, I submitted a patch, and needed to make changes. I made the changes, but am not sure how to submit it for re-review. I’m used to GitHub, and less formal development practices where it just automatically pops up as open again. Is there something I need to do to get it so it’s mergeable again? I’ve been rebasing for weeks. Should I just close the MR, and submit a new one? Thanks, Rob

2 2

[RFC] Running Wine under AddressSanitizer
by Yuxuan Shui 13 May '25

13 May '25

Hi all, I've been working on this for a while and the list of changes are getting long. So I think this is a good time as ever to announce it, and get some feedback to make sure I haven't gone too far off the rails. This email is a bit long. What is this about? =================== AddressSanitizer (ASan for short) is one of a class of tools that help with discovering common coding mistakes. ASan specifically detects memory problems, like buffer overflows, use after frees, memory leaks, etc. It has been extremely successful in the past decade, and the list of bugs it helped discover is very very long. It has even already seen successes in the wine project as well. @bernhardu was able to get the PE side of wine to work with ASan (with some exceptions) using llvm-mingw, after he fixed [1] a handful of incompatibility problems in llvm compiler-rt. And with that many bugs [2] were then discovered and fixed. And my plan is to take this a step further. [1]: https://github.com/llvm/llvm-project/pulls?q=is%3Apr+is%3Aclosed+author%3Ab… [2]: https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-04-26_wine-10.… Goals ===== I want this to be a quick and easy to use tool, the first thing one would reach for when seeing something that might be a memory related problem. e.g. I spend 5 minutes reproducing the bug with an ASan-enabled wine build, if it catches it, then I am done; otherwise I move on with my usual debugging routine, without having wasted too much time. I also want it to be a first line of defence, which runs in CI to catch occasional bugs that slip through reviews. In my mind, this means 1) it must be easy to set up, ideally just a flag passed to `configure`, no fuss. 2) it should cover as much of wine as possible, both PE and unix, and ideally all PE DLLs. Current status ============== Wine builds and runs. A majority of test cases pass, but some failures seem to be ASan related, which I still need to investigate. Both stack and heap problems are detected and reported. Stack traces are captured, but only on the PE side, and are not symbolized yet - I need to pipe the numbers into llvm-symbolizer. Stack traces aren't being saved for heap allocations and frees, so for use-after-frees the reports aren't very useful yet. Fiber support is TODO. Leak detection is TODO as well. Works done so far ================ You can find my branch here: [3]. To build it, you need either clang, or a slightly patched [4] gcc, and you just run configure with `--enable-sanitize`. I tried to put into the commit messages as comprehensive a list of what I did as possible, but I'll also provide an overview here. It's very abbreviated to not make this email even longer. If you need to know of how ASan works, there is a quick explanation here [5]. Since no existing ASan runtimes can support the unix and the PE side at the same time, I chose to write my own ASan runtime. The runtime is made part of ntdll, since that's the first DLL that loads. A non-standard shadow offset was chosen, so in the new WoW64 mode the 32-bit and the 64-bit side can share a common shadow. Shadow memory is mapped very early inside `virtual_init` to make sure we can enable ASan for as much code as possible (though doing it inside the loader is also an option). Some care needed to be taken to make sure no false positives show up after stack manipulations (e.g. unwinding). Redzoning and quarantining is added to ntdll's heap allocator, though I don't like that. [3]: https://gitlab.winehq.org/yshui/wine/-/commits/address-sanitizer-presentable [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119926 [5]: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm Request for help ================ I intend to continue working on this, and I don't really see any technical challenges that would make this fundamentally undoable. But I do worry that certain things I had/will have to do might make this not upstreamable. So, I think I need some guidance. (I will open a draft MR on winehq gitlab shortly, if you prefer commenting there). Bad things I did to get it working ---------------------------------- There are certain things I did that didn't feel good when I did them, so I am listing them here to see if anyone has a better way to do them. - ASan runtime as part of ntdll. I can't think of a better place to put it, since the runtime needs to be available before PE code runs. This also means all these functions are exported from ntdll, and I have yet to find a way to not export them when ASan is disabled. - dinput/tests and ntoskrnl.exe/tests need to be linked with ntdll, since they need to get their ASan runtime from ntdll. - Things I added to winecrt0. ASan uses some global variables for information such as where the shadow was mapped, and dynamically linked libraries need this information too. On the unix side the dynamic linker will nicely find them for you, but the same doesn't work with PE. So ASan duplicates these variables for each DLLs. In the vanilla ASan runtime, this comes from linking with a "dynamic runtime thunk"; in wine, I felt winecrt0 is the best place for them? These variables also need to be initialized, which means calling an ASan interface function which is exported from ntdll, from `DllMainCRTStartup`. This meant I had to add `-Wl,--{start,end}-group` for starters, because now libntdll.a and libwinecrt0.a have circular dependencies. Additionally though this works for other DLLs, it becomes a problem when winecrt0 is linked into ntdll, which creates a importing-from-self situation. I added a `DllMainCRTStartup` to ntdll, so the one from libwinecrt0.a is not pulled in, thus breaking the cycle. But it definitely feels wrong. (Vanilla ASan does this initialization by putting functions into the `.CRT$XIB` section, which the CRT will call on DLL load. I was told wine CRT doesn't implement this). - `__WINE_FRAME`. I don't fully understand this, but IIUC this is a hacky exception/unwinding mechanism, for when the compiler doesn't support native __try/__except? These are put on the stack which later the unwinder will look for to find the correct exception handler. This doesn't work since ASan uses fake stack frames, so the unwinder can't find these `__WINE_FRAME`s and thus fails. I get this somewhat working by translating between fake and real stack addresses, ew. I don't know much about SEH, is it really not possible to use it for these __try/__excepts as well? Things I need advices on ----------------------- - Heap. I added ASan redzoning directly to the ntdll heap allocator, which I don't like since it added a lot of complexity to it, and it's not available on the unix side. I want to write an ASan specific allocator, since performance and memory efficiency aren't major concerns here, this allocator can be made simple. But I am not 100% sure if this is a good idea. - Stack trace. What's the best way of capturing stack traces from PE _and_ unix, if we are in a syscall/unix call for example? - Shadow offset. This is a bit complicated. clang supports dynamic shadow offset but mingw-gcc doesn't (it doesn't officially have ASan support), so for max compatibility we want a fixed shadow offset. If we want a single shadow to be shared between 32 and 64 bit in the case of new WoW64, the shadow offset needs to be below 4G, which basically precludes non-relocatable 64-bit PE from being loaded (the shadow takes 16 TiB); or we choose a high shadow offset for 64-bit to avoid conflicts, but that means we need to mirror this shadow into the lower 4G of the address space for 32-bit, which complicates the initialization phase. (If you made it to the end, thank you!) -- Regards Yuxuan Shui

1 0

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

wine-9.0.1-rc1 Available
by Michael Stefaniuc 02 Mar '25

02 Mar '25

Hello, I have pushed wine-9.0.1-rc1 (0186f5408a91049ca9fe564bac36aa7eee718cc3) with tag to https://gitlab.winehq.org/mstefani/wine/-/tree/oldstable https://people.redhat.com/mstefani/wine/stable/ And created the merge request https://gitlab.winehq.org/wine/wine/-/merge_requests/7462 But more importantly I have created the MR to remove myself as maintainer of Stable: https://gitlab.winehq.org/wine/wine/-/merge_requests/7463 In the the last two years I didn't have the time for Wine. So it is better to make space for somebody else. What's new in this release: - Various bug fixes. ---------------------------------------------------------------- ### Bugs fixed in 9.0.1 (total 74): - #25207 SHFileOperation does not create new directory on FO_MOVE - #33050 FDM (Free Download Manager) crashes with page fault when any remote FTP directory opened - #44863 Performance regression in Prince of Persia 3D - #46070 Basemark Web 3.0 Desktop Launcher crashes - #46074 Visio 2013 crashes with unimplemented function msvcr100.dll.??0_ReaderWriterLock@details@Concurrency@@QAE@XZ - #48110 Multiple .NET 4.x applications need TaskService::ConnectedUser property (Toad for MySQL Freeware 7.x, Microsoft Toolkit from MS Office 2013) - #49089 nProtect Anti-Virus/Spyware 4.0 'tkpl2k64.sys' crashes on unimplemented function 'fltmgr.sys.FltBuildDefaultSecurityDescriptor' - #49703 Ghost Recon fails to start - #49877 Minecraft Education Edition shows error during install: Fails to create scheduled task - #51285 The bmpcoreimage test in user32:cursoricon fails on most Windows versions - #51599 cmd.exe incorrectly parses an all-whitespace line followed by a closing parenthesis - #51813 python fatal error redirecting stdout to file - #51957 Program started via HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths should also be started if extension ".exe" is missing - #52399 SIMATIC WinCC V15.1 Runtime installer: SeCon tool fails with error 5 while trying to create 'C:\\windows\Security\\SecurityController' (needs '%windir%\\security') - #52622 windows-rs 'lib' test crashes on unimplemented function d3dcompiler_47.dll.D3DCreateLinker - #52879 ESET SysInspector 1.4.2.0 crashes on unimplemented function wevtapi.dll.EvtCreateRenderContext - #53934 __unDName fails to demangle a name - #54759 Notepad++: slider of vertical scrollbar is too small for long files - #55000 wineserver crashes below save_all_subkeys after RegUnLoadKey - #55268 user32:cursoricon - LoadImageA() fails in test_monochrome_icon() on Windows 8+ - #55282 Flutter SDK can't find "aapt" program (where.exe is a stub) - #55421 Fallout Tactics launcher has graphics glitches - #55619 VOCALOID AI Shared Editor v.6.1.0 crashes with System.Management.ManagementObject object construction - #55724 mfmediaengine:mfmediaengine sometimes gets a threadpool assertion in Wine - #55765 The 32-bit d2d1:d2d1 frequently crashes on the GitLab CI - #55810 Finding Nemo (Steam): window borders gone missing (virtual desktop) - #55876 Acrom Controller Updater broken due to oleaut32 install - #55883 SpeedWave can't draw Window, needs oleaut32.OleLoadPictureFile(). - #55897 cpython 3.12.0 crashes due to unimplemented CopyFile2 - #55945 KakaoTalk crashes when opening certain profiles after calling GdipDrawImageFX stub - #55997 Dolphin Emulator crashes from 5.0-17264 - #56054 Microsoft Safety Scanner crashes on exit on unimplemented function tbs.dll.GetDeviceIDString - #56062 unimplemented function mgmtapi.dll.SnmpMgrOpen - #56078 LibreOffice 7.6.4 crashes on unimplemented function msvcp140_2.dll.__std_smf_hypot3 - #56093 msys/pacman: fails with "fixup_mmaps_after_fork: VirtualQueryEx failed" - #56122 LANCommander won't start, prints "error code 0x8007046C" (ERROR_MAPPED_ALIGNMENT) - #56133 explorer.exe: Font leak when painting - #56135 Dictionnaire Hachette Multimédia Encyclopédique 98 crashes on start - #56139 scrrun: Dictionary does not allow storing at key Undefined - #56168 dbghelp hits assertion in stabs_pts_read_type_def - #56174 Forza Horizon 4 crashes with concrt140.dll.?_Confirm_cancel@_Cancellation_beacon@details@Concurrency@@QEAA_NXZ - #56195 Device name inconsistent casing between GetRawInputDeviceInfo and PnP - #56223 winedbg: crashes after loading gecko debug information - #56235 Windows Sysinternals Process Explorer 17.05 crashes showing Threads property page. - #56243 ShowSystray registry key was removed without alternative - #56244 SplashTop RMM client for Atera crashes on unimplemented function shcore.dll.RegisterScaleChangeNotifications - #56256 Windows Sysinternals Process Explorer 17.05 shows incomplete user interface (32-bit). - #56265 Epic Games Launcher 15.21.0 calls unimplemented function cfgmgr32.dll.CM_Get_Device_Interface_PropertyW - #56271 Free Download Manager no longer works after it updated (stuck at 100% CPU, no visible window) - #56309 Across Lite doesn't show the letters properly when typing - #56334 Page fault when querying dinput8_a_EnumDevices - #56357 Zero sized writes using WriteProcessMemory succeed on Windows, but fail on Wine. - #56361 Geovision Parashara's Light (PL9.exe) still crashes in wine - #56367 Tomb Raider 3 GOG crashes at start - #56369 Advanced IP Scanner crashes on unimplemented function netapi32.dll.NetRemoteTOD - #56372 musl based exp2() gives very inaccurate results on i686 - #56400 SSPI authentication does not work when connecting to sql server - #56434 WScript.Network does not implement UserName, ComputerName, and UserDomain properties - #56493 PresentationFontCache.exe crashes during .Net 3.51 SP1 installation - #56498 Incorrect substring expansion for magic variables - #56503 CryptStringToBinary doesn't adds CR before pad bytes in some cases - #56554 ON1 photo raw installs but wont run the application - #56579 Setupapi fails to read correct class GUID and name from INF file containing %strkey% tokens - #56582 vb3 combobox regression: single click scrolls twice - #56598 Calling [vararg] method via ITypeLib without arguments via IDispatch fails - #56599 HWMonitor 1.53 needs unimplemented function pdh.dll.PdhConnectMachineA - #56609 vcrun2008 fails to install - #56653 GetLogicalProcessorInformation can be missing Cache information - #56666 BExAnalyzer from SAP 7.30 does not work correctly - #56730 Access violation in riched20.dll when running EditPad - #56755 White textures in EverQuest (Unsupported Conversion in windowscodec/convert.c) - #56763 Firefox 126.0.1 crashes on startup - #56781 srcrrun: Dictionary setting item to object fails - #56871 The 32-bit wpcap program is working abnormally ### Changes since 9.0: Alex Henrie (10): tbs: Add GetDeviceIDString stub. include: Add mgmtapi.h and LPSNMP_MGR_SESSION. mgmtapi: AddSnmpMgrOpen stub. msvcp140_2: Implement __std_smf_hypot3. where: Implement search with default options. explorer: Fix font handle leaks in virtual desktop. pdh: Add PdhConnectMachineA stub. ntdll/tests: Delete the WineTest registry key when the tests finish. ntdll/tests: Rewrite the RtlQueryRegistryValues tests and add more of them. ntdll: Succeed in RtlQueryRegistryValues on direct query of nonexistent value. Alexandre Julliard (15): winsta: Start time is an input parameter in WinStationGetProcessSid. oleaut32: Fix IDispatch::Invoke for vararg functions with empty varargs. ntdll: Add default values for cache parameters. secur32/tests: Update count for new winehq.org certificate. gitlab: Add 'build' tag on Linux build jobs. gitlab: Remove make -j options. dnsapi/tests: Update tests for winehq.org DNS changes. urlmon/tests: Fix a test that fails after WineHQ updates. wininet/tests: Update issuer check for winehq.org certificate. urlmon/tests: Skip test if ftp connection fails. user32/tests: Fix some sysparams results on recent Windows. dnsapi/tests: Update DNS names for the new test.winehq.org server. wininet/tests: Update certificate for the new test.winehq.org server. secur32/tests: Update expected results for the new test.winehq.org server. winhttp/tests: Allow some more notifications for the new test.winehq.org server. Alistair Leslie-Hughes (3): fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor. fltmgr.sys: Create import library. ntoskrnl/tests: Add FltBuildDefaultSecurityDescriptor test. Andrew Nguyen (2): oleaut32: Bump version resource to Windows 10. ddraw: Reserve extra space in the reference device description buffer. Bartosz Kosiorek (2): gdiplus/tests: Add GdipDrawImageFX tests except effects or attributes. gdiplus: Partially implement GdipDrawImageFX. Benjamin Mayes (1): windowscodecs: Add conversions from PixelFormat32bppBGRA->PixelFormat16bppBGRA5551. Bernhard Übelacker (10): server: Avoid unloading of HKU .Default registry branch. server: Allow VirtualQueryEx on "limited" handle. wing32: Add tests. wing32: Avoid crash in WinGGetDIBPointer when called with NULL bitmap info. dbghelp: Return early if HeapAlloc failed. ntdll: Fix structure layout in RtlQueryProcessDebugInformation for 64-bit. wininet: Add missing assignment of return value. wininet: Avoid crash in InternetCreateUrl with scheme unknown. cmd: Handle lines with just spaces in bracket blocks. cmd: Avoid execution if block misses closing brackets. Dmitry Timoshkov (4): oleaut32: Do not reimplement OleLoadPicture in OleLoadPicturePath. oleaut32: Factor out stream creation from OleLoadPicturePath. oleaut32: Implement OleLoadPictureFile. kerberos: Allocate memory for the output token if requested. Eric Pouech (4): dbghelp: Support redefinition of a range statement. server: Allow 0-write length in WriteProcessMemory(). cmd: Add test for substring handling in 'magic' variable expansion. cmd: Fix substring expansion for 'magic' variables. Esme Povirk (1): gdiplus: Prefer Tahoma for generic sans serif font. Fabian Maurer (11): win32u: Factor out scroll timer handling. win32u: Only set scroll timer if it's not running. oleaut32: Add test for invoking a dispatch get-only property with DISPATCH_PROPERTYPUT. oleaut32: Handle cases where invoking a get-only property with INVOKE_PROPERTYPUT returns DISP_E_BADPARAMCOUNT. riched20: In para_set_fmt protect against out of bound cTabStop values. mmdevapi/tests: Add tests for IAudioSessionControl2 GetDisplayName / SetDisplayName. mmdevapi/tests: Add tests for IAudioSessionControl2 GetIconPath / SetIconPath. mmdevapi/tests: Add tests for IAudioSessionControl2 GetGroupingParam / SetGroupingParam. mmdevapi: Implement IAudioSessionControl2 GetDisplayName / SetDisplayName. mmdevapi: Implement IAudioSessionControl2 GetIconPath / SetIconPath. mmdevapi: Implement IAudioSessionControl2 GetGroupingParam SetGroupingParam. Felix Münchhalfen (2): ntdll: Use pagesize alignment if MEM_REPLACE_PLACEHOLDER is set in flags of NtMapViewOfSection(Ex). kernelbase/tests: Add a test for MapViewOfFile3 with MEM_REPLACE_PLACEHOLDER. Hans Leidekker (12): wbemprox: Protect tables with a critical section. wbemprox: Handle implicit property in object path. netprofm: Support NLM_ENUM_NETWORK flags. netprofm: Set return pointer to NULL in networks_enum_Next(). msi: Install global assemblies before running deferred custom actions. msi: Install global assemblies after install custom actions and before commit custom actions. wpcap: Handle different layout of the native packet header structure on 32-bit. winhttp/tests: Fix test failures introduced by the server upgrade. secur32: Handle GNUTLS_MAC_AEAD. secur32/tests: Switch to TLS 1.2 for connections to test.winehq.org. secur32/tests: Mark some test results as broken on old Windows versions. crypt32/tests: Fix a test failure. Helix Graziani (1): cfgmgr32: Add CM_Get_Device_Interface_PropertyW stub. Jinoh Kang (4): include: Add definition for FILE_STAT_INFORMATION. ntdll/tests: Add tests for NtQueryInformationFile FileStatInformation. ntdll: Implement NtQueryInformationFile FileStatInformation. kernelbase: Replace FileAllInformation with FileStatInformation in GetFileInformationByHandle(). Kartavya Vashishtha (1): kernelbase: Implement CopyFile2(). Louis Lenders (3): shcore: Add stub for RegisterScaleChangeNotifications. shell32: Try appending .exe when looking up an App Paths key. wmic: Support interactive mode and piped commands. Martin Storsjö (1): musl: Fix limiting the float precision in intermediates. Michael Stefaniuc (2): gitlab: Do not run the build script on each commit. tools: Get the ANNOUNCE bug list from the stable-notes git notes. Nicholas Tay (1): win32u: Preserve rawinput device instance ID case in add_device(). Nikolay Sivov (10): scrrun/dictionary: Add support for hashing VT_EMPTY keys. scrrun/dictionary: Add support for hashing VT_NULL keys. scrrun/dictionary: Handle VT_EMPTY/VT_NULL keys. wshom/network: Use TRACE() for implemented method. wshom/network: Implement GetTypeInfo(). wshom/network: Implement ComputerName() property. wshom/network: Check pointer argument in get_UserName(). wshom/network: Implement UserDomain property. d2d1: Fix a double free on error path (Valgrind). scrrun/dictionary: Implement putref_Item() method. Paul Gofman (4): explorer: Don't pop start menu on "minimize all windows" systray command. explorer: Don't pop start menu on "undo minimize all windows" systray command. winhttp: Always return result at once if available in WinHttpQueryDataAvailable(). winhttp: Always return result at once if available in WinHttpReadData(). Peter Johnson (1): wined3d: Added missing GTX 3080 & 1070M. Piotr Caban (5): msvcp140_2: Fix i386 export names. msvcp140_2: Implement __std_smf_hypot3f. msvcp140_t/tests: Add __std_smf_hypot3 tests. concrt140: Add _Cancellation_beacon::_Confirm_cancel() implementation. msvcrt: Store _unDName function parameter backreferences in parsed_symbol structure. Roland Häder (1): wined3d: Added missing GTX 1650. Rémi Bernon (9): dinput/tests: Add some IRawGameController2 interface tests. windows.gaming.input: Stub IRawGameController2 interface. explorer: Restore a per-desktop ShowSystray registry setting. secur32/tests: Update the tests to expect HTTP/2 headers. imm32/tests: Add todo_himc to some ImmTranslateMessage expected calls. urlmon/tests: Expect "Upgrade, Keep-Alive" connection string. user32/tests: Add flaky_wine to some SetActiveWindow tests. wininet: Parse multi-token Connection strings for Keep-Alive. user32/tests: Fix cursoricon tests on recent Windows versions. Sam Joan Roque-Worcel (1): win32u: Make SCROLL_MIN_THUMB larger. Santino Mazza (1): crypt32: Fix CryptBinaryToString not adding a separator. Tim Clem (1): gitlab: Update configuration for the new Mac runner. Tuomas Räsänen (2): setupapi/tests: Add tests for reading INF class with %strkey% tokens. setupapi: Use INF parser to read class GUID and class name. Vijay Kiran Kamuju (10): msvcr100: Add _ReaderWriterLock constructor implementation. wine.inf: Create security directory. concrt140: Add stub for _Cancellation_beacon::_Confirm_cancel(). taskschd: Implement ITaskService_get_ConnectedUser. taskschd: Return success from Principal_put_RunLevel. taskschd: Implement TaskService_get_ConnectedDomain. d3dcompiler: Add D3DCreateLinker stub. netapi32: Add NetRemoteTOD stub. mscms: Add stub for WcsGetDefaultColorProfile. wevtapi: Add stub EvtCreateRenderContext(). Zebediah Figura (4): shell32/tests: Remove obsolete workarounds from test_move(). ddraw: Use system memory for version 4 vertex buffers. ddraw: Upload only the used range of indices in d3d_device7_DrawIndexedPrimitive(). ddraw/tests: Test GetVertexBufferDesc(). Zhenbo Li (1): shell32: Create nonexistent destination directories in FO_MOVE. Zhiyi Zhang (6): include: Rename DF_WINE_CREATE_DESKTOP to DF_WINE_VIRTUAL_DESKTOP. server: Inherit internal desktop flags when creating desktops. rtworkq: Avoid closing a thread pool object while its callbacks are running. rtworkq: Avoid possible scenarios that an async callback could be called twice. user32/tests: Add some ReleaseCapture() tests. win32u: Only send mouse input in ReleaseCapture() when a window is captured. bye michael

1 0

Re: Apple Silicon compilation
by Donald Smith 27 Feb '25

27 Feb '25

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 >

1 0

Question about `Avoid const strarray pointers in all functions' patch
by Mitch Wilkinson 27 Feb '25

27 Feb '25

2 1

Wine staging 10.2 release
by Alistair Leslie-Hughes 22 Feb '25

22 Feb '25

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.

1 0

Ask for help
by 谢威 21 Feb '25

21 Feb '25

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

1 0

Re: [PATCH] ntsync: Check wait count based on byte size.
by Elizabeth Figura 20 Feb '25

20 Feb '25

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

1 0

[PATCH v2] ntsync: Check wait count based on byte size.
by Elizabeth Figura 20 Feb '25

20 Feb '25

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

1 1

[PATCH] ntsync: Check wait count based on byte size.
by Elizabeth Figura 19 Feb '25

19 Feb '25

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

1 0

Re: [PATCH] ntsync: Set the permissions to be 0666
by Elizabeth Figura 18 Feb '25

18 Feb '25

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.

1 0

Re: [PATCH] ntsync: Set the permissions to be 0666
by Elizabeth Figura 15 Feb '25

15 Feb '25

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

1 0

Re: [PATCH] ntsync: Set the permissions to be 0666
by Elizabeth Figura 14 Feb '25

14 Feb '25

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.

1 0

Re: [PATCH] ntsync: Set the permissions to be 0666
by Elizabeth Figura 14 Feb '25

14 Feb '25

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.

1 0

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