wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

Start a nNew thread

Re: [PATCH v8 0/5] MR310: mf: Fix several reference leaks. - approved
by Alexandre Julliard (＠julliard) 29 Jun '22

29 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/310

1 0

Re: [PATCH v2 0/2] MR335: uxtheme/tests: Add dialog procedure message tests. - approved
by Alexandre Julliard (＠julliard) 29 Jun '22

29 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/335

1 0

Re: [PATCH v3 0/1] MR315: windowscodecs: Fix non-zero alpha detection in ImagingFactory_CreateBitmapFromHICON. - approved
by Alexandre Julliard (＠julliard) 29 Jun '22

29 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/315

1 0

[PATCH v4 0/1] MR256: ntdll: Do not open directory file when setting the same directory path.
by Paul Gofman (＠gofman) 29 Jun '22

29 Jun '22

Fixes The Rising of The Shield Hero: Relieve the Animation hangs on start (and maybe something else with ENIGMA protector). The protector implements virtual file system which hotpatches a lot of file related functions, in particular, NtOpenFile(). When NtOpenFile() is called from RtlSetCurrentDirectory_U() with peb lock held the hotpatcher takes its own lock and that can deadlock with other threads performing file / path operations ending up in get_full_path_helper() which also takes PEB lock. Once the hotpatcher is initialized the game only sets "." or the same full path as current and may do that rather often. It seems that reopening the file handle for the same directory is redundant anyway, so probably makes sense to just avoid that part. -- v4: ntdll: Do not open directory file when setting the same directory path. https://gitlab.winehq.org/wine/wine/-/merge_requests/256

2 2

[PATCH v2 0/2] MR89: Use +threadname channel for thread names.
by Brendan Shanks (＠bshanks) 29 Jun '22

29 Jun '22

Currently, the two methods of setting thread names in Windows (SetThreadDescription() and the 0x406D1388 exception) log to different channels. I think it would be useful for these to both log to the same +threadname channel. My thinking is that this would be similar to +debugstr, in that all messages are human-readable descriptions which would be useful for debugging crashes. -- v2: ntdll: Use +threadname channel for SetThreadDescription(). ntdll: Use +threadname channel for thread rename exceptions. https://gitlab.winehq.org/wine/wine/-/merge_requests/89

2 3

Re: [PATCH v4 0/1] MR105: winegstreamer: reintroduce flushing for wg_parser
by zlice (＠zlice) 29 Jun '22

29 Jun '22

Still happening in 7.11 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/105#note_2965

1 0

Having problems (re-)building i686 wine staging rpm's on fedora
by Hin-Tak Leung 29 Jun '22

29 Jun '22

Due to having a few modifications considered unsuitable for upstreaming, I have been grabbing the official fedora rpm's since at least wine-1.9.20 / 2016 , patching the spec file, adding my patches, plus a "Epoch: 100" line, so it blocks auto--upgrades, until I rebuild it myself every two or three wine releases. This has worked well for 6+ years, until 7.3+ . I last built 7.2 staging with (rpmbuild -bb wine.spec && rpmbuild --target=i686 -bb wine.spec) 2>&1 | tee build-log . Fedora's koji build farm only have 7.3, 7.5, 7.9, and 7.10. I tried 7.10 and the x86_64 part finished (*see notes below), but the i686 part just wouldn't go ahead, due to some PE-related collisions. I back-tracked, and found the failure was between 7.3 and 7.5. === i686-w64-mingw32-gcc -c -o dlls/windowscodecs/libjpeg.cross.o dlls/windowscodecs/libjpeg.c -Idlls/windowscodecs -Iinclude -Iinclude/msvcrt \ -I/usr/include -I./libs/png -D__WINESRC__ -D_UCRT -D__WINE_PE_BUILD -Wall -fno-strict-aliasing \ -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self \ -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value \ -fno-omit-frame-pointer -gdwarf-4 -g -O2 In file included from include/objbase.h:20, from dlls/windowscodecs/libjpeg.c:31: include/rpcndr.h:73:23: error: conflicting types for 'boolean'; have 'unsigned char' 73 | typedef unsigned char boolean; | ^~~~~~~ In file included from /usr/include/jpeglib.h:31, from dlls/windowscodecs/libjpeg.c:24: /usr/include/jmorecfg.h:207:13: note: previous declaration of 'boolean' with type 'boolean' {aka 'int'} 207 | typedef int boolean; | ^~~~~~~ dlls/windowscodecs/libjpeg.c: In function 'jpeg_decoder_initialize': dlls/windowscodecs/libjpeg.c:180:40: warning: assignment to 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'int (*)(struct jpeg_decompress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_decompress_struct *)' {aka 'unsigned char (*)(struct jpeg_decompress_struct *)'} [-Wincompatible-pointer-types] 180 | This->source_mgr.fill_input_buffer = source_mgr_fill_input_buffer; | ^ dlls/windowscodecs/libjpeg.c: In function 'jpeg_encoder_initialize': dlls/windowscodecs/libjpeg.c:466:40: warning: assignment to 'boolean (*)(struct jpeg_compress_struct *)' {aka 'int (*)(struct jpeg_compress_struct *)'} from incompatible pointer type 'boolean (*)(struct jpeg_compress_struct *)' {aka 'unsigned char (*)(struct jpeg_compress_struct *)'} [-Wincompatible-pointer-types] 466 | This->dest_mgr.empty_output_buffer = dest_mgr_empty_output_buffer; | ^ make: *** [Makefile:127914: dlls/windowscodecs/libjpeg.cross.o] Error 1 === I tried setting PNG_PE_CFLAGS, ZLIB_PE_CFLAGS, LCMS2_PE_CFLAGS, JPEG_PE_CFLAGS, JPEG_PE_LIBS etc explicitly, and sometimes it get worse. Anyway, I have tried some many things that I thought it might be worth reaching out to the people who maintain the fedora rpm's as well as well wine-devel. A few questions/thoughts: - it seems that the build system is getting confused occasionally about say, native headers vs mingw headers like jpeg-devel; at some point, I got a error saying I was trying to build one of the unixlib.c's with mingw headers, for example. But I see for example that in the generated Makefile for dlls/windowscodecs/ , It is feeding *PE_FLAGS to unixlib.c (plus the PE stub), and I explicitly put -I...mingw32/include to *PE_FLAGS. That seems wrong. - I don't understand why --target=x86_64 rebuild works, built --target=i686 rebuild fails with the above error. My list of mingw32-* packages and mingw64-* packages are almost identical, I think, and certainly regarding libjpeg (zlib/png dependencies) . I have the 29MB combined x86-64 and i686 build-log of 7.3, plus the 15MB x86-64 and ~3MB i686 failure of each of 7.5/7.9/7.10 ; but it is kind of difficult to see what to check. Any hints on what to look at at config.log would be useful. *note rpmbuild detects isdn4k-utils on my system so I needed to add these two lines +%{_libdir}/wine/%{winesodir}/capi2032.so +%{_libdir}/wine/%{winepedir}/capi2032.dll to my modified spec. I suppose I should formalize this part of my diff with one furthe line of BuildRequires: isdn4k-utils-devel as a reminder to myself.

3 4

[PATCH 0/8] MR343: scrrun: Implement MoveFolder().
by Robert Wilhelm (＠sloper42) 29 Jun '22

29 Jun '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52128 Signed-off-by: Robert Wilhelm <robert.wilhelm(a)gmx.net> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/343

2 8

[PATCH v2 0/3] MR337: winepulse: Return device-specific values for GetMixFormat and GetDevicePeriod
by Claire (＠ClearlyClaire) 29 Jun '22

29 Jun '22

When `GetMixFormat` or `GetDevicePeriod` are used, return values specific to the selected device instead of those of the default one. This is especially useful when the audio devices features less channels than one specifically selected by the application. This patch is part of an attempt to get Sony's DualSense controllers to work with Windows games through Wine. This is not enough by itself, but getting the proper mix format is required for most of those games to correctly use the haptic feedback features of the DualSense (which go through an audio output with 4 audio devices). -- v2: winepulse: Return device-specific values for GetDevicePeriod winepulse: Return device-specific values for GetMixFormat winepulse: Store device-specific format and periods https://gitlab.winehq.org/wine/wine/-/merge_requests/337

3 4

[PATCH 0/1] MR338: mmdevapi: Override product strings for DualSense controller audio devices
by Claire (＠ClearlyClaire) 29 Jun '22

29 Jun '22

Some games expect the DualSense audio device (used for haptic feedback and controller speaker) to be called “Wireless Controller”. This is the case of Final Fantasy XIV Online and Final Fantasy VII Remake Intergrade, and possibly other games as well. Together with !337, this is enough for all DualSense features to properly work with those games (provided the controller is plugged in before the game is started). Note that this is not sufficient for many other games which have more elaborate logic for finding the DualSense audio output. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/338

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel