--
v2: winegstreamer: Output BGRx video from the media source.
winegstreamer: Move flipping based on RGB to the frontends.
winegstreamer: Translate the MF_MT_DEFAULT_STRIDE attribute to flipped video in mf_media_type_to_wg_format().
winegstreamer: Set the MF_MT_DEFAULT_STRIDE attribute in mf_media_type_from_wg_format().
winegstreamer: Initialize media source video types from a wg_video_format array.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2159
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v14: windows.media.speech: Implement Vosk create and release functions in the unixlib.
windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine.
windows.media.speech/tests: Get rid of duplicated hresult.
windows.media.speech: Add unixlib stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
Track ticks since draw start per window_surface, instead of per DC as is
currently the case. This change helps reduce visual glitches caused by
badly timed flushes when drawing to the same window_surface from
multiple DCs, e.g., child windows (see first commit), or in some special
scenarios when the window_surface is updated (see second commit).
(Much) more information about this issue and the rationale for the changes
can be found in the commit messages.
Note that since this is an inherently timing related issue, the visual glitches
depend on the application specific draw patterns, drawing speed (and thus
processor performance and load) etc.
Here is a capture which exhibits the issue with the current implementation:
[resizing-regedit-per-dc-ticks.mkv](/uploads/d7d30d009cc4db1337cbc3266df5ae17/resizing-regedit-per-dc-ticks.mkv)
And here is a capture of the same scenario with the proposed changes applied, which shows the improvement:
[resizing-regedit-per-surface-ticks.mkv](/uploads/6f878568862f5fb5157567341e4e452f/resizing-regedit-per-surface-ticks.mkv)
--
v2: win32u: Reset draw_start_ticks for new window_surface.
gdi32: Track ticks since draw start per window_surface.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2226
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.
--
v10: vkd3d-shader/normalise: Insert hull shader control point input declarations if no control point phase is defined.
vkd3d-shader/spirv: Delete an unnecessary call to spirv_compiler_get_register_id().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/84
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v13: windows.media.speech: Implement Vosk create and release functions in the unixlib.
windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine.
windows.media.speech/tests: Get rid of duplicated hresult.
windows.media.speech: Add unixlib stub.
windows.media.speech: Add Vosk checks to autoconf.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
This is what it looks like:
**v1**

**v2**

--
v5: winecfg: Add an option to enable WinRT app dark theme.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
There are two common ways I observe how games get monitor name to display:
1. Registry key under Enum/Display (also present in EnumDisplayDevicesA result for monitors). On Windows this key is derived from edid as 'Manufacturer ID' (3 letters) combined with "Manufacturer product code" (4 hex digits). We currently have 'Default_Display' there for all the displays;
2. DisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME). Windows sets friendlyNameFromEdid flag and returns a name from 'EDID Display Descriptor' with code 0xfc ("Display name"). As far as I could see by searching through the Windows registry this name doesn't seem to be explicitly present anywhere in registry (besides binary raw edid of course).
The first patch removes name from the gdi driver's display structure. Now none of the drivers set anything genuine there. x11 and winemac always end up with "Generic Non-Pnp Monitor" string, wineandroid sets NULL there and "Generic Non-Pnp Monitor" is set in win32u in this case. That "Generic Non-Pnp Monitor" goes to "DeviceDesc" registry value. While our value doesn't match Windows string exactly, Windows also doesn't have any meaningful name under DeviceDesc (and contains "Generic Non-Pnp Monitor" as a part of it). So this patch is essentially a no-op currently. Going forward my idea is that we just want to have edid from drivers. If the raw one is not available we can generate fallback one ourselves based on the info about the monitor we might have from elsewhere in the drivers. My motivation is:
- EDID is sometimes queried by apps directly, and it is better to provide a true one or a synthetic one with as much of accurate info as possible / reasonable;
- There is more info in EDID, e. g., colorimetry for HDR support in d3d. As far as I can tell, there is no documented way to query HDR info on Windows besides dxgi interfaces (which in case on Wine are based on gdi drivers for such things and can hardly become a genine source of such info in Wine) and WinRT interface (for which I don't know where it takes the info on Windows but we probably don't want to make it a lower level source of such info in Wine).
The alternative would be, instead of basing higher level win32u on EDID, parse EDID in drivers instead and add all the necessary info into gdi_monitor structure (instead of removing display name from there), but so far it seems less straightforward to me.
--
v3: win32u: Get friendly monitor name from EDID in NtUserDisplayConfigGetDeviceInfo().
win32u: Return edidManufactureId and edidProductCodeId from NtUserDisplayConfigGetDeviceInfo().
win32u: Store EDID info in monitors cache.
win32u: Use monitor ID from EDID when available.
win32u: Remove monitor name from gdi driver monitor info.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2177
This is what it looks like:
**v1**

**v2**

--
v4: winecfg: Add an option to enable WinRT app dark theme.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v16: ddraw: Also Buffer D3DPT_POINTLIST
ddraw: Add a local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
We need to use the ODBC v1 function SQLColAttributesW, to ensure that we
use the lowest verion available. This ODBC function internally will call
SQLColAttribute or SQLColAttributesW depending on what the driver supports.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2223
Fixes Gungrave G.o.r.e media playback and hang on start.
I tested separately that setting an obviously invalid AudioSpecificConfig fails on Windows as well. On Windows stream attributes incompatible with AudioSpecificConfig (e. g., sample rate) also fails. We currently don't have such checks (and that will require fully parsing AudioSpecificConfig on our side), but since we don't have to choose between the parameters and only validate them I hope missing validation is not critical until we have something depending on that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2189
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v14: ddraw: Convert buffer API to use d3d_device struct
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v12: windows.media.speech: Implement Vosk create and release functions in the unixlib.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
I was mainly after the issue fixed by the second patch but stomped on another one while testing that and that one looks even more unfortunate to me.
1. When connect() is used on blocking socket and fails for whatever reason, next connect() will make a new independent connection attempt (both on Windows and Unix). In non-blocking mode however (and Unix sockets are always in non-blocking mode in Wine) on Linux the next connect() will always return an error (unlike Windows which will make a new connect attempt if the previous one completed and failed). So in Wine now even for blocking socket connect() will fail if previous attempt failed and return WSAECONNABORTED. The error returned by Linux connect() will be ECONNABORTED if getsockopt(SO_ERROR) was called on the socket after connect completed with failure, and true connect() fail error if getsockopt wasn't called.
2. connect() on blocking socket times out after ~21sec on Windows and after ~130 sec on Linux. That is the case when peer doesn't actively reject connection but just never replies anything. That is, client sent SYN and never heard back. So much longer timeout leads to what is seen as hang on exit in one game, but probably more important that it affect much more in various apps provoking timeouts or huge delays not just on exit.
I did not find a way to set connect() timeout for socket on Windows. That difference mostly corresponds to number of SYN send retries. That is 7 on Linux by default and 4 on Windows (the delay between attempts starts from 1s and is doubled on each next attempt). There is TCP_SYNCNT socket option (Linux specific now, unfortunately) which allows to set the number of retries. Setting that to 4 yields 32 sec timeout (vs 21 sec on Windows). The remaining difference is probably due to different amount of time waited after last SYN is sent. There is also TCP_USER_TIMEOUT parameter which allows to effectively set the delay exactly, but it might interfere with SO_KEEPALIVE somehow and I hope that 32 vs 21 is not that critical already as 130 vs 21 and probably we can avoid complicating the thing with it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2215
This prevents a bad free if RtlDosPathNameToNtPathName_U fails.
I should have included this change in commit 69ea31ffb594eadb2b35c3f713d89f5488ee86f2, sorry.
--
v2: winspool: Initialize nt_ppd in add_printer_driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2190
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.
--
v3: 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 responseText's length in XHRs and report it manually.
mshtml: Track readyState in XHRs and report it manually.
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
Huw Davies (@huw) commented about dlls/bluetoothapis/bluetoothapis.spec:
> @ stub BluetoothIsDiscoverable
> @ stub BluetoothIsVersionAvailable
> @ stub BluetoothRegisterForAuthentication
> -@ stub BluetoothRegisterForAuthenticationEx
> +@ stdcall BluetoothRegisterForAuthenticationEx(ptr ptr ptr ptr) bthprops.cpl.BluetoothRegisterForAuthenticationEx
It looks like this is going the wrong way and that `bluetoothapis.dll` was introduced to be called by `bthprops.cpl`.
I'd start switching the existing functions around (i.e. move the existing stubs in `bthprops.cpl` to `bluetoothapis.dll`). Once that is done you can add the new ones.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1889#note_24530
This series provides a bunch of new tests related to module management
in dbghelp, and a couple of fixes:
- correcting some module's name vs filename propagation
- better handling in SymLoadModules when module overlaps the already
loaded module(s)
--
v2: dbghelp: Unload overlapping modules in SymLoadModule*().
dbghelp: Add new module at end of the process' modules list.
dbghelp: Add some more tests about module handling.
dbghelp: Add test for loaded modules enumeration.
dbghelp: Let EnumerateLoadedModules() expose image names.
dbghelp: Add tests for 'module' name in EnumLoadedModules() callback.
dbghelp/tests: Test return value of SymLoadModule.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2220
This is what it looks like:
**v1**

**v2**

--
v3: winecfg: Add an option to enable WinRT app dark theme.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51848
SPORE creates a swapchain on a window, then destroys it, then creates a
different swapchain on the same window and uses it for the rest of its lifetime.
The swapchains have different GLX visuals (the details are unimportant).
The effect is that the second swapchain sees the pixel format set by the first
swapchain, through GetPixelFormat(), and therefore needs to set and then
restore the new pixel format on every present. This results in recreating the
GLX drawable twice per frame, which is extremely expensive.
This patch series changes WGL_WINE_pixel_format_passthrough to only set an
"internal" pixel format. The real pixel format will still be set as it is now,
but GetPixelFormat() will always return 0, signalling to wined3d that the
application has not set the pixel format, and therefore there is no need to
restore it.
As the tests show, this change also matches Windows, which does not report that
a pixel format has been set after presenting a Direct3D swapchain.
This is a large series by patch count, but I fear that splitting it into two
parts would make it difficult to grasp the entire picture, and purpose of the
earlier patches. It also contains six patches which are simply repetitions
across the three user drivers, which should ease the burden of review somewhat.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2217
This series provides a bunch of new tests related to module management
in dbghelp, and a couple of fixes:
- correcting some module's name vs filename propagation
- better handling in SymLoadModules when module overlaps the already
loaded module(s)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2220
There are two common ways I observe how games get monitor name to display:
1. Registry key under Enum/Display (also present in EnumDisplayDevicesA result for monitors). On Windows this key is derived from edid as 'Manufacturer ID' (3 letters) combined with "Manufacturer product code" (4 hex digits). We currently have 'Default_Display' there for all the displays;
2. DisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME). Windows sets friendlyNameFromEdid flag and returns a name from 'EDID Display Descriptor' with code 0xfc ("Display name"). As far as I could see by searching through the Windows registry this name doesn't seem to be explicitly present anywhere in registry (besides binary raw edid of course).
The first patch removes name from the gdi driver's display structure. Now none of the drivers set anything genuine there. x11 and winemac always end up with "Generic Non-Pnp Monitor" string, wineandroid sets NULL there and "Generic Non-Pnp Monitor" is set in win32u in this case. That "Generic Non-Pnp Monitor" goes to "DeviceDesc" registry value. While our value doesn't match Windows string exactly, Windows also doesn't have any meaningful name under DeviceDesc (and contains "Generic Non-Pnp Monitor" as a part of it). So this patch is essentially a no-op currently. Going forward my idea is that we just want to have edid from drivers. If the raw one is not available we can generate fallback one ourselves based on the info about the monitor we might have from elsewhere in the drivers. My motivation is:
- EDID is sometimes queried by apps directly, and it is better to provide a true one or a synthetic one with as much of accurate info as possible / reasonable;
- There is more info in EDID, e. g., colorimetry for HDR support in d3d. As far as I can tell, there is no documented way to query HDR info on Windows besides dxgi interfaces (which in case on Wine are based on gdi drivers for such things and can hardly become a genine source of such info in Wine) and WinRT interface (for which I don't know where it takes the info on Windows but we probably don't want to make it a lower level source of such info in Wine).
The alternative would be, instead of basing higher level win32u on EDID, parse EDID in drivers instead and add all the necessary info into gdi_monitor structure (instead of removing display name from there), but so far it seems less straightforward to me.
--
v2: win32u: Get friendly monitor name from EDID in NtUserDisplayConfigGetDeviceInfo().
win32u: Return edidManufactureId and edidProductCodeId from NtUserDisplayConfigGetDeviceInfo().
win32u: Store EDID in monitors cache.
win32u: Use monitor ID from EDID when available.
win32u: Remove monitor name from gdi driver monitor info.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2177
This is what it looks like:

--
v2: winecfg: Add an option to enable WinRT app dark theme.
wine.inf: Add AppsUseLightTheme key.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2183
--
v3: Revert "ntoskrnl.exe: Enforce path case in WM_DEVICECHANGE notifications."
ntoskrnl: Preserve the device instance ID case in IoRegisterDeviceInterface().
ntoskrnl/tests: Expand tests for device and interface naming.
user32: Map DEV_BROADCAST_DEVICEINTERFACE to ANSI for registered device notifications.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2185
--
v2: Revert "ntoskrnl.exe: Enforce path case in WM_DEVICECHANGE notifications."
ntoskrnl: Preserve the device instance ID case in IoRegisterDeviceInterface().
ntoskrnl/tests: Expand tests for device and interface naming.
user32: Map DEV_BROADCAST_DEVICEINTERFACE to ANSI for registered device notifications.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2185
When using msadosql it always returns the number of records
affected or records returned by a SELECT statement.
The access database, which is what the defaults tests are using
doesn't return the number of records for a SELECT.
It's a known issue that you have to MoveLast/MoveFirst before
the correct RecordCount value is return for an Access DB.
--
v2: msdasql: Always return affected rows if required.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2216
First part of v2 of !27, which aims to:
* Allow allocation of variables of complex types that contain both numerics and objects across multiple register sets (regsets).
* Support the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions.
* Support for arrays of resources for both SM1 and SM4 (not to be confused with the resource-arrays of SM 5.1, which can have non-constant indexes).
* Support for resources declared within structs.
* Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of structs.
* Imitate the way the native compiler assigns the register indexes of the resources on allocation, which proved to be the most difficult thing.
* Support for object components within complex input parameters.
* Small fixes to corner cases.
This part consists on parsing the `tex2D()` and `tex3D()` intrinsics and beginning to support the allocation of variables across multiple regsets.
The whole series, is on my [master6](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/master6) branch.
--
v11: vkd3d-shader/hlsl: Allocate register reservations in a separate pass.
vkd3d-shader/hlsl: Respect object reservations even if the object is unused.
tests: Test allocation of unused objects.
vkd3d-shader/hlsl: Allocate objects according to register set.
vkd3d-shader/hlsl: Keep an hlsl_reg for each register set in hlsl_ir_var.
vkd3d-shader/hlsl: Obtain extern resources as a separate array in SM4.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/66
When using msadosql it always returns the number of records
affected or records returned by a SELECT statement.
The access database, which is what the defaults tests are using
doesn't return the number of records for a SELECT.
It's a known issue that you have to MoveLast/MoveFirst before
the correct RecordCount value is return for an Access DB.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2216
I ran into some scripts with the following code:
```
DMD CL(0, "HIGHSCORES"), "1> " &HighScoreName(0) & " " &FormatScore(HighScore(0)), "", eNone, eScrollLeft, eNone, 2000, False, ""
```
When there is no space after `&` the `H` in the `HighScoreName` variable is making the parser think it's a hex value.
In real vbscript I tried the following:
```
Dim hescore
hescore = "WOW"
WScript.echo "" &hescore & &h02
```
Syntax error
```
Dim h1score
h1score = "WOW"
WScript.echo "" &h1score & &h02
```
Syntax error
```
Dim hiscore
hiscore = "WOW"
WScript.echo "" &hiscore & &h02
```
WOW2
So it looks like it's checking the next character after the `h` to see if it's a valid hex character.
I believe this MR fixes this case and continues to support the test case:
```
Call ok((&h01or&h02)=3,"&h01or&h02 <> 3")
```
Fixes: https://bugs.winehq.org/show_bug.cgi?id=54493
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2214
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v10: windows.media.speech: Implement Vosk create and release functions in the unixlib.
windows.media.speech/tests: Allow the SpeechRecognizer creation to fail in Wine.
windows.media.speech/tests: Get rid of duplicated hresult.
windows.media.speech: Add unixlib stub.
windows.media.speech: Add Vosk checks to autoconf.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
Currently, we can't use add_load_index() or add_load_component() on the loads to the `"retval"` variables that come from `add_call()` because these functions assume that the loaded value (`var_instr`) won't change between its location and the location and the new load to be created.
We can't get rid of this assumptions either, because, at least
`add_load_index()` may be used in the lhs of an assignment, and in that case we
can't store to the "deref" synthetic:
```
x[0] = 20;
```
Here I implemented the alternative solution of copying `"retval"` into a synthetic variable after each function call, but we may want to discuss this approach.
The second problem this that is covered in 3/3 is fixing the number of components of the swizzle instructions generated by copy-prop, without it, the following assertion in `hlsl_sm4.c` fails for me
```c
/* Narrowing casts were already lowered. */
assert(src_type->dimx == dst_type->dimx);
```
for some tests, in one of my branches, because of narrowing casts may end up appearing if the node is replaced with a node with more components. This error happens under quite complex conditions (involving casts and matrices) that I still try to narrow down, but I think that the fix is logical enough, without it, the asserts introduced in the patch fail in many tests.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/93
On Wed Feb 15 13:55:41 2023 +0000, Nikolay Sivov wrote:
> Hi, @giomasce. Is anything blocking this MR?
I'd like to see more tests that `reflect()` really behaves like on native with different types combinations. For example, what happens if you call `reflect()` on a `float` and a `float2`? Or on a `float2` and a `float3`? From my tests, it seems that the current implementation is correct, but it would be nice to have this shown by tests, so that we don't regress it in the future. It should be quite a quick thing to do.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/80#note_24372
Second commit is to be removed.
Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com>
--
v9: windows.media.speech: Implement Vosk create and release functions in the unixlib.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2091
The following two examples fail to compile, but work fine in real vbscript:
```
Dim x
x = 8
if x = 9 Then
Wscript.Echo "HERE1"
elseif x = 8 then Wscript.Echo "HERE2"
else
Wscript.Echo "HERE3"
end if
```
```
Dim x
x = 8
if x = 9 Then
Wscript.Echo "HERE1"
elseif x = 8 then
: Wscript.Echo "HERE2"
else
Wscript.Echo "HERE3"
end if
```
This was fixed similar using the same approach as https://gitlab.winehq.org/wine/wine/-/merge_requests/2142
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2188
The separate lists were added to avoid iterating device nodes if not necessary. I believe we don't need that anymore as we now keep the devices in a more efficient sequential array.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2207