August 2026 - Wine-Bugs - list.winehq.org

[Bug 46871] New: err:rpc: rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87
by wine-bugs＠winehq.org Sept. 15, 2026

Sept. 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=46871 Bug ID: 46871 Summary: err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 Product: Wine Version: 4.4 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: rpc Assignee: wine-bugs(a)winehq.org Reporter: susancragin(a)earthlink.net Distribution: --- Created attachment 63932 --> https://bugs.winehq.org/attachment.cgi?id=63932 NaturallySpeaking 13 setup log When installing Dragon NaturallySpeaking 13, the installation hangs up right at the last instruction. A prior bug 46160 was filed about NatSpeak 13 hanging up at the end of installation, and I think that bug might have been fixed in the most recent wine version, and this other bug uncovered. bug 46160 Anyway, the installation stops as of this: err:rpc:rpcrt4_protseq_np_wait_for_new_connection wait failed with error 87 I have posted the installation log. If I kill the installation and then try to start the program, the program works up to a point. It waves hello, and then asks if I want to register the program immediately or run it up to 5 times without registering. When I hit either of these options, the program crashes. I have included the crash log also. -- 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.

3 13

[Bug 60128] New: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM)
by WineHQ Bugzilla Sept. 15, 2026

Sept. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60128 Bug ID: 60128 Summary: Problem with resizing X11 decorated windows in Linux Mint Cinnamon (Muffin WM) Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: empcomputer(a)outlook.com.au Target Milestone: --- Distribution: --- Created attachment 81701 --> http://bugs.winehq.org/attachment.cgi?id=81701 Notepad after launch - OK Running Linux Mint 22.3 Cinnamon. If window manager decorations are enabled and a window is resized/maximised/restored, mouse coordinates are reported incorrectly, resulting in an offset between the on-screen cursor position and hit point. Also manifests as a menu activated by keyboard accelerators appearing in incorrect position. I have found that, under certain conditions (can't see a clear pattern, but seems to depend on window position and size), the window manager triggers ConfigureNotify events for the client window before the parent (frame) window. When this happens, the X11 driver computes the window rectangles using the old frame coordinates, leading to the offset problem described earlier. If window manager decorations are disabled, the problem does not occur (there is no frame window in that case). Simple repro steps: - Ensure that "Allow the window manager to decorate the windows" and "Allow the window manager to control the windows" options are checked - Ensure that "Emulate a virtual desktop" is UNchecked - Launch Notepad - Position the window approximately in the centre of the screen (away from the top-left corner) - Maximise the window - Pull down a menu using the keyboard (e.g. Alt+F or Alt+H) - Note that the menu appears away from the expected position - If you restore the window, you'll notice a similar effect (with reversed offsets) - Moving the window using the title bar corrects the coordinates The problem was first noticed in Wine 11.13, but testing shows that it goes back as far as ~10.0. It is more pronounced/consistent in 11.13, but can be triggered sporadically in some earlier versions as well. After looking through the code and some experimenting, one possible fix is to modify the "host_window_map_point" function to use XTranslateCoordinates. I'm not sure if it's the best solution; I imagine there's a good reason it was coded the way it is (e.g. performance issues due to X protocol overhead - I haven't looked into it enough). I hope I have at least provided a good starting point. I'll also note that I have tested it with a few other window managers (Xfwm, Metacity and Compiz, running Linux Mint 22.3 Xfce Live ISO in VirtualBox) and they did not exhibit the same problem. (More attachments to follow...) -- 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 11

[Bug 60268] New: wine got case sensitive in case of complete file pathes
by WineHQ Bugzilla Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60268 Bug ID: 60268 Summary: wine got case sensitive in case of complete file pathes Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: mywine(a)schiermeier-it.de Target Milestone: --- Distribution: --- Until wine-11.12 wine wasn't case sensitive. This behaviour changed in wine-11.14 (I did not use wine-11.13). Example: my windows apps are in /opt/winprog. There live a small flashcards app called CUEcards with this path: /opt/winprog/CUEcards/cuecards.exe. To get an easy access I created a desktop file with this path: /opt/winprog/cuecards/cuecards.exe So the first three letters of the word CUEcards were witten in small letters. This worked until wine-11.12 flawless. Than this behaviour changed: wine got case insensitiv! In Windows both would work - but not anymore in wine. -- 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 60260] New: Listview text disappears when selected
by WineHQ Bugzilla Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60260 Bug ID: 60260 Summary: Listview text disappears when selected Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: svens(a)stackframe.org Target Milestone: --- Distribution: --- Created attachment 81977 --> http://bugs.winehq.org/attachment.cgi?id=81977 trace+listview output I'm using the Tektronix TLA software (https://www.tek.com/de/support/software/application/tla-application-softwar…) with wine. In the initial dialog during startup which allows to select the logic analyzer to connect to, the text '[offline]' disappears as soon as I click on the text. This is reproducible with a fresh install in a new wine prefix. Only thing installed is dotnet40. I attached the output of 'WINEDEBUG=trace+listview tla700 2>&1|tee logfile' to this bug, and also a screenshot of the window in question. Note that i'm unable to take a screenshot of the error, because the text immediately re-appears when the screenshot program takes focus of the screen. -- 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 12

[Bug 59737] New: IME/VK_PROCESSKEY path loses scan code in follow-up WM_KEYDOWN under Chinese HKL
by WineHQ Bugzilla Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59737 Bug ID: 59737 Summary: IME/VK_PROCESSKEY path loses scan code in follow-up WM_KEYDOWN under Chinese HKL Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: ax+3lzp806u(a)fxzx.ident.com.es Distribution: --- ### Summary When Wine runs under a Chinese locale / Chinese HKL (`00000804`), or after a Chinese IME path is activated, normal key presses are delivered through a `VK_PROCESSKEY` path. The initial `VK_PROCESSKEY` message contains the correct scan code in `lParam`, but the following real `WM_KEYDOWN` message for the actual key, such as `VK_W` or `VK_BACK`, has scan code `0`. This breaks games and engines that rely on scan codes for keyboard input or key binding. ### Environment * Affected HKL: Chinese layout, `00000804` * Working HKL: US layout, `00000409` The runtime XKB map appears normal: ```text key <BKSP> { [ BackSpace, BackSpace ] }; key <AD02> { type= "ALPHABETIC", symbols[Group1]= [ w, W ] }; ``` So this does not appear to be caused by a broken XKB layout. ### Steps to reproduce 1. Run Wine under a Chinese locale, or use a session where Wine selects Chinese HKL `00000804`. 2. Start an affected game or test program that logs Windows keyboard messages. 3. Press normal keys such as `W` or `Backspace`. 4. Observe the generated `WM_KEYDOWN` messages and their `lParam` scan-code bits. The problem may also appear after a Chinese IME / input method is activated during the same Wine session. ### Actual behavior Wine reports Chinese keyboard layout: ```text NtUserGetKeyboardLayoutName ret L"00000804" layout 0x8040804 Default IME Wine IME WM_IME_NOTIFY ``` Pressing `W` produces: ```text WM_KEYDOWN wp=000000e5 lp=00110001 # VK_PROCESSKEY, scan code = 0x11 WM_KEYDOWN wp=00000057 lp=00000011 # VK_W, scan code = 0 WM_CHAR wp=00000077 lp=00000011 WM_KEYUP wp=000000e5 lp=c0110001 WM_KEYUP wp=00000057 lp=0000c011 ``` Pressing `Backspace` produces: ```text WM_KEYDOWN wp=000000e5 lp=000e0001 # VK_PROCESSKEY, scan code = 0x0e WM_KEYDOWN wp=00000008 lp=0000000e # VK_BACK, scan code = 0 WM_CHAR wp=00000008 lp=0000000e WM_KEYUP wp=000000e5 lp=c00e0001 WM_KEYUP wp=00000008 lp=0000c00e ``` The scan code is present on the `VK_PROCESSKEY` message, but is lost in the follow-up real key message. ### Expected behavior When Wine sends the final real key message after IME processing, the scan code in `lParam` should be preserved. Expected examples: ```text WM_KEYDOWN VK_W lp=00110001 WM_KEYDOWN VK_BACK lp=000e0001 ``` The real key message should not have scan code `0`. ### Working case When Wine is launched with an English locale: ```sh LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 wine <app> ``` Wine uses US layout: ```text NtUserGetKeyboardLayoutName ret L"00000409" ``` No `VK_PROCESSKEY` message is generated, and scan codes are correct. For `W`: ```text WM_KEYDOWN dispatched wp=00000057 lp=00110001 WM_KEYUP dispatched wp=00000057 lp=c0110001 ``` For `Backspace`: ```text WM_KEYDOWN dispatched wp=00000008 lp=000e0001 WM_CHAR dispatched wp=00000008 lp=000e0001 WM_KEYUP dispatched wp=00000008 lp=c00e0001 ``` ### Additional observation The issue can reappear after a Chinese IME/input method is activated inside the session. Before IME activation, keyboard input may work normally. After the IME appears or composition is activated, affected games may start receiving real key messages with scan code `0`. This suggests the issue is likely in Wine's IME / `VK_PROCESSKEY` handling path, not only in initial locale selection. ### Impact Games and engines that depend on scan codes for keyboard input or key binding ignore affected keys. Observed symptoms include: * `W` is not recognized unless pressed as `Alt+W`. * `Backspace` is ignored in some games. * Plain letter keys may fail in some games. * The problem disappears when Wine is launched with an English locale. `Alt+W` works because it goes through the system-key path and receives a correct scan code: ```text WM_SYSKEYDOWN wp=00000012 lp=20380001 # Alt WM_SYSKEYDOWN wp=00000057 lp=20110001 # W, scan code = 0x11 ``` ### Workaround Launching Wine with an English locale avoids the problem: ```sh LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 XMODIFIERS=@im=none wine <app> ``` ### Suspected cause Wine appears to construct the follow-up real `WM_KEYDOWN` message incorrectly after `VK_PROCESSKEY` handling. The correct scan code is available in the `VK_PROCESSKEY` message, but is not preserved in bits 16–23 of `lParam` for the real key message. -- 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 6

[Bug 35128] New: Air Conflicts (Pacific Carriers/Secret Wars) hangs at the loading screen
by wine-bugs＠winehq.org Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=35128 Bug ID: 35128 Summary: Air Conflicts (Pacific Carriers/Secret Wars) hangs at the loading screen Product: Wine Version: 1.7.8 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com Classification: Unclassified Created attachment 46858 --> http://bugs.winehq.org/attachment.cgi?id=46858 terminal output I have this bug with both games from the Air Conflicts series when running under Wine. The native Linux version of AC:Pacific Carriers (running under the Linux version of Steam) doesn't have the problem. Also, running the Windows version in Virtualbox doesn't have the problem. The problem: the game starts fine and mouse/keyboard work as expected in the menus, but when I start a mission the game is stuck in the loading screen. The game is not completely dead because game tips are cycling through on the screen and the text 'Press any key to continue' is flashing, but the game doesn't accept mouse or keyboard input any more so I can't get in the game. The ACPC.exe process is consuming 30-40% cpu, but nothing happens, I have to kill the process to exit. Fedora 19 Nvidia binary drivers 325.15 X.Org X Server 1.14.4 -- 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.

3 17

[Bug 60156] New: amstream: IAMMultiMediaStream::OpenFile() renders only the first output pin of the source filter
by WineHQ Bugzilla Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=60156 Bug ID: 60156 Summary: amstream: IAMMultiMediaStream::OpenFile() renders only the first output pin of the source filter Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81775 --> http://bugs.winehq.org/attachment.cgi?id=81775 Proposed patch: render all output pins of the source filter in IAMMultiMediaStream::OpenFile() IAMMultiMediaStream::OpenFile() asks the source filter's pin enumerator for exactly one pin and renders exactly that pin. When the source filter parses the file itself and therefore exposes one output pin per elementary stream -- as the WM ASF reader in dlls/qasf does -- every pin after the first is silently left unconnected. Where it is ----------- dlls/amstream/multimedia.c, multimedia_stream_OpenFile(), lines 429-510 in wine-11.15/master (identical, same line numbers, in 8.0, 9.0, 10.0, 11.0 and 11.14): 455 if (SUCCEEDED(ret)) 456 ret = IBaseFilter_EnumPins(BaseFilter, &EnumPins); 457 458 if (SUCCEEDED(ret)) 459 ret = IEnumPins_Next(EnumPins, 1, &ipin, NULL); 460 461 if (SUCCEEDED(ret)) 462 { 463 ret = IPin_QueryDirection(ipin, &pin_direction); 464 if (ret == S_OK && pin_direction == PINDIR_OUTPUT) 465 This->ipin = ipin; 466 } ... 476 ret = IFilterGraph2_RenderEx(graph, This->ipin, renderflags, NULL); There is no loop. The enumerator is queried once, and RenderEx() is called once, always with This->ipin. This does not show up with .avi because CLSID_AsyncReader has a single output pin and quartz's autoplug_through_filter() (dlls/quartz/filtergraph.c) then recursively renders all output pins of the filters it inserts, so the AVI splitter's video and audio pins both get connected. A source filter that is itself the parser never gets that treatment: dlls/qasf/asfreader.c creates one source pin per stream inside Load(), before AddSourceFilter() returns, and quartz does not enumerate the source filter's own pins -- that is amstream's job. Application: Sacred Gold ------------------------ Sacred Gold (Steam appid 12320, also sold by GOG) plays its .wmv cutscenes through DirectShow Multimedia Streaming. It creates a video stream and an audio stream, the latter with AMMSF_ADDDEFAULTRENDERER, then calls OpenFile() with flags 0. Trace with +quartz, Proton 11.0 (wine-11.0), ASF Reader registered as the source filter for the ASF media type: multimedia_stream_AddMediaStream ... id {a35ff56a-...} (MSPID_PrimaryVideo), flags 0 multimedia_stream_AddMediaStream ... id {a35ff56b-...} (MSPID_PrimaryAudio), flags 0x1 dsound_render_create Created DirectSound renderer 001D5218. multimedia_stream_OpenFile (001D0780/001D0780)->(L".\\MOVIE\\ASCARON.WMV",0) FilterGraph2_AddSourceFilter Using source filter {187463a0-5bb7-11d3-acbe-0080c75e246e}. asf_reader_get_pin iface 001D56B0, index 0. asf_reader_get_pin iface 001D56B0, index 1. asf_reader_get_pin iface 001D56B0, index 2. pin_QueryDirection pin 001D5850 L"Source":L"Raw Video 0", dir 02292C44. FilterGraph2_RenderEx graph 001D4FD0, source 001D5850, flags 0x1, context 00000000. ... source_Connect pin 001D5850 L"Source":L"Raw Video 0", peer 001D53D0, mt 00000000. The reader exposes two output pins, "Raw Video 0" and "Raw Audio 1". RenderEx() is called exactly once, for "Raw Video 0". "Raw Audio 1" is never rendered, and the DirectSound renderer that amstream itself created a few lines earlier stays unconnected. Result: the cutscenes play with picture and no sound at all. Measurements ------------ Captured from the PipeWire monitor of the output sink with parec, analysed with ffmpeg -af volumedetect, system volume 100%, not muted. Intro.wmv (WMA2, 44100 Hz, stereo, 128 kbit/s; WMV3 video, 640x480): while the cutscene plays, ASF Reader as source filter: mean -91.0 dB, max -91.0 dB (digital silence) main menu music for reference (played by the game's own Miles engine, not through DirectShow): mean -36.3 dB, max -23.7 dB So the silence is specific to the DirectShow path, and the audio device is fine. Second symptom: hang on aborting playback ----------------------------------------- Pressing Escape during a cutscene tears the graph down while it is running. The game window disappears, the process stays alive and one thread spins at 100% CPU forever: wmvcore/winegstreamer loops in wg_parser_get_next_read_offset() on the same offset and never leaves. When a cutscene is allowed to finish normally the loop does terminate ("Reader is shutting down; exiting"); on an abort it does not. The same happens when quitting the game from the main menu after a cutscene has been played. Both symptoms have the same origin: the WM ASF reader (qasf + wmvcore) being in the graph at all. There is no bugzilla entry mentioning wg_parser_get_next_read_offset. Confirmation that this is the right place ----------------------------------------- Switching the source filter for the ASF media type away from the ASF reader, in the prefix registry: HKCR\Media Type\{e436eb83-524f-11ce-9f53-0020af0ba770}\{6b6d0801-9ada-11d0-a520-00a0d10129c0} "Source Filter" = {187463a0-5bb7-11d3-acbe-0080c75e246e} (WM ASF Reader) -> {e436ebb5-524f-11ce-9f53-0020af0ba770} (File Source (Async.)) makes File Source (Async.) the source. It has a single output pin, so amstream's single-pin walk happens to be enough; quartz then autoplugs the GStreamer splitter filter {F9D8D64E-A144-47DC-8EE0-F53498372C29}, and because the splitter is an *inserted* filter, quartz does render both of its output pins recursively. cutscene audio after the change: mean -29.6 dB, max -14.1 dB (8 s window) mean -22.0 dB, max -0.4 dB (whole 143 s cutscene) Escape during a cutscene: returns to the main menu, CPU back to ~19% quitting the game: exits cleanly Picture, resolution and the game's own audio are unaffected either way. This is exactly the workaround that was applied upstream for bug 53748 (same game, same symptom): commit 409d0f4247ea reverted the ASF media type registration in dlls/qasf "so that the File Source filter is preferred instead". That hides the amstream defect but does not fix it -- any environment where the ASF reader is registered as the ASF source filter, as in the Proton prefix here, walks straight back into it, and any future attempt to enable the ASF reader upstream will too. Correct fix ----------- OpenFile() should render every output pin of the source filter, not just the first. A patch is attached. It walks the enumerator, renders each output pin, keeps the first output pin in This->ipin for multimedia_stream_Render(), and reports success when at least one pin could be rendered. It also fixes three smaller issues in the same block: IEnumPins_Next() returning S_FALSE passing SUCCEEDED() and leaving ipin uninitialised, the leaked reference when the first pin is an input pin, and This->ipin being overwritten without releasing the previous reference. The patch applies cleanly to master (11.15) and to 11.0. Wine was built with it (--enable-archs=x86_64) and dlls/amstream's test suite passes, with and without the patch, so it causes no regression. I have not run the patched build against the game itself: the build is 64-bit only and sacred.exe is 32-bit. The evidence that this is the right place is the registry experiment above, not the patched build. There is currently no test coverage for a multi-pin source: test_openfile() and test_mmstream_get_duration() in dlls/amstream/tests/amstream.c both load test.avi through the async reader, and struct testfilter has a single strmbase_source. A test is cheap to add using the existing mock graph in the same file -- graph_AddSourceFilter() and graph_RenderEx() are currently ok(0, "Unexpected call.\n") stubs; making the former return a two-output-pin filter and counting calls to the latter fails with 1 instead of 2 before the patch. That stays valid on Windows, since it only observes how many times amstream calls RenderEx(). Related bugs ------------ 53748 - same game, same symptom, closed by the qasf revert rather than fixed 39597 - open; its last comment already quotes the offending RenderEx() call 25329 - open umbrella bug about WM ASF Reader being needed for .wmv intros 51324 - the one previous real fix to this function (AMMSF_RENDERALLSTREAMS, Wine 6.12) Steps to reproduce ------------------ 1. Install Sacred Gold (Steam appid 12320, or the GOG build). 2. In the prefix registry, make sure the source filter for the ASF media type is the WM ASF reader (this is the case in a Proton 11.0 prefix out of the box): HKCR\Media Type\{e436eb83-524f-11ce-9f53-0020af0ba770} \{6b6d0801-9ada-11d0-a520-00a0d10129c0} "Source Filter" = {187463a0-5bb7-11d3-acbe-0080c75e246e} 3. Start the game with WINEDEBUG=+quartz. 4. The opening cutscene plays with picture and no sound. 5. In the trace, FilterGraph2_RenderEx appears exactly once, for the pin named "Raw Video 0"; the pin "Raw Audio 1" is never rendered. 6. Press Escape during a cutscene: the window disappears and the process spins at 100% CPU indefinitely. -- 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 21

[Bug 58313] New: Reader Rabbit Kindergarten randomly crashes
by WineHQ Bugzilla Sept. 14, 2026

Sept. 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=58313 Bug ID: 58313 Summary: Reader Rabbit Kindergarten randomly crashes Product: Wine Version: 10.9 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexhenrie24(a)gmail.com Distribution: --- Created attachment 78670 --> http://bugs.winehq.org/attachment.cgi?id=78670 Backtrace Steps to reproduce: 1. Mount "RR Kindergarten.iso" 2. Run `wine 'D:\Setup.exe'` 3. Run `WINEDEBUG=+relay wine 'C:\Program Files (x86)\The Learning Company\Reader Rabbit Kindergarten\rrk32.exe' 2>&1 | tail` 4. Enter and leave areas of the game repeatedly. For example, I tested by clicking "Dinner Lineup", repairing the stairs, talking to the French raccoon chef, going back to the main area, then going back to the raccoon chef over and over. WINEDEBUG=+relay is not strictly necessary to reproduce the crash, but it makes it happen much more frequently provided that the output is piped to a program or to a file other than /dev/null. A backtrace is attached. It shows an exception in mfc42.dll. $ sha256sum Reader-Rabbit-s-Kindergarten_Win_EN_ISO-Version.zip 2e7a5d3e3ec7d2afc08b21d9cecca5632c6ba494671fa1b70186e9567ec882ed $ sha256sum 'RR Kindergarten.iso' b6ab5770a058f16f1a30c3a4e7cde8255c083190cbee4715880fcf4e8842bb91 https://d2.myabandonware.com/t/3a78bf1b-d002-4991-bcb1-781ec6530524/Reader-… -- 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 58084] New: Commit d813ffc3 (ntdll: Align virtual memory allocations to the host page size) breaks Wine in a Rosetta emulated Docker environment
by WineHQ Bugzilla Sept. 13, 2026

Sept. 13, 2026

http://bugs.winehq.org/show_bug.cgi?id=58084 Bug ID: 58084 Summary: Commit d813ffc3 (ntdll: Align virtual memory allocations to the host page size) breaks Wine in a Rosetta emulated Docker environment Product: Wine Version: 10.5 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: alex(a)willner.ws **Version:** 10.5 and 10.4 **Steps that will reproduce the problem:** On an arm64 M2 run macOS 15.4 (24E248) and execute with Docker version 28.0.4 (b8034c0): docker run --platform linux/amd64 --rm scottyhardy/docker-wine:devel-10.4 sh -c 'wine --version && winecfg' **What is the expected result:** > % docker run --platform linux/amd64 --rm scottyhardy/docker-wine:devel-10.5 sh -c 'wine --version && winecfg' > wine-10.5 > wine: created the configuration directory > ... **What happens instead:** > wine-10.5 > wine: dlls/ntdll/unix/virtual.c:253: anon_mmap_fixed: Assertion `!((UINT_PTR)start & host_page_mask)' failed. > qemu: uncaught target signal 6 (Aborted) - core dumped > Aborted **Possible workaround:** Downgrade to Wine 10.4: > % docker run --platform linux/amd64 --rm scottyhardy/docker-wine:devel-10.4 sh -c 'wine --version && winecfg' > wine-10.4 > wine: created the configuration directory > ... *Any additional information:** See Commit d813ffc3: ntdll: Align virtual memory allocations to the host page size. https://gitlab.winehq.org/wine/wine/-/commit/d813ffc3557083fd135a28d59f490b… -- 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 13

[Bug 58946] New: Homebrew packages deprecated; will be disabled Q3 2026
by WineHQ Bugzilla Sept. 12, 2026

Sept. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=58946 Bug ID: 58946 Summary: Homebrew packages deprecated; will be disabled Q3 2026 Product: Packaging Version: unspecified Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs(a)list.winehq.org Reporter: keener_muffles_83(a)icloud.com CC: dimesio(a)earthlink.net Created attachment 79641 --> http://bugs.winehq.org/attachment.cgi?id=79641 Full output of `brew info wine-stable` The wine packages on Homebrew (`wine-stable`, `wine(a)devel`, `wine(a)staging`) are currently deprecated, and will be disabled in the future. The exact message provided by `brew info` is "Deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01." The dependency `gstreamer-runtime` also has this issue with the same message, though I do not know if or how this is related. -- 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 3