Adding support for interfaces implies adding support for function descriptions,
so the patch is a bit large. I didn't manage to create an .idl with a function
outside of an interface, so I couldn't test it separately.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5458
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.
--
v6: 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
On Sun Apr 7 09:32:45 2024 +0000, Sam Joan Roque-Worcel wrote:
> Hmm I thought the tests I was getting were flakey, but it seems that my
> changes here are causing failing tests. I may ask in IRC if anyone can
> think of a better approach.
I don't see why adding them only to a new MS Gothic font stub with only 3 symbol wouldn't work?
If peoples add the real MS Gothic everything should work fine, there is no reason for it to not work.
Especially since most peoples use `winetricks` and it's already used to override existing stub fonts.
Adding to Tahoma seems fine as a workaround because Tahoma doesn't have those, but upstream isn't a fan of MR that push wine away from Win32 like behavior, so it may delay this being merged.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5447#note_67258
I don't know how much this test actually shows. Device manager is provided by the sink. Topology loader then is documented to set this device manager to the transforms on the video branch. There is MF_TOPOLOGY_DXVA_MODE attribute that supposedly controls that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5464#note_67239
Otherwise pipelines fail to resolve when media source outputs compressed samples and applications have inserted optional effects (such as VRChat with AVPro player).
Note that the topology loader doesn't currently support MF_CONNECT_AS_OPTIONAL, although the connection succeeds in the the cases I've seen.
--
v2: mfmediaengine: Allow decoder / converter to be resolved between topology nodes.
mfmediaengine/tests: Test that effects allow converters between them.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5460
Starting with late Windows 10 version, in ucrtbase, stderr is now unbuffered
whatever the type of the underlying fd (previously, native only set it to
unbuffered when attached to character fd (console, NUL...)).
This serie adds also tests for msvcrt & ucrtbase to show the discrepancies.
Note: ucrtbase's tests also include a reversed engineered structure layout
for FILE.
_get_stream_buffer_pointers already gives base, ptr and cnt, and toying with
setvbuf gave easily the rest of the fields.
Didn't spend time in guessing the flags meaning: which look different
from msvcrt's.
Related to https://bugs.winehq.org/show_bug.cgi?id=56459
@piotr: I can share the details (the access to the test result in the bug
report is limited).
--
v2: msvcrt: Let stderr be always be unbuffered.
ucrtbase/tests: Add tests for checking buffering state of standard streams.
msvcrt/tests: Add tests for check buffering state of standard streams.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5462
On Thu Apr 4 03:18:16 2024 +0000, Sam Joan Roque-Worcel wrote:
> Correct! In Windows, these are missing in Tahoma, but are present in MS Gothic.
> Things I considered doing:
> - I attempted to find a suitable, metric-compatible font capable of
> replacing MS Gothic but it is very particular, and nothing fits the bill
> - I thought about creating a metric compatible font, but I'm not sure
> that this approach would be the best as it is very time consuming.
> - I thought about creating a bare-bones font and shipping it with Wine,
> which contains only these three glyphs. This would potentially break
> Wine for users who have installed Microsoft's font, depending of the
> order of precedence in font loading (I'm not sure about this one)
> So as a workaround, I added them to Tahoma which doesn't have any of
> those disadvantages. If you can suggest a better approach though please
> let me know and I will look into it.
Hmm I thought the tests I was getting were flakey, but it seems that my changes here are causing failing tests. I may ask in IRC if anyone can think of a better approach.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5447#note_67123
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
Starting with late Windows 10 version, in ucrtbase, stderr is now unbuffered
whatever the type of the underlying fd (previously, native only set it to
unbuffered when attached to character fd (console, NUL...)).
This serie adds also tests for msvcrt & ucrtbase to show the discrepancies.
Note: ucrtbase's tests also include a reversed engineered structure layout
for FILE.
_get_stream_buffer_pointers already gives base, ptr and cnt, and toying with
setvbuf gave easily the rest of the fields.
Didn't spend time in guessing the flags meaning: which look different
from msvcrt's.
Related to https://bugs.winehq.org/show_bug.cgi?id=56459
@piotr: I can share the details (the access to the test result in the bug
report is limited).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5462
When using a video sample allocator, the session will allocate samples from it, then try to get some output from a transform, and if there's no output to be pulled, release the sample immediately. This will trigger the sample allocator notify callback, which will then trigger another try at pulling samples, ending up in a callback loop that can starve other working threads.
Another option here would be to keep the last returned status, and only re-try to pull samples from the allocator notify callback if we previously failed to process output because of a failed allocation.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5296
This fixes a latency issue with audio, particular when played with 4k
video.
With a single queue, only one sample request can be processed at a
time. So, for example, if a video sample takes 40ms to be delivered,
then all pending audio samples will be delayed 40ms. This can lead to
the audio PTS lagging the presentation clock and being dropped.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5439
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
--
v4: quartz: Fix memory leak on failure path.
quartz/tests: Test the new error codes.
quartz: Fix error code on empty filename.
quartz/tests: Test the new compressed output support.
quartz: Permit compressed output from CLSID_decodebin_parser.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5419
Don't use old typelib in do_everything cases. This is a regression from 0bffa3222611015a3b3596c679be53c557daae1b.
--
v2: widl: Don't use old typelib format in do_everything mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5461
Otherwise pipelines fail to resolve when media source outputs compressed samples and applications have inserted optional effects (such as VRChat with AVPro player).
Note that the topology loader doesn't currently support MF_CONNECT_AS_OPTIONAL, although the connection succeeds in the the cases I've seen.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5460
--
v2: mfreadwrite/reader: Pass the device manager to the stream transforms.
winegstreamer/video_processor: Implement D3D awareness.
mf/tests: Test video processor D3D11 awareness.
mfreadwrite/tests: Add some source reader D3D11 awareness tests.
mfreadwrite/tests: Avoid using MFCreateMediaBufferFromMediaType.
mfreadwrite/tests: Do not accept MFVideoFormat_RGB32 in the test transform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5459