This MR fixes seek in VRChat by copying the sequence of flushes/stop/starts that Windows does.
The order on Windows is:
1. Stop sources;
2. Flush MFTs;
3. Start sources;
4. Request output down the chain of sink inputs;
6. Flush sinks; and
7. Start the clock
This takes place whether we pause before we seek or seek without pause.
Changes in version 2:
1. Add test to see when SAR requests new samples;
2. Add test to examine when step 4 from above takes place;
3. Adjust the seek implementation in `mf/session.c` to match findings from the new tests;
4. Adjust `mfmediaengine` to reflect findings from the new tests;
5. Refactored `if` statement in `session_start` to be a `switch` again
--
v7: mfmediaengine: Request sample if we are seeking.
mfmediaengine: Don't perform implicit flush on state change.
mf: Don't send MFT_MESSAGE_NOTIFY_START_OF_STREAM when seeking.
mf: Restart transforms and sinks on seek.
mf/tests: Test sequence of calls during a Pause and Seek.
mf/tests: Test when SAR requests a new sample.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7932
> So that versioned window classes gets registered as well. Otherwise, comctl32 v6 fails to register
> its window classes when comctl32 v5 classes are still being used. This can happen, for example, when
> creating a window using comctl32 v5, then unload comctl32 v5 and not destroying the window, and then
> load comctl32 v6.
Is this still true? This shouldn't happen if things are working correctly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110509
On Mon Jul 21 08:04:25 2025 +0000, Zhiyi Zhang wrote:
> > Is there an embedded manifest in comctl32.dll from system32?
> No. The manifest seems to be from somewhere else. Anyway, I think it's
> clearer that the manifest is for comctl32 v6 this way.
It's a change that we don't need, that's my point.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110508
The glyphs are based on BitstreamVeraSans-Bold.
The glyphs in WineTahomaBold are not truely bold, this font is just a copy of WineTahoma.
If this patch is acceptable, I'm planning to make more glyphs bold, including at least all ASCII characters.
--
v2: fonts: Make numbers bold for WineTahomaBold.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8533
> it doesn't matter if our v5 has manifest or not. I think we don't have to care about that at this point.
Yeah. We don't need to care about whether comctl32 v5 has a manifest or not at this point. The problem with this part of the code is that comctl32 v6 doesn't get some of its window class version from its manifest without this change.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110490
On Mon Jul 21 08:03:29 2025 +0000, Nikolay Sivov wrote:
> Another way would be to extend this builtin signature check to
> optionally include installed module name instead of assuming it's the
> same as a filename, so that we can specify comctl32_v6.dll there and
> build everything as builtin. I don't know if it's easy, because it
> requires variable length data.
It will be a lot more work. First, we need to pack variable-length data into e_lfanew for every DLL/EXE(output_pe_file(),output_module16, etc). Then we need to change this signature parsing to support variable-length data(winedump, dbghelp, build_module() in NTDLL, ntdll DLL loader, setupapi fakedll support). There will probably be alignment issues to be handled. Also, increasing e_lfanew might increase the chance of anti-virus software misdetecting wine DLLs as malware. Overall, I don't think it's worth it to extend the built-in signature check for this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110489