The BURIKO visual novel engine (as seen in, for example, https://store.steampowered.com/app/1200720/MakingLovers/) demands that the upstream filter tries to connect with a MPEG format type.
Then it memorizes the resolution, rejects the connection, and expects upstream to try RGB32 or RGB24 instead.
It also passes an empty string as filename, and demands this exact error code.
I have no idea why.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56491
--
v6: quartz: Fix memory leak on failure path.
quartz/tests: Test the new error codes.
quartz: Fix error code on empty filename.
quartz/tests: Test that compressed formats are offered for MPEGs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5419
The BURIKO visual novel engine (as seen in, for example, https://store.steampowered.com/app/1200720/MakingLovers/) demands that the upstream filter tries to connect with a MPEG format type.
Then it memorizes the resolution, rejects the connection, and expects upstream to try RGB32 or RGB24 instead.
It also passes an empty string as filename, and demands this exact error code.
I have no idea why.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56491
--
v5: quartz: Fix memory leak on failure path.
quartz/tests: Test the new error codes.
quartz: Fix error code on empty filename.
quartz/tests: Test that compressed formats are offered for MPEGs.
winegstreamer: Reduce CLSID_decodebin_parser merit, so the MPEG splitter is chosen instead for MPEGs.
winegstreamer: Delete now-meaningless wg_parser_type enum.
winegstreamer: Use decodebin instead of wavparse.
winegstreamer: Create decodebin instead of avidemux.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5419
Not sure if this is stalled because it's not convincing enough, but if it helps, the debugger check is not merely conjecture. Disassembly around the crashing site is:
```
4d97fd: 68 e8 13 19 01 pushl $0x11913e8
4d9802: e8 c9 98 51 00 call 9f30d0
4d9807: 83 c4 04 add $0x4, %esp
4d980a: a0 90 01 00 00 mov 0x190, %al
```
where 0x11913e8 points to a string "Causing exception to test for debugger..", and 0x9f30d0 is presumably some sort of logging function.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5437#note_67064
On Sat Mar 23 08:48:29 2024 +0000, Rémi Bernon wrote:
> It's perhaps instead that approval only show up if the person is
> assigned as a reviewer, or that it was overlooked.
Any plans to merge this? It missed the Wine release.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5178#note_67063
This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam).
The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that:
1. That *should* be an anomalous case, such as the app hanging on exit.
2. Effectively the same behavior would happen on Windows.
I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns.
--
v4: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5188