All unicode API functions are supposed to support paths longer than `MAX_PATH` if prepended with the extended-path prefix `\\?\`. As of writing this function in particular doesn't.
This is causing problems with Unreal Engine shader preprocessing when running under Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8285
--
v2: kerberos: When requested confidentiality InitializeSecurityContext() should also add integrity.
kerberos: EncryptMessage() should fail if context doesn't support confidentiality.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8272
On Wed Jun 11 01:09:53 2025 +0000, Elizabeth Figura wrote:
> But the patch is going to be edited before committing anyway, whether
> the generated changes are included or not, so I don't see the issue?
The generated files will be updated on commit, but if there's a conflict the MR won't apply cleanly. And in general I refrain from merging MRs that cause conflicts because that makes it too easy to screw something up.
So not including generated files is not a requirement, but it increases the chances that the MR can go in smoothly.
Of course it also depends on the file, conflicts are not very likely with `include/Makefile.in`, but are pretty much guaranteed with `ntsyscalls.h` or `server_protocol.h`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8244#note_106208
Now that is passed as environment block variable. Which generally works but not very well.
Fixes environment variables being stripped of in games started by FunCom launcher.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8276
This fixes a looping audio issue during seek in VRChat. The issue is that on Windows the stop request in handled immediately thus the AVPro MFT (which loops the audio) can be immediately flushed. Wine currently waits for a pending sample request to be completed before handling the stop request. As a result, the AVPro MFT loops audio whilst it waits for another sample (or to be flushed).
This MR releases the source CS before calling `wg_parser_stream_get_buffer` so it does not delay the handling of the stop request. This appears to be safe as the Unix side of `wg_parser_stream_get_buffer` has its own set of primitives.
--
v3: winegstreamer: Don't hold lock during wg_parser_stream_get_buffer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8282
NdrClientCall() should only be used in 32-bit mode when
Oi or Oic stub optimizations are used. Currently our interpreted
mode targets Oicf mode and other levels are not supported.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v4: include: Add errlup.idl.
widl: Do not write "const" modifiers for _PARAM_STRUCT fields.
widl: Always use NdrClientCall2() for interpreted stubs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8195
This fixes a looping audio issue during seek in VRChat. The issue is that on Windows the stop request in handled immediately thus the AVPro MFT (which loops the audio) can be immediately flushed. Wine currently waits for a pending sample request to be completed before handling the stop request. As a result, the AVPro MFT loops audio whilst it waits for another sample (or to be flushed).
This MR releases the source CS before calling `wg_parser_stream_get_buffer` so it does not delay the handling of the stop request. This appears to be safe as the Unix side of `wg_parser_stream_get_buffer` has its own set of primitives.
--
v2: winegstreamer: Don't hold lock during wg_parser_stream_get_buffer.
winegstreamer: Signal eos on disconnect.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8282
This fixes a looping audio issue during seek in VRChat. The issue is that on Windows the stop request in handled immediately thus the AVPro MFT (which loops the audio) can be immediately flushed. Wine currently waits for a pending sample request to be completed before handling the stop request. As a result, the AVPro MFT loops audio whilst it waits for another sample (or to be flushed).
This MR releases the source CS before calling `wg_parser_stream_get_buffer` so it does not delay the handling of the stop request. This appears to be safe as the Unix side of `wg_parser_stream_get_buffer` has its own set of primitives.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8282
On Tue Jun 10 23:46:26 2025 +0000, Jinoh Kang wrote:
> Thanks for your insight. I understand, but IMHO it's a good idea not to
> include generated files since they introduce unnecessary merge conflicts.
> For example, adding a new syscall results in about half of
> `dlls/ntdll/ntsyscalls.h` to be rewritten. MRs that (1) add a syscall,
> and (2) include generated files will surely conflict each other.
But the patch is going to be edited before committing anyway, whether the generated changes are included or not, so I don't see the issue?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8244#note_106184
On Tue Jun 10 18:39:40 2025 +0000, Elizabeth Figura wrote:
> Where did this advice come from exactly? I've never heard Alexandre
> request that people not include generated files, only that it's not
> necessary, and I've seen plenty of patches accepted with generated
> changes. As far as I can tell "it's not necessary" got somehow warped
> into "you shouldn't" and then spread as common knowledge.
Thanks for your insight. I understand, but IMHO it's a good idea not to include generated files since they introduce unnecessary merge conflicts.
For example, adding a new syscall results in about half of `dlls/ntdll/ntsyscalls.h` to be rewritten. MRs that (1) add a syscall, and (2) include generated files will surely conflict each other.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8244#note_106172
Currently xdg_toplevel_config size hints are ignored if the config has state 0
to avoid spurrious re-sizing. However, if the window is currently configured
with a non-zero state, e.g. it is in fullscreen, then such an event from the
compositor indicates a switch to a floating window, in which case the size
hint should be respected.
Additionally, the check for whether the current size of a fullscreen window is compatible
with the compositor requested size would always return true regardless of size. Reading the
comments for `wayland_surface_config_is_compatible`, it seems that behavior is intended in
the other places the function is used, so that call was replaced with a simple size
comparison.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8279