> moreover it means that we'd want two different behaviors when receiving SIGINT (whether it's a genuine unix signal or one sent by the server if we follow the tests result above) perhaps, the solution would be in the default_ctrl_handler to only terminate the program if attached to a console, or in the program group of a unix console
One way or another, terminating GUI process in response to Unix SIGINT is a Wine thing, it's not something we can express in Windows terms. If kernelbase part is not suitable, maybe we may just terminate process from ntdll when we're not connected to console. We know that in this case the signal originated from the host.
> remark: Wine unix console is the sole case where launching a GUI program from command line doesn't return immediately to prompt (native & builtin cmd implementation only wait on CUI programs completion). But that's conform to unix behavior.
I'm not sure what exactly you mean by conforming to unix behavior, but it's arguably a bug that will cause problems similar to !3145, under different conditions. I'd rather avoid depending on this behavior in the solution for SIGINT if possible.
> note: I'm not even sure tweeking with setsid whould be useful as anyway the unix console is in raw mode, so only conhost regenerates the signals
It's in raw mode only if a console application reads input. In this case, taking more control by conhost seems justified.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312#note_40761
This get us pass the "Update your browser" blocker in adobe's sign-in page. The page itself doesn't make use of `window.MutationObserver`.
However the sign-in page is still broken.
--
v24: mshtml: add stubs for MutationObserver methods
mshtml: implement window.MutationObserver with MutationObserver stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/3391
By default, synchronously completed socket operations will still send completions, we currently don't mind that in winhttp. The most essential part is patch 1, which will also avoid stacking those completions. Patch 2 is not strictly necessary since now we indeed shouldn't be getting unexpected completions, but it seems to me it is better not to fully rely on that and skip unexpected ones just in case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3446
Some applications (e.g. UE4) requires
the DriverVersion string in the registry.
The string is taken from `dlls/wbemprox/builtin.c`
--
v6: win32u: Add DriverVersion string for GPUs to registry.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3104
Some applications (e.g. UE4) requires
the DriverVersion string in the registry.
The string is taken from `dlls/wbemprox/builtin.c`
--
v5: win32u: Add DriverVersion string for GPUs to registry
https://gitlab.winehq.org/wine/wine/-/merge_requests/3104
Let The Good Life able to play its intro video, the game creates a source reader from a `http://localhost:6000/<random-hash>` URL. This should also probably work with other games playing streams over http(s).
This is a very basic implementation, using urlmon, and it will download the entire stream to a local temporary file before playback. An more optimized implementation would probably use WinHttp and range requests to partially download the requested stream segments, but this can be implemented in a future change.
--
v2: mfreadwrite: Allow URL source resolution to not match extension or mime type.
mf/scheme_handler: Implement http(s):// scheme handler using urlmon.
mf/scheme_handler: Split file scheme handler to scheme_handler.c.
mfplat: Support MF_BYTESTREAM_EFFECTIVE_URL attribute.
mf/tests: Add some network scheme resolver tests.
include: Add MF_BYTESTREAM_EFFECTIVE_URL GUID declaration.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3439