Windows 11 uses a narrow non-breaking space instead of a plain one when formatting numbers. This is probably more correct and maybe Wine should switch too. But marking the old result as broken() would require unbundling expect_wstr() which would be bothersome.
So this commit just accepts both.
--
v3: kernel32/tests: Fix the French GetNumberFormatEx() test on Windows 11.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2288
There are some minor style and formatting issues in this series that I'm going to ignore for the moment. The test either doesn't test the changes in patch 2/2, or it fails before that patch.
The larger issue with this series though is that it doesn't seem quite ideal to potentially set and restore the stream source frequency on each DrawPrimitive()/DrawPrimitiveUP() call, because of the resulting state invalidation. It may be time to move the d3d9-style instance count handling out of wined3d and track that entirely in d3d9.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2282#note_25548
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v10: winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v9: winspool: Check the alignment of dmSize in IsValidDevmodeW()
winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
Signed-off-by: Fan WenJie <fanwj(a)mail.ustc.edu.cn>
calling unix funcions from PE must via unix_call, Because must switch fs register vaule and other context on wow64 mode. Currently calling some unix functions of win32u via function pointers. The patch modify the way of calling unix functions of win32u by unix_call
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2291
Windows 11 uses a narrow non-breaking space instead of a plain one when formatting numbers. This is probably more correct and maybe Wine should switch too. But marking the old result as broken() would require unbundling expect_wstr() which would be bothersome.
So this commit just accepts both.
--
v2: kernel32:locale: Fix the French GetNumberFormatEx() test on Windows 11.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2288
This serie:
- fixes a couple of tests failures on Windows 11 (Note: there are still
other issues under Windows 11, mostly addressed by MR!2252)
- introduce a couple of helpers to simplify current and yet to come
test code
- improves some existing tests
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2285
based on libpcsclite1 \
rework of [original code by Mounir IDRASSI](https://sourceforge.net/projects/scard4wine/) to use unixlib interface
First step to resolve \
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=39113 \
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=37495 \
It will probably also require the implementation of scarddlg.
In order for the tests to work fully in a virtual environment without the appropriate hardware,
I suggest using the project https://github.com/Jakuje/virt_cacard
Example for setting up a build server (It is supposed to be Debian):
```
apt-get install -y pcscd vsmartcard-vpcd libpcsclite1 libpcsclite-dev libcacard-dev libsofthsm2 libnss3-tools gnutls-bin opensc
service pcscd restart
git clone https://github.com/Jakuje/virt_cacard
cd virt_cacard
./autogen.sh && ./configure && make
./setup-softhsm2.sh
```
"Insert" smartcard before runing tests: \
`cd /path/to/virt_cacard && SOFTHSM2_CONF=softhsm2.conf ./virt_cacard &`
Partial test can be done if installed vsmartcard-vpcd (only test create/release context and list aviable card readers): \
```
apt-get install -y pcscd vsmartcard-vpcd
service pcscd restart
```
--
v3: winscard: fix discards 'const' qualifier
https://gitlab.winehq.org/wine/wine/-/merge_requests/2249
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v6: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v5: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v4: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v3: ntdll: Use IOPowerSources API to fill battery info on macOS
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
v2: Apply 1 suggestion(s) to 1 file(s)
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
The current implementation based on `IOPMCopyBatteryInfo` does not work (macOS 13.2, M2 Max, returns `kIOReturnUnsupported`) and is not recommended/supported by Apple:
> WARNING! IOPMCoyBatteryInfo is unsupported on ALL Intel CPU based systems. For PPC CPU based systems, it remains not recommended. For almost all purposes, developers should use the richer IOPowerSources API (with change notifications) instead of using IOPMCopyBatteryInfo. Keys to decipher IOPMCopyBatteryInfo's return CFArray exist in IOPM.h.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2283
wine-gecko does actually support synchronous XMLHttpRequests, even if they are deprecated, but unfortunately it is very broken compared to IE or all the other major browsers (more details [here](https://bugzilla.mozilla.org/show_bug.cgi?id=697151)). Thankfully, it still provides us with the event message loop, which is enough to fix it on mshtml side and act like IE.
For sync XHRs, send() is supposed to block all script code, except for notifications sent to the sync XHR. This is because when send() blocks, no other piece of code in the script should execute other than the sync XHR handlers. Unfortunately, that's not the case in Gecko's broken implementation, which can execute handlers as if they were APCs while it's "blocked" in send().
Note that it doesn't actually block, though, because we still process the message loop (non-event related tasks such as navigation, paints, and other stuff), and that's normal. Gecko doesn't block everything related to script events, only some things on the document and timers, but that's far from enough and not even enough for our purposes since we use our own timer tasks. And not even message events are blocked, even though we *also* use our own message event dispatchers (but it doesn't block Gecko ones either).
So what we have to do is we need to track all the timers and events dispatched that result in script handlers being executed, while "blocking" inside of a sync XHR send(), and queue them up to defer them to be dispatched later, after send() unblocks. But this is easier said that done. There are many corner cases to consider here, for example:
* Events dispatched *synchronously* from within a sync XHR handler or other piece of code called from it.
* Nested sync XHR send() calls (called during handler of another sync XHR).
* Async XHRs having their events dispatched during a blocking sync XHR send() are complicated. `readyStateChange` for example needs to have the async XHR's readyState at the time it was sent, **not** at the time it was actually dispatched, since we're going to delay it and dispatch it later. It's similar with other XHR states, such as responseText (which can be partial).
* Aborts of async XHRs during such handlers.
These patches hopefully should address all the issues and, on a high level, work like this:
* Track the `readyState` and `responseText` length manually, so we can override / force them to specific values.
* "Snapshot" the async XHR at the time we encounter an event for it, and queue this event with such information. When later dispatching this event (after being deferred), we temporarily set the state of the async XHR to the snapshot.
* To deal with nested event dispatches, keep track of a "dispatch depth" (everytime we dispatch an event we increase the depth, and when it returns we decrease it).
* For sync XHRs, we note the depth when send() is called, and defer events at that depth, since they're dispatched during the "blocked" message loop and need to be delayed (except for sync XHR events, which is a special case since it must be dispatched synchronously). When it returns, we restore the previous blocking depth.
--
v5: mshtml: Send all readystatechange events for synchronous XHRs in IE9
mshtml: Implement synchronous XMLHttpRequest.
mshtml: Add separate task list for tasks dispatching events.
mshtml: Track readyState in XHRs and report it manually.
mshtml: Register all event handlers when creating the XMLHttpRequest.
mshtml: Pass optional args to XMLHttpRequest.open() correctly.
mshtml: Free the task after the destructor.
mshtml: Use proper types for readystate_locked and readystate_pending.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2098
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v7: winspool: Check the alignment of dmSize in IsValidDevmodeW()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v6: winspool: Check the alignment of dmSize in IsValidDevmodeW()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v5: winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
Related bug report: #54405
The game engine (FVP) does compare GetGlyphOutlineA result with zero and checks GetLastError in that case. Maybe I'm missing something but I believe the last error shouldn't be set for "empty" characters. I don't know why it was omitted in tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2253
The idea here is to track the cursor changes on the server side, ultimately [1] using a private message to notify user drivers of changes to apply, instead of tracking the changes in user drivers with throttle mechanisms.
This would greatly simplify winex11 mouse message handling as we would not need to try syncing the window cursor on every mouse move, and ultimately it would also make it possible to have a single thread listening to input in the background. Currently the input thread needs to own the windows that are under the cursor to be able to set it.
Having a single input thread (per-process at least, but ideally and ultimately per-prefix), will solve several issues with input not being received when the foreground thread isn't actively checking their message, as well as issues with DInput incorrectly checking window messages when it should not.
[1] See https://gitlab.winehq.org/rbernon/wine/-/merge_requests/8/commits
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2038
This restores the feature we had with the testbot running related on intermediate commits, though it only does it on Linux and it would be nice to have it on Windows too.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1240
This adds a new Input tab to winecfg, moving the mouse grab settings there. Then this makes winex11 keyboard layout detection configurable as well, allowing the user to override the keyboard layout detection if for some reason it was incorrect.
This isn't solving anything yet, but I then intend to make keyboard scancode detection configurable as well, and optional.
As I described in https://www.winehq.org/pipermail/wine-devel/2020-October/175641.html, I believe that X11 keyboard keycode to scancode mapping is most of the time a fixed mapping, except in some rare cases.
Trying to detect it from the keyboard layout will never work reliably, especially nowadays where keyboard layouts are completely made up from Linux IME (for instance a GNOME language settings with up to four keyboard layouts translates to a single Xkb mapping using groups for each layout). The X11 keycode are remapped only in some more rarely used implementations, such as XVNC and we should try to detect it only in such cases.
Many Windows applications are depending on accurate scancodes, and making the mapping detection optional (and disabled by default) will solve all the issues we have in the most common case (https://bugs.winehq.org/show_bug.cgi?id=30984, https://bugs.winehq.org/show_bug.cgi?id=45605).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2062
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
v6: evr: Fix crash when clear input type for the mixer
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v4: winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
v5: evr: Fix crash when clear input type for the mixer
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
v4: evr: Fix crash when clear input type for the mixer
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v3: winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
v2: winspool: Check dmSize in IsValidDevmodeW
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
Public API for parsing and serialising DXBC blobs.
--
v3: vkd3d-shader/dxbc: Introduce API for serialising DXBC blobs.
vkd3d-shader/dxbc: Introduce API for parsing DXBC blobs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/103
--
v3: winegstreamer: Implement ProcessInput and ProcessOutput for WMV decoder DMO.
winegstreamer: Create wg_transform for WMV decoder.
winegstreamer: Better handle framerate.
winegstreamer: Add format field to wmv wg_format.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2258
When count = 0, returned value may become -1 which seems wrong in
the case of successful process_events() call. Also MSDN suggests
that `count` may be a valid return value in this case. When -1 is
returned, it may cause SetLastError to -1 as well which is not a
valid error code AFAIK.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54405
--
v2: wine32u: move count fixup out of MsgWaitForMultipleObjectsEx drivers
https://gitlab.winehq.org/wine/wine/-/merge_requests/2067
--
v2: msvcrt: Fix _wdupenv_s behavior with missing env var.
msvcrt: Fix _dupenv_s behavior with missing env var.
msvcr80/tests: Test _wdupenv_s outcome with missing env var.
msvcr80/tests: Test _dupenv_s outcome with missing env var.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2267
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
v3: evr: Fix crash when clear input type for the mixer
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
Public API for parsing and serialising DXBC blobs.
--
v2: vkd3d-shader/dxbc: Introduce API for serialising DXBC blobs.
vkd3d-shader/dxbc: Introduce API for parsing DXBC blobs.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/103
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
v2: evr: Fix crash when clear input type for the mixer
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
--
v2: winegstreamer: Implement ProcessInput and ProcessOutput for WMV decoder DMO.
winegstreamer: Create wg_transform for WMV decoder.
winegstreamer: Better handle framerate.
winegstreamer: Add format field to wmv wg_format.
winegstreamer: Implement wg_transform data read/write for DMO.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2258
When dmSize is zero or greter than size of input buffer, `IsValidDevmodeW()`
failed in Windows 10.
But current implementation in wine, it will return `true` because
there is no check to `dm.dmSize`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2262
--
v4: wined3d: Disable 64-bit integer support.
wined3d: Require shader cull distance support to create a feature level 10.0 device.
wined3d: Require shader clip distance support to create a feature level 10.0 device.
wined3d: Require gather offset support to create a feature level 11.0 device.
wined3d: Require fragment shader image stores and atomics to create a feature level 11.0 device.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2010
In the implementation of
[`evr_disconnect()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/evr.c#L325-333),
it will try to clear types of mixer by pass null to
`IMFTransform_SetInputType()`:
```c
static void evr_disconnect(struct strmbase_renderer *iface)
{
struct evr *filter = impl_from_strmbase_renderer(iface);
if (filter->mixer)
IMFTransform_SetInputType(filter->mixer, 0, NULL, 0);
evr_set_input_type(filter, NULL);
evr_release_services(filter);
}
```
This null ptr (`media_type`) will be pass to
[`video_mixer_collect_output_types()`](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c#L869)
and cause a [crash](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.2/dlls/evr/mixer.c…:
```c
static HRESULT WINAPI video_mixer_transform_SetInputType(IMFTransform *iface, DWORD id, IMFMediaType *media_type, DWORD flags)
{
...
if (!mixer->device_manager)
hr = MF_E_NOT_INITIALIZED;
else
{
if (SUCCEEDED(hr = video_mixer_get_processor_service(mixer, &service)))
{
if (SUCCEEDED(hr = video_mixer_init_dxva_videodesc(media_type, &video_desc)))
...
```
In this patch, `video_mixer_transform_SetInputType()` will only clear types when
got a NULL `media_type` and return `S_OK`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2263
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53176
1) The async test is broken on Windows 10 1507. This appears to be a trend among WinRT dlls. I'm thinking that we can add macro definitions for each testbot VM to avoid having to skip tests that would otherwise be working fine, and just greater control over tests in general.
2) The provider file that contains `interface IWineAsyncInfoImpl` is likely going to be reused again in the future. Perhaps a new file can be added in the include/wine folder to prevent duplicate code? I can do this in a separate merge request and cleanup the existing provider files.
3) All the check_bool_async tests return a random async_id so I skipped them. Testbot example: https://testbot.winehq.org/JobDetails.pl?Key=127232&f208=exe32.report#k208
--
v9: cryptowinrt/tests: Add IKeyCredentialManagerStatics::IsSupportedAsync() tests.
cryptowinrt: Implement IKeyCredentialManagerStatics::IsSupportedAsync().
cryptowinrt: Import IAsyncOperation from windows.gaming.input.
cryptowinrt: Stub IKeyCredentialManagerStatics interface.
cryptowinrt: Add private.h file.
cryptowinrt/tests: Add ICryptographicBufferStatics interface test.
include: Add windows.security.credentials.idl file.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1714
Normalise the incoming vkd3d_shader_instruction IR to the shader model 6 pattern where only one patch constant function is emitted. This allows generation of a single patch constant function in SPIR-V.
--
v12: vkd3d-shader/spirv: Declare the phase SPIR-V function in spirv_compiler_enter_shader_phase().
vkd3d-shader/spirv: Remove the hull shader phase array.
vkd3d-shader/trace: Trace the normalised instruction array after tracing the input.
vkd3d-shader/ir: Merge all shader IR fork and join phases into a single phase.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84