- wine-devel - winehq.org

Does the timing of composition need to be moved from dcomp.dll to win32u?
by zhengxianwei 19 Jun '25

19 Jun '25

Zhiyi Zhang provided an implementation of DComp composition： https://gitlab.winehq.org/zhiyi/wine/-/commit/ef4f90c2ae909f4a732f0ebeae3b7… I created a simple sample that renders three equally sized red circles with varying alpha values on a plain white background window. On Windows, it displays as follows. [image: dcomp_test_window.png] But on Linux, it display as follows. [image: dcomp_test_wine.png] One of the main issues here is that the background turns black. This is because the foreground (swapchain) is not alpha-blended with the background (GDI); instead, it is simply overlaid using BitBlt. ``` * BitBlt(dst_dc, 0, 0, rect.right - rect.left, rect.bottom - rect.top, src_dc, 0, 0, SRCCOPY);* ``` So I added an alpha_blend step here instead of simply using the original BitBlt. ``` s1 = src_data; d1 = dst_data; for (int i = 0; i < height; i++) { for (int j = 0; j < width; j++) { // src is alpha pre multiple float bg_alpha = ((255.f - s1[3])) / 255; d1[0] = (d1[0] * bg_alpha) + s1[0]; d1[1] = (d1[1] * bg_alpha) + s1[1]; d1[2] = (d1[2] * bg_alpha) + s1[2]; s1 += 4; d1 += 4; } } //iret = SetDIBits(dst_hdc, dst_bitmap, 0, height, dst_data, &bmi, DIB_RGB_COLORS); iret = SetDIBitsToDevice(dst_hdc, 0, 0, width, height, 0, 0, 0, height, dst_data, &bmi, DIB_RGB_COLORS); ``` The new display effect is as follows. [image: dcomp_test_wine_alpha_blend.png] It looks like basic blending is working, but the alpha values of the circles are lost. After analyzing the issue, I found the following cause. I'll draw a diagram to briefly illustrate the cause of this issue. My original expectation of the image generation process [image: flush1.png] But the actual process is as follows [image: image.png] After the bitmap is alpha-blended and displayed on the screen, it is retrieved again in the next frame and repeatedly involved in alpha blending — resulting in redundant computations. I personally think that a more reasonable solution would be to insert window_surface_composition within window_surface_flush to more thoroughly resolve these kinds of issues [image: image.png] During window_surface_flush, composite the current surface with the swapchain's surface into an offscreen surface, then flush that to the screen. This way, the original window surface won't be affected. I'm trying to fix this issue now — do you have any suggestions?

2 3

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

Wine staging 10.1 release
by Alistair Leslie-Hughes 09 Feb '25

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

1 0

FOSDEM
by Huw Davies 30 Jan '25

30 Jan '25

Hi folks, Many CodeWeavers folks will be in Brussels this weekend attending FOSDEM. If anybody else is around, or near Brussels, please feel free to either drop me an email or simply turn up to the BrewDog on Friday or Saturday evenings from 17:00. Many of us will be in Brussels Thursday and Sunday evenings too, but our exact location is less certain; if you let me know you’re interested, I can keep you in the loop. Sorry for the late notice! Huw

1 0

Wine staging 10.0 release
by Alistair Leslie-Hughes 21 Jan '25

21 Jan '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0 (346 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

10.0 release notes, please review
by Alexandre Julliard 20 Jan '25

20 Jan '25

Folks, Here are the draft release notes for Wine 10.0. Please review them and let me know if anything is incorrect or missing. Thanks to Jacek and Rémi for their help! The final 10.0 should be out in a couple of days. -- Alexandre Julliard julliard(a)winehq.org

3 2

Wine staging 10.0-rc6 release
by Alistair Leslie-Hughes 18 Jan '25

18 Jan '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc6 (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

[PATCH] ntsync: Fix reference leaks in the remaining create ioctls.
by Elizabeth Figura 16 Jan '25

16 Jan '25

When ntsync_obj_get_fd() fails, we free the ntsync object but forget to drop the "file" member. This was fixed for semaphores in 0e7d523b5f7a23b1dc6ceceb04e31a60e9e3321d, but that commit did not fix the similar leak for events and mutexes, since they were part of patches not yet in the mainline kernel. Fix those cases. Fixes: 5bc2479a3585b "ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX." Fixes: 4c7404b9c2b57 "ntsync: Introduce NTSYNC_IOC_CREATE_EVENT." Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- drivers/misc/ntsync.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index b6441e978974..055395cde42b 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -781,7 +781,7 @@ static int ntsync_create_mutex(struct ntsync_device *dev, void __user *argp) mutex->u.mutex.owner = args.owner; fd = ntsync_obj_get_fd(mutex); if (fd < 0) - kfree(mutex); + ntsync_free_obj(mutex); return fd; } @@ -802,7 +802,7 @@ static int ntsync_create_event(struct ntsync_device *dev, void __user *argp) event->u.event.signaled = args.signaled; fd = ntsync_obj_get_fd(event); if (fd < 0) - kfree(event); + ntsync_free_obj(event); return fd; } base-commit: 0e7d523b5f7a23b1dc6ceceb04e31a60e9e3321d -- 2.45.2

1 0

Upcoming vkd3d 1.15 release
by Henri Verbeet 15 Jan '25

15 Jan '25

Hi all, As previously announced, the planned release date for vkd3d 1.15 is February 19. That means the public API will become frozen a week from now on January 22, and we'll go into feature freeze on February 5. 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. 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.16 is May 21. Regards, Henri

1 0

Wine staging 10.0-rc5 release
by Alistair Leslie-Hughes 11 Jan '25

11 Jan '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc5 (347 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

Re: [PATCH v7 00/30] NT synchronization primitive driver
by Elizabeth Figura 09 Jan '25

09 Jan '25

On Tuesday, 7 January 2025 13:42:41 CST Peter Zijlstra wrote: > On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote: > > Given a lack of complaints, I've now applied this to my testing tree. > > Thanks for sticking with it! > > Right, so I acked v6, which wasn't preserved. The v7 changes are minor > and seem fine (IIRc I even suggested them some very very long time ago). I wasn't sure it was fine to preserve the ack across changes (even if they were the ones you suggested) and decided to err on the safe side. Thank you for the review!

2 1

Wine staging 10.0-rc4 release
by Alistair Leslie-Hughes 04 Jan '25

04 Jan '25

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc4 (346 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: * None 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 staging 10.0-rc3 release
by Alistair Leslie-Hughes 21 Dec '24

21 Dec '24

Right subject this time. Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc3 (346 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

Wine staging 10.0-rc2 release
by Alistair Leslie-Hughes 21 Dec '24

21 Dec '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc2 (346 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

Wine staging 10.0-rc2 release
by Alistair Leslie-Hughes 14 Dec '24

14 Dec '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc2 (349 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

[PATCH v7 00/30] NT synchronization primitive driver
by Elizabeth Figura 13 Dec '24

13 Dec '24

This patch series implements a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. NT synchronization primitives are unique in that the wait functions both are vectored, operate on multiple types of object with different behaviour (mutex, semaphore, event), and affect the state of the objects they wait on. This model is not compatible with existing kernel synchronization objects or interfaces, and therefore the ntsync driver implements its own wait queues and locking. This patch series is rebased against the "char-misc-next" branch of gregkh/char-misc.git. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The performance measurements described below are copied from earlier versions of the patch set. While some of the code has changed, I do not currently anticipate that it has changed drastically enough to affect those measurements. The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 27/28 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync7 == Previous versions == Changes from v6: * rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT terminology instead of POSIX), * change object creation ioctls to return the fds directly in the return value instead of through the args struct, which simplifies the API a bit. * Link to v6: https://lore.kernel.org/lkml/20241209185904.507350-1-zfigura@codeweavers.co… * Link to v5: https://lore.kernel.org/lkml/20240519202454.1192826-1-zfigura@codeweavers.c… * Link to v4: https://lore.kernel.org/lkml/20240416010837.333694-1-zfigura@codeweavers.co… * Link to v3: https://lore.kernel.org/lkml/20240329000621.148791-1-zfigura@codeweavers.co… * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (30): ntsync: Return the fd from NTSYNC_IOC_CREATE_SEM. ntsync: Rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. ntsync: No longer depend on BROKEN. Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ntsync.rst | 385 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 1 - drivers/misc/ntsync.c | 992 +++++++++++- include/uapi/linux/ntsync.h | 42 +- tools/testing/selftests/Makefile | 1 + .../selftests/drivers/ntsync/.gitignore | 1 + .../testing/selftests/drivers/ntsync/Makefile | 7 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1343 +++++++++++++++++ 11 files changed, 2767 insertions(+), 16 deletions(-) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 tools/testing/selftests/drivers/ntsync/.gitignore create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: cdd30ebb1b9f36159d66f088b61aee264e649d7a -- 2.45.2

1 30

Clarification regarding clean room guidelines and headers / prototypes
by Fabian Maurer 13 Dec '24

13 Dec '24

Hello, Not sure who, apart from Alexandre, could help here, but I wanted to ask for some clarification on the clean room guidelines (https://gitlab.winehq.org/ wine/wine/-/wikis/Clean-Room-Guidelines) Let's say we want to add a few new COM classes / interfaces from WinRT for some program. What is the official way to get those header definitions? Copy paste from the official SDK? Or worse, there is some windows adjacent dlls that only contain typelibs - can we decompile those typelibs to get the COM interface definitions? Or how about undocumented functions that are documented by third parties? ROS is off limits, all others as well? There are for example C# projects that provide P/Invoke definitions of otherwise undocumented functions. I think it would be helpful for the wiki to be updated with a bit of clarification. Thanks in advance, Regards, Fabian Maurer

4 3

wine Conformance-Tests page download url broken
by zhengxianwei 13 Dec '24

13 Dec '24

https://gitlab.winehq.org/wine/wine/-/wikis/Conformance-Tests - https://test.winehq.org/builds/winetest-latest.exe for the 32-bit Windows executable. - https://test.winehq.org/builds/winetest64-latest.exe for the 64-bit Windows executable. download link broken

1 0

Photoshop 2023 flink
by zhengxianwei 13 Dec '24

13 Dec '24

Hello, I am trying to run Photoshop 23 using the DLL generated by VKD3D-Proton. I noticed that after opening an image, dragging it causes display issues. Here’s a video showing the problem: https://www.youtube.com/watch?v=JgWrsFx4GrM (Because I have not been using the successful obs recording, so I switched to recording with my cell phone, the result is worse, sorry!) When I capture frames with RenderDoc, the images appear normal. I suspect the issue might be related to the desktop gui composition process, but I’m unsure how to analyze such problems. Do you have any suggestions? Software information Photoshop23 System information - GPU: GTX 1070ti - Driver: 535.183.01 - Wine version: 9.2 (latest, not proton-wine) - VKD3D-Proton version: (latest)

3 5

Re: [PATCH v6 00/28] NT synchronization primitive driver
by Elizabeth Figura 09 Dec '24

09 Dec '24

On Monday, 9 December 2024 14:24:36 CST Arnd Bergmann wrote: > On Mon, Dec 9, 2024, at 19:58, Elizabeth Figura wrote: > > == Previous versions == > > > > No changes were made from v5 other than rebasing on top of the 6.13-rc1 > > char-misc-next tree. > > > > I would like to repeat a question from the last round of review, though. Two > > changes were suggested related to API design, which I did not make because the > > APIs in question were already released in upstream Linux. However, the driver is > > also completely nonfunctional and hidden behind BROKEN, so would this be > > acceptable anyway? The changes in question are: > > If it was impossible to use the driver, there is no regression. > I feel the entire point of marking it as broken was to be able > to add that type of change. Makes sense. [I figured that the BROKEN was just there to prevent anyone from trying to use a half-finished driver, and the point of committing a half-finished driver was just to reduce the number of patches that needed to be resent.] I'll make these changes and resend. > > * rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT > > terminology instead of POSIX), > > No objections my me on either name. > > > * change object creation ioctls to return the fds directly in the return value > > instead of through the args struct. I would also still appreciate a > > clarification on the advice in [1], which is why I didn't do this in the first > > place. > > > > [1] https://docs.kernel.org/driver-api/ioctl.html#return-code > > The git log tells me that I have written that, but I don't remember > why I put that in, maybe someone else suggested it. > > My feeling right now is that returning a file descriptor number > as a small positive integer from the ioctl() return code makes > sense. On the other hand, returning pointers, negative signed > integers or large (> 32bit) 'unsigned long' values can cause > a number of issues, so I would avoid all those the same way we > discourage passing those integers as a literal 'arg' into ioctl() > instead of going through a pointer. Ah, that makes sense to me, thanks.

1 0

[PATCH v6 00/28] NT synchronization primitive driver
by Elizabeth Figura 09 Dec '24

09 Dec '24

This patch series implements a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. NT synchronization primitives are unique in that the wait functions both are vectored, operate on multiple types of object with different behaviour (mutex, semaphore, event), and affect the state of the objects they wait on. This model is not compatible with existing kernel synchronization objects or interfaces, and therefore the ntsync driver implements its own wait queues and locking. This patch series is rebased against the "char-misc-next" branch of gregkh/char-misc.git. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The performance measurements described below are copied from earlier versions of the patch set. While some of the code has changed, I do not currently anticipate that it has changed drastically enough to affect those measurements. The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 27/28 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Previous versions == No changes were made from v5 other than rebasing on top of the 6.13-rc1 char-misc-next tree. I would like to repeat a question from the last round of review, though. Two changes were suggested related to API design, which I did not make because the APIs in question were already released in upstream Linux. However, the driver is also completely nonfunctional and hidden behind BROKEN, so would this be acceptable anyway? The changes in question are: * rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT terminology instead of POSIX), * change object creation ioctls to return the fds directly in the return value instead of through the args struct. I would also still appreciate a clarification on the advice in [1], which is why I didn't do this in the first place. [1] https://docs.kernel.org/driver-api/ioctl.html#return-code * Link to v5: https://lore.kernel.org/lkml/20240519202454.1192826-1-zfigura@codeweavers.c… * Link to v4: https://lore.kernel.org/lkml/20240416010837.333694-1-zfigura@codeweavers.co… * Link to v3: https://lore.kernel.org/lkml/20240329000621.148791-1-zfigura@codeweavers.co… * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (28): ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. ntsync: No longer depend on BROKEN. Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ntsync.rst | 398 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 1 - drivers/misc/ntsync.c | 989 +++++++++++- include/uapi/linux/ntsync.h | 39 + tools/testing/selftests/Makefile | 1 + .../selftests/drivers/ntsync/.gitignore | 1 + .../testing/selftests/drivers/ntsync/Makefile | 7 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 11 files changed, 2850 insertions(+), 4 deletions(-) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 tools/testing/selftests/drivers/ntsync/.gitignore create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: cdd30ebb1b9f36159d66f088b61aee264e649d7a -- 2.45.2

1 28

Wine staging 10.0-rc1 release
by Alistair Leslie-Hughes 06 Dec '24

06 Dec '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 10.0-rc1 (350 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * windows.networking.connectivity: Add stub dll. * indows.networking.connectivity: Implement IActivationFactory stubs. * windows.networking.connectivity: Implement INetworkInformationStatics stubs. * windows.networking.connectivity: Implement INetworkInformationStatics GetInternetConnectionProfile. * windows.networking.connectivity: IConnectionProfile GetNetworkConnectivityLevel always return internet access. 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

Unable to completely replace vkd3d with vkd3d-proton?
by zhengxianwei 28 Nov '24

28 Nov '24

I tried replacing Wine’s built-in DLLs with the d3d12.dll compiled from vkd3d-proton and the dxgi.dll compiled from dxvk. However, I noticed that Wine’s built-in D3DCompile2 still calls vkd3d_shader_compiler( https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/d3dcompiler_43/compi…), which belongs to vkd3d, not vkd3d-proton. Does this mean that even in Proton, vkd3d and vkd3d-proton coexist, and it’s not possible to completely replace vkd3d? So if there’s a bug in it, I would still need to fix the issue in vkd3d rather than being able to replace it with functions from vkd3d-proton. Is that correct?

3 8

How could I use my own build vkd3d in wine ?
by zhengxianwei 26 Nov '24

26 Nov '24

I want to try modifying and building vkd3d myself, but I’m not sure how to make Wine use my custom-built vkd3d. My development environment is Ubuntu 24.04 + x64.

1 1

Wine staging 9.22 release
by Alistair Leslie-Hughes 23 Nov '24

23 Nov '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.22 (350 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Implement HashLinks field in LDR module data. * ntdll: Use HashLinks when searching for a dll using the basename. 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

How to use DLL files from vkd3d-proton in Wine?
by zhengxianwei 22 Nov '24

22 Nov '24

I am a beginner with Wine and currently using it to run Photoshop 23. I noticed that vkd3d seems to lack support for Tiled Resource, which causes Photoshop’s compatibility check to fail in displaying the correct GPU information. I found that vkd3d-proton appears to implement this feature, so I compiled vkd3d-proton and copied the resulting d3d12.dll and d3d12core.dll directly into Wine’s directory. I also ensured that the required d3d12.dll was loaded correctly. However, when launching Photoshop, it crashes when using certain swapchain features. Setting aside the swapchain crash for now, is my approach of directly using the d3d12.dll generated by vkd3d-proton correct?

2 3

Pending Reviews page
by Alexandre Julliard 19 Nov '24

19 Nov '24

Folks, In our grand tradition of shaming people into doing work, after the Regressions page I'm proud to present the Pending Reviews page: https://source.winehq.org/reviews As with the regressions page, the goal should be to *not* be number one on the list. But feel free to congratulate Huw anyway ;-) Note that the list is a little overestimated, commenting on the diff counts as a review but simply adding a note doesn't, so you may see some MRs in your list that you have actually commented on already. If people find this thing useful we can try to make it smarter. Feedback is welcome! -- Alexandre Julliard julliard(a)winehq.org

2 3

Wine staging 9.21 release
by Alistair Leslie-Hughes 08 Nov '24

08 Nov '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.21 (358 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9_36: Add semi-stub for D3DXOptimizeVertices. Removed (No longer required). * None Added: * [56699] dmime: Semi-Implement IDirectMusicSegment8::GetAudioPathConfig * [55982] dmscript: IDirectMusicScript::EnumRoutine return S_FALSE by default 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

Release plans
by Alexandre Julliard 31 Oct '24

31 Oct '24

Folks, Since there has been little activity this week, and I'm travelling on Friday, I'm going to delay Wine 9.21 until next Friday, November 8. There will then be a 9.22 release two weeks later, and two weeks after that, on December 6, the 10.0-rc1 release will mark the beginning of our annual code freeze period. As usual, the freeze will last until the final 10.0 is released sometime around mid-January. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 31 Oct '24

31 Oct '24

Hi Christian, Thanks for exploring this option, it's great to have a better understanding of the capabilities/limits of mremap. First, a few practical questions: - How would Wine detect the updated mremap, I suppose we would want to create a test persistent mapping on init and see if mremap works on that page? - In my experience Mesa will sometimes return malloc'd pointers from glMapBuffer when using the transfer helper, which I assume has to do with buffer textures. If wine blindly uses remap for all glMapBuffer calls, we'll then end up hitting the private anonymous path, where from what I understand page faults are use to preserve the old page, potentially slowing things down, thoughts? Second, in regards to going forward: I don't have the final call on what path we end up taking 😅. I think it would be good if others from wine-devel pitched into what they think, but here's my opinion: I think the mremap approach should definitely be pursued since it looks like such a simple Kernel patch, but it may also be good to pursue a simple Mesa-Integrated path as well, maybe with Mesa calling into a Wine library to allocate 32-bit pages, as we support non-linux OS's as well. Thanks, Derek Am 10/30/24 um 14:03 schrieb Christian König: > Hi guys, > > so I looked a bit deeper into the problem of duplicating graphics > driver mappings with mremap(). > > This use case of duplicating a mapping into a fixed address is already > supported quite well using mremap(). This is used by a couple of > different emulators to re-create the address space like you would find > it in the specific environment. > > The only problem is that this only works for files and shared memory > at the moment. Graphic driver mappings on the other hand have the > VM_DONTEXPAND and VM_PFNMAP flag set because their mappings shouldn't > grow and can also include VRAM. > > The attached patch changes this restriction for the mremap() function > and so also allows duplicating the VMAs of graphics drivers into the > lower 32bit address space managed by Wine. > > I've tested this with some of AMD's GPU unit tests and it actually > seems to work quite fine. > > Derek please let me know if that solution works for you and if you're > interested in using it. If yes I would go ahead and send the patch to > the Linux memory management folks for discussion. > > Regards, > Christian. > > Am 24.10.24 um 17:06 schrieb Christian König: >> Darek we are unfortunately both partially right. >> >> Linux supports cloning VMAs using mremap() from userspace by using a >> zero old size, but unfortunately only for SHM areas. >> >> See the code in mm/mremap.c: >> /* >> * We allow a zero old-len as a special case >> * for DOS-emu "duplicate shm area" thing. But >> * a zero new-len is nonsensical. >> */ >> if (!new_len) >> return ret; >> >> Going to take a closer look to figure out what would be necessary to >> solve that for GPU drivers as well. >> >> Regards, >> Christian. >> >> Am 24.10.24 um 14:56 schrieb Christian König: >>> I haven't tested it but as far as I know that isn't correct. >>> >>> As far as I know you can map the same VMA at a different location >>> even without MREMAP_DONTUNMAP. And yes MREMAP_DONTUNMAP only work >>> with private mappings, but that isn't needed here. >>> >>> Give me a moment to test this. >>> >>> Regards, >>> Christian. >>> >>> Am 24.10.24 um 10:03 schrieb Derek Lesho: >>>> In my last mail I responded to this approach all the way at the >>>> bottom, so it probably got lost: mremap on Linux as it exists now >>>> won't work as it only supports private anonymous mappings (in >>>> conjunction with MREMAP_DONTUNMAP), which GPU mappings are not. >>>> >>>> Am 10/24/24 um 01:06 schrieb James Jones: >>>>> That makes sense. Reading the man page myself, it does seem like: >>>>> >>>>> -If the drivers can guarantee they set MAP_SHARED when creating >>>>> their initial mapping. >>>>> >>>>> -If WINE is fine rounding down to page boundaries to deal with >>>>> mappings of suballocations and either using some lookup structure >>>>> to avoid duplicate remappings (probably needed to handle unmap >>>>> anyway per below) or just living with the perf cost and address >>>>> space overconsumption for duplicate remappings. >>>>> >>>>> -If mremap() preserves the cache attributes of the original mapping. >>>>> >>>>> Then no GL API change would be needed. WINE would just have to do >>>>> an if (addrAbove4G) { mremapStuff() } on map and presumably add >>>>> some tracking to perform an equivalent munmap() when unmapping. I >>>>> assume WINE already has a bunch of vaddr tracking logic in use to >>>>> manage the <4G address space as described elsewhere in the thread. >>>>> That would be pretty ideal from a driver vendor perspective. >>>>> >>>>> Does that work? >>>>> >>>>> Thanks, >>>>> -James >>>>> >>>>> On 10/23/24 06:12, Christian König wrote: >>>>>> I haven't read through the whole mail thread, but if you manage >>>>>> the address space using mmap() then you always run into this issue. >>>>>> >>>>>> If you manage the whole 4GiB address space by Wine then you never >>>>>> run into this issue. You would just allocate some address range >>>>>> internally and mremap() into that. >>>>>> >>>>>> Regards, >>>>>> Christian. >>>>>> >>>>>> Am 22.10.24 um 19:32 schrieb James Jones: >>>>>>> This sounds interesting, but does it come with the same "Only >>>>>>> gets 2GB VA" downside Derek pointed out in the thread fork where >>>>>>> he was responding to Michel? >>>>>>> >>>>>>> Thanks, >>>>>>> -James >>>>>>> >>>>>>> On 10/22/24 07:14, Christian König wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> one theoretical alternative not mentioned in this thread is the >>>>>>>> use of mremap(). >>>>>>>> >>>>>>>> In other words you reserve some address space below 2G by using >>>>>>>> mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) >>>>>>>> and then use mremap(addr64bit, 0, length, MREMAP_FIXED, >>>>>>>> reserved_addr). >>>>>>>> >>>>>>>> I haven't tested this but at least in theory it should give you >>>>>>>> a duplicate of the 64bit mapping in the lower 2G of the address >>>>>>>> space. >>>>>>>> >>>>>>>> Important is that you give 0 as oldsize to mremap() so that the >>>>>>>> old mapping isn't unmapped but rather just a new mapping of the >>>>>>>> existing VMA created. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Christian. >>>>>>>> >>>>>>>> >>>>>>>> Am 18.10.24 um 23:55 schrieb Derek Lesho: >>>>>>>>> Hey everyone 👋, >>>>>>>>> >>>>>>>>> I'm Derek from the Wine project, and wanted to start a >>>>>>>>> discussion with y'all about potentially extending the Mesa OGL >>>>>>>>> drivers to help us with a functionality gap we're facing. >>>>>>>>> >>>>>>>>> Problem Space: >>>>>>>>> >>>>>>>>> In the last few years Wine's support for running 32-bit >>>>>>>>> windows apps in a 64-bit host environment (wow64) has almost >>>>>>>>> reached feature completion, but there remains a pain point >>>>>>>>> with OpenGL applications: Namely that Wine can't return a >>>>>>>>> 64-bit GL implementation's buffer mappings to a 32 bit >>>>>>>>> application when the address is outside of the 32-bit range. >>>>>>>>> >>>>>>>>> Currently, we have a workaround that will copy any changes to >>>>>>>>> the mapping back to the host upon glBufferUnmap, but this of >>>>>>>>> course is slow when the implementation directly returns mapped >>>>>>>>> memory, and doesn't work for GL_PERSISTENT_BIT, where directly >>>>>>>>> mapped memory is required. >>>>>>>>> >>>>>>>>> A few years ago we also faced this problem with Vulkan's, >>>>>>>>> which was solved through the VK_EXT_map_memory_placed >>>>>>>>> extension Faith drafted, allowing us to use our Wine-internal >>>>>>>>> allocator to provide the pages the driver maps to. I'm now >>>>>>>>> wondering if an GL equivalent would also be seen as feasible >>>>>>>>> amongst the devs here. >>>>>>>>> >>>>>>>>> Proposed solution: >>>>>>>>> >>>>>>>>> As the GL backend handles host mapping in its own code, only >>>>>>>>> giving suballocations from its mappings back to the App, the >>>>>>>>> problem is a little bit less straight forward in comparison to >>>>>>>>> our Vulkan solution: If we just allowed the application to set >>>>>>>>> its own placed mapping when calling glMapBuffer, the driver >>>>>>>>> might then have to handle moving buffers out of already mapped >>>>>>>>> ranges, and would lose control over its own memory management >>>>>>>>> schemes. >>>>>>>>> >>>>>>>>> Therefore, I propose a GL extension that allows the GL client >>>>>>>>> to provide a mapping and unmapping callback to the >>>>>>>>> implementation, to be used whenever the driver needs to >>>>>>>>> perform such operations. This way the driver remains in full >>>>>>>>> control of its memory management affairs, and the amount of >>>>>>>>> work for an implementation as well as potential for bugs is >>>>>>>>> kept minimal. I've written a draft implementation in Zink >>>>>>>>> using map_memory_placed [1] and a corresponding Wine MR >>>>>>>>> utilizing it [2], and would be curious to hear your thoughts. >>>>>>>>> I don't have experience in the Mesa codebase, so I apologize >>>>>>>>> if the branch is a tad messy. >>>>>>>>> >>>>>>>>> In theory, the only requirement from drivers from the >>>>>>>>> extension would be that glMapBuffer always return a pointer >>>>>>>>> from within a page allocated through the provided callbacks, >>>>>>>>> so that it can be guaranteed to be positioned within the >>>>>>>>> required address space. Wine would then use it's existing >>>>>>>>> workaround for other types of buffers, but as Mesa seems to >>>>>>>>> often return directly mapped buffers in other cases as well, >>>>>>>>> Wine could also avoid the slowdown that comes with copying in >>>>>>>>> these cases as well. >>>>>>>>> >>>>>>>>> Why not use Zink?: >>>>>>>>> >>>>>>>>> There's also a proposal to use a 32-bit PE build of Zink in >>>>>>>>> Wine bypassing the need for an extension; I brought this to >>>>>>>>> discussion in this Wine-Devel thread last week [3], which has >>>>>>>>> some arguments against this approach. >>>>>>>>> >>>>>>>>> >>>>>>>>> If any of you have thoughts, concerns, or questions about this >>>>>>>>> potential approach, please let me know, thanks! >>>>>>>>> >>>>>>>>> 1: >>>>>>>>> https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation >>>>>>>>> >>>>>>>>> >>>>>>>>> 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 >>>>>>>>> >>>>>>>>> 3: https://marc.info/?t=172883260300002&r=1&w=2 >>>>>>>>> >>>>>>>> >>>>>> >>> >>

1 0

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by tblodt＠icloud.com 24 Oct '24

24 Oct '24

> On Oct 24, 2024, at 1:04 AM, Derek Lesho <dlesho(a)codeweavers.com> wrote: > > In my last mail I responded to this approach all the way at the bottom, so it probably got lost: mremap on Linux as it exists now won't work as it only supports private anonymous mappings (in conjunction with MREMAP_DONTUNMAP), which GPU mappings are not. This is seemingly not insurmountable: https://lore.kernel.org/linux-mm/20210303175235.3308220-1-bgeffon@google.co… ~Theodore

2 2

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 24 Oct '24

24 Oct '24

In my last mail I responded to this approach all the way at the bottom, so it probably got lost: mremap on Linux as it exists now won't work as it only supports private anonymous mappings (in conjunction with MREMAP_DONTUNMAP), which GPU mappings are not. Am 10/24/24 um 01:06 schrieb James Jones: > That makes sense. Reading the man page myself, it does seem like: > > -If the drivers can guarantee they set MAP_SHARED when creating their > initial mapping. > > -If WINE is fine rounding down to page boundaries to deal with > mappings of suballocations and either using some lookup structure to > avoid duplicate remappings (probably needed to handle unmap anyway per > below) or just living with the perf cost and address space > overconsumption for duplicate remappings. > > -If mremap() preserves the cache attributes of the original mapping. > > Then no GL API change would be needed. WINE would just have to do an > if (addrAbove4G) { mremapStuff() } on map and presumably add some > tracking to perform an equivalent munmap() when unmapping. I assume > WINE already has a bunch of vaddr tracking logic in use to manage the > <4G address space as described elsewhere in the thread. That would be > pretty ideal from a driver vendor perspective. > > Does that work? > > Thanks, > -James > > On 10/23/24 06:12, Christian König wrote: >> I haven't read through the whole mail thread, but if you manage the >> address space using mmap() then you always run into this issue. >> >> If you manage the whole 4GiB address space by Wine then you never run >> into this issue. You would just allocate some address range >> internally and mremap() into that. >> >> Regards, >> Christian. >> >> Am 22.10.24 um 19:32 schrieb James Jones: >>> This sounds interesting, but does it come with the same "Only gets >>> 2GB VA" downside Derek pointed out in the thread fork where he was >>> responding to Michel? >>> >>> Thanks, >>> -James >>> >>> On 10/22/24 07:14, Christian König wrote: >>>> Hi guys, >>>> >>>> one theoretical alternative not mentioned in this thread is the use >>>> of mremap(). >>>> >>>> In other words you reserve some address space below 2G by using >>>> mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and >>>> then use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr). >>>> >>>> I haven't tested this but at least in theory it should give you a >>>> duplicate of the 64bit mapping in the lower 2G of the address space. >>>> >>>> Important is that you give 0 as oldsize to mremap() so that the old >>>> mapping isn't unmapped but rather just a new mapping of the >>>> existing VMA created. >>>> >>>> Regards, >>>> Christian. >>>> >>>> >>>> Am 18.10.24 um 23:55 schrieb Derek Lesho: >>>>> Hey everyone 👋, >>>>> >>>>> I'm Derek from the Wine project, and wanted to start a discussion >>>>> with y'all about potentially extending the Mesa OGL drivers to >>>>> help us with a functionality gap we're facing. >>>>> >>>>> Problem Space: >>>>> >>>>> In the last few years Wine's support for running 32-bit windows >>>>> apps in a 64-bit host environment (wow64) has almost reached >>>>> feature completion, but there remains a pain point with OpenGL >>>>> applications: Namely that Wine can't return a 64-bit GL >>>>> implementation's buffer mappings to a 32 bit application when the >>>>> address is outside of the 32-bit range. >>>>> >>>>> Currently, we have a workaround that will copy any changes to the >>>>> mapping back to the host upon glBufferUnmap, but this of course is >>>>> slow when the implementation directly returns mapped memory, and >>>>> doesn't work for GL_PERSISTENT_BIT, where directly mapped memory >>>>> is required. >>>>> >>>>> A few years ago we also faced this problem with Vulkan's, which >>>>> was solved through the VK_EXT_map_memory_placed extension Faith >>>>> drafted, allowing us to use our Wine-internal allocator to provide >>>>> the pages the driver maps to. I'm now wondering if an GL >>>>> equivalent would also be seen as feasible amongst the devs here. >>>>> >>>>> Proposed solution: >>>>> >>>>> As the GL backend handles host mapping in its own code, only >>>>> giving suballocations from its mappings back to the App, the >>>>> problem is a little bit less straight forward in comparison to our >>>>> Vulkan solution: If we just allowed the application to set its own >>>>> placed mapping when calling glMapBuffer, the driver might then >>>>> have to handle moving buffers out of already mapped ranges, and >>>>> would lose control over its own memory management schemes. >>>>> >>>>> Therefore, I propose a GL extension that allows the GL client to >>>>> provide a mapping and unmapping callback to the implementation, to >>>>> be used whenever the driver needs to perform such operations. This >>>>> way the driver remains in full control of its memory management >>>>> affairs, and the amount of work for an implementation as well as >>>>> potential for bugs is kept minimal. I've written a draft >>>>> implementation in Zink using map_memory_placed [1] and a >>>>> corresponding Wine MR utilizing it [2], and would be curious to >>>>> hear your thoughts. I don't have experience in the Mesa codebase, >>>>> so I apologize if the branch is a tad messy. >>>>> >>>>> In theory, the only requirement from drivers from the extension >>>>> would be that glMapBuffer always return a pointer from within a >>>>> page allocated through the provided callbacks, so that it can be >>>>> guaranteed to be positioned within the required address space. >>>>> Wine would then use it's existing workaround for other types of >>>>> buffers, but as Mesa seems to often return directly mapped buffers >>>>> in other cases as well, Wine could also avoid the slowdown that >>>>> comes with copying in these cases as well. >>>>> >>>>> Why not use Zink?: >>>>> >>>>> There's also a proposal to use a 32-bit PE build of Zink in Wine >>>>> bypassing the need for an extension; I brought this to discussion >>>>> in this Wine-Devel thread last week [3], which has some arguments >>>>> against this approach. >>>>> >>>>> >>>>> If any of you have thoughts, concerns, or questions about this >>>>> potential approach, please let me know, thanks! >>>>> >>>>> 1: >>>>> https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation >>>>> >>>>> >>>>> 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 >>>>> >>>>> 3: https://marc.info/?t=172883260300002&r=1&w=2 >>>>> >>>> >>

1 0

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 23 Oct '24

23 Oct '24

Am 10/21/24 um 11:35 schrieb Michel Dänzer: > And Wine's solution for this can't be implemented in Mesa? I think this might actually be possible: In order to accomplish this Wine essentially keeps calling mmaps with addresses in its range until it finds a free spot. It of course is able to already skip addresses it itself has mapped, which spares needlessly calling of mmap for nearly every possible page before finding one in cases where the address space is almost filled up. The two practical problems here would be that Mesa wouldn't have access to Wine's mapping table without additional plumbing, and allocating GPU memory, already a slow operation, might become even slower. (If wanted I can try drafting this solution when I get time to see, but I'm swamped with Uni work atm). The other problem is that Wine also has a system of reserved ranges, where it reserves certain important page ranges on setup so that no other libraries steal them from Wine. As far as I can see in Vanilla Wine this isn't a huge portion of the address-space, but if I remember correctly there have been considerations in the past to expand these ranges to speed up virtual memory allocation instead of working through mmap. And then of course there's the question: Do y'all want to have all this allocation complexity in Mesa, when you're have the Wine library sitting right next to you able to do it in a way guaranteed to work? Am 10/21/24 um 16:33 schrieb Jose Fonseca: > I see a few downsides with the proposed callback: > - feels like a solution too tailored for WINE > - there's a layering violation: the application suddenly takes the > driving seat for a thing deep down in the GL driver > so I fear Mesa community might regret it doing, and once WINE supports > there would be outcry if to go back. Yeah, I'm sensible to this critic, and I also would rather a more surface level extension if possible, but it seems to me the troubles with the GL model prohibit it. Also, I would counter that the driver relying on Wine for what is effectively a glorified mmap most likely won't cause restrictions or pains in the future. > IIUC the problem at hand, another way to go about this would be an > extension that allows applications to get a malloc'ed/valloc'ed memory > exposed to the GPU as a GL buffer object. I'll defer to others more knowledgeable than me on the viability of using host imported memory, but I know we have a fallback path in Winevulkan using the Vulkan external_host_memory extension, which was known to be slower than the more direct placed memory solution. I'm cc'ing Jacek (I hope you don't mind 😅), as they ended up implementing both Wine's external_host_memory path and placed_memory path for our WoW64 support, and might have more details on the differences here. Am 10/21/24 um 23:21 schrieb James Jones: > All that said, I don't love the idea of callbacks either. Callbacks in > general are tough to specify and use robustly, and hence should be a > last resort. E.g., this particular callback might sometimes come from > the application thread, and sometimes come from some separate > driver-managed thread. It's hard to validate that all applications can > handle that properly and wouldn't do something crazy like rely on > their own TLS data in the callback or try to call back into OpenGL > from the callback and deadlock themselves, even if these are clearly > specified as an unsupported actions. Yeah, I agree it should be a last resort solution. In my draft Wine implementation, I marshal all calls from driver threads back to a thread created by Wine for the allocation to work, but having to then define this in terms of a general extension is quite ugly... I'm curious if there's a consensus here that Mesa would rather call into a custom Wine mmap when available, instead of exposing a general extension for other applications to shoot themselves in the foot with. If so, I hope Julliard or someone in that area could chime in what they think of the idea. Am 10/22/24 um 11:15 schrieb Jose Fonseca: > So, it sounds like something like an OpenGL equivalent of > VK_EXT_map_memory_placed would be more palatable? Yes this is the goal, if a similarly straightforward extension for GL is possible I think everyone would be for it, but I'm not sure that's the case. To this topic, maybe take a look at the wine-devel thread about some potential options I started a few weeks ago, where we discuss potential callback-less alternatives. This link should have relevant context: https://marc.info/?l=wine-devel&m=172894900019588&w=2 Am 10/22/24 um 16:14 schrieb Christian König: > Hi guys, > > one theoretical alternative not mentioned in this thread is the use of > mremap(). > > In other words you reserve some address space below 2G by using > mmap(NULL, length, PROT_NONE, MAP_32BIT | MAP_ANONYMOUS, 0, 0) and > then use mremap(addr64bit, 0, length, MREMAP_FIXED, reserved_addr). > > I haven't tested this but at least in theory it should give you a > duplicate of the 64bit mapping in the lower 2G of the address space. > > Important is that you give 0 as oldsize to mremap() so that the old > mapping isn't unmapped but rather just a new mapping of the existing > VMA created. > > Regards, > Christian. This unfortunately won't work for the reason that mremap on Linux only works on anonymous private pages, which GPU mappings are not.

2 1

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 21 Oct '24

21 Oct '24

On 10/21/24 11:08, Michel Dänzer wrote: > On 2024-10-18 23:55, Derek Lesho wrote: >> Hey everyone 👋, >> >> I'm Derek from the Wine project, and wanted to start a discussion with y'all about potentially extending the Mesa OGL drivers to help us with a functionality gap we're facing. >> >> Problem Space: >> >> In the last few years Wine's support for running 32-bit windows apps in a 64-bit host environment (wow64) has almost reached feature completion, but there remains a pain point with OpenGL applications: Namely that Wine can't return a 64-bit GL implementation's buffer mappings to a 32 bit application when the address is outside of the 32-bit range. >> >> Currently, we have a workaround that will copy any changes to the mapping back to the host upon glBufferUnmap, but this of course is slow when the implementation directly returns mapped memory, and doesn't work for GL_PERSISTENT_BIT, where directly mapped memory is required. >> >> A few years ago we also faced this problem with Vulkan's, which was solved through the VK_EXT_map_memory_placed extension Faith drafted, allowing us to use our Wine-internal allocator to provide the pages the driver maps to. I'm now wondering if an GL equivalent would also be seen as feasible amongst the devs here. >> >> Proposed solution: >> >> As the GL backend handles host mapping in its own code, only giving suballocations from its mappings back to the App, the problem is a little bit less straight forward in comparison to our Vulkan solution: If we just allowed the application to set its own placed mapping when calling glMapBuffer, the driver might then have to handle moving buffers out of already mapped ranges, and would lose control over its own memory management schemes. >> >> Therefore, I propose a GL extension that allows the GL client to provide a mapping and unmapping callback to the implementation, to be used whenever the driver needs to perform such operations. This way the driver remains in full control of its memory management affairs, and the amount of work for an implementation as well as potential for bugs is kept minimal. I've written a draft implementation in Zink using map_memory_placed [1] and a corresponding Wine MR utilizing it [2], and would be curious to hear your thoughts. I don't have experience in the Mesa codebase, so I apologize if the branch is a tad messy. >> >> In theory, the only requirement from drivers from the extension would be that glMapBuffer always return a pointer from within a page allocated through the provided callbacks, so that it can be guaranteed to be positioned within the required address space. Wine would then use it's existing workaround for other types of buffers, but as Mesa seems to often return directly mapped buffers in other cases as well, Wine could also avoid the slowdown that comes with copying in these cases as well. > Does this really require a callback, or could e.g. a "keep application-visible mappings within 32-bit range" context flag work? > > Unfortunately that wouldn't be quite enough, as linux-mmap's MAP_32BIT flag only uses the first 2 GBs of address space, and we need to allow for the use of all 4GB of address space for apps which have activated the LAA (large address-space aware) flag in their executable.

1 0

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 20 Oct '24

20 Oct '24

Hey Timur, This is actually what Wine has traditionally done, the problem is that we are moving forward to a new implementation for running 32-bit Windows apps, where all of Wine's ELF code is 64-bit, and interacts with the host as a normal 64-bit app. In order to use a 32-bit driver in this context, we'd have to somehow switch the codepage back to 32-bit on the unix side again, and then manually load second copies of mesa and its dependencies like glibc, which would be a lot of effort. I hope this clears things up, let me know if not On 10/19/24 17:47, Timur Kristóf wrote: > Hello Derek, > > As I am not working on GL, I don't have anything to contribute to the > discussion, but I just have a question out of curiosity: what's wrong > with simply using a driver that is compiled for 32-bit? > > Best regards, > Timur > > On Fri, 2024-10-18 at 23:55 +0200, Derek Lesho wrote: >> Hey everyone 👋, >> >> I'm Derek from the Wine project, and wanted to start a discussion >> with >> y'all about potentially extending the Mesa OGL drivers to help us >> with a >> functionality gap we're facing. >> >> Problem Space: >> >> In the last few years Wine's support for running 32-bit windows apps >> in >> a 64-bit host environment (wow64) has almost reached feature >> completion, >> but there remains a pain point with OpenGL applications: Namely that >> Wine can't return a 64-bit GL implementation's buffer mappings to a >> 32 >> bit application when the address is outside of the 32-bit range. >> >> Currently, we have a workaround that will copy any changes to the >> mapping back to the host upon glBufferUnmap, but this of course is >> slow >> when the implementation directly returns mapped memory, and doesn't >> work >> for GL_PERSISTENT_BIT, where directly mapped memory is required. >> >> A few years ago we also faced this problem with Vulkan's, which was >> solved through the VK_EXT_map_memory_placed extension Faith drafted, >> allowing us to use our Wine-internal allocator to provide the pages >> the >> driver maps to. I'm now wondering if an GL equivalent would also be >> seen >> as feasible amongst the devs here. >> >> Proposed solution: >> >> As the GL backend handles host mapping in its own code, only giving >> suballocations from its mappings back to the App, the problem is a >> little bit less straight forward in comparison to our Vulkan >> solution: >> If we just allowed the application to set its own placed mapping when >> calling glMapBuffer, the driver might then have to handle moving >> buffers >> out of already mapped ranges, and would lose control over its own >> memory >> management schemes. >> >> Therefore, I propose a GL extension that allows the GL client to >> provide >> a mapping and unmapping callback to the implementation, to be used >> whenever the driver needs to perform such operations. This way the >> driver remains in full control of its memory management affairs, and >> the >> amount of work for an implementation as well as potential for bugs is >> kept minimal. I've written a draft implementation in Zink using >> map_memory_placed [1] and a corresponding Wine MR utilizing it [2], >> and >> would be curious to hear your thoughts. I don't have experience in >> the >> Mesa codebase, so I apologize if the branch is a tad messy. >> >> In theory, the only requirement from drivers from the extension would >> be >> that glMapBuffer always return a pointer from within a page allocated >> through the provided callbacks, so that it can be guaranteed to be >> positioned within the required address space. Wine would then use >> it's >> existing workaround for other types of buffers, but as Mesa seems to >> often return directly mapped buffers in other cases as well, Wine >> could >> also avoid the slowdown that comes with copying in these cases as >> well. >> >> Why not use Zink?: >> >> There's also a proposal to use a 32-bit PE build of Zink in Wine >> bypassing the need for an extension; I brought this to discussion in >> this Wine-Devel thread last week [3], which has some arguments >> against >> this approach. >> >> >> If any of you have thoughts, concerns, or questions about this >> potential >> approach, please let me know, thanks! >> >> 1: >> https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation >> >> 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 >> >> 3: https://marc.info/?t=172883260300002&r=1&w=2 >>

1 0

Re: Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 19 Oct '24

19 Oct '24

On 10/19/24 00:47, Faith Ekstrand wrote: > The timing here isn't great, unfortunately. I'd love to contribute > more to the discussion but I'm going on leave starting next week until > mid-Febuary so I won't be able to participate much until then. I'll > try to leave a few thoughts, though. Thanks for the comments! I'll actually also be quite busy until then (Uni), but maybe by February they'll be a consensus on the path forward 😀. > > On Fri, Oct 18, 2024 at 5:10 PM Derek Lesho <dlesho(a)codeweavers.com> > wrote: > > Hey everyone 👋, > > I'm Derek from the Wine project, and wanted to start a discussion > with > y'all about potentially extending the Mesa OGL drivers to help us > with a > functionality gap we're facing. > > Problem Space: > > In the last few years Wine's support for running 32-bit windows > apps in > a 64-bit host environment (wow64) has almost reached feature > completion, > but there remains a pain point with OpenGL applications: Namely that > Wine can't return a 64-bit GL implementation's buffer mappings to > a 32 > bit application when the address is outside of the 32-bit range. > > Currently, we have a workaround that will copy any changes to the > mapping back to the host upon glBufferUnmap, but this of course is > slow > when the implementation directly returns mapped memory, and > doesn't work > for GL_PERSISTENT_BIT, where directly mapped memory is required. > > A few years ago we also faced this problem with Vulkan's, which was > solved through the VK_EXT_map_memory_placed extension Faith drafted, > allowing us to use our Wine-internal allocator to provide the > pages the > driver maps to. I'm now wondering if an GL equivalent would also > be seen > as feasible amongst the devs here. > > Proposed solution: > > As the GL backend handles host mapping in its own code, only giving > suballocations from its mappings back to the App, the problem is a > little bit less straight forward in comparison to our Vulkan > solution: > If we just allowed the application to set its own placed mapping when > calling glMapBuffer, the driver might then have to handle moving > buffers > out of already mapped ranges, and would lose control over its own > memory > management schemes. > > Therefore, I propose a GL extension that allows the GL client to > provide > a mapping and unmapping callback to the implementation, to be used > whenever the driver needs to perform such operations. This way the > driver remains in full control of its memory management affairs, > and the > amount of work for an implementation as well as potential for bugs is > kept minimal. I've written a draft implementation in Zink using > map_memory_placed [1] and a corresponding Wine MR utilizing it > [2], and > would be curious to hear your thoughts. I don't have experience in > the > Mesa codebase, so I apologize if the branch is a tad messy. > > It's an interesting approach, to be sure. I don't mean that as a bad > or good thing as I haven't given this enough thought with GL in mind > to have a better, more well thought out plan. > > The most obvious issue that jumps out to me is that we really want > that callback to be set before anyone ever maps a buffer that might > possibly get exposed to the client and we want it to never change. If > this were Vulkan, we'd have you provide it at vkCreateDevice() time. > But this is GL where everybody loves a big mutable state object. If we > do go with callbacks (and it's still not 100% clear to me what the > right choice is), we'd want them to be somehow set-once and set before > any buffers are created. I'm not 100% sure how you'd spec that or how > we'd enforce it. There may be some precedent for this somewhere in GL > (no_error, maybe?) but I'm not sure. Right, in the case of Zink I was just lucky it doesn't happen to map anything upon context creation. If I understand what you mean by using a no_error like approach correctly, I think that should definitely work, I think we would then just somewhat-awkwardly want to pass through the callback address as two context attributes, one for the lower and one for the higher part of the address. However, even if we find a way to make the mapping callback's global on the context level, that then still requires from the driver that they relegate mappings in these contexts to dedicated memory pools. This might be desired, in order to allow other GL clients in the process to continue using the full 64-bit address space, although in practice I don't think Wine uses any libraries that create GL contexts (*other than potentially GStreamer which we are moving away from). If we just want to keep it simple and workaround the GL context, maybe Wine could just export its allocator in ntdll.so in a way that where Mesa could then directly call it when present. That way we could even avoid the need for a GL extension that will at the end of the day probably only be used by Wine, plus avoid the awkwardness of not wanting to map anything in the driver until we get mapping callback. > > The other question that comes to mind is when exactly we'd be expected > to use these things. Obviously, we need to do so for any map that may > be exposed to the client. However, it's not always easy to do that > because you don't know at buffer create time whether or not it will be > persistently mapped. A driver is likely to have all sorts of internal > mappings for things and, while those can come from one of those > ranges, it'll burn more of that precious 32-bit address space than > needed. This gets worse when you take sub-allocation into account. If > we're okay with all buffer mappings going down the client-request path > then it's probably okay. The driver just might need an extra bit in > its buffer cache key. Yeah, it would definitely be a nice bonus to the new path if drivers kept their internal mappings outside of 32-bit address space, but as far as I can see I don't think this affects our choice of interface, as mesa should be able to handle client visible buffers differently from driver-internal ones without the help of the client. > > I'm also sitting here trying to come up with some plan that would let > us do this more like Vulkan and I'm having trouble coming up with one > that works. GL has no concept of "create time". We could theoretically > do something where we flush everything, copy the data to a new > placed-mappable buffer and then continue on but that's gonna suck. Yeah, and then you also still have to define how you create this new placed-mappable buffer, and there isn't really a small-neat solution for this. You could define a GL_OUT_OF_PLACED_MEMORY error in glMapBuffer, and then have another entry point by which the app feeds the driver pages, but then you run into the problem of unmapping, which as far as I can see is often performed asynchronously. > > I think that's all that comes to mind immediately. As I said at the > top, I'm happy to talk more in a few months. Best of luck until then! > > ~Faith > > In theory, the only requirement from drivers from the extension > would be > that glMapBuffer always return a pointer from within a page allocated > through the provided callbacks, so that it can be guaranteed to be > positioned within the required address space. Wine would then use > it's > existing workaround for other types of buffers, but as Mesa seems to > often return directly mapped buffers in other cases as well, Wine > could > also avoid the slowdown that comes with copying in these cases as > well. > > Why not use Zink?: > > There's also a proposal to use a 32-bit PE build of Zink in Wine > bypassing the need for an extension; I brought this to discussion in > this Wine-Devel thread last week [3], which has some arguments > against > this approach. > > > For cases where Zink is being used on the host (this is the current > plan for Nouveau going forward), doing Zink in Windows may not be a > bad idea. However, I agree that it may not be the best idea to rely on > that plan. > > If any of you have thoughts, concerns, or questions about this > potential > approach, please let me know, thanks! > > 1: > https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation > > 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 > > 3: https://marc.info/?t=172883260300002&r=1&w=2 > <https://marc.info/?t=172883260300002&r=1&w=2> >

1 0

Helping Wine use 64 bit Mesa OGL drivers for 32-bit Windows applications
by Derek Lesho 18 Oct '24

18 Oct '24

Hey everyone 👋, I'm Derek from the Wine project, and wanted to start a discussion with y'all about potentially extending the Mesa OGL drivers to help us with a functionality gap we're facing. Problem Space: In the last few years Wine's support for running 32-bit windows apps in a 64-bit host environment (wow64) has almost reached feature completion, but there remains a pain point with OpenGL applications: Namely that Wine can't return a 64-bit GL implementation's buffer mappings to a 32 bit application when the address is outside of the 32-bit range. Currently, we have a workaround that will copy any changes to the mapping back to the host upon glBufferUnmap, but this of course is slow when the implementation directly returns mapped memory, and doesn't work for GL_PERSISTENT_BIT, where directly mapped memory is required. A few years ago we also faced this problem with Vulkan's, which was solved through the VK_EXT_map_memory_placed extension Faith drafted, allowing us to use our Wine-internal allocator to provide the pages the driver maps to. I'm now wondering if an GL equivalent would also be seen as feasible amongst the devs here. Proposed solution: As the GL backend handles host mapping in its own code, only giving suballocations from its mappings back to the App, the problem is a little bit less straight forward in comparison to our Vulkan solution: If we just allowed the application to set its own placed mapping when calling glMapBuffer, the driver might then have to handle moving buffers out of already mapped ranges, and would lose control over its own memory management schemes. Therefore, I propose a GL extension that allows the GL client to provide a mapping and unmapping callback to the implementation, to be used whenever the driver needs to perform such operations. This way the driver remains in full control of its memory management affairs, and the amount of work for an implementation as well as potential for bugs is kept minimal. I've written a draft implementation in Zink using map_memory_placed [1] and a corresponding Wine MR utilizing it [2], and would be curious to hear your thoughts. I don't have experience in the Mesa codebase, so I apologize if the branch is a tad messy. In theory, the only requirement from drivers from the extension would be that glMapBuffer always return a pointer from within a page allocated through the provided callbacks, so that it can be guaranteed to be positioned within the required address space. Wine would then use it's existing workaround for other types of buffers, but as Mesa seems to often return directly mapped buffers in other cases as well, Wine could also avoid the slowdown that comes with copying in these cases as well. Why not use Zink?: There's also a proposal to use a 32-bit PE build of Zink in Wine bypassing the need for an extension; I brought this to discussion in this Wine-Devel thread last week [3], which has some arguments against this approach. If any of you have thoughts, concerns, or questions about this potential approach, please let me know, thanks! 1: https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 3: https://marc.info/?t=172883260300002&r=1&w=2

1 0

Wine staging 9.20 release
by Alistair Leslie-Hughes 18 Oct '24

18 Oct '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.20 (357 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Removed (No longer required). * None Added: * [33190]: win32u - Fix rendering of the rotated and scaled text. 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

Trouble compiling Winelib DLL for 64-bit on OpenSUSE
by aleithner＠level101.at 18 Oct '24

18 Oct '24

Hi, I have previously asked about the problem I'm describing below on openSUSE's forums [1], StackOverflow [2] and Wine's forums [3], where dimesio told me that I could try to ask here. If this is the wrong place to ask, I apologise. Over the past few weeks, I've been re-implementing a DLL using Winelib to be able to leverage Unix sockets to communicate with a Linux process outside of Wine. For context, I'm on a 64-bit machine running openSUSE Tumbleweed. I've had success compiling the DLL as a 32-bit object using the command line winegcc -m32 -L/usr/lib64/wine/i386-unix -shared -o myproject.dll myproject_main.c myproject.spec This DLL (myproject.dll.so) works as expected, i.e. 32-bit Windows programs running under Wine can load and execute the DLL just fine. (I've found specifying -L/usr/lib64/wine/i386-unix to be necessary since WineGCC didn't pick up Wine's library path by itself.) Now, I've been trying to compile this same project as a 64-bit object using winegcc -L/usr/lib64/wine/x86_64-unix -shared -o myproject64.dll myproject_main.c myproject.spec and I'm facing the following WineGCC output: /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -ladvapi32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -luser32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lwinecrt0: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lkernel32: No such file or directory /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: cannot find -lntdll: No such file or directory collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed As I've discovered, openSUSE's wine-devel package does not provide any archive files in /usr/lib64/wine/x86_64-unix, whereas wine-devel-32bit does provide archive files under /usr/lib/wine/i386-unix (symlinked with the same directory in /usr/lib64). Interestingly, I've inspected Wine's Fedora packages [4] and haven't found these archive files for 32-bit but only for 64-bit; so, the Fedora packages seem to have the opposite "problem." Now, I've tried to use the archive files provided by openSUSE's 64-bit wine-devel package under /usr/lib64/wine/x86_64-windows, but of course they're PE binaries so LD complains it can't link to my Winelib DLL: /usr/bin/ld: relocatable linking with relocations from format pe-x86-64 (/usr/lib64/wine/x86_64-windows/libwinecrt0.a(debug.o)) to format elf64-x86-64 (tmp66fd686a/myproject64-00000001.spec-00000001.o) is not supported winebuild: /usr/bin/ld failed with status 1 winegcc: /usr/bin/winebuild failed I feel like I should be able to compile this Winelib DLL as both a 32-bit and a 64-bit object respectively, on any supported system. (I haven't found any info on this skimming through the Winelib User's Guide [5].) Is this assumption wrong? If so, what's the correct way of building Winelib DLLs? If not, how can I get a 64-bit version of this DLL? Any advice on what I might be misunderstanding or doing wrong or what might be the cause of this problem would be greatly appreciated. Best regards, Alexander Leithner [1]: https://forums.opensuse.org/t/wines-64-bit-archive-files-are-missing/179038 [2]: https://stackoverflow.com/questions/79058718/whats-the-correct-way-of-build… [3]: https://forum.winehq.org/viewtopic.php?t=39513 [4]: e.g. https://dl.winehq.org/wine-builds/fedora/40/x86_64/wine-staging-9.19-1.1.x8… under /opt/wine-staging/lib64/wine inside the package [5]: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide

6 5

Discussing paths forward for OpenGL mappings on Wow64
by Derek Lesho 15 Oct '24

15 Oct '24

Hi everyone, I'm creating this thread to start a discussion about how we want to complete GL support on Wow64, in the hopes that, if we want a MESA extension for this, we can get it to them sooner rather than later. The core of the problem is same that we faced for Vulkan: namely that host visible mappings from graphics APIs may be located above 32-bit memory, in which case we can't pass them to the application as is. In the current implementation that Rémi wrote a few years ago, we use a temporary buffer for glMapBuffer, and manually have to copy the data from it back to the real mapping on glUnmapBuffer. This solution works for most applications, but is slower than direct writes, and doesn't allow use of the GL_MAP_PERSISTENT_BIT glMapBuffer flag, where the application doesn't have to unmap the memory before usage by the API. Because of this problem, we can't support GL versions >= 4.4 in this path, which admittedly isn't a huge problem considering wined3d now supports Vulkan, but does rule out some native GL apps/games from running on the new path. I'll go over a few potential solutions: - "Just Use Zink": this idea has been floated for a while, and would be to use a PE build of Zink, the MESA gallium driver on top of Vulkan, which would then automatically make use of our VK_EXT_map_memory_placed integration in winevulkan and bypass the problem. Rémi has a branch with a draft solution for this [1] The advantage of approach is that it doesn't require any more extensions to any more APIs, but the disadvantage is that Wine would have to worry about keeping a separate version of Mesa up to date and support for building the required c++ components of mesa to its build system, as can be seen in the commits. - GL extension with placed memory allocation callback: In this case, Wine provides a map and unmap callback for the GL implementation to use in creating the pages it needs for GPU-mappings. In comparison to the PE Zink solution, we can continue to use system libraries, and maintain fast buffer IO, as long as the glMapBuffer implementation returns the mapped ptr directly. The main downside for this solution is of course the introduction of a new extension to the mostly dormant GL API, but here it would be possible to just use a VK_EXT_map_memory leveraging Zink like in the first solution, only this time on the Unix side. For this solution I've created a draft: Wine MR [2] Mesa Branch with Zink implementation [3] - glMapBuffer extension which we send our placed allocation: The idea here is that slightly extended glMapBuffer could be sent a flag to use Wine mapping, avoiding callbacks and targeting the problem where it manifests for Wine (when we get an address out of 32-bit space). This was briefly discussed on the LGD discord server, but it won't work well, due to the fact that a GL buffer is usually only a suballocation of a memory mapping, and often has already been assigned to another pool of memory by the time glMapMemory is called. Mesa would have to add a considerable sized implementation setting up custom-allocator pools, and be able to move buffers between them to implement this. - glBufferStorage extension to ease Mesa implementation: The next logical conclusion based on the problems of the last solution is that the Mesa implementation should get the information about any custom allocation at buffer creation time. The closest equivalent to this is the glBufferStorage entry, where we could create a new type of memory that we would ask the implementation to put the buffer in. For this solution we'd either have to implement custom memory allocator or introduce more API entries in order to allow the driver to convey to the application what size mappings it prefers. This would be very unwieldy, and wouldn't solve speed up the slow buffer copies for legacy buffers which don't use ARB_buffer_storage. - finally, going off the last possibility, if we're willing to create our own buffer allocator (we probably shouldn't, as the driver probably knows best), we could use the already existing EXT_external_objects extensions to import Vulkan memory objects, from which our allocator would allocate slices for the buffers. In glMapBuffer we would then return the Vulkan placed memory mapping. If I got anything wrong or overlooked anything, please let me know. If we decide on a solution that involves mesa, I would gladly then include the mesa-dev list to see if they have opinions for/against any of the proposals. Thanks, Derek 1: https://gitlab.winehq.org/rbernon/wine/-/tree/wip/just-use-zink 2: https://gitlab.winehq.org/wine/wine/-/merge_requests/6663 3: https://gitlab.freedesktop.org/Guy1524/mesa/-/commits/placed_allocation

5 7

wined3d surface handle buffer overflow
by Fabian Maurer 11 Oct '24

11 Oct '24

Hello, I'm currently investigating a wined3d regression that leads to an assert - bug 57300. In short, there is memorys corruption in "d3d_device2_SwapTextureHandles" when copying a "global handle table" handle into the "device handle table". The "device handle table" is only 64 entries long, but the handle is bigger than that - writing out of bounds. As I see, it all surfaces get allocated into the global handle table. Then in d3d_device2_SwapTextureHandles they get copied into the device handle table. Once in "CreateStateBlock" and once in "EndStateBlock". The device handle table only contains the wined3d state block handle. If those assumptions are correct, I have a few questions: 1) Isn't there a risk of overriding the state block handle when swapping the texture with handle 1? 2) Why are the handles only copied, completely bypassing the ddraw_allocate_handle function? Doesn't this mess up the next call to "ddraw_allocate_handle"? A potential solution to the buffer overflow would be the increase the size of the table if the handle doesn't fit. But I don't know if that's the correct course of action, and I don't know what to do with the table size / count values. Or maybe there' something else wrong here that I'm not seeing, insights would be appreciated. Regards, Fabian Maurer

2 1

Upcoming vkd3d 1.14 release
by Henri Verbeet 10 Oct '24

10 Oct '24

Hi all, As previously announced, the planned release date for vkd3d 1.14 is November 21. That means the public API will become frozen two weeks from now on October 24, and features will be frozen after November 7. 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 all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. 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.15 is February 19. Regards, Henri

1 0

Wine staging 9.19 release
by Alistair Leslie-Hughes 05 Oct '24

05 Oct '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.19 (354 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9_36: Add format description for X8L8V8U8 for format conversions. 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

ntdll WRITECOPY dropped from staging
by Fabian Maurer 29 Sep '24

29 Sep '24

Hello, I noticed that the ntdll WRITECOPY changes got mostly dropped from staging in commit https://github.com/wine-staging/wine-staging/commit/ 16dce521242b3f4a52cd2c8799ce6fe464fac83c > The current state even after multiple iterations, the whole > WRITECOPY implemenet needs differently. Upstream will need to > do this. As I understand it, the implementation marks WRITECOPY pages as read-only on the unix side, handling the access violation and marking it as read-write afterwards. (Correct me if I'm wrong) What is wrong with the underlying concept, how should it be implemented properly? Regards, Fabian Maurer

2 1

Carry flag state after a system function call
by robert.ayrapetyan＠gmail.com 25 Sep '24

25 Sep '24

Hello, some legacy applications depend on the carry flag state after calling system functions. I've noticed that certain apps work correctly when using Wine installed from packages, but fail when Wine is built from sources. After investigating, I found that Wine from Debian packages is compiled with certain flags that stabilize ESP at the end of system function calls (e.g., sub ESP, 0x10), which, as a side effect, clears the carry flag, making the application happy. I tried using fno-omit-frame-pointer, but it generates lea instructions, which don't impact the carry flag. Has anyone else encountered same behavior? How frequently do older applications rely on the carry flag after system function calls? Also, which specific flags are used to compile the Wine version available in Debian packages?

5 5

Gitlab forks limit issue
by robert.ayrapetyan＠gmail.com 24 Sep '24

24 Sep '24

Hello, could you please let me know who I should contact to increase the quotas for my account (rayrapetyan) on https://gitlab.winehq.org/wine? I'm currently unable to fork Wine from https://gitlab.winehq.org/wine/wine/-/forks/new due to the following error: "Limit reached. You cannot create projects in your personal namespace. Contact your GitLab administrator." Also, would you consider accepting a merge request that modifies the GetDriveTypeA\W function to prioritize the mount manager? Let me know if this was discussed somewhere already.

2 3

Wine staging 9.18 release
by Alistair Leslie-Hughes 21 Sep '24

21 Sep '24

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

Staging WRITECOPY fixes
by DodoGTA GT 20 Sep '24

20 Sep '24

Hello, I found a few issues with the WRITECOPY patch after wine-staging commit ae46f56f2cf20585387ff61cb7b36fd5f3d84837 which I managed to pretty much fix Patch 0003 is a replacement for the previous 0003 patch (apparently very early signal handling is still needed for some Unix-side ntdll functions); the added early argument checks could be replaced with NtCurrentTeb() instead (this would lead to 2 identical signal_init_process() calls though which may look weird) Patch 0004 updates the previous 0004 patch by removing a forgotten i386 compile-time check (which didn't make sense after that wine-staging commit) Patch 0005 is updated to fix conflicts because of the patch 0004 update (so it can be ignored for a manual rebase) Patch 0010 enables the WRITECOPY stuff by default (this is effectively a replacement for patches 0010 and 0011 without their hacky logic which really only works for Chromium-based applications); if this patch addition is too radical, then at least patches 0010 and 0011 should definitely be removed (hopefully there won't be another patch race anytime soon) Please note that patch 0003 also adds an extra ntdll-Syscall_Emulation dependency to fix a bad interaction with that patchset (also I should've sent this email at least a day earlier but hopefully some of these patches can get pushed) Thanks

1 0

[PATCH] Correction for Bug 52627 - Wishlist: add ohm symbol (greek capital Omega) to wine tahoma font
by MATHEUS VENTURINI BORTOLUZZI 20 Sep '24

20 Sep '24

Good afternoon, I've made a patch to fix the Ohm sign not appearing in LTSpice. I followed what was written in the discussion of Bug 52627 <https://bugs.winehq.org/show_bug.cgi?id=52627> - I copied the glyph for "OHM SIGN" and pasted it for "GREEK CAPITAL LETTER OMEGA" using FontForge. Since this is my first contribution to anything ever, I would greatly appreciate if someone could test this patch... Thank you in advance Matheus

2 1

Gitlab News
by Alexandre Julliard 17 Sep '24

17 Sep '24

Folks, As you may have noticed, now that the ARM64 support is done (just kidding), I've picked up the work on the Gitlab migration: 1. The Wiki has been moved to Gitlab, it's now at [1]. Existing URLs to the previous Wiki are redirected to the appropriate page. There are also separate Wikis for appdb, vkd3d and wine-staging, under their respective project pages. As part of the migration I've done some minor edits, but most of the Wiki is badly out-of-date, and could use some love. Help is welcome! Check the Writers page [2] for details on how to contribute. 2. We are now hosting the Mono project on the WineHQ Gitlab [3]. Please join me in welcoming the Mono developers to our community! 3. We have new hardware for the Gitlab server, which is now noticeably faster. Thanks to Jeremy Newman for setting this up! This also made it possible to enable robots.txt again so that our content is indexed. The next step will be to install new hardware for the Gitlab runners to offer more CI bandwidth. 4. The Gitlab issue tracker is currently disabled because it was attracting too much spam. I'm going to re-enable it, first for use by Mono, and then ultimately also for Wine itself. To fight the spam I'm planning to add an explicit user verification step, modelled along the procedure used by Freedesktop.org [4]. 5. As part of the new sign-up process, I think it would be a good idea to have an explicit Code of Conduct to spell out our expectations. Instead of reinventing the wheel, I propose that we adopt the Contributor Covenant [5] that many other projects (including Mono) are already using. Thoughts? Questions? Comments? [1]: https://gitlab.winehq.org/wine/wine/-/wikis [2]: https://gitlab.winehq.org/wine/wine/-/wikis/Writers [3]: https://gitlab.winehq.org/mono [4]: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home [5]: https://www.contributor-covenant.org/ -- Alexandre Julliard julliard(a)winehq.org

3 3

Wine staging 9.17 release
by Alistair Leslie-Hughes 06 Sep '24

06 Sep '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.17 (354 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * cmd: Support for launching programs based on file association. * cmd: Changed errorlevel type to DWORD. * winemapi: Directly use xdg-email if available, enabling file attachments. 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

Wine staging 9.16 release
by Alistair Leslie-Hughes 24 Aug '24

24 Aug '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.16 (355 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * odbc32: Support freeing SQL handles for ODBC v2 drivers. * odbc32: Support Allocating SQL handles for ODBC v2 drivers. * odbc32: Support Driver in connection string. * odbc32: SQLSetDescFieldW pass correct handle onto driver. * odbc32: Use SQLAllocHandle to allocate a STMT handle. * odbc32: Call drivers SQLBindCol function. * printdlg: Allow button id psh1 for "Properties" button. * odbc32: Store handles when requesting information of Columns. * odbc32: Pass statment when creating a descriptor. * odbccp32: Support System wide ODBC DSN keys. * odbccp32: SQLWritePrivateProfileStringW check for existing DSN first. * odbc32: SQLSetEnvAttr isnt supported in ODBC v2.0. * odbc32: set_con_attr return success by default. * odbc32: SQLColAttributeW support fallback function. * odbc32: SQLGetDiagRec/W handle fallback function. * setupapi: Add stub for DriverStoreFindDriverPackageW. * winex11.drv: Update a candidate window's position with over-the-spot style. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * eventfd_synchronization * ntdll-WRITECOPY 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

Staging dinput-scancode fix
by DodoGTA GT 23 Aug '24

23 Aug '24

Hello Here's a better regression fix for the dinput-scancode patchset (the 0001 patch of that patchset caused NFS Underground to segfault since Wine 9.15 with the addition of a keycode loop in keyboard_create_device() because of DIPROP_SCANCODE stuff); I modified the existing 0001 patch to solve this by copying the duplicate object checks to that new loop (maybe I should create a separate 0003 patch to show the changes better?) Hopefully the patch can be merged before 9.16 to not re-introduce that regression after it has been worked around in wine-staging 9.15 Thanks

3 2

stack size change
by Mahin Pandya 16 Aug '24

16 Aug '24

Hello everyone, I am looking to change stack size of Wine executable. Apart from specifying .def (which contains STACKSIZE value) file during compilation, is there any other option which is supported by Wine? Some kind configurable runtime option without modifying binary? Sample code: $ cat hello.c #include <stdio.h> #include <windows.h> int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { char buffer [1024*1024*3]; printf( "Hello world\n"); return 0; } $ winegcc hello.c $ ./a.out Segmentation fault (core dumped) Note: I am able to change/patch stack size via modifying a.out.so file. Any pointers/suggestion are welcome. Thanks in advance. regards, Mahin

1 1

[PATCH v5 00/28] NT synchronization primitive driver
by Elizabeth Figura 12 Aug '24

12 Aug '24

This patch series implements a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. NT synchronization primitives are unique in that the wait functions both are vectored, operate on multiple types of object with different behaviour (mutex, semaphore, event), and affect the state of the objects they wait on. This model is not compatible with existing kernel synchronization objects or interfaces, and therefore the ntsync driver implements its own wait queues and locking. This patch series is rebased against the "char-misc-next" branch of gregkh/char-misc.git. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The performance measurements described below are copied from earlier versions of the patch set. While some of the code has changed, I do not currently anticipate that it has changed drastically enough to affect those measurements. The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 27/28 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Previous versions == Changes from v4: * Rework wait-all locking code to avoid taking more than one spinlock at a time, and also to fix a race where the wait-all lock would not be not correctly taken. The new locking mechanism involves taking a simple spinlock for normal "any" waits, and taking a device-wide mutex for "all" waits or when locking any object that is involved in an "all" wait. The mechanism was written by Peter Zijlstra. * Try to reword or clarify various parts of the documentation (patch 27), per Peter Zijlstra. * I did not rename NTSYNC_IOC_SEM_POST to RELEASE (like NT) although this was suggested by Peter Zijlstra, mostly because it's not clear to me that renaming an already committed ioctl would be fine. The API committed isn't actually usable yet, though, so if altering it would be fine on those grounds, I can revise this series to rename the function accordingly. * Similarly, I did not change the create ioctls to return the fd directly, although this was suggested and would be a bit simpler and cleaner, because NTSYNC_IOC_CREATE_SEM already exists upstream and returns the fd through a struct. I can make this change in the next revision if that'd be preferable. I also still would appreciate a clarification on the advice in [1]. [1] https://docs.kernel.org/driver-api/ioctl.html#return-code * Link to v4: https://lore.kernel.org/lkml/20240416010837.333694-1-zfigura@codeweavers.co… * Link to v3: https://lore.kernel.org/lkml/20240329000621.148791-1-zfigura@codeweavers.co… * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (28): ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. ntsync: No longer depend on BROKEN. Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ntsync.rst | 398 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 1 - drivers/misc/ntsync.c | 989 +++++++++++- include/uapi/linux/ntsync.h | 39 + tools/testing/selftests/Makefile | 1 + .../selftests/drivers/ntsync/.gitignore | 1 + .../testing/selftests/drivers/ntsync/Makefile | 7 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 11 files changed, 2850 insertions(+), 4 deletions(-) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 tools/testing/selftests/drivers/ntsync/.gitignore create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: f5b335dc025cfee90957efa90dc72fada0d5abb4 -- 2.43.0

1 30

Wine staging 9.15 release
by Alistair Leslie-Hughes 11 Aug '24

11 Aug '24

Binary packages for various distributions will be available from: https://www.winehq.org/download We have included a few PR to fix regressions with the current wine release. If you want to play NFS Underground or connect to a database via ODBC, take wine-staging for a spin. Summary since last release * Rebased to current wine 9.15 (376 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * dinput-regression-fix - Fix crash in NFS Underground. * printdlg-properties_btn - [55841] Lotus Approach: print "Properties" button ignored. Updated: * vkd3d-latest * odbc32-fixes * eventfd_synchronization * winemapi-user-xdg-mail 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 staging 9.14 release
by Alistair Leslie-Hughes 28 Jul '24

28 Jul '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.14 (371 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * odbc32: SQLError/W handle NULL handles * odbc32: SQLSetEnvAttr fake success for SQL_ATTR_CONNECTION_POOLING * odbc32: SQLSetConnectAttrW correct default return value * odbc32: SQLTransact handle NULL EnvironmentHandle Removed (No longer required). * None Added: * [53696] d3d11: Semi-stub IDXGISwapChain::GetFrameStatistics. Updated: * vkd3d-latest * odbc32-fixes * ntdll-WRITECOPY 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

Staging WRITECOPY fix
by DodoGTA GT 26 Jul '24

26 Jul '24

Hello, I finally managed to submit a regression fix for the ntdll-WRITECOPY patchset (it's a normal Wine patch so there should be no diff confusion this time) Hopefully this can be merged soon because it fixes annoying segfaults in 3 apps (2 of these have a bug report) Thanks

1 0

Upcoming vkd3d 1.13 release
by Henri Verbeet 25 Jul '24

25 Jul '24

Hi all, As previously announced, the planned release date for vkd3d 1.13 is August 29. That means the public API will become frozen one week from now on August 1, and features will be frozen after August 15. 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 all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. 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.14 is November 21. Regards, Henri

1 0

Porting Wine to the other programming languages
by alegorium＠gmail.com 20 Jul '24

20 Jul '24

Hello, everyone! I'm porting parts of WineHQ into other programming languages. Simply came here to make developers aware of the code reuse. Hope everyone here is okay with that. Example: https://github.com/GreenteaOS/Caramel/blob/kawaii/dlls/user32/dialogs.hexa dialog.c reports "2.1 of the License, or (at your option) any later version" Had to apply heuristics to restore some "high-levelness" of the code. Thanks

1 0

Broken GitWeb
by M. GOUJON 18 Jul '24

18 Jul '24

Hi everyone, It appears Wine GitWeb <https://source.winehq.org/git/wine.git/?a=shortlog> page is broken since Monday, returning a 403 Forbidden error. I know there is also the GitLab version <https://gitlab.winehq.org/wine/wine/-/commits/master> but I prefer the old one. Can someone have a look and fix the (permission) issue? Thanks in advance, Regards

7 6

Wine-Staging 9.13 release
by Elizabeth Figura 18 Jul '24

18 Jul '24

The Wine-Staging development release 9.13 is now available. Summary since last release: * Rebased to upstream Wine 9.13. 355 patches are applied to upstream Wine. Patches removed from Wine-Staging since the last release: * ntdll: Implement virtual_map_shared_memory. * server: Implement support for global and local shared memory blocks based on memfd. * user32: Get rid of wineserver call for GetInputState. * ntdll: Only enable wineserver shared memory communication when a special environment variable is set. * server: Store a list of associated queues for each thread input. * user32: Get rid of wineserver call for GetActiveWindow, GetFocus, GetCapture. * user32: Avoid unnecessary wineserver calls in PeekMessage/GetMessage. * user32: Get rid of wineserver call for GetLastInputInfo. Patches added: * odbc32-fixes (replaces odbc-remove-unixodbc) Patches otherwise updated: * vkd3d-latest Binary packages for various distributions will be available from: https://www.winehq.org/download As always, if you find a bug, please report it via https://bugs.winehq.org ἔρρωσθε, Zeb Figura

1 0

Wine staging 9.12 release
by Alistair Leslie-Hughes 30 Jun '24

30 Jun '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.12 (XXXX patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * oledb32: Support Multiple values when parsing the property Mode. * wined3d: Implement WINED3DFMT_B8G8R8X8_UNORM to WINED3DFMT_L8_UNORM conversion. Removed (No longer required). * Compiler_Warnings Added: * [7955] oledb32: Mode can have multiple values as a string * [56786] odbccp32: Correct lookup of DSN before writing to registry. Updated: * vkd3d-latest * md-launch-association * odbc-remove-unixodbc 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-staging wineodbc fix
by DodoGTA GT 28 Jun '24

28 Jun '24

Hello, I've noticed that the wine-staging wineodbc library fails to compile ever since it got introduced in commit 14f63f40e7c87dc87ca1dc64aaa66f344bada4da (but only for 32-bit) This is because the unixlib part of wineodbc requires linking to libodbc (which is rarely present on 32-bit) and because libodbc isn't present, there's a lot of missing symbols The Wine configure.ac does have some checks to prevent building of the whole odbc component if libodbc is missing (but that only works for odbc32, not wineodbc) To fix this issue, enable_odbc32 can be edited to enable_wineodbc in the configure.ac file (make sure to run autoreconf to actually include the fix in the configure script too) Thanks

1 0

Support for loongarch64 architecture
by 李鹏飞 18 Jun '24

18 Jun '24

Hello Everyone: May I ask if there is any official support for the loongarch64 architecture in the future. I added the loongarch64 architecture code based on the wine-9.9, and currently, built-in programs such as regedit and notepad can be launched. I would like to confirm if these codes can be merged by the master branch. 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

2 1

Wine staging 9.11 release
by Alistair Leslie-Hughes 15 Jun '24

15 Jun '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.11 (428 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * include: Add windows.networking.connectivity.idl Removed (No longer required). * None Added: * [7955] oledb32: Mode can have multiple values as a string * [56786] odbccp32: Correct lookup of DSN before writing to registry. Updated: * vkd3d-latest * shell32-IconCache * odbc-remove-unixodbc The odbc patchset had a major update to support ODBC v2.0 drivers. This allows ODBC 3.0 functions to use fallback functions when the native driver only supports ODBC 2.0 functions. 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

How to add ICU support?
by Thomas Bleher 02 Jun '24

02 Jun '24

Hi all, I'm currently trying to get the current version of Logos (https://appdb.winehq.org/objectManager.php?sClass=application&iId=771) running on Wine. One of the (many) problems is that newer versions of the app use the icu libraries that are part of newer versions of Windows (see https://learn.microsoft.com/en-us/windows/win32/intl/international-componen… ). As far as I could gather, the source code for the icu libraries as shipped with Windows is at https://github.com/microsoft/icu (see especially https://github.com/microsoft/icu/tree/master/icu-patches/patches for the patches that are applied relative to the upstream icu library). What would be the best way to add ICU support to Wine? Best regards, Thomas

1 0

Wine staging 9.10 release
by Alistair Leslie-Hughes 01 Jun '24

01 Jun '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.10 (429 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 * Compiler_Warnings 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

Implementing NtGetSystemInformation(SystemProcessorIdleInformation)
by Niko Patterson 31 May '24

31 May '24

Hello, for the past couple of days I've been trying to get a program to run under wine, everything seems to function correctly except for a CPU stats window that errors every time it updates. After a few hours of debugging I traced it to NtGetSystemInformation and have been trying to write patches for wine to implement it. My only issue is that the program only uses certain parts of the output, and I'm not sure how to put together the structure for it, should I just name the unknown fields "ReservedX"? I'm also not 100% sure where to put the structure afterwards, since it doesn't seem to show up anywhere in MSDN (I may be using the wrong name, I assumed the structure name is just the enum name in title case like the ones that are documented). I apologize if I sent this to the wrong list, this is my first time contributing to wine and I'm still trying to figure things out. ~Niko

2 2

Missing macro in commctrl.h
by Michael Dluhosch 31 May '24

31 May '24

Hi, is there a reason why this macro https://learn.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-tr… is not defined in the wine version of commctrl.h? I currently try to compile windows sources with winegcc which need this macro. Kind Regards Michael

2 4

Proposal: changing the default bug status (from 'UNCONFIRMED' to 'NEW')
by Austin English 22 May '24

22 May '24

Howdy all, Currently, unprivileged users have their bugs set to 'UNCONFIRMED' by default (while privileged users have the option of 'UNCONFIRMED'/'NEW'/'ASSIGNED'). As a general rule, no one seems to care if a bug is confirmed ('NEW') or not. This often leads to confusion for users (for example recently, [1]), who think that because their bug is 'UNCONFIRMED', it won't get attention. Because this distinction is useless, I'd like to propose that we make a few changes to Bugzilla: * change the default status for newly submitted bugs to 'NEW' (here: https://bugs.winehq.org/editworkflow.cgi) * do a bulk status update of existing bugs from 'UNCONFIRMED' to 'NEW' * disable the 'UNCONFIRMED' status (here: https://bugs.winehq.org/editproducts.cgi?action=edit&product=Wine) Thoughts/concerns? [1] https://bugs.winehq.org/show_bug.cgi?id=50876 -- -Austin GPG: 267B CC1F 053F 0749 (expires 2026-03-03)

5 4

Wine staging 9.9 release
by Alistair Leslie-Hughes 18 May '24

18 May '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.9 (427 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 * ntdll-Junction_Points 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 v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 15 May '24

15 May '24

On Wednesday, 17 April 2024 05:01:32 CDT Peter Zijlstra wrote: > > > > =================================== > > NT synchronization primitive driver > > =================================== > > > > This page documents the user-space API for the ntsync driver. > > > > ntsync is a support driver for emulation of NT synchronization > > primitives by user-space NT emulators. It exists because implementation > > in user-space, using existing tools, cannot match Windows performance > > while offering accurate semantics. It is implemented entirely in > > software, and does not drive any hardware device. > > > > This interface is meant as a compatibility tool only, and should not > > be used for general synchronization. Instead use generic, versatile > > interfaces such as futex(2) and poll(2). > > > > Synchronization primitives > > ========================== > > > > The ntsync driver exposes three types of synchronization primitives: > > semaphores, mutexes, and events. > > > > A semaphore holds a single volatile 32-bit counter, and a static 32-bit > > integer denoting the maximum value. It is considered signaled when the > > counter is nonzero. The counter is decremented by one when a wait is > > satisfied. Both the initial and maximum count are established when the > > semaphore is created. > > > > A mutex holds a volatile 32-bit recursion count, and a volatile 32-bit > > identifier denoting its owner. A mutex is considered signaled when its > > owner is zero (indicating that it is not owned). The recursion count is > > incremented when a wait is satisfied, and ownership is set to the given > > identifier. > > 'signaled' is used twice now but not defined. For both Semaphore and > Mutex this seems to indicate uncontended? Edit: seems to be needs-wakeup > more than uncontended. Uncontended, yes, or needs-wakeup (I'm not sure what the difference between the two is?) > > A mutex also holds an internal flag denoting whether its previous owner > > has died; such a mutex is said to be abandoned. Owner death is not > > tracked automatically based on thread death, but rather must be > > communicated using NTSYNC_IOC_MUTEX_KILL. An abandoned mutex is > > inherently considered unowned. > > > > Except for the "unowned" semantics of zero, the actual value of the > > owner identifier is not interpreted by the ntsync driver at all. The > > intended use is to store a thread identifier; however, the ntsync > > driver does not actually validate that a calling thread provides > > consistent or unique identifiers. > > Why not verify it? Seems simple enough to put in a TID check, esp. if NT > mandates the same. I mostly figured it'd be simplest to leave the driver completely agnostic, but I don't think there's any reason we can't use the real TID for most calls. > > An event holds a volatile boolean state denoting whether it is signaled > > or not. There are two types of events, auto-reset and manual-reset. An > > auto-reset event is designaled when a wait is satisfied; a manual-reset > > event is not. The event type is specified when the event is created. > > But what is an event? I'm familiar with semaphores and mutexes, but less > so with events. It's what I'm trying to define there, a single bit of state that's either contended or not. It acts broadly like an eventfd, in that you can wake (write) or wait (read), but without the distinction of having different nonzero values in the internal counter. You could also think of it as a semaphore with a maximum count of one. However, unlike a semaphore it also supports the "pulse" operation, and you can also have "manual-reset" events that *don't* change state when you wait on them (no equivalent for regular semaphores). > > Unless specified otherwise, all operations on an object are atomic and > > totally ordered with respect to other operations on the same object. > > > > Objects are represented by files. When all file descriptors to an > > object are closed, that object is deleted. > > > > Char device > > =========== > > > > The ntsync driver creates a single char device /dev/ntsync. Each file > > description opened on the device represents a unique instance intended > > to back an individual NT virtual machine. Objects created by one ntsync > > instance may only be used with other objects created by the same > > instance. > > > > ioctl reference > > =============== > > > > All operations on the device are done through ioctls. There are four > > structures used in ioctl calls:: > > > > struct ntsync_sem_args { > > __u32 sem; > > __u32 count; > > __u32 max; > > }; > > > > struct ntsync_mutex_args { > > __u32 mutex; > > __u32 owner; > > __u32 count; > > }; > > > > struct ntsync_event_args { > > __u32 event; > > __u32 signaled; > > __u32 manual; > > }; > > > > struct ntsync_wait_args { > > __u64 timeout; > > __u64 objs; > > __u32 count; > > __u32 owner; > > __u32 index; > > __u32 alert; > > __u32 flags; > > __u32 pad; > > }; > > > > Depending on the ioctl, members of the structure may be used as input, > > output, or not at all. All ioctls return 0 on success. > > > > The ioctls on the device file are as follows: > > > > NTSYNC_IOC_CREATE_SEM > > > > Create a semaphore object. Takes a pointer to struct ntsync_sem_args, > > which is used as follows: > > > > * sem: On output, contains a file descriptor to the created semaphore. > > * count: Initial count of the semaphore. > > * max: Maximum count of the semaphore. > > > > Fails with EINVAL if `count` is greater than `max`. > > So the implication is that @count and @max are input argument and as > such should be set before calling the ioctl()? > > It would not have been weird to have the ioctl() return the fd on > success I suppose, instead of mixing input and output arguments like > this, but whatever, this works. I think that would have been fine, and I could still change it accordingly. The reason I didn't do that was that [1] advises against it (although I don't know why). [1] https://docs.kernel.org/driver-api/ioctl.html#return-code > > The ioctls on the individual objects are as follows: > > > > NTSYNC_IOC_SEM_POST > > > > Post to 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. > > > > If adding to the semaphore's current count would raise the latter > > past the semaphore's maximum count, the ioctl fails with > > EOVERFLOW and the semaphore is not affected. If raising the > > semaphore's count causes it to become signaled, eligible threads > > waiting on this semaphore will be woken and the semaphore's count > > decremented appropriately. > > Urg, so this is the traditional V (vrijgeven per Dijkstra, release in > English), but now 'conveniently' called POST, such that it can be > readily confused with the P operation (passering, or passing) which it > is not. > > Glorious :-/ > > You're of course going to tell me NT did this and you can't help this > naming foible. No, NT calls it "release" (and the operation on a mutex is also "release" rather than "unlock".) I called it "post" after POSIX semaphores, on the idea that it'd be more familiar to a Unix developer (and shorter). I see I was wrong, so I'll rename it to "release". > > NTSYNC_IOC_MUTEX_UNLOCK > > > > Release a mutex object. Takes a pointer to struct ntsync_mutex_args, > > which is used as follows: > > > > * mutex: Ignored. > > * owner: Specifies the owner trying to release this mutex. > > * count: On output, contains the previous recursion count. > > > > If "owner" is zero, the ioctl fails with EINVAL. If "owner" > > is not the current owner of the mutex, the ioctl fails with > > EPERM. > > ISTR you having written elsewhere that NT actually demands mutexes to be > strictly per thread, which for the above would mandate @owner to be > current, no? Right. We could replace owner with current everywhere except for NTSYNC_IOC_KILL_OWNER. > > The mutex's count will be decremented by one. If decrementing the > > mutex's count causes it to become zero, the mutex is marked as > > unowned and signaled, and eligible threads waiting on it will be > > woken as appropriate. > > > > NTSYNC_IOC_SET_EVENT > > > > Signal an event object. Takes a pointer to a 32-bit integer, which on > > output contains the previous state of the event. > > > > Eligible threads will be woken, and auto-reset events will be > > designaled appropriately. > > Hmm, so the event thing is like a simple wait-wake scheme? Where the > 'signaled' bit is used as the wakeup state? Yes, exactly. > > NTSYNC_IOC_RESET_EVENT > > > > Designal an event object. Takes a pointer to a 32-bit integer, which > > on output contains the previous state of the event. > > > > NTSYNC_IOC_PULSE_EVENT > > > > Wake threads waiting on an event object while leaving it in an > > unsignaled state. Takes a pointer to a 32-bit integer, which on > > output contains the previous state of the event. > > > > A pulse operation can be thought of as a set followed by a reset, > > performed as a single atomic operation. If two threads are waiting on > > an auto-reset event which is pulsed, only one will be woken. If two > > threads are waiting a manual-reset event which is pulsed, both will > > be woken. However, in both cases, the event will be unsignaled > > afterwards, and a simultaneous read operation will always report the > > event as unsignaled. > > *groan* Yep :D This one is terrible, and it's the only one that Microsoft has come out and explicitly said "don't use this". Supposedly their kernel is even coded such that if a waiting thread gets hit by an interrupt that the pulse will go unnoticed, although I've tried to reproduce this in practice and been unsuccessful. But of course it's terrible regardless, because you never know if your thread is waiting or not. In practice it seems to usually be used on a timer, though, so that part doesn't matter as much. > > NTSYNC_IOC_READ_SEM > > > > Read the current state of a semaphore object. Takes a pointer to > > struct ntsync_sem_args, which is used as follows: > > > > * sem: Ignored. > > * count: On output, contains the current count of the semaphore. > > * max: On output, contains the maximum count of the semaphore. > > This seems inherently racy -- what is the intended purpose of this > interface? > > Specifically the moment a value is returned, either P or V operations > can change it, rendering the (as yet unused) return value incorrect. I have no idea what it's intended for. Actually it's not even exposed as a documented API, only an undocumented one. But it does work, and applications use it. > > NTSYNC_IOC_READ_MUTEX > > > > Read the current state of a mutex object. Takes a pointer to struct > > ntsync_mutex_args, which is used as follows: > > > > * mutex: Ignored. > > * owner: On output, contains the current owner of the mutex, or zero > > if the mutex is not currently owned. > > * count: On output, contains the current recursion count of the mutex. > > > > If the mutex is marked as abandoned, the function fails with > > EOWNERDEAD. In this case, "count" and "owner" are set to zero. > > Another questionable interface. I suspect you're going to be telling me > NT has them so you have to have them, but urgh. Unfortunately yes. > > NTSYNC_IOC_READ_EVENT > > > > Read the current state of an event object. Takes a pointer to struct > > ntsync_event_args, which is used as follows: > > > > * event: Ignored. > > * signaled: On output, contains the current state of the event. > > * manual: On output, contains 1 if the event is a manual-reset event, > > and 0 otherwise. > > I can't help but notice all those @sem, @mutex, @event 'output' members > being unused except for create. Seems like a waste to have them. Yes, mostly so I could reuse the existing structures. On the other hand if there's no reason not to return fds from the create ioctls, then we could just remove those members. > > NTSYNC_IOC_KILL_OWNER > > > > 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 > > owner. If the owner is zero, the ioctl fails with EINVAL. If the > > owner does not own the mutex, the function fails with EPERM. > > > > Eligible threads waiting on the mutex will be woken as appropriate > > (and such waits will fail with EOWNERDEAD, as described below). > > Wine will use this when it detects a thread exit I suppose. Exactly. > > NTSYNC_IOC_WAIT_ANY > > > > Poll on any of a list of objects, atomically acquiring at most one. > > Takes a pointer to struct ntsync_wait_args, which is used as follows: > > > > * timeout: Absolute timeout in nanoseconds. If NTSYNC_WAIT_REALTIME > > is set, the timeout is measured against the REALTIME > > clock; otherwise it is measured against the MONOTONIC > > clock. If the timeout is equal to or earlier than the > > current time, the function returns immediately without > > sleeping. If "timeout" is U64_MAX, the function will > > sleep until an object is signaled, and will not fail > > with ETIMEDOUT. > > > > * objs: Pointer to an array of "count" file descriptors > > (specified as an integer so that the structure has the > > same size regardless of architecture). If any object is > > invalid, the function fails with EINVAL. > > > > * count: Number of objects specified in the "objs" array. If > > greater than NTSYNC_MAX_WAIT_COUNT, the function fails > > with EINVAL. > > > > * owner: Mutex owner identifier. If any object in "objs" is a > > mutex, the ioctl will attempt to acquire that mutex on > > behalf of "owner". If "owner" is zero, the ioctl > > fails with EINVAL. > > Again, should that not be current? That is, why not maintain the NT > invariant and mandates TIDs and avoid the arguments in both cases? I don't think there's any particular reason. > > * index: On success, contains the index (into "objs") of the > > object which was signaled. If "alert" was signaled > > instead, this contains "count". > > Could be the actual return value, no? Edit: no it cannot be because > -EOWNERDEAD case below. Yeah. Again the advice about "only return zero from an ioctl", too. Although we could also use a bit in the return value (which is also kind of what NT does). > > A semaphore is considered to be signaled if its count is nonzero, and > > is acquired by decrementing its count by one. A mutex is considered > > to be signaled if it is unowned or if its owner matches the "owner" > > argument, and is acquired by incrementing its recursion count by one > > and setting its owner to the "owner" argument. An auto-reset event > > is acquired by designaling it; a manual-reset event is not affected > > by acquisition. > > > > Acquisition is atomic and totally ordered with respect to other > > operations on the same object. If two wait operations (with different > > "owner" identifiers) are queued on the same mutex, only one is > > signaled. If two wait operations are queued on the same semaphore, > > and a value of one is posted to it, only one is signaled. The order > > in which threads are signaled is not specified. > > Note that you do list the lack of guarantee here, but not above. I > suspect both cases are similar and guarantee nothing. There's no documented guarantee in either case, but when testing in controlled well-ordered environments, NtWaitForMultipleObjects() always acquires the lowest index first, and I think wakes are FIFO. I'm not really sure why I specified the guarantee for the former but not the latter. > > The "alert" argument is an "extra" event which can terminate the > > wait, independently of all other objects. If members of "objs" and > > "alert" are both simultaneously signaled, a member of "objs" will > > always be given priority and acquired first. > > > > It is valid to pass the same object more than once, including by > > passing the same event in the "objs" array and in "alert". If a > > wakeup occurs due to that object being signaled, "index" is set to > > the lowest index corresponding to that object. > > Urgh, is this an actual guarantee? This almost seems to imply that at > [A] above we can indeed guarantee the lowest indexed object is acquired > first. It's definitely legal in NT to pass the same object more than once (in wait-for-any, not wait-for-all though), and it's definitely the case that (at least in controlled well-ordered environments) the lowest index is acquired first. I don't know of any application that definitely depends on either of these, and they're not documented behaviours, but Wine has implemented those behaviours and it would make me nervous to break them here. The part about passing the same event in "alert" and "objs" is not part of NT exactly (in NT the "alert" isn't even an event; it's a special bit of thread state; we just use an event for simplicity). I think I specified it just to avoid coding an extra check (since it should Just Work), while also making it clear that case was considered. > > The function may fail with EINTR if a signal is received. > > In which case @index must be disregarded since nothing will be acquired, > right? > > So far nothing really weird, and I'm thinking futexes should be able to > do all this, no? Even disregarding wait-for-all, futexes aren't really good enough. Wait operations need to consume state, and while we could put that state in user space (and in fact we *do* have an out of tree patch set that kind of does this) that requires all that state to be shared across processes, which is a problem since we want processes to be isolated unless they explicitly share objects with each other. There's not a scalable way to achieve this, especially since you can share objects lazily. You also cannot do NtPulseEvent() this way. The aforementioned patch set badly emulates it and it does in practice break any application that uses it. Similarly there are some applications that do a weird "fake pulse" where they set and then immediately reset an event from the same thread, and expect that to always wake.

1 1

Re: [PATCH v4 02/27] ntsync: Introduce NTSYNC_IOC_WAIT_ALL.
by Elizabeth Figura 14 May '24

14 May '24

On Friday, April 19, 2024 11:28:14 AM CDT Peter Zijlstra wrote: > On Thu, Apr 18, 2024 at 11:35:11AM +0200, Peter Zijlstra wrote: > > On Wed, Apr 17, 2024 at 03:03:05PM -0500, Elizabeth Figura wrote: > > > Ach. I wrote this with the idea that the race isn't meaningful, but > > > looking at it again you're right—there is a harmful race here. > > > > > > I think it should be fixable by moving the atomic_read inside the lock, > > > though. > > > > Right, I've ended up with the (as yet untested) below. I'll see if I can > > find time later to actually test things. > > Latest hackery... I tried testing this but I'm not having luck using the > patched wine as per the other email. > I converted the rest of the direct uses of spin_lock() using the below patch and tested it myself, and it passes Wine tests. As far as I can tell the logic is correct, too; I couldn't find any races. I'll incorporate these changes into the next revision, unless there's a good reason not to. --- --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -569,17 +569,19 @@ static int ntsync_event_set(struct ntsync_obj *event, void __user *argp, bool pu static int ntsync_event_reset(struct ntsync_obj *event, void __user *argp) { + struct ntsync_device *dev = event->dev; __u32 prev_state; + bool all; if (event->type != NTSYNC_TYPE_EVENT) return -EINVAL; - spin_lock(&event->lock); + all = ntsync_lock_obj(dev, event); prev_state = event->u.event.signaled; event->u.event.signaled = false; - spin_unlock(&event->lock); + ntsync_unlock_obj(dev, event, all); if (put_user(prev_state, (__u32 __user *)argp)) return -EFAULT; @@ -590,16 +592,21 @@ static int ntsync_event_reset(struct ntsync_obj *event, void __user *argp) static int ntsync_sem_read(struct ntsync_obj *sem, void __user *argp) { struct ntsync_sem_args __user *user_args = argp; + struct ntsync_device *dev = sem->dev; struct ntsync_sem_args args; + bool all; if (sem->type != NTSYNC_TYPE_SEM) return -EINVAL; args.sem = 0; - spin_lock(&sem->lock); + + all = ntsync_lock_obj(dev, sem); + args.count = sem->u.sem.count; args.max = sem->u.sem.max; - spin_unlock(&sem->lock); + + ntsync_unlock_obj(dev, sem, all); if (copy_to_user(user_args, &args, sizeof(args))) return -EFAULT; @@ -609,18 +616,23 @@ static int ntsync_sem_read(struct ntsync_obj *sem, void __user *argp) static int ntsync_mutex_read(struct ntsync_obj *mutex, void __user *argp) { struct ntsync_mutex_args __user *user_args = argp; + struct ntsync_device *dev = mutex->dev; struct ntsync_mutex_args args; + bool all; int ret; if (mutex->type != NTSYNC_TYPE_MUTEX) return -EINVAL; args.mutex = 0; - spin_lock(&mutex->lock); + + all = ntsync_lock_obj(dev, mutex); + args.count = mutex->u.mutex.count; args.owner = mutex->u.mutex.owner; ret = mutex->u.mutex.ownerdead ? -EOWNERDEAD : 0; - spin_unlock(&mutex->lock); + + ntsync_unlock_obj(dev, mutex, all); if (copy_to_user(user_args, &args, sizeof(args))) return -EFAULT; @@ -630,16 +642,21 @@ static int ntsync_mutex_read(struct ntsync_obj *mutex, void __user *argp) static int ntsync_event_read(struct ntsync_obj *event, void __user *argp) { struct ntsync_event_args __user *user_args = argp; + struct ntsync_device *dev = event->dev; struct ntsync_event_args args; + bool all; if (event->type != NTSYNC_TYPE_EVENT) return -EINVAL; args.event = 0; - spin_lock(&event->lock); + + all = ntsync_lock_obj(dev, event); + args.manual = event->u.event.manual; args.signaled = event->u.event.signaled; - spin_unlock(&event->lock); + + ntsync_unlock_obj(dev, event, all); if (copy_to_user(user_args, &args, sizeof(args))) return -EFAULT; @@ -962,6 +979,7 @@ static int ntsync_wait_any(struct ntsync_device *dev, void __user *argp) __u32 i, total_count; struct ntsync_q *q; int signaled; + bool all; int ret; if (copy_from_user(&args, argp, sizeof(args))) @@ -981,9 +999,9 @@ static int ntsync_wait_any(struct ntsync_device *dev, void __user *argp) struct ntsync_q_entry *entry = &q->entries[i]; struct ntsync_obj *obj = entry->obj; - spin_lock(&obj->lock); + all = ntsync_lock_obj(dev, obj); list_add_tail(&entry->node, &obj->any_waiters); - spin_unlock(&obj->lock); + ntsync_unlock_obj(dev, obj, all); } /* @@ -1000,9 +1018,9 @@ static int ntsync_wait_any(struct ntsync_device *dev, void __user *argp) if (atomic_read(&q->signaled) != -1) break; - spin_lock(&obj->lock); + all = ntsync_lock_obj(dev, obj); try_wake_any_obj(obj); - spin_unlock(&obj->lock); + ntsync_unlock_obj(dev, obj, all); } /* sleep */ @@ -1015,9 +1033,9 @@ static int ntsync_wait_any(struct ntsync_device *dev, void __user *argp) struct ntsync_q_entry *entry = &q->entries[i]; struct ntsync_obj *obj = entry->obj; - spin_lock(&obj->lock); + all = ntsync_lock_obj(dev, obj); list_del(&entry->node); - spin_unlock(&obj->lock); + ntsync_unlock_obj(dev, obj, all); put_obj(obj); } @@ -1075,9 +1093,9 @@ static int ntsync_wait_all(struct ntsync_device *dev, void __user *argp) struct ntsync_q_entry *entry = &q->entries[args.count]; struct ntsync_obj *obj = entry->obj; - spin_lock_nest_lock(&obj->lock, &dev->wait_all_lock); + dev_lock_obj(dev, obj); list_add_tail(&entry->node, &obj->any_waiters); - spin_unlock(&obj->lock); + dev_unlock_obj(dev, obj); } /* check if we are already signaled */ @@ -1095,9 +1113,9 @@ static int ntsync_wait_all(struct ntsync_device *dev, void __user *argp) struct ntsync_obj *obj = q->entries[args.count].obj; if (atomic_read(&q->signaled) == -1) { - spin_lock(&obj->lock); + dev_lock_obj(dev, obj); try_wake_any_obj(obj); - spin_unlock(&obj->lock); + dev_unlock_obj(dev, obj); } } @@ -1127,9 +1145,9 @@ static int ntsync_wait_all(struct ntsync_device *dev, void __user *argp) struct ntsync_q_entry *entry = &q->entries[args.count]; struct ntsync_obj *obj = entry->obj; - spin_lock_nest_lock(&obj->lock, &dev->wait_all_lock); + dev_lock_obj(dev, obj); list_del(&entry->node); - spin_unlock(&obj->lock); + dev_unlock_obj(dev, obj); put_obj(obj); }

1 0

Re: [PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 07 May '24

07 May '24

On Friday, 19 April 2024 11:16:11 CDT Peter Zijlstra wrote: > On Tue, Apr 16, 2024 at 05:18:56PM -0500, Elizabeth Figura wrote: > > On Tuesday, 16 April 2024 16:18:24 CDT Elizabeth Figura wrote: > > > On Tuesday, 16 April 2024 03:14:21 CDT Peter Zijlstra wrote: > > > > I don't support GE has it in his builds? Last time I tried, building > > > > Wine was a bit of a pain. > > > > > > It doesn't seem so. I tried to build a GE-compatible ntsync build, uploaded > > > here (thanks Arek for hosting): > > > > > > https://f002.backblazeb2.com/file/wine-ntsync/ntsync-wine.tar.xz > > > > Oops, the initial version I uploaded had broken paths. Should be fixed now. > > > > (It's also broken on an unpatched kernel unless explicitly disabled with > > WINE_DISABLE_FAST_SYNC=1. Not sure what I messed up there—it should fall back > > cleanly—but hopefully shouldn't be too important for testing.) > > So I've tried using that wine build with lutris, and I can't get it to > start EGS or anything else. > > I even added a printk to the ntsync driver for every open, to see if it > gets that far, but I'm not even getting that :/ That's odd, it works for me, both as a standalone build and with lutris... Does /dev/ntsync exist (module is loaded) and have nonzero permissions? I forgot to mention that's necessary, sorry. Otherwise I can try to look at an strace, or a Wine debug log. I don't think there's an easy way to get the latter with Lutris, but something like `WINEDEBUG=+all ./wine winecfg 2>log` should work.

1 2

Wine staging 9.8 release
by Alistair Leslie-Hughes 04 May '24

04 May '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.8 (430 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * widl: Make automatic dispid generation scheme better match what midl does. * widl: Create library block index right after the CompObj one. * widl: Set the lowest bit in the param name to indicate whether type description follows the name. * widl: Add support for function parameter flags to SLTG typelib generator. * widl: Avoid relying on side effects when marking function index as the last one. * stdole32.tlb: Compile typelib with --oldtlb. Removed (No longer required). * ntdll-CriticalSection * Pipelight * winex11-XEMBED Added: * [46012] d3d9: Implement ID3DXEffect::SetRawValue. Updated: * vkd3d-latest * odbc-remove-unixodbc * ddraw-GetPickRecords 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: Alexandre Julliard : dbghelp: Ignore a couple of Dwarf-3 opcodes.
by Eric Pouech 30 Apr '24

30 Apr '24

Le 29/04/2024 à 22:22, Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 754f11a4adc2b7431837a92448b93bb845d99d61 > URL: https://gitlab.winehq.org/wine/wine/-/commit/754f11a4adc2b7431837a92448b93b… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Sun Apr 28 16:06:54 2024 +0200 > > dbghelp: Ignore a couple of Dwarf-3 opcodes. Hi for curiosity, how did you get these ? (clang ?) (for the record, dbghelp doesn't generate yet prologue & epilogue tagging in dwarf debug info (it's done for pdb)) A+

2 1

Re: Fwd: Bumping the minimum supported macOS version
by Tim Clem 28 Apr '24

28 Apr '24

I would prefer 10.15 in particular so we could drop support for native (i.e. macho) 32-bit binaries. That would allow us to use modern Obj-C runtime features (e.g. auto-synthesis) and eventually consider ARC. It's also worth noting that winehq's gitlab CI runs 10.15. On 4/11/24 11:06 AM, dgreer(a)codeweavers.com wrote: > I can safely say that upstream wine hasn't work on 10.8 since 7.22 ish, > wine-8.21 the lowest is probably 10.10 though I've aired on the side of > caution and locked 7.22 to require 10.11. > > The absolute lowest would be 10.13 though I'd already dropped support > below 10.15 in the winehq packages (installed via brew cask system), > myself and Marzent have long been in favor of upping the minimum > requirement for sometime. > > ---------- Forwarded message --------- > From: *Tim Clem* <tclem(a)codeweavers.com <mailto:tclem@codeweavers.com>> > Date: Thu, Apr 11, 2024 at 1:51 PM > Subject: Bumping the minimum supported macOS version > To: <wine-devel(a)winehq.org <mailto:wine-devel@winehq.org>> > > > Hello everyone-- > > I'm proposing raising the official minimum supported macOS version to > Catalina, 10.15. According to the wiki > (https://wiki.winehq.org/MacOS <https://wiki.winehq.org/MacOS>), we > theoretically support 10.8. > > Does anyone object? > > Thanks! > --Tim > > >

3 4

Bugzilla having issues sending mail
by Austin English 26 Apr '24

26 Apr '24

An unexpected error occurred. This could be a temporary problem, or some code is behaving incorrectly. If this problem persists, please email this page to wine-bugs(a)winehq.org with details of what you were doing at the time this message appeared. URL: https://bugs.winehq.org/process_bug.cgi There was an error sending mail from '"WineHQ Bugzilla" <wine-bugs(a)winehq.org>' to 'dark.shadow4(a)web.de': Couldn't connect to mail.winehq.org Traceback: at Bugzilla/Mailer.pm line 162. Bugzilla::Mailer::MessageToMTA(...) called at Bugzilla/BugMail.pm line 354 Bugzilla::BugMail::sendMail(...) called at Bugzilla/BugMail.pm line 255 Bugzilla::BugMail::Send(...) called at Bugzilla/Bug.pm line 1200 Bugzilla::Bug::_send_bugmail(...) called at Bugzilla/Bug.pm line 1138 Bugzilla::Bug::send_changes(...) called at /home/winehq/opt/bugzilla/process_bug.cgi line 378 -- -Austin GPG: 267B CC1F 053F 0749 (expires 2026-03-03)

2 2

Upcoming vkd3d 1.12 release
by Henri Verbeet 24 Apr '24

24 Apr '24

Hi all, The planned release date for vkd3d 1.12 is May 28. The development branch will become increasingly frozen as we're nearing that date, starting with a freeze of the public API after April 30. Features will be frozen after May 14. 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 all the vkd3d tests pass on your hardware, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for regressions, and file bug reports if you find any. If you're the maintainer of a Wine module that (indirectly) depends on vkd3d, like e.g. d2d1, d3dx9, d3dcompiler, or any of the core Direct3D modules, that includes making sure the unit tests still pass with the new version. The planned release date for vkd3d 1.13 is August 29. Regards, Henri

1 0

Wine staging 9.7 release
by Alistair Leslie-Hughes 21 Apr '24

21 Apr '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.7 (432 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * widl: Add support for recursive type references to SLTG typelib generator. * widl: Add support for interfaces to SLTG typelib generator. * widl: Add support for inherited interfaces to SLTG typelib generator. * ntdll: Add fake data implementation for ProcessQuotaLimits class. Removed (No longer required). * None Added: * None. Updated: * vkd3d-latest * kernel32-CopyFileEx NOTE: The updated ntdll-WRITECOPY patchset now allow Battle.net to run. 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

Mailing list traffic
by Francois Gouget 19 Apr '24

19 Apr '24

With GitLab and the spinning off of commit messages to wine-gitlab I think the traffic estimates on the mailing list page need to be updated... at least for wine-devel: it no longer has 50 messages per day. https://www.winehq.org/forums (unfortunately there is no unit on the little per mailing-list graph) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

4 3

Re: [PATCH v4 02/27] ntsync: Introduce NTSYNC_IOC_WAIT_ALL.
by Elizabeth Figura 17 Apr '24

17 Apr '24

On Wednesday, 17 April 2024 06:37:03 CDT Peter Zijlstra wrote: > On Mon, Apr 15, 2024 at 08:08:12PM -0500, Elizabeth Figura wrote: > > + if (atomic_read(&sem->all_hint) > 0) { > > + spin_lock(&dev->wait_all_lock); > > + spin_lock_nest_lock(&sem->lock, &dev->wait_all_lock); > > > > + prev_count = sem->u.sem.count; > > + ret = post_sem_state(sem, args); > > + if (!ret) { > > + try_wake_all_obj(dev, sem); > > + try_wake_any_sem(sem); > > + } > > > > + spin_unlock(&sem->lock); > > + spin_unlock(&dev->wait_all_lock); > > + } else { > > + spin_lock(&sem->lock); > > + > > + prev_count = sem->u.sem.count; > > + ret = post_sem_state(sem, args); > > + if (!ret) > > + try_wake_any_sem(sem); > > + > > + spin_unlock(&sem->lock); > > + } > > > > if (!ret && put_user(prev_count, user_args)) > > ret = -EFAULT; > > vs. > > > + /* queue ourselves */ > > + > > + spin_lock(&dev->wait_all_lock); > > + > > + for (i = 0; i < args.count; i++) { > > + struct ntsync_q_entry *entry = &q->entries[i]; > > + struct ntsync_obj *obj = entry->obj; > > + > > + atomic_inc(&obj->all_hint); > > + > > + /* > > + * obj->all_waiters is protected by dev->wait_all_lock rather > > + * than obj->lock, so there is no need to acquire obj->lock > > + * here. > > + */ > > + list_add_tail(&entry->node, &obj->all_waiters); > > + } > > This looks racy, consider: > > atomic_read(all_hints) /* 0 */ > > spin_lock(wait_all_lock) > atomic_inc(all_hint) /* 1 */ > list_add_tail() > > spin_lock(sem->lock) > /* try_wake_all_obj() missing */ > > > > > I've not yet thought about if this is harmful or not, but if not, it > definitely needs a comment. > > Anyway, I need a break, maybe more this evening. Ach. I wrote this with the idea that the race isn't meaningful, but looking at it again you're right—there is a harmful race here. I think it should be fixable by moving the atomic_read inside the lock, though.

1 0

Re: [PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 17 Apr '24

17 Apr '24

On Wednesday, 17 April 2024 00:22:18 CDT Peter Zijlstra wrote: > On Tue, Apr 16, 2024 at 04:18:19PM -0500, Elizabeth Figura wrote: > > Let me know if that's good enough or if I should try to render it into > > plain text somehow. > > Plain text is much preferred. I'm more of a text editor kinda guy -- > being a programmer and all that. I can certainly sympathize with that ;-) Here's a (slightly ad-hoc) simplification of the patch into text form inlined into this message; hopefully it's readable enough. =================================== NT synchronization primitive driver =================================== This page documents the user-space API for the ntsync driver. ntsync is a support driver for emulation of NT synchronization primitives by user-space NT emulators. It exists because implementation in user-space, using existing tools, cannot match Windows performance while offering accurate semantics. It is implemented entirely in software, and does not drive any hardware device. This interface is meant as a compatibility tool only, and should not be used for general synchronization. Instead use generic, versatile interfaces such as futex(2) and poll(2). Synchronization primitives ========================== The ntsync driver exposes three types of synchronization primitives: semaphores, mutexes, and events. A semaphore holds a single volatile 32-bit counter, and a static 32-bit integer denoting the maximum value. It is considered signaled when the counter is nonzero. The counter is decremented by one when a wait is satisfied. Both the initial and maximum count are established when the semaphore is created. A mutex holds a volatile 32-bit recursion count, and a volatile 32-bit identifier denoting its owner. A mutex is considered signaled when its owner is zero (indicating that it is not owned). The recursion count is incremented when a wait is satisfied, and ownership is set to the given identifier. A mutex also holds an internal flag denoting whether its previous owner has died; such a mutex is said to be abandoned. Owner death is not tracked automatically based on thread death, but rather must be communicated using NTSYNC_IOC_MUTEX_KILL. An abandoned mutex is inherently considered unowned. Except for the "unowned" semantics of zero, the actual value of the owner identifier is not interpreted by the ntsync driver at all. The intended use is to store a thread identifier; however, the ntsync driver does not actually validate that a calling thread provides consistent or unique identifiers. An event holds a volatile boolean state denoting whether it is signaled or not. There are two types of events, auto-reset and manual-reset. An auto-reset event is designaled when a wait is satisfied; a manual-reset event is not. The event type is specified when the event is created. Unless specified otherwise, all operations on an object are atomic and totally ordered with respect to other operations on the same object. Objects are represented by files. When all file descriptors to an object are closed, that object is deleted. Char device =========== The ntsync driver creates a single char device /dev/ntsync. Each file description opened on the device represents a unique instance intended to back an individual NT virtual machine. Objects created by one ntsync instance may only be used with other objects created by the same instance. ioctl reference =============== All operations on the device are done through ioctls. There are four structures used in ioctl calls:: struct ntsync_sem_args { __u32 sem; __u32 count; __u32 max; }; struct ntsync_mutex_args { __u32 mutex; __u32 owner; __u32 count; }; struct ntsync_event_args { __u32 event; __u32 signaled; __u32 manual; }; struct ntsync_wait_args { __u64 timeout; __u64 objs; __u32 count; __u32 owner; __u32 index; __u32 alert; __u32 flags; __u32 pad; }; Depending on the ioctl, members of the structure may be used as input, output, or not at all. All ioctls return 0 on success. The ioctls on the device file are as follows: .. NTSYNC_IOC_CREATE_SEM Create a semaphore object. Takes a pointer to struct ntsync_sem_args, which is used as follows: * sem: On output, contains a file descriptor to the created semaphore. * count: Initial count of the semaphore. * max: Maximum count of the semaphore. Fails with EINVAL if `count` is greater than `max`. .. NTSYNC_IOC_CREATE_MUTEX Create a mutex object. Takes a pointer to struct ntsync_mutex_args, which is used as follows: * mutex: On output, contains a file descriptor to the created mutex. * count: Initial recursion count of the mutex. * owner: Initial owner of the mutex. If ``owner`` is nonzero and ``count`` is zero, or if ``owner`` is zero and ``count`` is nonzero, the function fails with EINVAL. .. NTSYNC_IOC_CREATE_EVENT Create an event object. Takes a pointer to struct ntsync_event_args, which is used as follows: * event: On output, contains a file descriptor to the created event. * signaled: If nonzero, the event is initially signaled, otherwise nonsignaled. * manual: If nonzero, the event is a manual-reset event, otherwise auto-reset. The ioctls on the individual objects are as follows: .. NTSYNC_IOC_SEM_POST Post to 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. If adding to the semaphore's current count would raise the latter past the semaphore's maximum count, the ioctl fails with EOVERFLOW and the semaphore is not affected. If raising the semaphore's count causes it to become signaled, eligible threads waiting on this semaphore will be woken and the semaphore's count decremented appropriately. .. NTSYNC_IOC_MUTEX_UNLOCK Release a mutex object. Takes a pointer to struct ntsync_mutex_args, which is used as follows: * mutex: Ignored. * owner: Specifies the owner trying to release this mutex. * count: On output, contains the previous recursion count. If ``owner`` is zero, the ioctl fails with EINVAL. If ``owner`` is not the current owner of the mutex, the ioctl fails with EPERM. The mutex's count will be decremented by one. If decrementing the mutex's count causes it to become zero, the mutex is marked as unowned and signaled, and eligible threads waiting on it will be woken as appropriate. .. NTSYNC_IOC_SET_EVENT Signal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. Eligible threads will be woken, and auto-reset events will be designaled appropriately. .. NTSYNC_IOC_RESET_EVENT Designal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. .. NTSYNC_IOC_PULSE_EVENT Wake threads waiting on an event object while leaving it in an unsignaled state. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. A pulse operation can be thought of as a set followed by a reset, performed as a single atomic operation. If two threads are waiting on an auto-reset event which is pulsed, only one will be woken. If two threads are waiting a manual-reset event which is pulsed, both will be woken. However, in both cases, the event will be unsignaled afterwards, and a simultaneous read operation will always report the event as unsignaled. .. NTSYNC_IOC_READ_SEM Read the current state of a semaphore object. Takes a pointer to struct ntsync_sem_args, which is used as follows: * sem: Ignored. * count: On output, contains the current count of the semaphore. * max: On output, contains the maximum count of the semaphore. .. NTSYNC_IOC_READ_MUTEX Read the current state of a mutex object. Takes a pointer to struct ntsync_mutex_args, which is used as follows: * mutex: Ignored. * owner: On output, contains the current owner of the mutex, or zero if the mutex is not currently owned. * count: On output, contains the current recursion count of the mutex. If the mutex is marked as abandoned, the function fails with EOWNERDEAD. In this case, ``count`` and ``owner`` are set to zero. .. NTSYNC_IOC_READ_EVENT Read the current state of an event object. Takes a pointer to struct ntsync_event_args, which is used as follows: * event: Ignored. * signaled: On output, contains the current state of the event. * manual: On output, contains 1 if the event is a manual-reset event, and 0 otherwise. .. NTSYNC_IOC_KILL_OWNER 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 owner. If the owner is zero, the ioctl fails with EINVAL. If the owner does not own the mutex, the function fails with EPERM. Eligible threads waiting on the mutex will be woken as appropriate (and such waits will fail with EOWNERDEAD, as described below). .. NTSYNC_IOC_WAIT_ANY Poll on any of a list of objects, atomically acquiring at most one. Takes a pointer to struct ntsync_wait_args, which is used as follows: * timeout: Absolute timeout in nanoseconds. If NTSYNC_WAIT_REALTIME is set, the timeout is measured against the REALTIME clock; otherwise it is measured against the MONOTONIC clock. If the timeout is equal to or earlier than the current time, the function returns immediately without sleeping. If ``timeout`` is U64_MAX, the function will sleep until an object is signaled, and will not fail with ETIMEDOUT. * objs: Pointer to an array of ``count`` file descriptors (specified as an integer so that the structure has the same size regardless of architecture). If any object is invalid, the function fails with EINVAL. * count: Number of objects specified in the ``objs`` array. If greater than NTSYNC_MAX_WAIT_COUNT, the function fails with EINVAL. * owner: Mutex owner identifier. If any object in ``objs`` is a mutex, the ioctl will attempt to acquire that mutex on behalf of ``owner``. If ``owner`` is zero, the ioctl fails with EINVAL. * index: On success, contains the index (into ``objs``) of the object which was signaled. If ``alert`` was signaled instead, this contains ``count``. * alert: Optional event object file descriptor. If nonzero, this specifies an "alert" event object which, if signaled, will terminate the wait. If nonzero, the identifier must point to a valid event. * flags: Zero or more flags. Currently the only flag is NTSYNC_WAIT_REALTIME, which causes the timeout to be measured against the REALTIME clock instead of MONOTONIC. * pad: Unused, must be set to zero. This function attempts to acquire one of the given objects. If unable to do so, it sleeps until an object becomes signaled, subsequently acquiring it, or the timeout expires. In the latter case the ioctl fails with ETIMEDOUT. The function only acquires one object, even if multiple objects are signaled. A semaphore is considered to be signaled if its count is nonzero, and is acquired by decrementing its count by one. A mutex is considered to be signaled if it is unowned or if its owner matches the ``owner`` argument, and is acquired by incrementing its recursion count by one and setting its owner to the ``owner`` argument. An auto-reset event is acquired by designaling it; a manual-reset event is not affected by acquisition. Acquisition is atomic and totally ordered with respect to other operations on the same object. If two wait operations (with different ``owner`` identifiers) are queued on the same mutex, only one is signaled. If two wait operations are queued on the same semaphore, and a value of one is posted to it, only one is signaled. The order in which threads are signaled is not specified. If an abandoned mutex is acquired, the ioctl fails with EOWNERDEAD. Although this is a failure return, the function may otherwise be considered successful. The mutex is marked as owned by the given owner (with a recursion count of 1) and as no longer abandoned, and ``index`` is still set to the index of the mutex. The ``alert`` argument is an "extra" event which can terminate the wait, independently of all other objects. If members of ``objs`` and ``alert`` are both simultaneously signaled, a member of ``objs`` will always be given priority and acquired first. It is valid to pass the same object more than once, including by passing the same event in the ``objs`` array and in ``alert``. If a wakeup occurs due to that object being signaled, ``index`` is set to the lowest index corresponding to that object. The function may fail with EINTR if a signal is received. .. NTSYNC_IOC_WAIT_ALL Poll on a list of objects, atomically acquiring all of them. Takes a pointer to struct ntsync_wait_args, which is used identically to NTSYNC_IOC_WAIT_ANY, except that ``index`` is always filled with zero on success if not woken via alert. This function attempts to simultaneously acquire all of the given objects. If unable to do so, it sleeps until all objects become simultaneously signaled, subsequently acquiring them, or the timeout expires. In the latter case the ioctl fails with ETIMEDOUT and no objects are modified. Objects may become signaled and subsequently designaled (through acquisition by other threads) while this thread is sleeping. Only once all objects are simultaneously signaled does the ioctl acquire them and return. The entire acquisition is atomic and totally ordered with respect to other operations on any of the given objects. If an abandoned mutex is acquired, the ioctl fails with EOWNERDEAD. Similarly to NTSYNC_IOC_WAIT_ANY, all objects are nevertheless marked as acquired. Note that if multiple mutex objects are specified, there is no way to know which were marked as abandoned. As with "any" waits, the ``alert`` argument is an "extra" event which can terminate the wait. Critically, however, an "all" wait will succeed if all members in ``objs`` are signaled, *or* if ``alert`` is signaled. In the latter case ``index`` will be set to ``count``. As with "any" waits, if both conditions are filled, the former takes priority, and objects in ``objs`` will be acquired. Unlike NTSYNC_IOC_WAIT_ANY, it is not valid to pass the same object more than once, nor is it valid to pass the same object in ``objs`` and in ``alert``. If this is attempted, the function fails with EINVAL.

1 0

Re: [PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 16 Apr '24

16 Apr '24

On Tuesday, 16 April 2024 03:14:21 CDT Peter Zijlstra wrote: > On Mon, Apr 15, 2024 at 08:08:10PM -0500, Elizabeth Figura wrote: > > This patch series implements a new char misc driver, /dev/ntsync, which is > > used to implement Windows NT synchronization primitives. > > This patch series does not apply to anything I have at hand. Nor does it > state anything explicit to put it on top of. It was written to apply against the 'char-misc-next' branch of gregkh/char- misc.git. I'll make a note of that next time, sorry for the inconvenience. > > Hence I would like to request review from someone familiar with locking to > > make sure that the usage of low-level kernel primitives is correct and > > that the wait queues work as intended, and to that end I've CC'd the > > locking maintainers. > I am sadly very limited atm, but I'll try and read through it. If only I > could apply... > > > == Patches == > > > > The intended semantics of the patches are broadly intended to match those > > of the corresponding Windows functions. For those not already familiar > > with the Windows functions (or their undocumented behaviour), patch 27/27 > > provides a detailed specification, and individual patches also include a > > brief description of the API they are implementing. > > > > The patches making use of this driver in Wine can be retrieved or browsed here: > > https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 > > I don't support GE has it in his builds? Last time I tried, building > Wine was a bit of a pain. It doesn't seem so. I tried to build a GE-compatible ntsync build, uploaded here (thanks Arek for hosting): https://f002.backblazeb2.com/file/wine-ntsync/ntsync-wine.tar.xz > > Some aspects of the implementation may deserve particular comment: > > > > * In the interest of performance, each object is governed only by a single > > > > spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of > > multiple > > objects be changed as a single atomic operation. In order to achieve > > this, we first take a device-wide lock ("wait_all_lock") any time we > > are going to lock more than one object at a time. > > > > The maximum number of objects that can be used in a vectored wait, and > > therefore the maximum that can be locked simultaneously, is 64. This > > number is NT's own limit. > > > > The acquisition of multiple spinlocks will degrade performance. This is > > a > > conscious choice, however. Wait-for-all is known to be a very rare > > operation in practice, especially with counts that approach the > > maximum, and it is the intent of the ntsync driver to optimize > > wait-for-any at the expense of wait-for-all as much as possible. > > Per the example of percpu-rwsem, it would be possible to create a > mutex-spinlock hybrid scheme, where single locks are spinlocks while > held, but can block when the global thing is pending. And the global > lock is always mutex like. > > If all that is worth it, I don't know. Nesting 64 spinlocks doesn't give > me warm and fuzzy feelings though. Is the concern about poor performance when ntsync is in use, or is nesting a lot of spinlocks like that something that could cause problems for unrelated tasks? I'm not familiar enough with the scheduler to know if this can be abused. I think we don't care about performance problems within Wine, at least. FWIW, the scheme here is actually similar to what Windows does (as described by one of their kernel engineers), although slightly different. NT nests spinlocks as well, but instead of using the outer lock like our "wait_all_lock" to prevent lock inversion, they instead sort the inner locks (by address, I assume). If there's deeper problems... I can look into (ab)using a rwlock for this purpose, at least for now. In any case making wait_all_lock into a sleeping mutex instead of a spinlock should be fine. I'll rerun performance tests but I don't expect it to cause any problems.

1 1

Re: [PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 16 Apr '24

16 Apr '24

On Tuesday, 16 April 2024 11:05:53 CDT Peter Zijlstra wrote: > On Mon, Apr 15, 2024 at 08:08:10PM -0500, Elizabeth Figura wrote: > > The intended semantics of the patches are broadly intended to match those > > of the corresponding Windows functions. For those not already familiar > > with the Windows functions (or their undocumented behaviour), patch 27/27 > > provides a detailed specification, and individual patches also include a > > brief description of the API they are implementing. > > You happen to have a readable copy of patch 27 around? RST is utter > garbage to read :/ An HTML copy should be available here now (thanks Arek): https://ivyl.gg/ntsync/ntsync.html Let me know if that's good enough or if I should try to render it into plain text somehow.

1 0

Re: [PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 16 Apr '24

16 Apr '24

On Tuesday, 16 April 2024 11:19:17 CDT Peter Zijlstra wrote: > On Tue, Apr 16, 2024 at 05:53:45PM +0200, Peter Zijlstra wrote: > > On Tue, Apr 16, 2024 at 05:50:14PM +0200, Peter Zijlstra wrote: > > > On Tue, Apr 16, 2024 at 10:14:21AM +0200, Peter Zijlstra wrote: > > > > > Some aspects of the implementation may deserve particular comment: > > > > > > > > > > * In the interest of performance, each object is governed only by a > > > > > single > > > > > > > > > > spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of > > > > > multiple > > > > > objects be changed as a single atomic operation. In order to > > > > > achieve this, we first take a device-wide lock ("wait_all_lock") > > > > > any time we are going to lock more than one object at a time. > > > > > > > > > > The maximum number of objects that can be used in a vectored wait, > > > > > and > > > > > therefore the maximum that can be locked simultaneously, is 64. > > > > > This number is NT's own limit. > > > > > > AFAICT: > > > spin_lock(&dev->wait_all_lock); > > > > > > list_for_each_entry(entry, &obj->all_waiters, node) > > > > > > for (i=0; i<count; i++) > > > > > > spin_lock_nest_lock(q->entries[i].obj->lock, > > > &dev->wait_all_lock); > > > > > > Where @count <= NTSYNC_MAX_WAIT_COUNT. > > > > > > So while this nests at most 65 spinlocks, there is no actual bound on > > > the amount of nested lock sections in total. That is, all_waiters list > > > can be grown without limits. > > > > > > Can we pretty please make wait_all_lock a mutex ? That should be fine, at least. > > Hurmph, it's worse, you do that list walk while holding some obj->lock > > spinlokc too. Still need to figure out how all that works.... > > So the point of having that other lock around is so that things like: > > try_wake_all_obj(dev, sem) > try_wake_any_sem(sem) > > are done under the same lock? The point of having the other lock around is that try_wake_all() needs to lock multiple objects at the same time. It's a way of avoiding lock inversion. Consider task A does a wait-for-all on objects X, Y, Z. Then task B signals Y, so we do try_wake_all_obj() on Y, which does try_wake_all() on A's queue entry; that needs to check X and Z and consume the state of all three objects atomically. Another task could be trying to signal Z at the same time and could hit a task waiting on Z, Y, X, and that causes inversion. The simple and easy way to implement everything is just to have a global lock on the whole device, but this is kind of known to be a performance bottleneck (this was NT's BKL, and they ditched it starting with Vista or 7 or something). Instead we use a lock per object, and normally in the wait-for-any case we only ever need to grab one lock at a time, but when we need to do a wait-for- all we need to lock multiple objects at once, and we grab the outer lock to avoid potential lock inversion. > Where I seem to note that both those functions do that same list > iteration. Over different lists. I don't know if there's a better way to name things to make that clearer. There's the "any" wait queue, which tasks which do a wait-for-any add themselves to, and the "all" wait queue, which tasks that do a wait-for-all add themselves to. Signaling an object could potentially wake up either one, but checking whether a task is eligible is a different process.

1 0

[PATCH v4 00/30] NT synchronization primitive driver
by Elizabeth Figura 16 Apr '24

16 Apr '24

This patch series implements a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. NT synchronization primitives are unique in that the wait functions both are vectored, operate on multiple types of object with different behaviour (mutex, semaphore, event), and affect the state of the objects they wait on. This model is not compatible with existing kernel synchronization objects or interfaces, and therefore the ntsync driver implements its own wait queues and locking. Hence I would like to request review from someone familiar with locking to make sure that the usage of low-level kernel primitives is correct and that the wait queues work as intended, and to that end I've CC'd the locking maintainers. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 27/27 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_MUTEX_KILL on any open mutexes. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes from v3: * Add .gitignore and use KHDR_INCLUDES in selftest build files, per Muhammad Usama Anjum. * Try to explain why we are rolling our own primitives a little better, per Greg Kroah-Hartman. * Link to v3: https://lore.kernel.org/lkml/20240329000621.148791-1-zfigura@codeweavers.co… * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (27): ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/ntsync.rst | 399 +++++ MAINTAINERS | 9 + drivers/misc/ntsync.c | 925 ++++++++++- include/uapi/linux/ntsync.h | 39 + tools/testing/selftests/Makefile | 1 + .../selftests/drivers/ntsync/.gitignore | 1 + .../testing/selftests/drivers/ntsync/Makefile | 7 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 10 files changed, 2786 insertions(+), 4 deletions(-) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 tools/testing/selftests/drivers/ntsync/.gitignore create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: ebbc1a4789c666846b9854ef845a37a64879e5f9 -- 2.43.0

1 27

Re: [PATCH v3 04/30] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 12 Apr '24

12 Apr '24

On Thursday, 11 April 2024 08:34:23 CDT Greg Kroah-Hartman wrote: > On Thu, Mar 28, 2024 at 07:05:55PM -0500, Elizabeth Figura wrote: > > This corresponds to part of the functionality of the NT syscall > > NtWaitForMultipleObjects(). Specifically, it implements the behaviour where > > the third argument (wait_any) is TRUE, and it does not handle alertable waits. > > Those features have been split out into separate patches to ease review. > > > > NTSYNC_IOC_WAIT_ANY is a vectored wait function similar to poll(). Unlike > > poll(), it "consumes" objects when they are signaled. For semaphores, this means > > decreasing one from the internal counter. At most one object can be consumed by > > this function. > > > > Up to 64 objects can be waited on at once. As soon as one is signaled, the > > object with the lowest index is consumed, and that index is returned via the > > "index" field. > > So it's kind of like our internal locks already? Or futex? Striking the right balance of explaining the problem space without inundating the reader with information has been tricky; I'll do my best to try to explain here. The primitives include mutexes and semaphores, like our internal locks. I don't really want to compare them to futexes because futexes don't have internal state. However NT's primitives are *way* more complicated. The big part of it is they consume state in a way that usual wait functions don't, and as if that weren't enough, you can do operations with them like wait-for-all (wait for all objects to be simultaneously signaled and atomically consume them) or pulse (signal an object without changing its state). None of this can be expressed with poll or futex. You can't even express those operations with wait_event() etc. We really need to replace the entire wait queue and use schedule() + wake_up_process() directly. ntsync_q is the wait queue struct in this. They're also really ugly things to do; they only exist for compatibility reasons, and retrofitting support into anything would complicate and slow down hot paths. > > A timeout is supported. The timeout is passed as a u64 nanosecond value, which > > represents absolute time measured against either the MONOTONIC or REALTIME clock > > (controlled by the flags argument). If U64_MAX is passed, the ioctl waits > > indefinitely. > > > > This ioctl validates that all objects belong to the relevant device. This is not > > necessary for any technical reason related to NTSYNC_IOC_WAIT_ANY, but will be > > necessary for NTSYNC_IOC_WAIT_ALL introduced in the following patch. > > > > Two u32s of padding are left in the ntsync_wait_args structure; one will be used > > by a patch later in the series (which is split out to ease review). > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > drivers/misc/ntsync.c | 250 ++++++++++++++++++++++++++++++++++++ > > include/uapi/linux/ntsync.h | 16 +++ > > 2 files changed, 266 insertions(+) > > > > diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c > > index 3c2f743c58b0..c6f84a5fc8c0 100644 > > --- a/drivers/misc/ntsync.c > > +++ b/drivers/misc/ntsync.c > > @@ -6,11 +6,16 @@ > > */ > > > > #include <linux/anon_inodes.h> > > +#include <linux/atomic.h> > > #include <linux/file.h> > > #include <linux/fs.h> > > +#include <linux/hrtimer.h> > > +#include <linux/ktime.h> > > #include <linux/miscdevice.h> > > #include <linux/module.h> > > #include <linux/overflow.h> > > +#include <linux/sched.h> > > +#include <linux/sched/signal.h> > > #include <linux/slab.h> > > #include <linux/spinlock.h> > > #include <uapi/linux/ntsync.h> > > @@ -30,6 +35,8 @@ enum ntsync_type { > > * > > * Both rely on struct file for reference counting. Individual > > * ntsync_obj objects take a reference to the device when created. > > + * Wait operations take a reference to each object being waited on for > > + * the duration of the wait. > > */ > > > > struct ntsync_obj { > > @@ -47,12 +54,56 @@ struct ntsync_obj { > > __u32 max; > > } sem; > > } u; > > + > > + struct list_head any_waiters; > > +}; > > + > > +struct ntsync_q_entry { > > + struct list_head node; > > + struct ntsync_q *q; > > + struct ntsync_obj *obj; > > + __u32 index; > > +}; > > + > > +struct ntsync_q { > > + struct task_struct *task; > > + __u32 owner; > > + > > + /* > > + * Protected via atomic_try_cmpxchg(). Only the thread that wins the > > + * compare-and-swap may actually change object states and wake this > > + * task. > > + */ > > + atomic_t signaled; > > This feels odd, why are you duplicating a normal lock functionality > here? ntsync_q represents a single waiter (like struct wait_queue_entry). In short, waiting is a destructive operation; it changes the state of the primitives waited on. If a waiter is woken successfully then it must have consumed the state of exactly one object. Therefore, if task A is waiting on two primitives X and Y, and those primitives are respectively woken at the same time by tasks B and C, we need a way to ensure that B and C don't both wake A and consume the state of X and Y. Only one of them should win. We could do that with a lock on the ntsync_q struct, but having a single variable with atomic-test-and-set achieves the same thing while being lock-free. > > + > > + __u32 count; > > + struct ntsync_q_entry entries[]; > > }; > > > > struct ntsync_device { > > struct file *file; > > }; > > > > +static void try_wake_any_sem(struct ntsync_obj *sem) > > +{ > > + struct ntsync_q_entry *entry; > > + > > + lockdep_assert_held(&sem->lock); > > + > > + list_for_each_entry(entry, &sem->any_waiters, node) { > > + struct ntsync_q *q = entry->q; > > + int signaled = -1; > > + > > + if (!sem->u.sem.count) > > + break; > > + > > + if (atomic_try_cmpxchg(&q->signaled, &signaled, entry->index)) { > > + sem->u.sem.count--; > > + wake_up_process(q->task); > > + } > > You are waking up _all_ "locks" that with the atomic_try_cmpxchg() call, > right? Not just the "first". > > Or am I confused? This is looping over all tasks trying to lock / acquire "sem", and waking them (assuming something else didn't wake them first) while decrementing "sem" state accordingly. > > + } > > +} > > + > > /* > > * Actually change the semaphore state, returning -EOVERFLOW if it is made > > * invalid. > > @@ -88,6 +139,8 @@ static int ntsync_sem_post(struct ntsync_obj *sem, void __user *argp) > > > > prev_count = sem->u.sem.count; > > ret = post_sem_state(sem, args); > > + if (!ret) > > + try_wake_any_sem(sem); > > > > spin_unlock(&sem->lock); > > > > @@ -141,6 +194,7 @@ static struct ntsync_obj *ntsync_alloc_obj(struct ntsync_device *dev, > > obj->dev = dev; > > get_file(dev->file); > > spin_lock_init(&obj->lock); > > + INIT_LIST_HEAD(&obj->any_waiters); > > > > return obj; > > } > > @@ -191,6 +245,200 @@ static int ntsync_create_sem(struct ntsync_device *dev, void __user *argp) > > return put_user(fd, &user_args->sem); > > } > > > > +static struct ntsync_obj *get_obj(struct ntsync_device *dev, int fd) > > +{ > > + struct file *file = fget(fd); > > + struct ntsync_obj *obj; > > + > > + if (!file) > > + return NULL; > > + > > + if (file->f_op != &ntsync_obj_fops) { > > + fput(file); > > + return NULL; > > + } > > + > > + obj = file->private_data; > > + if (obj->dev != dev) { > > + fput(file); > > + return NULL; > > + } > > + > > + return obj; > > +} > > + > > +static void put_obj(struct ntsync_obj *obj) > > +{ > > + fput(obj->file); > > +} > > + > > +static int ntsync_schedule(const struct ntsync_q *q, const struct ntsync_wait_args *args) > > +{ > > + ktime_t timeout = ns_to_ktime(args->timeout); > > + clockid_t clock = CLOCK_MONOTONIC; > > + ktime_t *timeout_ptr; > > + int ret = 0; > > + > > + timeout_ptr = (args->timeout == U64_MAX ? NULL : &timeout); > > + > > + if (args->flags & NTSYNC_WAIT_REALTIME) > > + clock = CLOCK_REALTIME; > > + > > + do { > > + if (signal_pending(current)) { > > + ret = -ERESTARTSYS; > > + break; > > + } > > + > > + set_current_state(TASK_INTERRUPTIBLE); > > + if (atomic_read(&q->signaled) != -1) { > > + ret = 0; > > + break; > > What happens if the value changes right after you read it? The corresponding wake code flips signaled and then does wake_up_process(), so schedule() returns immediately (and we see q->signaled set and exit the loop.) > Rolling your own lock is tricky, and needs review from the locking > maintainers. And probably some more documentation as to what is > happening and why our normal types of locks can't be used here? Definitely. (Unfortunately this hasn't gotten attention from any locking maintainer yet since your last call for review; not sure if there's anything I can do there.) Hopefully my comment at the top of this mail explains why we're rolling our own everything, but if not please let me know and I can try to explain more clearly. --Zeb

1 0

Bumping the minimum supported macOS version
by Tim Clem 11 Apr '24

11 Apr '24

Hello everyone-- I'm proposing raising the official minimum supported macOS version to Catalina, 10.15. According to the wiki (https://wiki.winehq.org/MacOS), we theoretically support 10.8. Does anyone object? Thanks! --Tim

2 1

Wine staging 9.6 release
by Alistair Leslie-Hughes 06 Apr '24

06 Apr '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.6 (431 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * macOS.yml: Set ac_cv_lib_soname_vulkan * winegstreamer: Add MFVideoFormat_ARGB32 output for the source. * fltmgr.sys: Implement FltBuildDefaultSecurityDescriptor * fltmgr.sys: Create import library * ntoskrnl.exe: Add FltBuildDefaultSecurityDescriptor test * widl: Add initial implementation of SLTG typelib generator. * widl: Add support for structures. * widl: Properly align name table entries. * widl: More accurately report variable descriptions data size. * widl: Calculate size of instance for structures. * widl: Write correct typekind to the SLTG typeinfo block. * widl: Write SLTG blocks according to the index order. * widl: Write correct syskind by SLTG typelib generator. * widl: Add support for VT_VOID and VT_VARIANT to SLTG typelib generator. * widl: Add support for VT_USERDEFINED to SLTG typelib generator. * widl: Factor out SLTG tail initialization. * widl: Fix generation of resources containing an old typelib. * widl: Add --oldtlb switch in usage message. * widl: Minor/cosmetic clean up. Removed (No longer required). * None Added: * None. Updated: * vkd3d-latest * windows.networking.connectivity-new-dll * ntdll-WRITECOPY NOTE: The updated ntdll-WRITECOPY patchset now allow Battle.net to run. 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

Solving the slow review problem with AI
by Gabriel Ivăncescu 02 Apr '24

02 Apr '24

Hi all, As we all know, the Wine project suffers from a shortage of maintainers/reviewers and timely reviews. This has always been a thing, so it's not something recent. While it's all too easy to dismiss this and say we simply need to get more maintainers, the reality is that it's not that simple, or we would've done so by now already. Since Generative AI and Large Language Models (LLMs) are all the rage these days, I figured it would be a good opportunity to join the trend. I propose a LLM trained for reviewing Wine code with full authority over the entire review process, so we can focus on writing code (and having it ripped out by the AI, for good reasons of course). The plan is to have it completely integrated with gitlab and the review process automatically, with the goal of it becoming the ultimate—and only—maintainer for the project. I've been training one for a while now with cloud services, though it needs more fine tuning of course, and it has no access to gitlab so far. Due to the training data, it exhibits a bias of review styles by famous reviewers such as Linus Torvalds (from the Linux kernel), so expect a lot of productive rants. I also gave it the capability to close MRs if the code is simply unsalvageable, though obviously only when it gets authorization to do so. In my tests, 98.657% of the code I sent it was classified as "garbage" and "unsalvageable", proving its effectiveness. The code tested were random patches and commits that were upstreamed to the Wine project, which explains a lot why we still haven't reached feature parity with Windows… Gone will be the days of waiting weeks to even get a response to your MR; now you'll just get bashed almost immediately and most likely even have your MR instantly closed "as a lost cause" if it stinks that much for the all-knowing LLM. I mean, computers don't make mistakes, so it must be right. For example we have MR !5432, where the LLM instantly rambled about how the old code was even upstreamed in the first place when it was clearly incorrect and didn't do what it was supposed to, but praised the MR for "finally doing something about it." I did tell it the new code doesn't compile, but that's obviously a compiler bug, or so it says. Next I plan to give it the ability to automatically submit bug reports to compiler vendors because obviously they aren't working right. Unfortunately I'll need to find a way to tone its language down a bit because I'm certain they'll be classified as spam—they're not ready for the AI revolution yet. Ideally we'd need to fine tune this a lot more on way more powerful hardware if it sounds like a good way forward. Thoughts?

3 2

[PATCH v3 00/30] NT synchronization primitive driver
by Elizabeth Figura 29 Mar '24

29 Mar '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 31/31 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_MUTEX_KILL on any open mutexes. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes from v2: * Check the result of fget() for NULL. * Squash patch 31 (introducing the NTSYNC_WAIT_REALTIME flag) into patch 4, per Arnd Bergmann. * Use atomic_try_cmpxchg() instead of atomic_cmpxchg(), per off-list review from Uros Bizjak. * Link to v2: https://lore.kernel.org/lkml/20240219223833.95710-1-zfigura@codeweavers.com/ * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (30): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 2 + Documentation/userspace-api/ntsync.rst | 399 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 11 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 1166 ++++++++++++++ include/uapi/linux/ntsync.h | 62 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/drivers/ntsync/Makefile | 8 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 12 files changed, 3068 insertions(+) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: 4cece764965020c22cff7665b18a012006359095 -- 2.43.0

1 30

List failing (?!?!)
by David Kahurani 27 Mar '24

27 Mar '24

Hello, I am subscribed to receive mail from the list wine(a)gitlab.winehq.org However, I notice this morning that all mail from last night's merger are missing. Did the list fail or something I don't understand? Regards David.

1 0

Wine staging 9.5 release
by Alistair Leslie-Hughes 23 Mar '24

23 Mar '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.5 (435 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * shell32: Append .exe when registry lookup fails first time. * wined3d: Use bindless textures for GLSL shaders. * kernel32/tests: Add tests for job object accounting. * shell32: Fix SHFileOperation(FO_MOVE) for creating subdirectories. * user32: Added LoadKeyboardLayoutEx stub. Removed (No longer required). * ws2_32-TransmitFile * ntdll-Threading Added: * None. Updated: * vkd3d-latest NOTE: widl-SLTG_Typelib_Support has been disabled due and is currently being upstreamed. 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

[PATCH v2 00/31] NT synchronization primitive driver
by Elizabeth Figura 11 Mar '24

11 Mar '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. This was previously submitted as an RFC [1]. Since there were no major changes requested to the last RFC revision, I've stripped the RFC prefix. [1] https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 31/31 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_MUTEX_KILL on any open mutexes. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes from v1: * Fix a broken rebase that stole part of the Kconfig documentation from the neighbouring entry, per Randy Dunlap. * Add my email address to copyright and MODULE_AUTHOR lines, per Randy Dunlap. * Document the reference counting behaviour more clearly, per Greg Kroah-Hartman. * Hopefully submit all the patches this time the right way. * Link to v1: https://lore.kernel.org/lkml/20240214233645.9273-1-zfigura@codeweavers.com/ * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (31): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. ntsync: Allow waits to use the REALTIME clock. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Elizabeth Figura (31): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. ntsync: Allow waits to use the REALTIME clock. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 2 + Documentation/userspace-api/ntsync.rst | 399 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 11 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 1159 ++++++++++++++ include/uapi/linux/ntsync.h | 62 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/drivers/ntsync/Makefile | 8 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 12 files changed, 3061 insertions(+) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: 8d11c6d9b14f7a87f65529cb33edc5fed846ed9d -- 2.43.0

1 32

Wine staging 9.4 release
by Alistair Leslie-Hughes 09 Mar '24

09 Mar '24

Binary packages for various distributions will be available from: https://www.winehq.org/download vkd3d has been updated to 1.11 For a full list of changes, please follow the link below. https://gitlab.winehq.org/wine/vkd3d/-/releases/vkd3d-1.11 NOTE: Upstream Wine was updated to this version as well. We have continued with keeping wine-staging to latest vkd3d. Summary since last release * Rebased to current wine 9.4 (462 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * shell32: Implement NewMenu with new folder item. * shell32: Implement insert/paste for item context menus. * shell32: Recognize cut/copy/paste string verbs in item menu - context menu. * shell32: Implement the "runas" verb. * shell32: Add support for setting/getting PREFERREDDROPEFFECT in IDataObject. * shell32: Add parameter to ISFHelper::DeleteItems to allow deleting files without confirmation. * shell32: Remove source files when using cut in the context menu. * wine.inf: Add 'New' context menu handler entry for directories. * msi: Do not sign extend after multiplying. * wine.inf: Set the EnableLUA value to 1. * msi: Create the custom action server as an elevated process. * ntdll: Implement process token elevation through manifests. * ntdll: Always start the initial process through start.exe. * ntdll: Elevate processes if requested in RtlCreateUserProcess(). * user32: Start explorer.exe using limited rights. * programs/runas: Basic implementation for starting processes with a different trustlevel. * server: Create processes using a limited administrator token by default. * kernelbase: Elevate processes if requested in CreateProcessInternal(). Removed (No longer required). * server-File_Permissions * mscoree-CorValidateImage (Fixed uptream already). Added: * None. Updated: * vkd3d-latest * kernel32-CopyFileEx * ntdll-Junction_Points * ntdll-WRITECOPY * user32-rawinput-mouse 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

Staging update drop part 2
by DodoGTA GT 08 Mar '24

08 Mar '24

Hello, I managed to prepare another round of patches for wine-staging (the last one is actually a Wine patch though and it's a bit hacky too so I'm not sure if it's a good solution) Thanks

2 1

Wine staging 9.3 release
by Alistair Leslie-Hughes 24 Feb '24

24 Feb '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.3 (473 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winex11.drv: Simplify XInput2 valuator lookup. * winex11.drv: Split XInput2 thread initialization. * winex11.drv: Advertise XInput2 version 2.1 support. * shlwapi: Support ./ in UrlCanonicalize. * shlwapi/tests: Add additional tests for UrlCombine and UrlCanonicalize * shlwapi: UrlCombineW workaround for relative paths * Revert "explorer: Set layered style on systray icons only when it's actually layered." * Revert "explorer: Don't activate the systray icon when showing it." * where: Implement search with default options. * Try to retrieve the unix name on handles created from file descriptors. Added: * None. Removed (No longer required) * kernel32-Processor_Group * ntdll-x86_64_Builtin_Frames * wined3d-mesa_texture_download * winex11-Vulkan_support * winspool.drv-ClosePrinter * ntdll-NtQuerySection Updated: * vkd3d-latest * Compiler_Warnings 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 v2 01/31] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 22 Feb '24

22 Feb '24

On Thursday, 22 February 2024 04:56:21 CST Geert Uytterhoeven wrote: > > --- a/drivers/misc/Kconfig > > +++ b/drivers/misc/Kconfig > > @@ -506,6 +506,17 @@ config OPEN_DICE > > > > If unsure, say N. > > > > +config NTSYNC > > + tristate "NT synchronization primitive emulation" > > + help > > + This module provides kernel support for emulation of Windows NT > > + synchronization primitives. It is not a hardware driver. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called ntsync. > > + > > + If unsure, say N. > > Is it useful to have this feature on systems or architectures that > are not supported by Windows NT? > > If not, this should depend on <something> || COMPILE_TEST. Hmm, that's an interesting question. Currently only Wine supports x86 and ARM, as the only architectures supported by modern Windows. On the other hand, that hasn't always been the case, and there's been some desire to use Wine (as a porting tool) on architectures that Windows doesn't support, and out-of-tree ports to e.g. PowerPC to that end. Perhaps more saliently, there's no reason I'm aware of that this code *can't* run on any architecture, and Wine (or another NT emulator) may grow support for more architectures in the future. I (with my limited experience) don't see a reason to artificially limit ourselves, especially if the driver is disabled by default. --Zeb

1 0

Re: [PATCH v2 17/31] ntsync: Allow waits to use the REALTIME clock.
by Elizabeth Figura 22 Feb '24

22 Feb '24

On Tuesday, 20 February 2024 01:01:59 CST Arnd Bergmann wrote: > On Mon, Feb 19, 2024, at 23:38, Elizabeth Figura wrote: > > NtWaitForMultipleObjects() can receive a timeout in two forms, relative or > > absolute. Relative timeouts are unaffected by changes to the system time and do > > not count down while the system suspends; for absolute timeouts the opposite is > > true. > > > > In order to make the interface and implementation simpler, the ntsync driver > > only deals in absolute timeouts. However, we need to be able to emulate both > > behaviours apropos suspension and time adjustment, which is achieved by allowing > > either the MONOTONIC or REALTIME clock to be used. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > I understand that there is no practical problem in building > up the API one patch at a time in the initial merge, but > it still feels wrong to have an incompatible ABI change in > the middle of the series: > > > @@ -35,6 +37,8 @@ struct ntsync_wait_args { > > __u32 owner; > > __u32 index; > > __u32 alert; > > + __u32 flags; > > + __u32 pad; > > }; > > If this was patch to get merged at any later point, you'd have > to support both the shorter and the longer structure layout > with their distinct ioctl command codes. > > If you do a v3 series, maybe just merge this patch into the > one that introduces the struct ntsync_wait_args. Overall, > you could probably have fewer but larger patches anyway > without harming the review process, but other than this > one that is not a problem. Oops, yes, that does feel wrong now that you point it out. I'll squash this in v3, assuming there's a need for one. --Zeb

1 0

Re: [PATCH 02/31] ntsync: Introduce NTSYNC_IOC_CREATE_SEM.
by Elizabeth Figura 19 Feb '24

19 Feb '24

On Saturday, 17 February 2024 02:03:15 CST Greg Kroah-Hartman wrote: > On Thu, Feb 15, 2024 at 01:22:01PM -0600, Elizabeth Figura wrote: > > On Thursday, 15 February 2024 01:28:32 CST Greg Kroah-Hartman wrote: > > > On Wed, Feb 14, 2024 at 05:36:38PM -0600, Elizabeth Figura wrote: > > > > This corresponds to the NT syscall NtCreateSemaphore(). > > > > > > > > Semaphores are one of three types of object to be implemented in this driver, > > > > the others being mutexes and events. > > > > > > > > An NT semaphore contains a 32-bit counter, and is signaled and can be acquired > > > > when the counter is nonzero. The counter has a maximum value which is specified > > > > at creation time. The initial value of the semaphore is also specified at > > > > creation time. There are no restrictions on the maximum and initial value. > > > > > > > > Each object is exposed as an file, to which any number of fds may be opened. > > > > When all fds are closed, the object is deleted. > > > > > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > > > --- > > > > .../userspace-api/ioctl/ioctl-number.rst | 2 + > > > > drivers/misc/ntsync.c | 120 ++++++++++++++++++ > > > > include/uapi/linux/ntsync.h | 21 +++ > > > > 3 files changed, 143 insertions(+) > > > > create mode 100644 include/uapi/linux/ntsync.h > > > > > > > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst > > > > index 457e16f06e04..2f5c6994f042 100644 > > > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > > > @@ -173,6 +173,8 @@ Code Seq# Include File Comments > > > > 'M' 00-0F drivers/video/fsl-diu-fb.h conflict! > > > > 'N' 00-1F drivers/usb/scanner.h > > > > 'N' 40-7F drivers/block/nvme.c > > > > +'N' 80-8F uapi/linux/ntsync.h NT synchronization primitives > > > > + <mailto:wine-devel@winehq.org> > > > > 'O' 00-06 mtd/ubi-user.h UBI > > > > 'P' all linux/soundcard.h conflict! > > > > 'P' 60-6F sound/sscape_ioctl.h conflict! > > > > diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c > > > > index e4969ef90722..3ad86d98b82d 100644 > > > > --- a/drivers/misc/ntsync.c > > > > +++ b/drivers/misc/ntsync.c > > > > @@ -5,26 +5,146 @@ > > > > * Copyright (C) 2024 Elizabeth Figura > > > > */ > > > > > > > > +#include <linux/anon_inodes.h> > > > > +#include <linux/file.h> > > > > #include <linux/fs.h> > > > > #include <linux/miscdevice.h> > > > > #include <linux/module.h> > > > > +#include <linux/slab.h> > > > > +#include <uapi/linux/ntsync.h> > > > > > > > > #define NTSYNC_NAME "ntsync" > > > > > > > > +enum ntsync_type { > > > > + NTSYNC_TYPE_SEM, > > > > +}; > > > > + > > > > +struct ntsync_obj { > > > > + enum ntsync_type type; > > > > + > > > > + union { > > > > + struct { > > > > + __u32 count; > > > > + __u32 max; > > > > + } sem; > > > > + } u; > > > > + > > > > + struct file *file; > > > > + struct ntsync_device *dev; > > > > +}; > > > > + > > > > +struct ntsync_device { > > > > + struct file *file; > > > > +}; > > > > > > No reference counting is needed for your ntsync_device? Or are you > > > relying on the reference counting of struct file here? > > > > > > You pass around pointers to this structure, and save it off into other > > > structures, how do you know it is "safe" to do so? > > > > Yes, this relies on the reference counting of struct file. The sync > > objects (semaphore etc.) grab a reference when they're created, via > > get_file(), and release it when they're destroyed. This reference is > > taken from within ioctls on the ntsync_device, so the file must be > > valid when we grab a reference. Maybe I'm missing something, though? > > If the reference count is driven by struct file, that's fine, and great, > otherwise you end up with two different reference counts and keeping > them in sync is impossible. > > But as it wasn't obvious, a comment somewhere here would be helpful for > reviewing and figuring out how this all works in 4 years when someone > has to touch it again. Ah, makes sense. I'll add comments to be clearer about the refcounting relationships, thanks. --Zeb

1 0

Moving Wine Mono
by Esme Povirk 16 Feb '24

16 Feb '24

I'm starting the process of moving Wine Mono off of my personal Github account and onto the Winehq Gitlab in the organization here: https://gitlab.winehq.org/wine-mono Obviously, I haven't gotten very far yet, as the main repo for Wine Mono itself doesn't exist, but the intent is to move every submodule that we've forked (as well as projects I've started just for Wine Mono) over to Winehq, set up CI there, and archive my Github repos. The procedure for contributing will be to fork the repository and create merge requests (which I will also do for my own contributions, once we're set up for it). I'm also rethinking the branch structure. The Mono repo will have three mainline branches: upstream (the upstream project as it exists in the official repos), main (upstream plus further development that I will review and maintain), and wine-mono (main plus changes we have only in Wine). The "upstream" and "main" branches should be the same for any upstream that is responsive and cares about preserving ABI compatibility (right now that's just FNA and monoDX). The wine-mono branch should only exist for projects that have a general use case in which Wine's changes don't make sense (I think that's just Mono, corefx, and FNA). The answer to "which branch should I send my MR to?" will almost always be main. There should be a very few changes on wine-mono only. The ones I can think of off the top of my head are: enabling native dll loading without coree hooks, renaming a bunch of assemblies to start with "WineMono.", winforms hooks in FNA, and proprietary media formats in FNA. Over the years we've been doing a lot of development on top of Mono that, in my opinion, belongs upstream. I will also accept changes to Mono that have nothing to do with Wine, such as winforms changes, and I will try to keep the main branch working for use cases outside of Wine and Windows, to the extent that it's feasible (there are a bunch of configurations I can't easily test, like PowerPC, ARM, Android, and iOS, and I can't see myself doing development to support new platforms like M1). I don't know how much development interest there will be, but I seem to be in a unique position to maintain Framework Mono, and I think it is needed.

1 0

Re: [PATCH 02/31] ntsync: Introduce NTSYNC_IOC_CREATE_SEM.
by Elizabeth Figura 15 Feb '24

15 Feb '24

On Thursday, 15 February 2024 01:28:32 CST Greg Kroah-Hartman wrote: > On Wed, Feb 14, 2024 at 05:36:38PM -0600, Elizabeth Figura wrote: > > This corresponds to the NT syscall NtCreateSemaphore(). > > > > Semaphores are one of three types of object to be implemented in this driver, > > the others being mutexes and events. > > > > An NT semaphore contains a 32-bit counter, and is signaled and can be acquired > > when the counter is nonzero. The counter has a maximum value which is specified > > at creation time. The initial value of the semaphore is also specified at > > creation time. There are no restrictions on the maximum and initial value. > > > > Each object is exposed as an file, to which any number of fds may be opened. > > When all fds are closed, the object is deleted. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > .../userspace-api/ioctl/ioctl-number.rst | 2 + > > drivers/misc/ntsync.c | 120 ++++++++++++++++++ > > include/uapi/linux/ntsync.h | 21 +++ > > 3 files changed, 143 insertions(+) > > create mode 100644 include/uapi/linux/ntsync.h > > > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst > > index 457e16f06e04..2f5c6994f042 100644 > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > @@ -173,6 +173,8 @@ Code Seq# Include File Comments > > 'M' 00-0F drivers/video/fsl-diu-fb.h conflict! > > 'N' 00-1F drivers/usb/scanner.h > > 'N' 40-7F drivers/block/nvme.c > > +'N' 80-8F uapi/linux/ntsync.h NT synchronization primitives > > + <mailto:wine-devel@winehq.org> > > 'O' 00-06 mtd/ubi-user.h UBI > > 'P' all linux/soundcard.h conflict! > > 'P' 60-6F sound/sscape_ioctl.h conflict! > > diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c > > index e4969ef90722..3ad86d98b82d 100644 > > --- a/drivers/misc/ntsync.c > > +++ b/drivers/misc/ntsync.c > > @@ -5,26 +5,146 @@ > > * Copyright (C) 2024 Elizabeth Figura > > */ > > > > +#include <linux/anon_inodes.h> > > +#include <linux/file.h> > > #include <linux/fs.h> > > #include <linux/miscdevice.h> > > #include <linux/module.h> > > +#include <linux/slab.h> > > +#include <uapi/linux/ntsync.h> > > > > #define NTSYNC_NAME "ntsync" > > > > +enum ntsync_type { > > + NTSYNC_TYPE_SEM, > > +}; > > + > > +struct ntsync_obj { > > + enum ntsync_type type; > > + > > + union { > > + struct { > > + __u32 count; > > + __u32 max; > > + } sem; > > + } u; > > + > > + struct file *file; > > + struct ntsync_device *dev; > > +}; > > + > > +struct ntsync_device { > > + struct file *file; > > +}; > > No reference counting is needed for your ntsync_device? Or are you > relying on the reference counting of struct file here? > > You pass around pointers to this structure, and save it off into other > structures, how do you know it is "safe" to do so? Yes, this relies on the reference counting of struct file. The sync objects (semaphore etc.) grab a reference when they're created, via get_file(), and release it when they're destroyed. This reference is taken from within ioctls on the ntsync_device, so the file must be valid when we grab a reference. Maybe I'm missing something, though?

1 0

Re: [PATCH 01/31] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 15 Feb '24

15 Feb '24

On Wednesday, 14 February 2024 19:57:23 CST Randy Dunlap wrote: > Hi, > > On 2/14/24 15:36, Elizabeth Figura wrote: > > ntsync uses a misc device as the simplest and least intrusive uAPI interface. > > > > Each file description on the device represents an isolated NT instance, intended > > to correspond to a single NT virtual machine. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > drivers/misc/Kconfig | 9 ++++++++ > > drivers/misc/Makefile | 1 + > > drivers/misc/ntsync.c | 52 +++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 62 insertions(+) > > create mode 100644 drivers/misc/ntsync.c > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > > index 4fb291f0bf7c..bdd8a71bd853 100644 > > --- a/drivers/misc/Kconfig > > +++ b/drivers/misc/Kconfig > > @@ -504,6 +504,15 @@ config OPEN_DICE > > measured boot flow. Userspace can use CDIs for remote attestation > > and sealing. > > > > +config NTSYNC > > + tristate "NT synchronization primitive emulation" > > + help > > + This module provides kernel support for emulation of Windows NT > > + synchronization primitives. It is not a hardware driver. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called ntsync. > > + > > If unsure, say N. > > It looks like the "If unsure" line belongs to the OPEN_DICE kconfig entry > above here. If you want one for NTSYNC, please add one. Oops, looks like that was a bad rebase :-( > > > > > config VCPU_STALL_DETECTOR > > > > diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c > > new file mode 100644 > > index 000000000000..e4969ef90722 > > --- /dev/null > > +++ b/drivers/misc/ntsync.c > > @@ -0,0 +1,52 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * ntsync.c - Kernel driver for NT synchronization primitives > > + * > > + * Copyright (C) 2024 Elizabeth Figura > > It would be nice to have your email address above... > > > + */ > > + > > > + > > +MODULE_AUTHOR("Elizabeth Figura"); > > but at least please add it in MODULE_AUTHOR(). Yes it's optional, but > roughly 7900 of 10400 entries do include it (according to my rough > grepping). > > Yes, I know that it's in MAINTAINERS. Will add, thanks. As you guessed I did just pick an arbitrary module to copy.

1 0

[PATCH 00/31] NT synchronization primitive driver
by Elizabeth Figura 15 Feb '24

15 Feb '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. This was previously submitted as an RFC [1]. Since there were no major changes requested to the last RFC revision, I've stripped the RFC prefix. [1] https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 31/31 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_MUTEX_KILL on any open mutexes. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes from the last (v2) RFC: * Add a new wait flag NTSYNC_WAIT_REALTIME. I had originally missed a corner case in NtWaitForMultipleObjects() related to its interaction with system time adjustments. Essentially the function is sometimes supposed to respect system time adjustments and sometimes supposed to ignore them, so in order to achieve this I've added a function that controls which flag is being synchronized to. Thanks Piotr Caban for catching this. * Add tests for overflowing semaphore and mutex counters, and a test for exceeding NTSYNC_MAX_WAIT_COUNT, per Andi Kleen. * Add a more intense and realistic test involving multiple threads using the same mutex to access data, per Andi Kleen. * Use check_add_overflow() instead of writing out overflow checking manually [and thereby avoid relying on -fwrapv]. * Add some missing headers that were being implicitly included: atomic.h, hrtimer.h, ktime.h, sched.h, sched/signal.h, spinlock.h. * Link to RFC v2: https://lore.kernel.org/lkml/20240131021356.10322-1-zfigura@codeweavers.com/ * Link to RFC v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (31): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. ntsync: Allow waits to use the REALTIME clock. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. selftests: ntsync: Add a stress test for contended waits. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 2 + Documentation/userspace-api/ntsync.rst | 399 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 1146 ++++++++++++++ include/uapi/linux/ntsync.h | 62 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/drivers/ntsync/Makefile | 8 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1407 +++++++++++++++++ 12 files changed, 3046 insertions(+) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c base-commit: e21817acb23ece75d41a4fa7b40c85550f147389 -- 2.43.0

1 32

Wine staging 9.2 release
by Alistair Leslie-Hughes 11 Feb '24

11 Feb '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.2 (489 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9_36-D3DXDisassembleShader Added: * None Updated: * vkd3d-latest * ntdll-Junction_Points The patch count is down due to the upstreaming of the rawinput changes and due to conflicts, the wine-staging rawinput patches are disabled. 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 staging 9.0 release
by Alistair Leslie-Hughes 10 Feb '24

10 Feb '24

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

4 5

Staging reparse point fix
by DodoGTA GT 09 Feb '24

09 Feb '24

Hello, I have made an updated version of the reparse points patchset fix that should reduce the patch noise quite a bit (I think the original version is better in terms of code duplication though)

2 1

kernelbase: adding support for callback in CopyFileEx, and implementing CopyFile2
by sendtokartavya＠gmail.com 08 Feb '24

08 Feb '24

context: https://bugs.winehq.org/show_bug.cgi?id=55897 While implementing CopyFile2, I noticed that CopyFileEx does not respect the progress callback and never calls it. The tests too assume that it will not be invoked other than in the case of a file having multiple streams, which is not something that Wine supports. There seem to have been multiple efforts to implement this functionality (in 2022 and 2013) but I can't tell find any reasoning for why they were not successful. Would implementing this be a desirable contribution? I don't know how to get assigned to an issue on Bugzilla. I read the Wine Developers Wiki but it doesn't seem to have the information, so I left a comment in the bug log itself.

4 3

Re: [RFC PATCH v2 19/29] selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 03 Feb '24

03 Feb '24

On Wednesday, 31 January 2024 02:52:11 CST Andi Kleen wrote: > Elizabeth Figura <zfigura(a)codeweavers.com> writes: > > > +TEST(test_wait_any) > > +{ > > + struct ntsync_mutex_args mutex_args = {0}; > > + struct ntsync_wait_args wait_args = {0}; > > + struct ntsync_sem_args sem_args = {0}; > > + __u32 owner, index, count; > > + struct timespec timeout; > > + int objs[2], fd, ret; > > + > > + clock_gettime(CLOCK_MONOTONIC, &timeout); > > + > > + fd = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); > > + ASSERT_LE(0, fd); > > + > > + sem_args.count = 2; > > + sem_args.max = 3; > > + sem_args.sem = 0xdeadbeef; > > + ret = ioctl(fd, NTSYNC_IOC_CREATE_SEM, &sem_args); > > + EXPECT_EQ(0, ret); > > + EXPECT_NE(0xdeadbeef, sem_args.sem); > > + > > + mutex_args.owner = 0; > > + mutex_args.count = 0; > > + mutex_args.mutex = 0xdeadbeef; > > + ret = ioctl(fd, NTSYNC_IOC_CREATE_MUTEX, &mutex_args); > > + EXPECT_EQ(0, ret); > > + EXPECT_NE(0xdeadbeef, mutex_args.mutex); > > It seems your tests are missing test cases for exceeding any limits, > especially overflow/underflow cases. Since these are the most likely > for any security problems it would be good to have extra coverage here. > The fuzzers will hopefully hit it too. > > Also some stress testing with multiple threads would be useful. Thanks, I'll add these.

1 0

Upcoming vkd3d 1.11 release
by Henri Verbeet 01 Feb '24

01 Feb '24

Hi all, The tentative release date for vkd3d 1.11 is March 5. As usual, that means the development branch will become increasingly frozen as we're nearing release. In particular, the public API should be considered frozen after February 6, and we'll only accept targetted fixes after February 20. 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 all the vkd3d tests pass on your hardware, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for regressions, and file bug reports if you find any. If you're the maintainer of a Wine module that (indirectly) depends on vkd3d, like e.g. d2d1, d3dx9, d3dcompiler, or any of the core Direct3D modules, that includes making sure the unit tests still pass with the new version. The planned release date for vkd3d 1.12 is currently May 28. Regards, Henri

1 0

[RFC PATCH v2 00/29] NT synchronization primitive driver
by Elizabeth Figura 31 Jan '24

31 Jan '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuils, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. For those not already familiar with the Windows functions (or their undocumented behaviour), patch 29/29 provides a detailed specification, and individual patches also include a brief description of the API they are implementing. The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync5 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize wait-for-any at the expense of wait-for-all as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_KILL_OWNER, which will mark mutexes owned by that thread (if any) as abandoned. * This implementation uses a misc device mostly because it seemed like the simplest and least obtrusive option. Besides simplicitly of implementation, the only particularly interesting advantage is the ability to create an arbitrary number of "contexts" (corresponding to Windows virtual machines) which are self-contained and shareable across multiple processes; this maps nicely to file descriptions (i.e. struct file). This is not impossible with syscalls of course but would require an extra argument. On the other hand, there is no reason to forbid using ntsync by default from user-mode processes, and (as far as I understand) to do so with a char device requires explicit configuration by e.g. udev or init. Since this is done with e.g. fuse, I assume this is the model to follow, but I may have chosen something deprecated. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. It is not a hard requirement, though. == Previous versions == Changes in v2: * Send the whole series instead of just the first few patches. * Try to add more description to each patch, as a short documentation of the functions to be implemented. A more complete documentation of all aspects of the driver is provided in the contents of the last patch. * Objects are now files rather than indices into a table. This prevents a process from changing the state of an object which it should not have access to. Suggested by Andy Lutorminski. * Because the device no longer inherently has a table of all objects, marking a thread's owned mutexes as abandoned is now done through an ioctl on the mutex. * Change the names of a couple ioctls to be a bit less odd (PUT_SEM -> SEM_POST, PUT_MUTEX -> MUTEX_UNLOCK), and to reflect that they are ioctls on an object rather than on the device. * Pass the timeout for wait functions as a bare u64 (in ns), per Arnd Bergmann, with U64_MAX used to indicate no timeout. I originally indicated that I would change the timeout to be relative, but on reflection ended up keeping it as absolute, as this results in the least number of calls to get the current time (i.e. one). * Use compat_ptr_ioctl(), per Arnd Bergmann. * Remove the fixed minor number and module alias, per Greg Kroah-Hartman. * Allocate the fds array on stack in setup_wait(). This array takes up 260 bytes. * Link to v1: https://lore.kernel.org/lkml/20240124004028.16826-1-zfigura@codeweavers.com/ Elizabeth Figura (29): ntsync: Introduce the ntsync driver and character device. ntsync: Introduce NTSYNC_IOC_CREATE_SEM. ntsync: Introduce NTSYNC_IOC_SEM_POST. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK. ntsync: Introduce NTSYNC_IOC_MUTEX_KILL. ntsync: Introduce NTSYNC_IOC_CREATE_EVENT. ntsync: Introduce NTSYNC_IOC_EVENT_SET. ntsync: Introduce NTSYNC_IOC_EVENT_RESET. ntsync: Introduce NTSYNC_IOC_EVENT_PULSE. ntsync: Introduce NTSYNC_IOC_SEM_READ. ntsync: Introduce NTSYNC_IOC_MUTEX_READ. ntsync: Introduce NTSYNC_IOC_EVENT_READ. ntsync: Introduce alertable waits. selftests: ntsync: Add some tests for semaphore state. selftests: ntsync: Add some tests for mutex state. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY. selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL. selftests: ntsync: Add some tests for manual-reset event state. selftests: ntsync: Add some tests for auto-reset event state. selftests: ntsync: Add some tests for wakeup signaling with events. selftests: ntsync: Add tests for alertable waits. selftests: ntsync: Add some tests for wakeup signaling via alerts. maintainers: Add an entry for ntsync. docs: ntsync: Add documentation for the ntsync uAPI. Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 2 + Documentation/userspace-api/ntsync.rst | 390 +++++ MAINTAINERS | 9 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 1132 ++++++++++++++ include/uapi/linux/ntsync.h | 58 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/drivers/ntsync/Makefile | 8 + tools/testing/selftests/drivers/ntsync/config | 1 + .../testing/selftests/drivers/ntsync/ntsync.c | 1300 +++++++++++++++++ 12 files changed, 2912 insertions(+) create mode 100644 Documentation/userspace-api/ntsync.rst create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h create mode 100644 tools/testing/selftests/drivers/ntsync/Makefile create mode 100644 tools/testing/selftests/drivers/ntsync/config create mode 100644 tools/testing/selftests/drivers/ntsync/ntsync.c -- 2.43.0

1 29

The future of WineConf
by Alexandre Julliard 27 Jan '24

27 Jan '24

Folks, As you may have noticed, we haven't been making any plans for WineConf this year. Jeremy has been busy preparing his retirement, and I haven't been pushing it either, mostly because I'm not convinced that we want to continue the traditional WineConf model. Even though we skipped a few years because of the pandemic, attendance at last year's WineConf wasn't great. We also suggested meeting at FOSDEM in February, like we did in previous years, but essentially no one showed up. So I'm wondering whether there is still enough interest for a traditional WineConf, or whether we should try a different approach, to maybe capture some of the recent excitement around gaming and downstream uses of Wine in general. I'd like to hear your thoughts. Should we do a Proton conference, or join some kind of gaming-related event? Do people even want to travel to conferences anymore? What kind of event would you be interested in, particularly those of you who don't show up to the traditional WineConf? -- Alexandre Julliard julliard(a)winehq.org

14 19

Wine staging 9.1 release
by Alistair Leslie-Hughes 27 Jan '24

27 Jan '24

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.1 (508 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * include: Add more D3D_FEATURE_LEVEL_ defines. * oleaut32: Do not reimplement OleLoadPicture in OleLoadPicturePath. * oleaut32: Factor out stream creation from OleLoadPicturePath. * oleaut32: Implement OleLoadPictureFile. (v2) * user32/tests: Add tests for clicking through layered window. * user32/tests: Add tests for window region of layered windows. Added: * [50148] msi: Process cabinet files only when one is supplied. * [51965] msxml3: IMXWrite::output to support DOMDocument. * [52128] scrrun: Implement IFileSystem3 MoveFolder. Updated: * vkd3d-latest * user32-Mouse_Message_Hwnd (Rebased and enabled) * wined3d-bindless-texture (Rebased and enabled) * ddraw-version-check (Rebased and enabled) * vcomp_for_dynamic_init_i8 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

Staging patchset update
by DodoGTA GT 27 Jan '24

27 Jan '24

Hello, I just updated the vkd3d-latest staging patchset with the latest vkd3d commit (attached below) Hopefully someone can push this to wine-staging Thanks, Aida/Echo (DodoGTA)

2 1

[RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 25 Jan '24

25 Jan '24

This patch series introduces a new char misc driver, /dev/ntsync, which is used to implement Windows NT synchronization primitives. == Background == The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. This driver was presented at Linux Plumbers Conference 2023. For those further interested in the history of synchronization in Wine and past attempts to solve this problem in user space, a recording of the presentation can be viewed here: https://www.youtube.com/watch?v=NjU4nyWyhU8 == Performance == The gain in performance varies wildly depending on the application in question and the user's hardware. For some games NT synchronization is not a bottleneck and no change can be observed, but for others frame rate improvements of 50 to 150 percent are not atypical. The following table lists frame rate measurements from a variety of games on a variety of hardware, taken by users Dmitry Skvortsov, FuzzyQuills, OnMars, and myself: Game Upstream ntsync improvement =========================================================================== Anger Foot 69 99 43% Call of Juarez 99.8 224.1 125% Dirt 3 110.6 860.7 678% Forza Horizon 5 108 160 48% Lara Croft: Temple of Osiris 141 326 131% Metro 2033 164.4 199.2 21% Resident Evil 2 26 77 196% The Crew 26 51 96% Tiny Tina's Wonderlands 130 360 177% Total War Saga: Troy 109 146 34% =========================================================================== == Patches == This is the first part of a 32-patch series. The series comprises 17 patches which contain the actual implementation, 13 which provide self-tests, 1 to update the MAINTAINERS file, and 1 to add API documentation. The intended semantics of the patches are broadly intended to match those of the corresponding Windows functions. Since I do not expect familiarity with Windows syscalls, however, and especially not with some of the more subtle or unspecified behaviour that they provide, the documentation patch included in the series also describes the intended behaviour in detail, and can be used as a specification for the rest of the series. The entire series can be retrieved or browsed here: https://repo.or.cz/linux/zf.git/shortlog/refs/heads/ntsync4 The patches making use of this driver in Wine can be retrieved or browsed here: https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync4 == Implementation == Some aspects of the implementation may deserve particular comment: * In the interest of performance, each object is governed only by a single spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of multiple objects be changed as a single atomic operation. In order to achieve this, we first take a device-wide lock ("wait_all_lock") any time we are going to lock more than one object at a time. The maximum number of objects that can be used in a vectored wait, and therefore the maximum that can be locked simultaneously, is 64. This number is NT's own limit. The acquisition of multiple spinlocks will degrade performance. This is a conscious choice, however. Wait-for-all is known to be a very rare operation in practice, especially with counts that approach the maximum, and it is the intent of the ntsync driver to optimize the wait-for-any pattern at the expense of the wait-for-all pattern as much as possible. * NT mutexes are tied to their threads on an OS level, and the kernel includes builtin support for "robust" mutexes. In order to keep the ntsync driver self-contained and avoid touching more code than necessary, it does not hook into task exit nor use pids. Instead, the user space emulator is expected to manage thread IDs and pass them as an argument to any relevant functions; this is the "owner" field of ntsync_wait_args and ntsync_mutex_args. When the emulator detects that a thread dies, it should therefore call NTSYNC_IOC_KILL_OWNER, which will mark mutexes owned by that thread (if any) as abandoned. * This implementation uses a misc device mostly because it seemed like the simplest and least obtrusive option. Besides simplicitly of implementation, the only particularly interesting advantage is the ability to create an arbitrary number of "contexts" (corresponding to Windows virtual machines) which are self-contained and shareable across multiple processes; this maps nicely to file descriptions (i.e. struct file). This is not impossible with syscalls of course but would require an extra argument. On the other hand, there is no reason to forbid using ntsync by default from user-mode processes, and (as far as I understand) to do so with a char device requires explicit configuration by e.g. udev or init. Since this is done with e.g. fuse, I assume this is the model to follow, but I may have chosen something deprecated. * ntsync is module-capable mostly because there was nothing preventing it, and because it aided development. I am not aware of any reason why being a module is required, though. * The misc minor number has not been reserved with LANANA. I am not sure at what point in the process this makes the most sense, but since this is still only an RFC I've abstained from doing so yet. Elizabeth Figura (9): ntsync: Introduce the ntsync driver and character device. ntsync: Reserve a minor device number and ioctl range. ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE. ntsync: Introduce NTSYNC_IOC_PUT_SEM. ntsync: Introduce NTSYNC_IOC_WAIT_ANY. ntsync: Introduce NTSYNC_IOC_WAIT_ALL. ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX. ntsync: Introduce NTSYNC_IOC_PUT_MUTEX. ntsync: Introduce NTSYNC_IOC_KILL_OWNER. Documentation/admin-guide/devices.txt | 3 +- .../userspace-api/ioctl/ioctl-number.rst | 2 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/ntsync.c | 916 ++++++++++++++++++ include/linux/miscdevice.h | 1 + include/uapi/linux/ntsync.h | 53 + 7 files changed, 984 insertions(+), 1 deletion(-) create mode 100644 drivers/misc/ntsync.c create mode 100644 include/uapi/linux/ntsync.h base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d -- 2.43.0

3 15

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 25 Jan '24

25 Jan '24

On Thursday, 25 January 2024 11:02:26 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 23:28, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 13:52:52 CST Arnd Bergmann wrote: > >> On Wed, Jan 24, 2024, at 19:02, Elizabeth Figura wrote: > >> > That'd be nicer in general. I think there was some documentation that > >> > advised using timespec64 for new ioctl interfaces but it may have been > >> > outdated or misread. > >> > >> It's probably something I wrote. It depends a bit on > >> whether you have an absolute or relative timeout. If > >> the timeout is relative to the current time as I understand > >> it is here, a 64-bit number seems more logical to me. > >> > >> For absolute times, I would usually use a __kernel_timespec, > >> especially if it's CLOCK_REALTIME. In this case you would > >> also need to specify the time domain. > > > > Currently the interface does pass it as an absolute time, with the > > domain implicitly being MONOTONIC. This particular choice comes from > > process/botching-up-ioctls.rst, which is admittedly focused around GPU > > ioctls, but the rationale of having easily restartable ioctls applies > > here too. > > Ok, I was thinking of Documentation/driver-api/ioctl.rst, which > has similar recommendations. > > > (E.g. Wine does play games with signals, so we do want to be able to > > interrupt arbitrary waits with EINTR. The "usual" fast path for ntsync > > waits won't hit that, but we want to have it work.) > > > > On the other hand, if we can pass the timeout as relative, and write it > > back on exit like ppoll() does [assuming that's not proscribed], that > > would presumably be slightly better for performance. > > I've seen arguments go either way between absolute and relative > times, just pick whatever works best for you here. > > > When writing the patch I just picked the recommended option, and didn't > > bother doing any micro-optimizations afterward. > > > > What's the rationale for using timespec for absolute or written-back > > timeouts, instead of dealing in ns directly? I'm afraid it's not > > obvious to me. > > There is no hard rule either way, I mainly didn't like the > indirect pointer to the timespec that you have here. For > traditional unix-style interfaces, a timespec with CLOCK_REALTIME > times usually makes sense since that is what user space is > already using elsewhere, but you probably don't need to > worry about that. In theory, the single u64 CLOCK_REALTIME > nanoseconds have the problem of no longer working after year > 2262, but with CLOCK_MONOTONIC that is not a concern anyway. > > Between embedding a __u64 nanosecond value and embedding > a __kernel_timespec, I would pick whichever avoids converting > a __u64 back into a timespec, as that is an expensive > operation at least on 32-bit code. Makes sense. I'll probably switch to using a relative and written-back u64 then, thanks!

1 0

Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 25 Jan '24

25 Jan '24

On Thursday, 25 January 2024 10:47:49 CST Arnd Bergmann wrote: > On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote: > >> On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote: > >> > On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > >> [There is also a potential problem where some broken applications > >> create a million (literally) sync objects. Making these into files runs > >> into NOFILE. We did specifically push distributions and systemd to > >> increase those limits because an older solution *did* use eventfds and > >> *did* run into those limits. Since that push was successful I don't > >> know if this is *actually* a concern anymore, but avoiding files is > >> probably not a bad thing either.] > > > > Of course, looking at it from a kernel maintainer's perspective, it > > wouldn't be insane to do this anyway. If we at some point do start to > > care about cross- process isolation in this way, or if another NT > > emulator wants to use this interface and does care about cross-process > > isolation, it'll be necessary. At least it'd make sense to make them > > separate files even if we don't implement granular permission handling > > just yet. > > I can think of a few other possible benefits of going with > per-mutex file descriptors: > > - being able to use poll() for waiting on them individually in > combination with other file descriptor based events (socket, > signalfd, pidfd, ...) I can say for sure this isn't going to be useful for Wine, at least not with the current design. It also doesn't really mesh well with the NT design in the first place. NTSYNC_IOC_WAIT_ANY differs from poll() in two major ways: it consumes state of most object types, and (as coded here) it needs the owner thread ID to be specifically passed for mutexes. Anyway, as Alexandre has informed me I clearly have misunderstood our requirements, so I'm going to try to put together something using files instead.

1 0

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 13:52:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 19:02, Elizabeth Figura wrote: > > On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > >> On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > >> > >> > + if (args->timeout) { > >> > + struct timespec64 to; > >> > + > >> > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > >> > + return -EFAULT; > >> > + if (!timespec64_valid(&to)) > >> > + return -EINVAL; > >> > + > >> > + timeout = timespec64_to_ns(&to); > >> > + } > >> > >> Have you considered just passing the nanosecond value here? > >> Since you do not appear to write it back, that would avoid > >> the complexities of dealing with timespec layout differences > >> and indirection. > > > > That'd be nicer in general. I think there was some documentation that advised > > using timespec64 for new ioctl interfaces but it may have been outdated or > > misread. > > It's probably something I wrote. It depends a bit on > whether you have an absolute or relative timeout. If > the timeout is relative to the current time as I understand > it is here, a 64-bit number seems more logical to me. > > For absolute times, I would usually use a __kernel_timespec, > especially if it's CLOCK_REALTIME. In this case you would > also need to specify the time domain. Currently the interface does pass it as an absolute time, with the domain implicitly being MONOTONIC. This particular choice comes from process/botching-up-ioctls.rst, which is admittedly focused around GPU ioctls, but the rationale of having easily restartable ioctls applies here too. (E.g. Wine does play games with signals, so we do want to be able to interrupt arbitrary waits with EINTR. The "usual" fast path for ntsync waits won't hit that, but we want to have it work.) On the other hand, if we can pass the timeout as relative, and write it back on exit like ppoll() does [assuming that's not proscribed], that would presumably be slightly better for performance. When writing the patch I just picked the recommended option, and didn't bother doing any micro-optimizations afterward. What's the rationale for using timespec for absolute or written-back timeouts, instead of dealing in ns directly? I'm afraid it's not obvious to me. --Zeb

1 0

Re: [RFC PATCH 8/9] ntsync: Introduce NTSYNC_IOC_PUT_MUTEX.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:42:19 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > @@ -738,6 +803,8 @@ static long ntsync_char_ioctl(struct file *file, > > diff --git a/include/uapi/linux/ntsync.h b/include/uapi/linux/ntsync.h > > index 26d1b3d4847f..2e44e7e77776 100644 > > --- a/include/uapi/linux/ntsync.h > > +++ b/include/uapi/linux/ntsync.h > > @@ -46,5 +46,7 @@ struct ntsync_wait_args { > > struct ntsync_wait_args) > > #define NTSYNC_IOC_CREATE_MUTEX _IOWR(NTSYNC_IOC_BASE, 5, \ > > struct ntsync_mutex_args) > > +#define NTSYNC_IOC_PUT_MUTEX _IOWR(NTSYNC_IOC_BASE, 6, \ > > + struct ntsync_mutex_args) > > > > In your implementation, this argument is not written back to > user space, so I think this should be _IOW rather than than _IORW. > > Again, no practical difference here. Hm, but there is a put_user() at the end of the function, or am I missing something?

1 0

Re: [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:56:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > > + if (args->timeout) { > > + struct timespec64 to; > > + > > + if (get_timespec64(&to, u64_to_user_ptr(args->timeout))) > > + return -EFAULT; > > + if (!timespec64_valid(&to)) > > + return -EINVAL; > > + > > + timeout = timespec64_to_ns(&to); > > + } > > Have you considered just passing the nanosecond value here? > Since you do not appear to write it back, that would avoid > the complexities of dealing with timespec layout differences > and indirection. That'd be nicer in general. I think there was some documentation that advised using timespec64 for new ioctl interfaces but it may have been outdated or misread. > > > + ids = kmalloc_array(count, sizeof(*ids), GFP_KERNEL); > > + if (!ids) > > + return -ENOMEM; > > + if (copy_from_user(ids, u64_to_user_ptr(args->objs), > > + array_size(count, sizeof(*ids)))) { > > + kfree(ids); > > + return -EFAULT; > > + } > > This looks like memdup_user() would be slightly simpler. That's useful, thanks.

1 0

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 06:32:13 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 09:43:09PM -0600, Elizabeth Figura wrote: > > > Why do you need a fixed minor number? Can't your userspace handle > > > dynamic numbers? What systems require a static value? > > > > I believe I added this because it's necessary for MODULE_ALIAS (and, more > > broadly, because I was following the example of vaguely comparable devices > > like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS > > (or even remove the ability to compile ntsync as a module entirely). > > Do you really need MODULE_ALIAS()? Having it for char devices to be > auto-loaded is not generally considered a good idea anymore as systems > should have the module loaded before userspace goes and asks for it. > > It also reduces suprises when any random userspace program can cause > kernel modules to be loaded for no real reason. I think there's no reason we can't make loading the system's problem. I'll remove it in v2.

1 0

Re: [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Wednesday, 24 January 2024 01:38:52 CST Arnd Bergmann wrote: > On Wed, Jan 24, 2024, at 01:40, Elizabeth Figura wrote: > > ntsync uses a misc device as the simplest and least intrusive uAPI interface. > > > > Each file description on the device represents an isolated NT instance, intended > > to correspond to a single NT virtual machine. > > > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > I'm looking at the ioctl interface to ensure it's well-formed. > > Your patches look ok from that perspective, but there are a > few minor things I would check for consistency here: > > > + > > +static const struct file_operations ntsync_fops = { > > + .owner = THIS_MODULE, > > + .open = ntsync_char_open, > > + .release = ntsync_char_release, > > + .unlocked_ioctl = ntsync_char_ioctl, > > + .compat_ioctl = ntsync_char_ioctl, > > + .llseek = no_llseek, > > +}; > > The .compat_ioctl pointer should point to compat_ptr_ioctl() > since the actual ioctl commands all take pointers instead > of interpreting the argument as a number. > > On x86 and arm64 this won't make a difference as compat_ptr() > is a nop. Thanks; will fix.

1 0

Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:54:02 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:21PM -0600, Elizabeth Figura wrote: > > Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> > > --- > > Note, we can't take patches without any changelog text, and you don't > want us to :) > > > Documentation/admin-guide/devices.txt | 3 ++- > > Documentation/userspace-api/ioctl/ioctl-number.rst | 2 ++ > > drivers/misc/ntsync.c | 3 ++- > > include/linux/miscdevice.h | 1 + > > 4 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/admin-guide/devices.txt > > b/Documentation/admin-guide/devices.txt index 94c98be1329a..041404397ee5 > > 100644 > > --- a/Documentation/admin-guide/devices.txt > > +++ b/Documentation/admin-guide/devices.txt > > @@ -376,8 +376,9 @@ > > > > 240 = /dev/userio Serio driver testing device > > 241 = /dev/vhost-vsock Host kernel driver for virtio vsock > > 242 = /dev/rfkill Turning off radio transmissions (rfkill) > > > > + 243 = /dev/ntsync NT synchronization primitive device > > > > - 243-254 Reserved for local use > > + 244-254 Reserved for local use > > Why do you need a fixed minor number? Can't your userspace handle > dynamic numbers? What systems require a static value? I believe I added this because it's necessary for MODULE_ALIAS (and, more broadly, because I was following the example of vaguely comparable devices like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS (or even remove the ability to compile ntsync as a module entirely). It's a bit difficult to figure out what's the preferred way to organize things like this (there not being a lot of precedent for this kind of driver) so I'd appreciate any direction. --Zeb

1 0

Re: [RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE.
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 19:14:17 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:22PM -0600, Elizabeth Figura wrote: > > +static int ntsync_create_sem(struct ntsync_device *dev, void __user > > *argp) > > +{ > > + struct ntsync_sem_args __user *user_args = argp; > > + struct ntsync_sem_args args; > > + struct ntsync_obj *sem; > > + __u32 id; > > + int ret; > > + > > + if (copy_from_user(&args, argp, sizeof(args))) > > + return -EFAULT; > > + > > + if (args.count > args.max) > > + return -EINVAL; > > No bounds checking on count or max? > > What's the relationship between count and max? Indeed, no bounds checking. The counter is just the semaphore's internal value and has no meaning other than that. It's basically like an EFD_SEMAPHORE, except that the maximum is configurable rather than always being 2**64-2. > Some sort of real > documentation is needed here, the changelog needs to explain this. Or > somewhere, but as-is, this patch series is pretty unreviewable as I > can't figure out how to review it because I don't know what it wants to > do. There is some comprehensive documentation in the series, but for ease of review I will try to write a basic description of the API in each relevant patch in v2.

1 0

Re: [RFC PATCH 0/9] NT synchronization primitive driver
by Elizabeth Figura 24 Jan '24

24 Jan '24

On Tuesday, 23 January 2024 18:59:35 CST Greg Kroah-Hartman wrote: > On Tue, Jan 23, 2024 at 06:40:19PM -0600, Elizabeth Figura wrote: > > == Patches == > > > > This is the first part of a 32-patch series. The series comprises 17 patches > > which contain the actual implementation, 13 which provide self-tests, 1 to > > update the MAINTAINERS file, and 1 to add API documentation. > > 32 patches? I only see 9 here, why not submit them all? Because Documentation/process/submitting-patches.rst makes a point of asking people not to submit large patch series (and it matches the expectation of other projects I've worked with—that patches would be submitted and reviewed a few at a time). I suppose I've misunderstood that advice, though. I'll resend with the entire series. Sorry for the noise.

1 0

9.0 release notes, please review
by Alexandre Julliard 18 Jan '24

18 Jan '24

Folks, We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help! It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear. -- Alexandre Julliard julliard(a)winehq.org

8 17

Force feedback auto center implementation?
by Tyson Whitehead 13 Jan '24

13 Jan '24

Would like to get disabling force feedback auto-centering working so that trimming will work properly with force feedback devices in flight simulators. Currently the call to disable it is a stub static HRESULT dinput_device_set_property( IDirectInputDevice8W *iface, const GUID *guid, const DIPROPHEADER *header ) { ... case (DWORD_PTR)DIPROP_AUTOCENTER: { const DIPROPDWORD *value = (const DIPROPDWORD *)header; if (!(impl->caps.dwFlags & DIDC_FORCEFEEDBACK)) return DIERR_UNSUPPORTED; if ( header->dwHow != DIPH_DEVICE) return DIERR_INVALIDPARAM; impl->vtbl->set_property( iface, FIXME( "DIPROP_AUTOCENTER stub!\n" ); impl->autocenter = value->dwData; return DI_OK; } ... } After having looked through the wine, SDL, and kernel code and read up on the force feedback HID physical interface device (PID) usage table reports, I am guessing this was left as a stub because it doesn't fit in with the current design of dipnut communicating with the backend via HID reports. The issue being that auto centering, unlike everything else, isn't part of the PID specification, so there isn't a predefined report that can be used for this (see table 0x0f) https://www.usb.org/document-library/hid-usage-tables-14 Although I am no wine or Windows code expert, I am guess this leaves the following options - leave it disabled in the backend and emulate it via a frontend spring effect - abuse an existing HID report to communicate it - add a WINE specific HID report to communicate it - add a WINE specific IOCTL to communicate it For the first option, I mean have the winebus backends disable it via the kernel or an SDL call and then have the dinput layer enable simulate it by adding a default spring effect. This then lets the dinput frontend disable it again by removing or disabling its spring effect. For the second one I mean something like reserve an effect ID for specifying auto centering. Both of these are inspired by the fact that from the kernel code, it seems auto centering for HID devices is an undocumented use of the first effect ID for a spring effect https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… https://github.com/torvalds/linux/blob/610a9b8f/drivers/hid/usbhid/hid-pidf… Would be interesting in knowing what sort of implementation people think would be best and acceptable for inclusion into wine? Thanks! Tyson

2 8

Wine staging 9.0-rc5 release
by Alistair Leslie-Hughes 13 Jan '24

13 Jan '24

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

vkd3d request
by Alistair Leslie-Hughes 09 Jan '24

09 Jan '24

Hi All, Now that vkd3d 1.10 is out, I have a request for developers. Would it be possible to include a file of all games/applications that have fixes when they are committed. It's too hard to track unless you really doing serious work with it. The whole concept of including the latest vk3d3d in staging was to help with testing but if people don't know what to test, they wont. This would also, give a nice section in the ANNOUNCE as to what now works. :) Best Regards Alistair

3 4

[PATCH] po: Update Asturian translation
by Enol P. 08 Jan '24

08 Jan '24

2 2

Wine staging 9.0-rc4 release
by Alistair Leslie-Hughes 06 Jan '24

06 Jan '24

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

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 4, 2024 6:47:04 PM PST, Andrew Cooper <andrew.cooper3(a)citrix.com> wrote: >On 05/01/2024 1:02 am, H. Peter Anvin wrote: >> Note that there is no fundamental reason you cannot run the Unix user space code inside the VM container, too; you only need to vmexit on an actual system call. > >I know this is going on a tangent, but getting a VMExit on the SYSCALL >instruction is surprisingly difficult. > >The "easy" way is to hide EFER.SCE behind the guests back, intercept #UD >and emulate both the SYSCALL and SYSRET instructions. It's slow, but it >works. > >However, FRED completely prohibits tricks like this, because what you >cannot reasonably do is clear CR4.FRED behind the back of a guest >kernel. You'd have to intercept and emulate all event sources in order >to catch SYSCALL. > >I raised this as a concern during early review, but Intel has no >official feature to take a VMExit on privilege change, and FRED >(rightly) wasn't an appropriate vehicle to add such a feature, so it was >deemed not an issue that the FRED design would break the unofficial ways >that people were using to intercept/monitor/etc system calls. > >~Andrew > >P.S. Yes, there are more adventurous tricks like injecting a thunk into >the guest kernel and editing MSR_LSTAR behind the guest's back. In >principle a similar trick works with FRED, but in order to do this to >Windows, you also need to hook checkpatch to blind it to the thunk, and >this is horribly invasive. *In this case* it shouldn't be a problem, since the "guest operating system" would be virtually nonexistent and entirely puppeted by Wine.

1 0

Re: x86 SGDT emulation for Wine
by H. Peter Anvin 05 Jan '24

05 Jan '24

On January 3, 2024 7:19:02 AM PST, Sean Christopherson <seanjc(a)google.com> wrote: >On Tue, Jan 02, 2024, Elizabeth Figura wrote: >> On Wednesday, December 27, 2023 5:58:19 PM CST H. Peter Anvin wrote: >> > On December 27, 2023 2:20:37 PM PST, Elizabeth Figura <zfigura(a)codeweavers.com> wrote: >> > >Hello all, >> > > >> > >There is a Windows 98 program, a game called Nuclear Strike, which wants to >> > >do some amount of direct VGA access. Part of this is port I/O, which >> > >naturally throws SIGILL that we can trivially catch and emulate in Wine. >> > >The other part is direct access to the video memory at 0xa0000, which in >> > >general isn't a problem to catch and virtualize as well. >> > > >> > >However, this program is a bit creative about how it accesses that memory; >> > >instead of just writing to 0xa0000 directly, it looks up a segment >> > >descriptor whose base is at 0xa0000 and then uses the %es override to >> > >write bytes. In pseudo-C, what it does is: > >... > >> > A prctl() to set the UMIP-emulated return values or disable it (giving >> > SIGILL) would be easy enough. >> > >> > For the non-UMIP case, and probably for a lot of other corner cases like >> > relying on certain magic selector values and what not, the best option >> > really would be to wrap the code in a lightweight KVM container. I do *not* >> > mean running the Qemu user space part of KVM; instead have Wine interface >> > with /dev/kvm directly. >> > >> > Non-KVM-capable hardware is basically historic at this point. >> >> Sorry for the late response—I've been trying to do research on what would be >> necessary to use KVM (plus I made the poor choice of sending this during the >> holiday season...) >> >> I'm concerned that KVM is going to be difficult or even intractable. Here are >> some of the problems that I (perhaps incorrectly) understand: >> >> * As I am led to understand, there can only be one hypervisor on the machine >> at a time, > >No. Only one instance of KVM-the-module is allowed, but there is no arbitrary >limit on the number of VMs that userspace can create. The only meaningful >limitation is memory, and while struct kvm isn't tiny, it's not _that_ big. > >> and KVM has a hard limit on the number of vCPUs. >> >> The obvious way to use KVM for Wine is to make each (guest) thread a vCPU. >> That will, at the very least, run into the thread limit. In order to avoid >> that we'd need to ship a whole scheduler, which is concerning. That's a huge >> component to ship and a huge burden to keep updated. It also means we need to >> hoist *all* of the ipc and sync code into the guest, which will take an >> enormous amount of work. >> >> Moreover, because there can only be one hypervisor, and Wine is a multi- >> process beast, that means that we suddenly need to throw every process into >> the same VM. > >As above, this is wildly inaccurate. The only KVM restriction with respect to >processes is that a VM is bound to the process (address space) that created the >VM. There are no restrictions on the number of VMs that can be created, e.g. a >single process can create multiple VMs. > >> That has unfortunate implications regarding isolation (it's been a dream for >> years that we'd be able to share a single wine "VM" between multiple users), >> it complicates memory management (though perhaps not terribly?). And it means >> you can only have one Wine VM at a time, and can't use Wine at the same time >> as a "real" VM, neither of which are restrictions that currently exist. >> >> And it's not even like we can refactor—we'd have to rewrite tons of code to >> work inside a VM, but also keep the old code around for the cases where we >> don't have a VM and want to delegate scheduling to the host OS. >> >> * Besides scheduling, we need to exit the VM every time we would normally call >> into Unix code, which in practice is every time that the application does an >> NT syscall, or uses a library which we delegate to the host (including e.g. >> GPU, multimedia, audio...) > >Maybe I misinterpreted Peter's suggestion, but at least in my mind I wasn't thinking >that the entire Wine process would run in a VM, but rather Wine would run just >the "problematic" code in a VM. > Yes, the idea would be that you would run the "problematic" code inside a VM *mapped 1:1 with the external address space*, i.e. use KVM simply as a special execution mode to give you more control of the fine grained machine state like the GDT. The code that you don't want executed in the VM context simply leave unmapped in the VM page tables and set up #PF to always exit the VM context.

2 2

x86 SGDT emulation for Wine
by Elizabeth Figura 03 Jan '24

03 Jan '24

Hello all, There is a Windows 98 program, a game called Nuclear Strike, which wants to do some amount of direct VGA access. Part of this is port I/O, which naturally throws SIGILL that we can trivially catch and emulate in Wine. The other part is direct access to the video memory at 0xa0000, which in general isn't a problem to catch and virtualize as well. However, this program is a bit creative about how it accesses that memory; instead of just writing to 0xa0000 directly, it looks up a segment descriptor whose base is at 0xa0000 and then uses the %es override to write bytes. In pseudo-C, what it does is: int get_vga_selector() { sgdt(&gdt_size, &gdt_ptr); sldt(&ldt_segment); ++gdt_size; descriptor = gdt_ptr; while (descriptor->base != 0xa0000) { ++descriptor; gdt_size -= sizeof(*descriptor); if (!gdt_size) break; } if (gdt_size) return (descriptor - gdt_ptr) << 3; descriptor = gdt_ptr[ldt_segment >> 3]->base; ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1; while (descriptor->base != 0xa0000) { ++descriptor; ldt_size -= sizeof(*descriptor); if (!ldt_size) break; } if (ldt_size) return (descriptor - ldt_ptr) << 3; return 0; } Currently we emulate IDT access. On a read fault, we execute sidt ourselves, check if the read address falls within the IDT, and return some dummy data from the exception handler if it does [1]. We can easily enough implement GDT access as well this way, and there is even an out-of-tree patch written some years ago that does this, and helps the game run. However, there are two problems that I have observed or anticipated: (1) On systems with UMIP, the kernel emulates sgdt instructions and returns a consistent address which we can guarantee is invalid. However, it also returns a size of zero. The program doesn't expect this (cf. the way the loop is written above) and I believe will effectively loop forever in that case, or until it finds the VGA selector or hits invalid memory. I see two obvious ways to fix this: either adjust the size of the fake kernel GDT, or provide a switch to stop emulating and let Wine handle it. The latter may very well a more sustainable option in the long term (although I'll admit I can't immediately come up with a reason why, other than "we might need to raise the size yet again".) Does anyone have opinions on this particular topic? I can look into writing a patch but I'm not sure what the best approach is. (2) On 64-bit systems without UMIP, sgdt returns a truncated address when in 32-bit mode. This truncated address in practice might point anywhere in the address space, including to valid memory. In order to fix this, we would need the kernel to guarantee that the GDT base points to an address whose bottom 32 bits we can guarantee are inaccessible. This is relatively easy to achieve ourselves by simply mapping those pages as noaccess, but it also means that those pages can't overlap something we need; we already go to pains to make sure that certain parts of the address space are free. Broadly anything above the 2G boundary *should* be okay though. Is this feasible? We could also just decide we don't care about systems without UMIP, but that seems a bit unfortunate; it's not that old of a feature. But I also have no idea how hard it would be to make this kind of a guarantee on the kernel side. This is also, theoretically, a problem for the IDT, except that on the machines I've tested, the IDT is always at 0xfffffe0000000000. That's not great either (it's certainly caused some weirdness and confusion when debugging, when we unexpectedly catch an unrelated null pointer access) but it seems to work in practice. --Zeb [1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/ instr.c#l702

3 3

Handling stack overflow
by Dāvis Mosāns 01 Jan '24

01 Jan '24

Hi, I've been looking to get League of Legends work in Wine. The issue is that their Anti-Cheat hooks bunch of functions in ntdll.dll directly by prepending `jmp their_code` before the real function and it seems it messes something up. Anyway, topic of this email is about handling of stack overflow. When their exception handler gets messed up it is invoked recursively until stack overflow. And because it happened while it was in critical section it causes other threads to deadlock. My question is how such case should be handled? When thread is killed should lock be released so other threads can still proceed? Or maybe just whole process should be killed if any thread has stack overflow? To me it looks like in Windows when exception handler goes too deep then Just in Time debugger is invoked or if that's not enabled then process is killed with EXCEPTION_ACCESS_VIOLATION (maybe because it tried to access beyond end of stack?) Log looks like: [...] 0120:trace:seh:call_handler calling handler 00006FFFFFC97030 (rec=00007F3214C54360, frame=00007F3214D4E710 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:trace:seh:call_handler handler at 00006FFFFFC97030 returned 2 0120:trace:seh:call_stack_handlers nested exception 0120:trace:seh:call_handler calling handler 00000001413B347C (rec=00007F3214C54360, frame=00007F3214D4F570 context=00007F3214C538D0, dispatch=00007F3214C537A0) 0120:err:virtual:virtual_setup_exception stack overflow 2576 bytes addr 0x6ffff9e66327 stack 0x7f3214c505f0 (0x7f3214c50000-0x7f3214c51000-0x7f3214d50000) 0124:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0124, blocked by 0120, retrying (60 sec) 011c:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 011c, blocked by 0120, retrying (60 sec) [...] // stuck like this And several threads stuck like this Thread 8 (Thread 472 "011c"): #0 0x00006fffffc966d4 in NtWaitForAlertByThreadId () from /opt/wine-lol-staging/lib/wine/x86_64-windows/ntdll.dll #1 0x00006fffffc9db68 in RtlWaitOnAddress (addr=addr@entry=0x6fffffcae4d8 <loader_section+24>, cmp=cmp@entry=0x6fffffcbda90 <zero>, size=size@entry=4, timeout=timeout@entry=0x7fc37b38f700) at ../wine/dlls/ntdll/sync.c:912 #2 0x00006fffffc9dd06 in wait_semaphore (timeout=<optimized out>, crit=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:196 #3 RtlpWaitForCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:314 #4 0x00006fffffc9df71 in RtlEnterCriticalSection (crit=crit@entry=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:383 #5 0x00006fffffc7667b in loader_init (context=context@entry=0x7fc37b38fb00, entry=entry@entry=0x7fc37b38fb80) at ../wine/dlls/ntdll/loader.c:4405 #6 0x00006fffffc9a444 in LdrInitializeThunk (context=0x7fc37b38fb00, unk2=<optimized out>, unk3=<optimized out>, unk4=<optimized out>) at ../wine/dlls/ntdll/signal_x86_64.c:1716 #7 0x00006ffff88f7954 in ?? () from /mnt/Riot Games/League of Legends/wine/dosdevices/s:/Riot Games/League of Legends/Game/stub.dll Best regards, Dāvis

3 4

Wine staging 9.0-rc3 release
by Alistair Leslie-Hughes 23 Dec '23

23 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc3 (498 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * None 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 staging 9.0-rc2 release
by Alistair Leslie-Hughes 16 Dec '23

16 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc2 (498 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * [45455] setupapi: Add stub for DriverStoreFindDriverPackageW. * [55282] where: Implement search with default options. Updated: * vkd3d-latest to 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

Code freeze for Wine 9.0
by Alexandre Julliard 10 Dec '23

10 Dec '23

Folks, With the end of the year approaching, it's time to start preparing for the 9.0 stable release. We'll follow the same schedule as every year, with code freeze in early December, and a final release sometime in January. This year, the code freeze period will start on December 8th. So if you have things that you'd like to see included in 9.0, make sure to submit them soon, so that there's enough time for review before code freeze starts. -- Alexandre Julliard julliard(a)winehq.org

1 1

Wine staging 9.0-rc1 release
by Alistair Leslie-Hughes 09 Dec '23

09 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc1 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * bcrypt: Allow multiple backends to coexist. * bcrypt: Implement BCryptSecretAgreement with libgcrypt. * bcrypt: Implement BCRYPT_KDF_HASH. Added: * None Updated: * vkd3d-latest to latest. * ntdll-DOS_Attributes * mfplat-streaming-support * 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

Wine 8.0.2 fails to create a window
by volker.schlegel＠tutanota.com 01 Dec '23

01 Dec '23

Hello everyone,I've recently switched from Manjaro to Mint, and just installed WINE again.Latest stable release, 8.0.2, from the wineHQ repos.Any application trying to create a window seems to crash.Example crash dump (new prefix): https://pastebin.com/T6WG9EhQ Since it seems to be a graphics issue, here is the output of inxi -G: https://pastebin.com/SvURv3fYWhile searching for a fix I stumbled across this bug, might be related? https://bugs.winehq.org/show_bug.cgi?id=51210"Deactivate your GPU" isn't really a solution though in my opinion.I'd try to actually fix it myself (I've built wine myself before, and I have written quite a bit of C code), but I've never used Vulkan or OpenGL, so any help is appreciated!

1 0

Wine staging 8.21 release
by Alistair Leslie-Hughes 25 Nov '23

25 Nov '23

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

GCC 4.3 support and language features
by Fabian Maurer 22 Nov '23

22 Nov '23

Hello wine-devel, I wanted to follow up on the discussion on https://gitlab.winehq.org/wine/ wine/-/merge_requests/3059 For those not in the loop: The question came up what GCC version is the oldest supported one, and which language features can't be used in Wine. Is there already a wiki entry on this? Associated bug report: https://bugs.winehq.org/show_bug.cgi?id=54601 (Compilation fails with gcc 4.3.4 (error: unknown field ‘Type’ specified in initializer) I have a bunch of gcc 4.3 patches, and if it's supported, I think it would be useful getting those in before the next stable. Although ongoing gcc 4.3 support is probably a bit of work, since most people don't test against gcc 4.3 compatibility so there's some "regressions" from time to time. An option would be to just patch it when someone complains, which would be the most reasonable to me. Or just cap it at 4.8 which currently works. In the end, some compiler will be too old, so where is the line? In a similar vein, what about https://bugs.winehq.org/show_bug.cgi?id=20474 (Wine can't be built with GCC in C99 mode) Is this a supported setup? IMHO itwould be too much effort work to get this working, but I don't make the decisions. Regards, Fabian Maurer

8 9

Wine staging 8.20 release
by Alistair Leslie-Hughes 11 Nov '23

11 Nov '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.20 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winemenubuilder: Create .desktop files for programs that open URIs. * winecfg: Mention protocol associations. Added: * None Updated: * vkd3d-latest to 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

Upcoming vkd3d 1.10 release
by Henri Verbeet 08 Nov '23

08 Nov '23

Hi all, The planned release for vkd3d 1.10 is about 4 weeks away. As usual, that means the development branch will become increasingly frozen as we're nearing release. 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 all the vkd3d tests pass on your hardware, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for regressions, and file bug reports if you find any. If you're the maintainer of a Wine module that (indirectly) depends on vkd3d, like e.g. d2d1, d3dx9, d3dcompiler, or any of the core Direct3D modules, that includes making sure the unit tests still pass with the new version. The planned release date for the release following vkd3d 1.10 is currently sometime in March. Regards, Henri

1 0

A case for policy changes to get to zero test failures
by Francois Gouget 31 Oct '23

31 Oct '23

TL;DR; Making lasting progress on fixing the Wine tests requires TBD policy changes to incentivize working on them. While there has definitely been progrees on the Wine tests front lately (and I'm grateful for all the Wine developpers who made it possible), I think there are structural problems that will prevent us from ever getting close to zero failures. Why would a developer work on fixing Wine test bugs? The naive thinking was that they would do so out of pride in the Wine code. Or that they would jump at the chance of fixing issues where all the source is available. But if those where the only factors we would not still have 200 hundred failing test units afer two decades. Another part of the naive thinking was that if developers did not work on the tests it was just because the tools needed to be improved or the test environments were too unreliable. So for a long time all efforts have centered on that. But I think the CI is good enough now to not be the main obstacle [1]. The inconvenient truth is there are forces that discourage working on the Wine tests: * Most developers come to Wine to fix a game or application they want to run, or to add some sexy new functionality. They will prefer to work on these over fixing tests. * Professional developers will be asked to work on issues for paying customers, not fixing tests. * There is a big exception to the source availability: Windows. So figuring out the logic behind the Windows behavior can still be maddeningly frustrating. * Replicating failures can sometimes be frustratingly hard. Even if you happen to have access to the CI environment! [2] * And usually one does not have access to the CI environment. That's the the case for the Windows environments for licensing reasons. On the Linux side the GitLab CI should mean progress but replicating it needs to be made much simpler before that's effective. In the meantime that means no debugger, no watching what happens on screen while the test runs, little poking into the test environment entrails (short of writing a dedicated program to do the poking), etc. In short it's remote debugging. * The CI itself can be an obstacle when it systematically reports failures unrelated to the current MR (a warning light that is on all the time is no warning light at all). [3] * The GitLab CI has been allowed to have a 99% failure rate for days on end (see failures-mr.txt in my 2023-10-20 email). That tells the developers that fixing tests is unimportant. There is also nothing to counterbalance that and push developers to work on Wine tests. A developer will not see their patches reverted if they don't fix the failures they introduce. In fact I'm not sure introducing new failures in Wine has any negative consequences. And that's assuming the commit causing the failures is ever identified. Developers fixing tests don't get rewards either. So the conclusion I have come to is that making further and lasting progress will require policy changes to incentivize work on the tests. This touches on the domain of social sciences so there will be no obvious 'right fix'. It's also something I cannot do myself since I don't have any authority to make policy changes. Anyway, here are a few ideas, including some extreme ones, and hopefully we can decide on something that works for Wine: * Revert commits that introduced new failures. - Do it the very next day if the failure is systematic? - What if the failure is random and only happens once a day? Or once a week? - What if the failure does not impact the CI? For instance if the CI has no macOS test configuration and the failure only happens on macOS. - Should only the test part of the MR be reverted? (if that's the cause of the failure) - Who makes the decision to revert? Alexandre? A dedicated person who will catch a lot of flak? * Block an author's new MRs if they did not fix failures introduced by one of their previous commit. - This has the potential to slow down Wine development. - Or the author could request their previous commit to be reverted to get unblocked. * If the CI shows failures, block the MR. - That can still cause the Wine development to halt when the CI has a 100% failure rate (as has been the case for the GitLab CI recently). - So it's only doable if the false positive rate is pretty low. But then it's likely to just result in the developer trying their luck with the next CI run. * If the CI shows failures, require that the author explain why they are not caused by their MR before it can be considered for merging. - The TestBot's new failure lookup tool would be a good way to prove the failure pre-existed the MR. https://testbot.winehq.org/FailuresList.pl - This is a softer version of the previous option and should not block Wine development. It may also push developers to fix the failures out of frustration at having to explain them away again and again since they cannot ignore them. - Reviewers would also be responsible for verifying that the explanations are accurate and for objecting to the merge if not. - Determining if the CI results contain new failures would not longer fall on Alexandre alone. * Have someone dedicated to tracking the source of new failures, reporting them to the authors, following up on the failures, asking for progress on a fix, etc. This would be a developer role bordering on community manager. * Do away with direct commits? (see the 'New failures analysis' email) * Use the Wine party fund to pay developers to fix test bugs. * Send swag to developers who fixed 10 or more test failures. Or set rewards for fixing specific test units like user32:msg, d3d11:d3d11, etc. * Point test.winehq.org/ to the patterns page instead of the index page: the patterns page better reflects the tests progress [4] and thus is less discouraging than the main index page. https://gitlab.winehq.org/winehq/tools/-/merge_requests/71 Suggestions welcome. Hopefully we can figure something out that will get us on the path to zero failures. [1] There are still a few infrastructure improvements that could help: - Fix the TestBot integration with GitLab so its reports don't go into a black hole. At least, while I cannot fix the bridge, I think I can replace it with a better solution. - Allowing to run the tests with WINEDEBUG. - Taking screenshots while the test runs. - Make it easier for developers to replicate the GitLab CI debian environment, build their Wine in it, run the tests, interact with the virtual X server, etc. [2] I will very humbly claim that the wt-test-bisect tool represents a huge step forward on that front when the faiure only happens in full test suite runs. https://gitlab.winehq.org/fgouget/wt-daily/-/blob/bisectors/wt-test-bisect?… [3] Though the GitLab CI false positive rate needs to get better. However my understanding is that the strategy there is to not have the CI try to distinguish false positives from the real issues. Rather my understanding is that it's a two prong approach: 1. Summarily hide unreliable tests by marking them as flaky. 2. Let all the systematic failures annoy the developers so they fix them out of frustration. However this is essentially the naive strategy that was used for years with the TestBot and that only resulted in the developers dismissing and ignoring the CI results. [4] For instance the patterns page makes it clear that there has been progress for Windows 10 1809 whereas that is invisible on the index page. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

11 14

Wine staging 8.19 release
by Alistair Leslie-Hughes 30 Oct '23

30 Oct '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.18 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Don't use Wine frames during exception processing on x64. Added: * None Updated: * vkd3d-latest to latest. * fltmgr.sys-FltBuildDefaultSecurityDescriptor 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

Win16 tests
by Zeb Figura 23 Oct '23

23 Oct '23

Hello! The idea of having tests for our win16 functionality has been raised every so often, but never actualized. I would like to change that now. I think win16 has been broken several times recently, especially with large scale refactoring like the PE conversion and wow64 work, and I'd like to put tests in place to stop that happening. I'd also like to have a way to easily *write* tests for nontrivial functionality, which is currently something of an ordeal. By my understanding, the big blocker for having win16 tests in tree is the lack of a usable win16 compiler. Existing win16 compilers are mostly hard to find; OpenWatcom is sometimes mentioned, but that only has win32 builds (as far as I'm aware), which makes it hard if not impossible to integrate into Wine. I've spent a while over the past year or so trying a certain idea, where we write a small win16 entry point, and use generic thunks to call into win32 code, then use generic thunks the other way (WOWCallback16Ex) to call back into win16 functions. I managed to get a working PoC that actually worked on Windows XP; however, it did not work on Windows 98 [1]. In light of this, I tried a different approach. I considered but ultimately rejected the idea of introducing Win16 support into GCC [2], and instead tried an experiment to see if I could write an extremely minimalist, non-optimizing Win16 compiler myself from "scratch" [3]. It turns out that I could, in the span of what didn't end up being more than a couple months' worth of weekends. The compiler is called Rosé, and it lives here: https://gitlab.winehq.org/zfigura/rose It is not fully featured; it's still missing a few notable pieces (in particular: unions, multiple code segments) but it is reasonably complete, and I was able to use it to compile a modified version of winetest.exe, and produce working executables for Windows 98. It is therefore my proposal to use this compiler in Wine, and write in-tree Win16 tests. Here are some of the important considerations involved in this proposal: * The compiler is small and could potentially be easily just imported into Wine. I don't have any feelings about continuing to maintain it outside of Wine—i.e. it could easily just be imported and any further development done in Wine (much like e.g. widl). "Small" here means about 15k LoC across a few files, including the builtin CRT and headers. * NE executables, unlike both their predecessor (MZ) and successor (PE), cannot output to a controlling console, and in general have no concept of a stdin/stdout/stderr. This does not fit well with wine tests, which are built to run with a console. There is also not much in the way of IPC available to a win16 process. They can, on the other hand, open a file and output to it. For Marvin (or gitlab CI), this is not a huge concern, but for development it's a bit more important. In light of this we may want to write a small win32 wrapper for win16 tests, possibly one that self-extracts the win16 test. * In order to properly test Win16 we need a contemporaneous test VM, I think ideally 98. A modern 32-bit Windows machine (of which I think we still have some) will *run* 16-bit code, and may be usable to test *some* functionality, but I do not think the results can be trusted. This is probably a more general problem—I think our current ability to test native ddraw is similarly worthless. (ddraw is also harder, though, because we need contemporaneous *hardware* as well.) There may be other areas where our current CI is not very valuable and we really do want to test old Windows versions, although I can't think of any off the top of my head. Thoughts and opinions? If not (as per usual) I will try to put together a patch series soon. --Zeb [1] In a sense this is actually very similar to how we currently implement 16-bit DLLs in Wine, except that we use a private thunk instead of the exported generic thunks [CallProcEx32W], so I spent some time refactoring various parts of krnl386 and winebuild to match my proposed design. This was going well up until I tried running the executable on Windows 98. It turns out that, unlike with NT, one cannot call any win32 functions from the 32-bit DLL without crashing. This may not be prohibitive per se [if we avoid ever making any win32 calls] but it did impose some pretty severe limitations. It's also worth mentioning that the process of refactoring was *very* convoluted, things had to be moved around very carefully in order to work. [2] The idea of introducing compiler support into GCC has obvious advantages: not just the reuse of frontend and optimization code, but the dialect is something that will already be perfectly familiar to a Wine developer. However, it also has disadvantages: it would take a lot of time to become familiar with gcc, and I expect that segmented address spaces will be very hard to fit into the GCC code and probably not accepted upstream. [3] In fact it is not built from scratch, but rather built from the HLSL compiler. This is largely because I am very familiar with the HLSL compiler, and familiarity is very important. I also found it far less daunting to start with the HLSL compiler, rip out everything specific to HLSL, rather than to start from scratch even using the HLSL compiler as a model.

5 8

New failures analysis
by Francois Gouget 20 Oct '23

20 Oct '23

New failures: Where do they come from? How do they get in? All you've ever wanted to know (or not). So I collected data about the new failure modes (see failure-new.txt), mostly from the start of July (older data is incomplete). By new failure mode I mean any failure group that I can say started happening on a specific day in that range. This calls for some caveats: * A failure mode is a group of failures that happens together in a given test unit and thus likely all have the same origin. Normally each failure mode is described in a bug. In the rest of this document I'll just say 'failure' in place of 'failure mode'. * This includes failures that happen on non GitLab / TestBot machines. * I don't know the origin of all of them so there are certainly some that are not caused by a change in Wine. So not all are Wine regressions. * But until their cause is known they still need to be investigated so I'm still counting them when it seems appropriate. However I did not include those where it was known from the start that they were caused by external factors. First the date range I used for each month: Jul 2023-06-30 - 2023-07-28 28 days Aug 2023-07-28 - 2023-08-28 31 days (08-28 is about when the TestBot -> GitLab CI bridge broke) Sep 2023-09-01 - 2023-10-06 39 days So how many new failures are there? Jul 36 new failures -> 1.3 / day Aug 7 new failures -> 0.2 / day (vacation effect!) Sep 53 new failures -> 1.4 / day Note that a single MR may cause multiple tests to fail but each new failing test would be counted separately here on the premise that they each need to be investigated and reported. Where do they come from? Jul Aug Sep Unknown 8 4 18 Commit 4 1 6 MR 7 2 17 Total 19 7 41 Total / day 0.7 0.2 1.1 * These counts are deduplicated except for the new failures of unknown origin obviously. * The commits correspond to direct Wine commits so they don't go through the GitLab CI or the TestBot. * About half of the new failures have no known origin. This can be because they happen on machines I don't have access to and thus where I cannot bisect. It can also be because the failure fails to reproduce which is annoyingly common. * To keep up 5 to 8 failure would have to be fixed How do they get in? Jul Aug Sep Untested 2 1 7 Bad 2 0 0 Module 1 0 1 Extra configs 0 0 2 Flaky 2 0 2 WineTest only 1 0 0 Bridge 0 0 7 Misc 1 1 0 Total 9 2 19 Here's a description of the way the failures got in. Those correspond to deduplicated failure counts since we're not interested in the number of tests impacted but in how the commits got in: o 33% Untested These correspond to direct Wine commits. As such they bypass the GitLab CI and TestBot so there was no way to detect them beforehand. There has been a lot of changes in the lowe level code lately so I think this is usually lower. o 23% Bridge These failures were detected by the TestBot but not forwarded to the MR page because the mailing list to GitLab bridge broke on or about 2023-08-28. o 13% Flaky These failures are random and just did not happen when the MR got tested by the GitLab CI and TestBot. One way to minimize the chances of this happening is to run the tests multiple times. But the TestBot already runs the tests on up to 24 Windows configurations and 10 Linux ones which means random failures that are not configuration-specific have a very good chance of being caught. It's the other ones that get through, like those that only impact a specific locale or a specific Windows version. o 7% Module When a patch modifies a module but not the tests it contains the TestBot skips some test configurations which can lead to some failures being undetected. o 7% Extra This corresponds to failures specific to test configurations that the TestBot only uses for the nightly WineTest runs. In the above counts I omitted the following: o 18 Unknown This corresponds to cases where what is causing the failure has not been identified, and thus how they got in undetected is not known. Note that there is one exception: if the failure does not impact the GitLab and TestBot machines then the reason is automatically "Non TestBot". o 17 Non TestBot These new failures impact neither the GitLab nor the TestBot machines. This corresponds to macOS-specific failures for instance. Detecting them beforehand is therefore impossible... except by expanding the set of test machines. Are they fixed yet? Jul Aug Sep Fixed 15 (47%) 2 (33%) 21 (40%) Not fixed 17 (53%) 4 (67%) 31 (60%) Not there yet. * Take with a big grain of salt : the bugs are not always closed when a failure is fixed. I may also have forgotten to mark some entries as fixed in failures-new.txt but I think that part is mostly okay now. * Older failures don't seem more likely to be fixed. But then failures are not necessarily reported in the order they appear. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

GitLab CI's Most Wanted list
by Francois Gouget 20 Oct '23

20 Oct '23

Processing the failures-mr.txt file for the past month (see previous email) points to the following test units as plagging the most merge requests: 100 msxml3:domdoc (55720) 87 amstream:amstream (55725) 81 quartz:filtergraph (55758) 44 build:mac 26 d2d1:d2d1 (55765) 19 winmm:mci (55605) 15 user32:msg (55786, mostly) 13 user32:win (55766) 12 psapi:psapi_main (55744, fixed on day 3) 11 wscript.exe:run (55746, fixed on day 3) 11 tasklist.exe:tasklist (55745, fixed on day 3) Good hunting! -- Francois Gouget <fgouget(a)codeweavers.com>

4 4

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