On Thu May 22 12:32:42 2025 +0000, Hans Leidekker wrote:
> They don't pass a SECBUFFER_STREAM buffer in that sample.
I was mentioning the part about using SECBUFFER_STREAM in DecryptMessage(). It was my guess that EncryptMessage() is supposed to support the mirroring logic of using SECBUFFER_DATA as input and SECBUFFER_STREAM as output buffers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104207
On Thu May 22 11:10:27 2025 +0000, Dmitry Timoshkov wrote:
> Why not? EncryptMessage() would get SECBUFFER_DATA as input and
> SECBUFFER_STREAM as output buffers.
They don't pass a SECBUFFER_STREAM buffer in that sample.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104206
On Thu May 22 11:10:27 2025 +0000, Hans Leidekker wrote:
> Yes, I had seen that. Note that it wouldn't make the issue of buffer
> layout
> differences between NTLM and Kerberos go away for EncryptMessage().
Why not? EncryptMessage() would get SECBUFFER_DATA as input and SECBUFFER_STREAM as output buffers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8020#note_104199
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
--
v2: 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
In CopyFileEx, and DeleteFile functions, by default, the file name
and path are limited to MAX_PATH characters. To extend this limit
to 32,767 wide characters, need prepend "\\\\?\\" to the path.
--
v8: kernelbase: Limit the maximum path length for DeleteFile.
kernelbase: Fix DeleteFileA doesn't support long path.
kernelbase: Limit the maximum path length for filesystem.
ntdll: Check if long path aware is enabled.
kernel32/tests: Add tests for maximum path length limitation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7540