wine-bugs October 2024

wine-bugs@winehq.org

2 participants
1844 discussions

[Bug 48272] New: Crackling and slower audio on Ubisoft's Assassin's Creed 1 & Far Cry 3 games
by WineHQ Bugzilla 20 Sep '25

20 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=48272 Bug ID: 48272 Summary: Crackling and slower audio on Ubisoft's Assassin's Creed 1 & Far Cry 3 games Product: Wine Version: 4.21 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: adrien_fernandes2(a)hotmail.com Created attachment 65940 --> https://bugs.winehq.org/attachment.cgi?id=65940 Output of Wine 4.21 running Assassin's Creed So here it is, it might be a bit long and I'll try to be as precise as I can to explain the problem. First, list of tested games : Far Cry 2 : No audio problem ✔ Crysis : No audio problem ✔ XIII : No audio problem ✔ Far Cry 3 : Crackling audio ✖ Assassin's Creed : Crackling audio ✖ I ran all the games set on DirectX 9 and I built Wine to use Open Sound System for audio (if this is important). Assassin's Creed 1's prefix is set to WinXP and Far Cry 3's one is set to Win7 (because of Uplay). The problem is that the audio on Far Cry 3 and Assassin's Creed is weirdly crackling and slower than it should be but, not EVERY sounds in the game are making the audio crackles. On Assassin's Creed, it's when a lot of people are around me and everytime I use the eagle vision. In the menu or when outside the Animus (in the present time of the game where there are only three people and a tiny room), the audio works well. Also, an important point is that neither Assassin's Creed nor Far Cry 3 are slowed down to fit the slowed down audio issue. They both work very well when it happens which is causing a strange issue I'll describe AND SHOW below. I'm using a GTX 765m to play which is not bad for old games like these. "Your computer certainly isn't powerful enough to run the game !" you say... Well, you are not totally wrong, I could have better hardware but, in the past, when I was playing these games on Windows then, later, on GNU/Linux, I never met this problem. The two differences are that I'm playing, for the first time, Assassin's Creed _ON_FREEBSD_ and we are now almost in 2020. My last Assassin's Creed session was on GNU/Linux in 2016. Wine changed so much in almost 4 years ! But let me remind you that only two of the five games mentioned above are having issue. all my native FreeBSD games (OpenMorrowind, Xonotic, Minetest, Tales of Maj'Eyal, Quake II from Yamagi's source code etc...), videos read with mpv, music listened with moc and even Firefox are all working well without crackling or slowed down audio. And three tested games on Wine with OSS are working perfecly. I could have tested more games but I think three is good enough. So here is the "show" I mentioned in the beginning. I took a video of Assassin's Creed's problem. I recorded it with my phone so... sorry for the poor quality but you can see the problem : https://www.youtube.com/watch?v=f5rhg-PwFeU In this video, you can see two people speaking together. In the normal game, one speak and, when finished, the other answer. They _NEVER_ speak above the other. In my Assassin's Creed, the game is running well but the audio is slowed down which creates a desyncing between the slowed down voice played and the mouth of the character. And, because the game is running well beside this issue, one didn't finish his sentence and the other will start his speech over the first one (it shouldn't happen). I found a longplay video of the game which is certainly played on Windows. I copied the video link to start at the exact same moment as the one I recorded from my computer and you can see how the game should normally behave : https://youtu.be/1gGz6vf35T0?t=2991 About the crackling audio issue, it can be heard by the end of my video when I use the eagle vision. For Far Cry 3, don't even need to run the game to hear crackling and slowed down audio. I also took a video of the problem, it speaks for itself : https://www.youtube.com/watch?v=JkOXvy_42jc The original theme can be listened here : https://youtu.be/rfAeL4JfHj8?t=10 I copied the video to start at the same time of my video of Far Cry 3, in the menu. What you can notice is that the normal music is faster than in my video, it's the same problem than with Assassin's Creed 1. I fetched the output of Wine when running Assassin's Creed 1. It repeatedly says two things so I cut it into "head -n 50" and "tail -n 50". I watched the long output and nothing is different between the first 50 and last 50 lines. I hope I was clear enough, English isn't my native language so I apologize if I didn't use it correctly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 54285] New: Mostly UE4 games failing to start when trying to use faudio by wine itself
by WineHQ Bugzilla 20 Sep '25

20 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=54285 Bug ID: 54285 Summary: Mostly UE4 games failing to start when trying to use faudio by wine itself Product: Wine Version: 7.0.1 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: xaudio2 Assignee: wine-bugs(a)winehq.org Reporter: Alexander88207(a)Protonmail.com Created attachment 73852 --> https://bugs.winehq.org/attachment.cgi?id=73852 Sea of Thieves Hello, since the update to wine 7 it is not possible to run mostly Unreal Engine 4 games. In the log there were indications that something might be wrong with the xaudio 2_7 dll. So I just applied faudio via winetricks and the games work again. Unfortunately this is not a permanent solution as there is a bug on platforms like Mac OS, FreeBSD that if you use native,buildin xaudio the sound does not work correctly in terms of stuttering and slightly distorted sound. As far as I know the games worked correctly in Wine 6.0.1. Unfortunately it is not possible for me to test more in wine-devel because the port is very often defective and also just once again not working. (Last version tested was 7.21 and it was there too) Thanks in advance! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 44817] New: Some software protection schemes need ntdll.NtSetLdtEntries implementation
by wine-bugs＠winehq.org 20 Sep '25

20 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=44817 Bug ID: 44817 Summary: Some software protection schemes need ntdll.NtSetLdtEntries implementation Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, to track https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-NtSe… The stub was added with bug 26268 ("Multiple applications need ntdll.ZwSetLdtEntries stub (kwiksupport.me, Ragnarok Online patcher)"). Unfortunately there is no further information/details *which* copy-protection scheme needs and actual implementation. No applications/games are mentioned. --- quote --- 1. Some copy protections call NtSetLdtEntries(0x000f) and then with 'retf' instruction jump to that selector expecting that it works (the tests show that NtSetLdtEntries(0x000f,0x001f) should succeed). In order to make this work a limitation to set only selectors > LDT_FIRST_ENTRY (512) in wine_ldt_set_entry() was removed. 2. wine_ldt_set_entry() was made to always mark modified selector entries as WINE_LDT_FLAGS_ALLOCATED, otherwise get_selector_entry() server call returns entries without that flag set and NtQueryInformationThread(ThreadDescriptorTableEntry) fails. --- quote --- $ wine --version wine-3.4 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 5

[Bug 49028] New: X-plane 11 (windows) falls back to opengl when trying to run with vulkan.
by WineHQ Bugzilla 19 Sep '25

19 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=49028 Bug ID: 49028 Summary: X-plane 11 (windows) falls back to opengl when trying to run with vulkan. Product: Wine Version: 5.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hubert(a)limitset.net Distribution: --- Created attachment 67006 --> https://bugs.winehq.org/attachment.cgi?id=67006 X plane log When attempting to run the windows version of X-plane 11 (to get access to windows only add-ons) the game will not run with vulkan enabled. When attempting to start the simulator in vulkan mode this is the error message: "The graphics card or driver lacks support for a required extension: VK_KHR_external_memory_win32" and coontinues to run but with opengl. This happens on Arch Linux and Debian Sid, and so far this issue has occurred for everyone who has tried running the game with wine using vulkan. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 38190] New: FEAR crash at runs
by wine-bugs＠winehq.org 19 Sep '25

19 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=38190 Bug ID: 38190 Summary: FEAR crash at runs Product: Wine Version: 1.7.38 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mrdeathjr28(a)yahoo.es Distribution: --- Created attachment 50967 --> https://bugs.winehq.org/attachment.cgi?id=50967 backtrace fear Game config works but when game is launched crash -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 6

[Bug 48548] New: Support running multiple tests in submitted jobs
by WineHQ Bugzilla 18 Sep '25

18 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=48548 Bug ID: 48548 Summary: Support running multiple tests in submitted jobs Product: Wine-Testbot Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: cdavis5x(a)gmail.com When I submit a job manually on the testbot, I can only run one instance of one executable. For a binary, this makes sense, since there's only one binary; but a patch, for which a choice of Wine test executables is offered, can affect multiple Wine unit tests. I then have to submit the job multiple times, one for each test unit affected. This seems... suboptimal. It'd be much faster and more convenient if I could run multiple tests in a single job. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 56059] New: Overwatch 2: highlight saving generates a 1ms (empty) webm video file
by WineHQ Bugzilla 18 Sep '25

18 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=56059 Bug ID: 56059 Summary: Overwatch 2: highlight saving generates a 1ms (empty) webm video file Product: Wine Version: 9.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: forestix(a)nom.one Distribution: --- Created attachment 75715 --> https://bugs.winehq.org/attachment.cgi?id=75715 example video file When attempting to save a game highlight as a webm video file, Overwatch 2 *seems* to be encoding the video as it should, in that it uses the CPU and takes an appropriate amount of time to complete. However, the resulting file is only about 700K, and doesn't play in any player. Examining the file with MediaInfo shows what looks like a reasonable container with video and audio parts, but only 1ms duration. I get the same results in all of these Wine versions: wine-9.0-rc2 wine-9.0-rc2 (Staging) wine-ge-custom (aka lutris-GE-Proton) 8-23 Game installer download link: https://download.battle.net/en-us?product=ow&blzcmp=ow_gamesite Steps to reproduce: - play a game (easiest way is via Play: Training: Practice vs. AI: Casual) - after the game is over, return to the main menu - click username button (top right corner) - click history tab (top edge) - click highlights tab (left edge) - click a highlight from "today's top 5" - click save button (bottom edge) - select movie format: webm - click save button -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 56137] New: Overwatch 2 fails to save highlight video files
by WineHQ Bugzilla 17 Sep '25

17 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=56137 Bug ID: 56137 Summary: Overwatch 2 fails to save highlight video files Product: Wine Version: 9.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: forestix(a)nom.one Distribution: --- When attempting to save an Overwatch 2 highlight video as an mp4 file (the default format), it fails with this error message: SAVING ERROR An unknown error has occurred. (6-04) Steps to reproduce: - play a game (easiest way is via Play: Training: Practice vs. AI: Casual) - after the game is over, return to the main menu - click username button (top right corner) - click history tab (top edge) - click highlights tab (left edge) - click a highlight from "today's top 5" - click save button (bottom edge) - select movie format: mp4 - click save button Note that this is a different kind of failure than the one with .webm format (bug 56059). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 55151] New: PC crashes after endlessly eating up memory
by WineHQ Bugzilla 17 Sep '25

17 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=55151 Bug ID: 55151 Summary: PC crashes after endlessly eating up memory Product: Wine Version: 8.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: axis6404(a)proton.me Distribution: --- example script (selfdel.bat): :REP del "selfdel.bat" if exist "selfdel.bat" goto REP wine selfdel.bat (An infinite loop occurs. Until it eats up all the memory and the PC stops.) The koeiuc.bat in Steam games made by Koei eats up all the memory and crashes the PC. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 49195] New: Multiple 4k demoscene OpenGL demos crash on startup (failure to lookup atom 0xC019 'static' from global atom tables)
by WineHQ Bugzilla 16 Sep '25

16 Sep '25

https://bugs.winehq.org/show_bug.cgi?id=49195 Bug ID: 49195 Summary: Multiple 4k demoscene OpenGL demos crash on startup (failure to lookup atom 0xC019 'static' from global atom tables) Product: Wine Version: 5.8 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, extracted from bug 48898 My comment: https://bugs.winehq.org/show_bug.cgi?id=48898#c12 --- quote --- To me it looks like bug 18490 ("Multiple games fail to set pixel format on D3D device context created on desktop window (Empire: Total War, Napoleon: Total War, Utopia City)") but for GL device context on the desktop window. According to online information it's not allowed to do any rendering using this context but enough to call functions like glGetString() etc. Maybe some of the Wine graphics folks could weigh in with an opinion if this limitation is already known / tracked in a bug? --- quote --- Henri's answer: https://bugs.winehq.org/show_bug.cgi?id=48898#c13 --- quote --- I'm not aware of an existing bug report for this issue, no. It does strike me as similar to bug 36506 though, and it would not particularly surprise me if wglGetProcAddress() is supposed to return results consistent with GL_EXTENSIONS/GL_VERSION here, even without a current GL context. I seem to recall having established in the context of bug 18490 that creating a GL context (or more specifically, setting a pixel format) on the desktop window is indeed supposed to fail. In any case, this seems like of of those bugs that would benefit from tests to establish what's supposed to happen. --- quote --- Turns out this was a side-effect of an earlier problem. It was not supposed to be GetDC(NULL) (Desktop window). --- snip --- $ WINEDEBUG=+seh,+relay,+server,+class,+win,+msg wine ./End\ of\ time\ 720p.exe >>log.txt 2>&1 ... 0024:Call user32.ChangeDisplaySettingsA(00421288,00000004) ret=004200da ... 0024: get_desktop_window( force=0 ) 0024: get_desktop_window() = 0 { top_window=00010020, msg_window=00010026 } ... 0024:Ret user32.ChangeDisplaySettingsA() retval=00000000 ret=004200da 0024:Call KERNEL32.CreateThread(00000000,00000000,004201ca,004304e8,00000000,00000000) ret=004200ee ... 0024:Ret KERNEL32.CreateThread() retval=00000080 ret=004200ee 00bc: *fd* 17 <- 38 00bc: init_thread( unix_pid=3683, unix_tid=3729, debug_level=1, teb=7ffd4000, entry=004201ca, reply_fd=15, wait_fd=17, cpu=x86 ) 0024:Call user32.CreateWindowExA(00000000,0000c019,00000000,91000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000) ret=004200f4 0024:trace:win:WIN_CreateWindowEx (null) #c019 ex=00000000 style=91000000 0,0 0x0 parent=(nil) menu=(nil) inst=(nil) params=(nil) 00bc: init_thread() = 0 { pid=0020, tid=00bc, server_start=1d62d3b280579be (-2.9701360), info_size=0, version=603, all_cpus=00000003, suspend=0 } 0024:trace:win:dump_window_styles style: WS_POPUP WS_VISIBLE WS_MAXIMIZE 0024:trace:win:dump_window_styles exstyle: ... 00bc:Starting thread proc 0x4201ca (arg=0x4304e8) ... 0024: create_window( parent=00010020, owner=00000000, atom=c019, instance=00000000, dpi=96, awareness=2, class=L"" ) 0024: create_window() = INVALID_HANDLE { handle=00000000, parent=00000000, owner=00000000, extra=0, class_ptr=00000000, dpi=0, awareness=0 } 0024:warn:win:create_window_handle error 6 creating window 0024:trace:class:GetClassInfoExW (nil) #c019 0x1518f9e0 0024:trace:class:CLASS_FindClass #c019 0x7e910000 -> not found 0024:Ret user32.CreateWindowExA() retval=00000000 ret=004200f4 --- snip --- The failing window creation resulted in NULL handle which got passed to user32.GetDC(): --- snip --- 0024:Call user32.GetDC(00000000) ret=004200fb 0024:trace:win:GetDCEx hwnd 0x10020, hrgnClip (nil), flags 00000003 ... 0024: get_visible_region( window=00010020, flags=00000013 ) 0024: get_visible_region() = 0 { top_win=00010020, top_rect={-1920,0;-1919,1}, win_rect={0,0;3200,1080}, paint_flags=00000001, total_size=16, region={{-1920,0;1280,1080}} } 0024:Call winex11.drv.GetDC(00030039,00010020,00010020,1518fde0,1518fdf0,00000013) ret=7e97bd3e 0024:Ret winex11.drv.GetDC() retval=00000001 ret=7e97bd3e 0024:trace:win:GetDCEx (0x10020,(nil),0x13): returning 0x30039 (updated) 0024:Ret user32.GetDC() retval=00030039 ret=004200fb --- snip --- Well, the rest of the OpenGL story is known and the current behaviour makes sense. Back to the actual problem... The creation of the window which ought the be used for OpenGL context/rendering fails because atom 0xc019 can't be found/resolved. I should have looked more carefully at the trace log and the demo disassembly. --- snip --- ... 004200B6 | xor esi,esi | 004200B8 | push esi | 004200B9 | push esi | 004200BA | push esi | 004200BB | push esi | 004200BC | push esi | 004200BD | push esi | 004200BE | push esi | 004200BF | push esi | 004200C0 | push esi | 004200C1 | push 91000000 | 004200C6 | push esi | 004200C7 | push C019 | global atom! 004200CC | push esi | 004200CD | push 4 | 004200CF | push end of time 720p.421288 | 004200D4 | call dword ptr ds:[<&user32.ChangeDisplaySettingsA>] | 004200DA | push esi | 004200DB | push esi | 004200DC | push end of time 720p.4304E8 | 004200E1 | push end of time 720p.4201CA | 004200E6 | push esi | 004200E7 | push esi | 004200E8 | call dword ptr ds:[<&KERNEL32.CreateThread>] | 004200EE | call dword ptr ds:[<&user32.CreateWindowExA>] | fails 004200F4 | push eax | 004200F5 | call dword ptr ds:[<&user32.GetDC>] | 004200FB | mov edi,eax | 004200FD | mov dword ptr ds:[3AB08EC],eax | 00420102 | push esi | 00420103 | push edi | 00420104 | push esi | 00420105 | push end of time 720p.42125C | 0042010A | push edi | 0042010B | call dword ptr ds:[<&gdi32.ChoosePixelFormat>] | 00420111 | push eax | 00420112 | push edi | 00420113 | call dword ptr ds:[<&gdi32.SetPixelFormat>] | 00420119 | call dword ptr ds:[<&opengl32.wglCreateContext>] | 0042011F | push eax | 00420120 | push edi | 00420121 | call dword ptr ds:[<&opengl32.wglMakeCurrent>] | 00420127 | call dword ptr ds:[<&user32.ShowCursor>] | 0042012D | call end of time 720p.4202CC | --- snip --- The demoscene guys are crazy and fight for each saved byte ;-) Courtesy of: http://www.pouet.net/topic.php?which=9894 --- quote --- I was able to get 4 bytes off of a test 1k intro (Peach GLSL Shader of Japan) by replacing the "edit" string with 0xC018, making it 1006 bytes instead of 1010. Nice. ...and then I got it down to 1004 bytes, because now "test eax, eax" compressed better than "test ax, ax", which used to compress better sometime before this newest change. ;) This 1k intro business is crazy, you'd really need some kind of brute-force code masher that tries all possible combinations of code that perform the same thing. --- quote --- --- quote --- That´s mine since 2009 using DirectX9...someone told me using "static" instead of "edit" would be better back then in some other thread...was iq if i remember correctly. The ATOM for "static" is 0xC019 btw, but be warned: it added 7 bytes here in my first test, opposed to chopping off 4 bytes in case of "edit". --- quote --- --- quote --- Oh, shit...i did the test the wrong way around...meaning the ATOM actually chopped off 7 bytes in case of "static" vs. "0xC019" :/ :D Yay, thanks for the nice trick, man! :) --- quote --- Also relevant, shows dump of global and typical local atom tables: https://github.com/lungetech/ICAS/blob/master/logs/volatility/win32/output/… Wine source: https://source.winehq.org/git/wine.git/blob/9e26bc811656ad8eb901bffa5528b9c… --- snip --- 407 /*********************************************************************** 408 * CLASS_FindClass 409 * 410 * Return a pointer to the class. 411 */ 412 static CLASS *CLASS_FindClass( LPCWSTR name, HINSTANCE hinstance ) 413 { 414 static const WCHAR comctl32W[] = {'c','o','m','c','t','l','3','2','.','d','l','l',0}; 415 struct list *ptr; 416 ATOM atom = get_int_atom_value( name ); 417 418 GetDesktopWindow(); /* create the desktop window to trigger builtin class registration */ 419 420 if (!name) return NULL; 421 422 name = CLASS_GetVersionedName( name, NULL, NULL, TRUE ); 423 424 for (;;) 425 { 426 USER_Lock(); 427 428 LIST_FOR_EACH( ptr, &class_list ) 429 { 430 CLASS *class = LIST_ENTRY( ptr, CLASS, entry ); 431 if (atom) 432 { 433 if (class->atomName != atom) continue; 434 } 435 else 436 { 437 if (strcmpiW( class->name, name )) continue; 438 } 439 if (!class->local || class->hInstance == hinstance) 440 { 441 TRACE("%s %p -> %p\n", debugstr_w(name), hinstance, class); 442 return class; 443 } 444 } 445 USER_Unlock(); 446 447 if (atom) break; 448 if (!is_comctl32_class( name )) break; 449 if (GetModuleHandleW( comctl32W )) break; 450 if (!LoadLibraryW( comctl32W )) break; 451 TRACE( "%s retrying after loading comctl32\n", debugstr_w(name) ); 452 } 453 454 TRACE("%s %p -> not found\n", debugstr_w(name), hinstance); 455 return NULL; 456 } --- snip --- https://source.winehq.org/git/wine.git/blob/9e26bc811656ad8eb901bffa5528b9c… $ sha1sum atz-end_of_time.zip 3a4ce3fd92e2fdd1a4533ee67d4809d3f2184f6b atz-end_of_time.zip $ du -sh atz-end_of_time.zip 3.3M atz-end_of_time.zip $ wine --version wine-5.8-173-g9e26bc8116 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 8

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-bugs October 2024