- Wine-devel - list.winehq.org

Wine staging 8.12 release
by Alistair Leslie-Hughes 09 Jul '23

09 Jul '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.12 (504 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * wined3d: rename shader_extract_from_dxbc to wined3d_shader_extract_from_dxbc Added: * [55205] dinput: Improve keyboard devices scancode support. Updated: * vkd3d-latest to lateset. 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 guidelines
by Alex Henrie 08 Jul '23

08 Jul '23

Hello everyone, I just finished rewriting the Wine coding guidelines based on feedback at <https://gitlab.winehq.org/wine/wine/-/merge_requests/3059>. Please look it over and let me know if there's anything that I missed or misstated: https://wiki.winehq.org/Submitting_Patches#Code_guidelines https://wiki.winehq.org/Wine_Developer's_Guide/Coding_Practice Thanks to Zeb and Alexandre in particular for the clarifications about style and compatibility. -Alex

1 0

GitLab notification emails stopped
by Alex Henrie 05 Jul '23

05 Jul '23

Hi, There was activity today on multiple merge requests that I was subscribed to, but I didn't get any notification emails. Is it just me, or have they stopped for everyone? -Alex

3 3

GCC 12 use-after-free false positives
by Fabian Maurer 26 Jun '23

26 Jun '23

When using GCC 12, there's two bogus warnings in Wine's code: ../wine-git/dlls/winex11.drv/clipboard.c: In function ‘X11DRV_CLIPBOARD_GetProperty’: ../wine-git/dlls/winex11.drv/clipboard.c:1871:13: error: pointer ‘val’ may be used after ‘realloc’ [-Werror=use-after-free] 1871 | free( val ); | ^~~~~~~~~~~ ../wine-git/dlls/winex11.drv/clipboard.c:1866:17: note: call to ‘realloc’ here 1866 | *data = realloc( val, pos * sizeof(int) + count + 1 ); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no real issue here, it's just a false positive. This could be worked around using a temporary void* variable to hold the result from realloc. Is this worth it or would you wait for gcc to fix their warning? Regards, Fabian Maurer

2 1

Wine staging 8.11 release
by Alistair Leslie-Hughes 25 Jun '23

25 Jun '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.11 (502 patches are applied to wine vanilla) vk3d3 has been updated to the 1.8 release. Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * [22904] Register URL protocol handlers under linux. * PR 3124 - Improve performance of Registry writes. Updated: * vkd3d-latest (1.8) * gdiplus-Performance-Improvements 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

Reduced role for me, Wine project organizational structure
by Jeremy White 21 Jun '23

21 Jun '23

Hey folks, As you may have seen, I recently stepped back from my role at CodeWeavers. [1] I'm still around, just in a greatly reduced fashion. I am still deeply invested in the success of Wine and plan to remain on the committee. Also, this is a good excuse to remind folks of the basic organizational structure of the Wine Project, which is described here: https://wiki.winehq.org/Project_Organization Effectively, this is a heads up that I will be a little less engaged. That may leave a bit of a void; as always, constructive help is always welcome. Cheers, Jeremy [1] https://www.codeweavers.com/blog/jwhite/2023/5/19/a-new-chapter-for-codewea…

1 0

Lots of failures in the new WoW 32-bit tests
by Francois Gouget 18 Jun '23

18 Jun '23

So as far as I understand all that's needed to build Wine with the new Windows-on-Windows support is to do: ./configure --enable-archs=i386,x86_64 make But then when I run WineTest I get 60+ failures instead of the usual ~16 on my machine. https://test.winehq.org/queue/err5z_5H/report https://test.winehq.org/queue/errloGNj/report That does not entirely surprise me since this mode has never been tested (neither GitLab nor the TestBot support it). But did I miss something? For instance one failure I get is with devenum:devenum: devenum:devenum start dlls/devenum/tests/devenum.c devenum.c:691: Test failed: Got hr 0x80004005. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00405a75). The reason for the crash is that wg_transform_create() in main.c returns NULL: if (WINE_UNIX_CALL(unix_wg_transform_create, &params)) return NULL; // <---- we return NULL here without actually calling the implementation in wg_transform.c as far as I can see. Here's the list of test units that fail in one of the runs. Lots of Direct3D (but not all) and multimedia (GStreamer?) tests. Maybe there are some quick gains to be had? (then there's msvcrt:file which gets -2 as a file descriptor) advapi32:security amstream:amstream comctl32:subclass d2d1:d2d1 d3d10core:d3d10core d3d11:d3d11 d3d8:visual d3d9:visual d3dcompiler_43:hlsl_d3d11 d3dcompiler_43:hlsl_d3d9 d3dcompiler_46:hlsl_d3d11 d3dcompiler_46:hlsl_d3d9 d3dcompiler_47:hlsl_d3d11 d3dcompiler_47:hlsl_d3d9 d3dx10_34:d3dx10 d3dx10_35:d3dx10 d3dx10_36:d3dx10 d3dx10_37:d3dx10 d3dx10_38:d3dx10 d3dx10_39:d3dx10 d3dx10_40:d3dx10 d3dx10_41:d3dx10 d3dx10_42:d3dx10 d3dx10_43:d3dx10 d3dx9_36:core d3dx9_36:math d3dx9_36:texture d3dx9_36:volume dbghelp:dbghelp ddraw:d3d ddraw:visual devenum:devenum explorer.exe:explorer gdi32:font iphlpapi:iphlpapi kernel32:debugger kernel32:thread kernel32:virtual mfmediaengine:mfmediaengine mfplay:mfplay mf:mf mf:transform msvcrt:file msvfw32:mciwnd ntdll:info ntdll:virtual ntdll:wow64 opengl32:opengl qasf:asfreader qedit:mediadet quartz:filtergraph quartz:vmr7 quartz:vmr9 riched20:editor user32:class user32:clipboard user32:msg user32:win win32u:win32u wininet:internet winmm:mci wmp:media wmvcore:wmvcore -- Francois Gouget <fgouget(a)codeweavers.com>

2 1

staging: Drop winemenubuilder-Desktop_Icon_Path patch
by Alex Henrie 12 Jun '23

12 Jun '23

Dear Wine Staging maintainers, I would like to drop the Wine Staging patch that changes `wine foo.exe` to `/usr/bin/wine foo.exe` in the .desktop files that winemenubuilder creates.[1] I'm guessing that the wine-devel mailing list is the best forum is for discussing it because the patch has no associated Bugzilla report and merge requests are disabled in the wine-staging repository. This patch isn't very useful in practice because most (if not all) Linux distributions have mutually exclusive packages for Wine and Wine Staging. From the package maintainer's perspective, not supporting the installation of multiple versions of Wine simultaneously makes a lot of sense because only one wineserver can run at a time. Moreover, we don't want to encourage the practice of installing multiple versions of Wine in order to get everything working. Instead, patches should be improved and merged into upstream Wine. Once the bugs are fixed upstream, the user should be free to switch from Wine Staging to mainline Wine without having to edit all of their .desktop files. Also... The patch conflicts with the winemenubuilder protocol associations patch that I'd like to get into Wine Staging,[2] so dropping it means less work to get the other patch in ;-) -Alex [1] https://gitlab.winehq.org/wine/wine-staging/-/blob/adda594159dcafc5dc8db820… [2] https://gitlab.winehq.org/wine/wine/-/merge_requests/2740

1 0

Wine staging 8.10 release
by Alistair Leslie-Hughes 10 Jun '23

10 Jun '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.10 (500 patches are applied to wine vanilla) In the spirit of testing, Wine Staging is now going to carry the latest vk3d3. Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID range. * ntdll: Support MEM_COALESCE_PLACEHOLDERS in NtFreeVirtualMemory(). * ntdll: Factor out unmap_view_of_section() function. * ntdll: Support MEM_PRESERVE_PLACEHOLDER in NtUnmapViewOfSectionEx(). Added: * [54034] d3dx9: Improve sprite rendering state handling. * [20732] oleaut32: OleLoadPictureEx - First look for specific icon size if specified. * [54998] dnsapi: DnsQuery(DNS_TYPE_SRV) fails to parse some of the server answers Updated: * vkd3d-latest * winex11-_NET_ACTIVE_WINDOW * msxml3-FreeThreadedXMLHTTP60 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: GCC 12 use-after-free false positives
by Fabian Maurer 10 Jun '23

10 Jun '23

Thanks for your reply, I agree, but seeing how old the issue is, I don't know how fast it will be fixed. I noticed it's not really fixable when compiling with -O2, it behaves differently from -O0. At least I didn't find a reliable way (except for ignoring realloc failure) There is already a bunch of gcc tickets regarding Wuse-after-free issues, see meta bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075 I think the closest to our case is https://gcc.gnu.org/bugzilla/show_bug.cgi? id=106578 Regards, Fabian Maurer On Samstag, 10. Juni 2023 10:17:39 CEST you wrote: > > Is this worth it or would you wait for gcc to fix their warning? > > I asked my self the very same question... > > given the very low number of warnings from GCC12 (compared to what we > got with GCC11) and their false positive nature, I'd rather pick the > wait and see road > > perhaps opening a GCC ticket could be useful (so we'd know if there's a > chance for a fix or if we'll have to fix it on our side) > > (reminder: if nothing is done, Alexandre will fix it when he upgrades > his compiler as he compiles with -Werror) > > A+

1 0