First MR to begin de-duplicating WineTest helpers.
The idea is to make most helpers static inline, and the counters extern, prefixing any variable moved to the global scope. This will allow dinput / ntoskrnl driver tests to re-use the helpers by only having to provide the counters and an implementation of `winetest_get_thread_data` / `winetest_vprintf` (and a couple of other functions).
Then, it will also be re-usable in WinRT tests for https://gitlab.winehq.org/wine/wine/-/merge_requests/3643.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3681
This patch implements properties that CeVIO AI checks during its authentication process that was not implemented before.
CeVIO AI is confirmed to boot up with this patch, properly recognizing devices required for registering.
--
v2: wbemprox: Add NetConnectionID, NetEnabled properties in Win32_NetworkAdapter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3679
On Tue Aug 29 19:37:31 2023 +0000, Alexander Chalikiopoulos wrote:
> Doesn't that literally use the same definition that I changed in this PR?
> In which case: it already gets a new value from the current change.
True. I missed that part
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1893#note_43747
On Mon Aug 28 19:44:10 2023 +0000, Bartosz Kosiorek wrote:
> Except this game, I don't know any benefits of Tahoma. Should I close
> this Merge Request?
> @madewokherd Could you please close the bug then?
It's still a valid bug.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3611#note_43746
This patch implements properties that CeVIO AI checks during its authentication process that was not implemented before.
CeVIO AI is confirmed to boot up with this patch, properly recognizing devices required for registering.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3679
On Tue Aug 29 15:47:39 2023 +0000, Jinoh Kang wrote:
> Specifically, the test should check if Windows indeed does *not* ignore
> hbmMask even if we have semitransparent icons.
That is what the added tests are doing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3657#note_43735
On Tue Aug 29 15:46:15 2023 +0000, Jinoh Kang wrote:
> We should have a test covering this so we know we don't have a
> regression here.
Specifically, the test should check if Windows indeed does *not* ignore hbmMask even if we have semitransparent icons.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3657#note_43720
Since Yousician's last update, it was throwing an error when initialising audio output. Unfortunately I don't have access to the old version, but they seem to have dropped win<10 support, and are using only IAudioClient3_InitializeSharedAudioStream. They also use IDeviceTopology to get the type of the first output connector.
This is the bare minimum I needed to get it working.
--
v8: mmdevapi: add stub for IDeviceTopology
mmdevapi/tests: add test for IDeviceTopology
mmdevapi: implement IAudioClient3_InitializeSharedAudioStream
mmdevapi/tests: add test for AudioClient3_InitializeSharedAudioStream
https://gitlab.winehq.org/wine/wine/-/merge_requests/3554
With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though:
* A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail).
* ~~The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too.~~ **Fixed**, now there is a shared worker with an AMD GPU available.
* While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!).
* ~~One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway).~~ **A better solution was implemented**
* ~~Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future.~~ **Done**
* ~~Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback.~~ **Fixed too**
--
v7: ci: Introduce a CI pipeline for GitLab.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271
This is similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/2684, https://gitlab.winehq.org/wine/wine/-/merge_requests/3004 or https://gitlab.winehq.org/wine/wine/-/merge_requests/3139 but it validates the session transform node behavior with tests.
The tests are added after the changes because they otherwise don't pass and making them pass would be unnecessarily complicated.
I also have some local tests for MF_TOPONODE_WORKQUEUE_ID attributes and how it is supposed to behave. It basically creates new serialized work queues for every source node and assign them to every node downstream. Any sample request or processing operation is done in the associated queue.
When joining streams, queues are assigned downstream one after another and the last assigned queue is used when requesting samples upstream, but when samples are received and processed downstream it looks like the current queue of the source node is used for every downstream operations.
The request behavior seems to be the same when work queues are used, with round robin input requests, and single ProcessInput call followed by ProcessOutput loop until it fails.
This is yet not optimally efficient, and could be improved, for the following reasons:
1) All session operations are serialized together, even unrelated streams, and ProcessInput / ProcessOutput calls may be costly and stalling the pipeline. I believe that native probably allows parallel processing of unrelated stream requests, this needs to be confirmed.
2) MFT_MESSAGE_COMMAND_DRAIN message use isn't ideal, the message forces the transform to process all queued input synchronously, which can take a long time. I haven't checked exactly what native does but I believe it instead uses MFT_MESSAGE_NOTIFY_END_OF_STREAM messages, which would allow us to notify and drain the GStreamer decoder asynchronously.
3) MFT_MESSAGE_COMMAND_DRAIN also doesn't distinguish between input streams and needs to be sent globally. It's unclear how it should be used when multiple input streams are involved, and when one stream ends its segment then start a new segment while other streams don't have yet reached EOS. MFT_MESSAGE_NOTIFY_END_OF_STREAM messages have a stream ID parameter and would be more appropriate to handle separate input streams independently.
--
v5: mf/session: Increase the request count when requests are already queued.
mf/session: Request more samples from upstream when necessary.
mf/session: Push transform input samples directly to ProcessInput.
mf/session: Use helpers to push and pop samples for transform streams.
mf/session: Drain remaining requests in transform_node_deliver_samples.
mf/session: Drain transform node input streams individually.
mf/session: Use a helper to deliver transform node requested samples.
mf/session: Use local variables to access transform node streams.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3245
On Tue Aug 29 12:04:33 2023 +0000, Nikolay Sivov wrote:
> One way would be to build some test against msvcr110, and see what
> happens with the destructor. You don't need a game for that.
It's unlikely that there's both inline destructor and export.
Our Context/ExternalContextBase layout is not compatible with native (and _Cancellation_beacon ctor/dtor modifies it). So if there is inline version of the destructor it will not work.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3664#note_43676
I hope this is compatible with the destructor and whatever other functions may be compiled into the game. When I investigated cm3 the destructor call never showed up in logs. But maybe I'm blind, or maybe the game deliberately never calls the destructor.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3664#note_43671
The default exit code is only used when a process is killed by the system or through a signal.
These are exceptional cases where exit code 1 (killed by Task Manager) is more appropriate than the normal termination code of 0.
Chromium does not restart helper processes that exit with code 0 (see [kill.h](https://source.chromium.org/chromium/chromium/src/+/main:base/proce…), with this fix they are restarted when killed by the system or by a signal.
--
v2: server: Set the default thread exit code to 1.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3648
With this pipeline vkd3d automatically gets built on Linux (in an image based on Debian unstable), both in 32 and 64 bit mode. Both builds are tested with radv and llvmpipe. A number of caveats apply, though:
* A number of tests currently fail in llvmpipe, so the llvmpipe jobs are marked as allowed to fail. Ideally we'll eventually fix our bugs and mark the llvmpipe ones in the tests, so that the CI tests completely pass and possible problems in the Vulkan driver are recorded at a better granularity (this is the reason why GitLab says that the pipeline is passed with warnings: the warnings are that there are jobs that failed, even if they were allowed to fail).
* ~~The runners provided by the GitLab instance don't have a GPU available, so I configured my own computer (equipped with an AMD Radeon RX 5700 RX) to provide a runner with access to the GPU. This setup is not currently satisfying: for me, because I use that computer for other things and I don't like having random code submitted to it (it is theoretically sandboxed, but sandboxes are not always bullet-proof, especially if they have access to a GPU); for the users, because my computer might be unavailable at any time. I'll work on a better solution. For the time being I intend the runner to only accept jobs from the master branch; once a better solution is implemented I'd like to run the pipeline for MRs too.~~ **Fixed**, now there is a shared worker with an AMD GPU available.
* While the `Dockerfile` and related assets do not necessarily need to be available in this repository, given that the CI accesses the binary image from the Docker hub anyway, I think it's still valuable to have them, so others can improve them (and for sure improvement opportunities are nowhere near missing). However, other ways to make them available can be found, if for some reason it is not liked to have them in this repository (they are not pretty!).
* ~~One of the reason they are not pretty is that I have a custom hack to compile `widl` from the Wine sources without compiling (or installing from the distribution) the whole of Wine, in the interest of keeping the Docker image small (well, small-ish: Vulkan drivers, compilers and X libraries are not small anyway).~~ **A better solution was implemented**
* ~~Again on the subject of the Docker image, I am currently putting the binary image in my own namespace on the Docker hub. Using the GitLab container registry in the namespace of the Wine project would probably be better, so that I am not a bottleneck in the future.~~ **Done**
* ~~Even if we discount all the points above, this MR cannot be merged yet, because my runner is currently configured for my namespace only. I guess I need the intervention of a GitLab admin to fix that. However, I think there's already material enough for valuable feedback.~~ **Fixed too**
--
v6: ci: Introduce a CI pipeline for GitLab.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/271
Is there anything major blocking the merge of this PR?
While it would indeed be best to find a proper way to handle midi devices, this PR would at least solve the current behavior of wine in dealing with this which is problematic.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1893#note_43592
On Wed Aug 23 20:11:56 2023 +0000, Esme Povirk wrote:
> Is there a convincing argument that Tahoma is better overall (as opposed
> to better for this one launcher)?
Except this game, I don't know any benefits of Tahoma. Should I close this Merge Request?
@madewokherd Could you please close the bug then?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3611#note_43587
I have found some scripts where comparisons that use floats and OLECOLOR directly fail. For example:
```
If Light005.State Then
' State is a float V_R4
End If
If Light005.Colorfull Then
' Colorfull is an OLECOLOR VT_UI4
End If
```
This is because `stack_pop_bool` does not handle `VT_R4` and `VT_UI4` and returns `E_NOTIMPL`.
This adds additional types to `stack_pop_bool` similar to `VARIANT_Coerce`.
Fixes https://bugs.winehq.org/show_bug.cgi?id=54731
--
v3:
https://gitlab.winehq.org/wine/wine/-/merge_requests/2507
I have found some scripts where comparisons that use floats and OLECOLOR directly fail. For example:
```
If Light005.State Then
' State is a float V_R4
End If
If Light005.Colorfull Then
' Colorfull is an OLECOLOR VT_UI4
End If
```
This is because `stack_pop_bool` does not handle `VT_R4` and `VT_UI4` and returns `E_NOTIMPL`.
This adds additional types to `stack_pop_bool` similar to `VARIANT_Coerce`.
Fixes https://bugs.winehq.org/show_bug.cgi?id=54731
--
v2: vbscript: Coerce to VT_BOOL when evaluating jump conditions.
vbscript: Coerce to VT_BOOL when evaluating jump conditions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2507
--
v2: mshtml: Implement Cycle Collection for XMLHttpRequest.
mshtml: Implement Cycle Collection for HTMLPerformanceTiming.
mshtml: Move PerformanceTiming related fields to the window.
mshtml: Move HTMLPerformanceNavigation related fields to the window.
mshtml: Implement Cycle Collection for inner windows.
mshtml: Get rid of NULL checks for the dispex vtbl.
mshtml: Implement Cycle Collection for outer windows.
mshtml: Implement Cycle Collection for HTMLLocation.
mshtml: Separate the HTMLLocation from the outer window.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3645
Since dcf0bf1f, one could no longer kill a GUI application launched from
unix shell (with start.exe /exec) with ctrl-c.
(depends on https://gitlab.winehq.org/wine/wine/-/merge_requests/3310
to be fully functional).
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v3: programs/cmd: Better handle ctrl-c events.
ntdll,server: Terminate GUI programs launched from unix shell.
kernel32/console: Add tests for GenerateConsoleCtrlEvent().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3312
--
v12: vkd3d-shader/tpf: Handle the swizzle type bitfield in dst param tokens.
vkd3d-shader/tpf: Handle the dimension bitfield in dst param tokens.
vkd3d-shader/tpf: Use the default vec4 swizzle if a src param contains a mask.
vkd3d-shader/tpf: Handle the dimension bitfield in src param tokens.
vkd3d-shader/tpf: Validate the src register of case conditions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/225
It's no problem to send fewer of these per MR. I have included the complete set because all but the last introduce no functional changes, and upstreaming a smaller set would leave the changes in a half-done state with unnecessary buffering.
--
v6: vkd3d: Store command list commands in a buffer until executed.
vkd3d: Store WriteBufferImmediate() arguments in a buffer.
vkd3d: Store ExecuteIndirect() arguments in a buffer.
vkd3d: Store SetPredication() arguments in a buffer.
vkd3d: Store ResolveQueryData() arguments in a buffer.
vkd3d: Store EndQuery() arguments in a buffer.
vkd3d: Store BeginQuery() arguments in a buffer.
vkd3d: Store d3d12_command_list_clear_uav() arguments in a buffer.
vkd3d: Store ClearRenderTargetView() arguments in a buffer.
vkd3d: Store ClearDepthStencilView() arguments in a buffer.
vkd3d: Store OMSetRenderTargets() arguments in a buffer.
vkd3d: Store SOSetTargets() arguments in a buffer.
vkd3d: Store IASetVertexBuffers() arguments in a buffer.
vkd3d: Store IASetIndexBuffer() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_descriptor() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_cbv() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_constants() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_descriptor_table() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_signature() arguments in a buffer.
vkd3d: Add an internal refcount to struct d3d12_root_signature.
vkd3d: Store ResourceBarrier() arguments in a buffer.
vkd3d: Store SetPipelineState() arguments in a buffer.
vkd3d: Store OMSetStencilRef() arguments in a buffer.
vkd3d: Store OMSetBlendFactor() arguments in a buffer.
vkd3d: Store RSSetScissorRects() arguments in a buffer.
vkd3d: Store RSSetViewports() arguments in a buffer.
vkd3d: Store IASetPrimitiveTopology() arguments in a buffer.
vkd3d: Store ResolveSubresource() arguments in a buffer.
vkd3d: Store CopyResource() arguments in a buffer.
vkd3d: Store CopyTextureRegion() arguments in a buffer.
vkd3d: Store CopyBufferRegion() arguments in a buffer.
vkd3d: Store Dispatch() arguments in a buffer.
vkd3d: Store DrawIndexedInstanced() arguments in a buffer.
vkd3d: Store DrawInstanced() arguments in a buffer.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/294
> > I think it's an improvement too, so I'll approve this. I do think there's further room for improvement though, both in terms of performance and in terms of code quality, and I'd prefer seeing those sooner rather than later. (E.g., I don't like the magic "16"; I don't like that we're rolling our own spinlocks here; I don't like the number of atomic operations in what's supposed to be a hot path.)
>
> I gave this some more thinking, and I'm not sure I like the idea of using spinlocks (either implemented by us or by others) any more. They're not wait-free and they don't even coordinate with the operating system, meaning that if a thread is suspended while a spinlock is hold any other thread trying to acquire the same spinlock will spin busily for an entire scheduling quantum (or more). In our case that's slightly different because there is striping, but there are still scenarios in which that can fail (depending on the number of active threads, CPUs and stripe buckets), so I don't like it. While I understand the engineering problems of the wait-free option with the CPU-specific code, I can't help but thinking that after some initial investment that's going to remove some opportunities for stuttering that may be even harder to reproduce and debug later.
I don't particularly like the spinlocks either, but the striping at least somewhat mitigates the issues here. As mentioned before, I think the more problematic parts here are "next_index" and "free_count", which I'd expect to bounce all over the place in the cases we care about. The lock-free list wouldn't really avoid that issue either; it would have similar issues with the list head. The main benefit of thread-local schemes would be that it keeps data local to the thread as much as possible. Or that's the theory anyway; we'd also want some careful benchmarking to be done...
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/297#note_43543
> I think it's an improvement too, so I'll approve this. I do think there's further room for improvement though, both in terms of performance and in terms of code quality, and I'd prefer seeing those sooner rather than later. (E.g., I don't like the magic "16"; I don't like that we're rolling our own spinlocks here; I don't like the number of atomic operations in what's supposed to be a hot path.)
I gave this some more thinking, and I'm not sure I like the idea of using spinlocks (either implemented by us or by others) any more. They're not wait-free and they don't even coordinate with the operating system, meaning that if a thread is suspended while a spinlock is hold any other thread trying to acquire the same spinlock will spin busily for an entire scheduling quantum (or more). In our case that's slightly different because there is striping, but there are still scenarios in which that can fail (depending on the number of active threads, CPUs and stripe buckets), so I don't like it. While I understand the engineering problems of the wait-free option with the CPU-specific code, I can't help but thinking that after some initial investment that's going to remove some opportunities for stuttering that may be even harder to reproduce and debug later.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/297#note_43540
---
See the added comment for details what is going on.
--
v3: d3d9/tests: Wait longer in test_occlusion_query for software renderers.
d3d9/tests: The device window may restore behind our back in test_wndproc.
d3d9/tests: Work around test_reset_fullscreen failing on gitlab CI.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3565
--
v2: vkd3d-shader/spirv: Handle thread group UAV barriers.
vkd3d-shader/spirv: Include Uniform in the memory semantics for UAV barriers.
vkd3d-shader/spirv: Handle globally coherent UAVs.
vkd3d-shader: Introduce a UAV_GLOBALLY_COHERENT descriptor info flag.
vkd3d-shader: Introduce the RASTERISER_ORDERED_VIEW UAV flag.
vkd3d-shader/tpf: Fix extraction of the UAV declaration flags.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/306
--
v2: gdiplus: Fix GdipCreateBitmapFromHICON bitmap data.
gdiplus/tests: Add test for bitmap locked data from GdipCreateBitmapFromHICON.
gdiplus/tests: Add test for non-square icon with GdipCreateBitmapFromHICON.
gdiplus/tests: Add test for 32 bpp icon with GdipCreateBitmapFromHICON.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3657
Since 1.20, gst_element_request_pad_simple is available and
gst_element_get_request_pad is marked as deprecated.
--
v6: winegstreamer: Add MFMPEG4SinkClassFactory.
mf/tests: Use h264 and aac in mp4 media sink tests.
mf/tests: Add tests for h264 encoder.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636
It's no problem to send fewer of these per MR. I have included the complete set because all but the last introduce no functional changes, and upstreaming a smaller set would leave the changes in a half-done state with unnecessary buffering.
--
v5: vkd3d: Store command list commands in a buffer until executed.
vkd3d: Store WriteBufferImmediate() arguments in a buffer.
vkd3d: Store ExecuteIndirect() arguments in a buffer.
vkd3d: Store SetPredication() arguments in a buffer.
vkd3d: Store ResolveQueryData() arguments in a buffer.
vkd3d: Store EndQuery() arguments in a buffer.
vkd3d: Store BeginQuery() arguments in a buffer.
vkd3d: Store d3d12_command_list_clear_uav() arguments in a buffer.
vkd3d: Store ClearRenderTargetView() arguments in a buffer.
vkd3d: Store ClearDepthStencilView() arguments in a buffer.
vkd3d: Store OMSetRenderTargets() arguments in a buffer.
vkd3d: Store SOSetTargets() arguments in a buffer.
vkd3d: Store IASetVertexBuffers() arguments in a buffer.
vkd3d: Store IASetIndexBuffer() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_descriptor() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_cbv() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_constants() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_descriptor_table() arguments in a buffer.
vkd3d: Store d3d12_command_list_set_root_signature() arguments in a buffer.
vkd3d: Add an internal refcount to struct d3d12_root_signature.
vkd3d: Store ResourceBarrier() arguments in a buffer.
vkd3d: Store SetPipelineState() arguments in a buffer.
vkd3d: Store OMSetStencilRef() arguments in a buffer.
vkd3d: Store OMSetBlendFactor() arguments in a buffer.
vkd3d: Store RSSetScissorRects() arguments in a buffer.
vkd3d: Store RSSetViewports() arguments in a buffer.
vkd3d: Store IASetPrimitiveTopology() arguments in a buffer.
vkd3d: Store ResolveSubresource() arguments in a buffer.
vkd3d: Store CopyResource() arguments in a buffer.
vkd3d: Store CopyTextureRegion() arguments in a buffer.
vkd3d: Store CopyBufferRegion() arguments in a buffer.
vkd3d: Store Dispatch() arguments in a buffer.
vkd3d: Store DrawIndexedInstanced() arguments in a buffer.
vkd3d: Store DrawInstanced() arguments in a buffer.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/294
On Sat Aug 26 21:47:32 2023 +0000, Chip Davis wrote:
> > Also the commit and the name that appear on gitlab is my full name,
> I'm not sure why in the mailing list it appears the user handle
> It's possible the commit itself has only your email in it. You won't see
> the problem on GitLab, because it's smart enough to map that to your
> user profile. Try looking at your local topic branch with `git log`.
@cdavis5e Thanks, it was that. I don't see a difference between the 2 commits, maybe gitlab also auto-map the commit name with the profile name if it can't find the handle.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3660#note_43508
Otherwise if a package fail to load the routine is stuck in a continuos loop trying to load the
package, resulting in a loader deadlock.
This was manifested as a regression when starting visual studio 2019, trying to load the SSO lsa package, that was failing because no SSO.dll was present (or loadable)
Restore the behaviour before commit 021547cabcb811c38060a2f7e675c25d26f16d3d (Pull Request !3472)
Signed-Off-By: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v2: secur32: Increment iteration index after load_package error
https://gitlab.winehq.org/wine/wine/-/merge_requests/3660
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v16: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
Since 1.20, gst_element_request_pad_simple is available and
gst_element_get_request_pad is marked as deprecated.
--
v5: winegstreamer: Add MFMPEG4SinkClassFactory.
mf/tests: Use h264 and aac in mp4 media sink tests.
mf/tests: Add tests for h264 encoder.
mf/tests: Call check_attributes in check_mft_get_output_current_type_.
winegstreamer: Add codec data to h264 format.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636
Otherwise if a package fail to load the routine is stuck in a continuos loop trying to load the
package, resulting in a loader deadlock.
This was manifested as a regression when starting visual studio 2019, trying to load the SSO lsa package, that was failing because no SSO.dll was present (or loadable)
Restore the behaviour before commit 021547cabcb811c38060a2f7e675c25d26f16d3d (Pull Request !3472)
Signed-Off-By: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3660
And discard irrelevant parts in select request. We currently store something in CTX_PENDING and ignore it later in select request if we're currently running in wow context.
--
v4: ntdll/tests: Add tests for setting context on unsuspended thread.
server: Store both contexts in pending context object.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3566
Fixed the following code:
```dos
for /F "tokens=1,* delims= " %%a in (" -sdkver=10.0.22000.0 -type=MD ") do (
for /F "tokens=1,2 delims==" %%1 in ("%%a") do (
echo param: '%%1'
echo value: '%%2'
)
)
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3616#note_43468
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v15: ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504