Let the sub-process be created, without implementing any additional
behavior from these flags.
Native cmd.exe uses this flag when spawning itself again for handling
builtin commands inside a pipe.
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6764
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v11: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
This has been tested with VRChat in Proton, and with one change to `IMFMediaEngine` and some small changes to winegstreamer it is able to play YouTube videos in Unity video player based players. The AVPro based players have many more issues, because that API uses YouTube's HLS files instead of the direct MP4 links, and new media source would need many fixes to be able to play HLS correctly. Which it isn't supposed to do anyway since that's the `IMFMediaEngine`'s job.
There are some things that I did not implement:
- `IMFByteStreamBuffering::SetBufferingParams`, the parameters don't have any obvious effect on the functionality of the byte stream or the HTTP requests it makes. It's probably not used by anything anyway.
- How much data has to be pre-buffered before it considers buffering to be complete and sends `MEBufferingStopped`. I didn't put much time into this and just chose 64 KiB.
- Persistent caching of downloaded data; Native seems to be able to omit redownloading data it has previously downloaded before by using the `If-Modified-Since` header. This seems like more work and unnecessary complexity than it's worth.
- Mapping of all the WinHTTP errors to HRESULTs; HTTP status codes are handled, as well as the most common `ERROR_WINHTTP_*` values, but anything else just goes through `HRESULT_FROM_WIN32`. I don't even know how to trigger most of the WinHTTP errors; It's probably fine, the most important info is just that there has been an error anyway.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6733
FWIW, as far as I'm concerned, this or a similar patch should probably still be merged, to fix the wow64 stub. It basically just comes down to the approach to fix it. If anyone gets a chance to look at this let me know.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6584#note_86467
This fixes one of the regression with ShellExecute when using a full patch and an executable without an extension.
--
v4: shell32: Allow FindExecutables to find unix files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6285
On Sat Nov 2 08:52:23 2024 +0000, Zhiyi Zhang wrote:
> This `else` branch should never get executed because only the
> test_WM_NOTIFY() test sends a WM_NOTIFY with TEST_WM_NOTIFY_CODE. So you
> can delete this branch.
`else` branch will be executed if WM_NOTIFY message gets forwarded twice by buggy non-test code
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86464