wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

Re: [PATCH v3 0/2] MR340: regedit: Fix broken handling of REG_DWORD and REG_QWORD values - 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/340

1 0

Re: [PATCH v2 0/1] MR341: dbghelp/msc: support LF_INDEX* in enumeration type definition - 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/341

1 0

[PATCH v2 0/1] MR339: programs/winedbg: no longer hide current WineDbg process from 'info proc'
by eric pouech (＠epo) 29 Jun '22

29 Jun '22

We used to hide current WineDbg instance when displaying processes' list (command 'info proc'). This can potentially generate some "dangling" processes in the hierarchy (related to this WineDbg instance): - conhost.exe - start.exe (when launched from unix shell without full path to winedbg.exe) Also, print a more comprehensive error message when trying to attach to itself (now that debugger's PID is more easily available). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- v2: winedbg: No longer hide current WineDbg process from 'info proc'. https://gitlab.winehq.org/wine/wine/-/merge_requests/339

3 2

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

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