In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Also add debug info for this critical section so it show a significant name in the log.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v3: ole32: Add debug info to RunningObjectTable critical section
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372
The validation code is meant both as a check that the frontend is behaving properly and as a sort of the documentation to establish what is allowed and what is not in the IR.
~~Currently an assertion is thrown if validation fails. I realize this is a rather strong proposal, but it's of course up for debate. In theory asserting here is the right thing, as it is expected that the frontend is generating correct IR code. However vkd3d is already used in production for many programs, and it could very well be that some of those are working properly even if the generated IR is somewhat out of specs; allowing the assertion might cause regressions as soon as enough checks are implemented in the validator. Please let me know your opinions.~~ **Solved in favor of a softer failure, and only when validation is enabled**
--
v6: vkd3d-shader/ir: Validate source parameters.
vkd3d-shader/ir: Validate destination parameters.
vkd3d-shader/ir: Validate register types.
vkd3d-shader/ir: Validate instruction handlers.
vkd3d-shader/ir: Introduce a boilerplate to validate the generated IR.
vkd3d-shader: Embed the parsing location in vkd3d_shader_instruction.
vkd3d-shader/dxil: Destroy the SM6 parser on parsing errors.
vkd3d-shader/tpf: Destroy the SM4 parser on parsing errors.
vkd3d-shader/d3dbc: Destroy the SM1 parser on parsing errors.
vkd3d-shader/d3dbc: Ignore DCL source parameters.
vkd3d-shader/ir: Simplify the control flow in shader_instruction_normalise_io_params().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/317
This is the last series I have to use hlsl_block instead of list manipulation.
There is still some list manipulation around, but it's a little trickier to get
rid of, and questionably worthwhile. At any rate things are a lot better now
than they were.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/334
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v26: server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
On Mon Sep 11 08:05:33 2023 +0000, Etaash Mathamsetty wrote:
> might have gotten the wow64 thunk wrong, so pls tell me how to fix it if
> that's the case :)
wow64 needs to be added to wow64win/syscall.h.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777#note_44868
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are not fully supported by this patch, matching the behavior of Windows.
--
v52: ws2_32/tests: Add test for AF_UNIX sockets fix.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ntdll/unix: Add support for AF_UNIX sockets to multiple functions.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
This MR fixes this random failure: http://test.winehq.org/data/126363ea5f9056449e8bd22cc69b51bd2d7dd9aa/linux_…
It happens mostly in d3d9, but if you try hard enough you can see it on d3d8 too.
There are more random failures in test_window_position that I have seen when running on an actual display but not in a dummy X server or Xephyr. One failure mode is that we lose focus in the initial create_device and minimize ourselves. This particular problem is specific to focus follows mouse. Another is that fvwm seems to place the window slightly offscreen, maybe shifted by the size of the window decoration. I am still looking into those issues.
Unrelated to test_windoow_position, there is at least one more random failure in test_wndproc (Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0.), so expect more fvwm3 related MRs after this one...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3778
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Also add debug info for this critical section so it show a significant name in the log.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v2: ole32: Add debug info to RunningObjectTable critical section
ole32: Leave the RunningObjectTable Critical Section before umarshalling object
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372
I wanted to use ._xy element access to make it shorter, but that attempt was crushed by the reality - such indexing apparently compiles but does not produce correct element access loads. I'm going to update once this is fixed.
--
v4: vkd3d-shader/hlsl: Add determinant() function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/329
Crysis 3 Remastered (and 2 probably) in RT mode rely on GetFileSize() returning available read size (more exactly, correctly return 0 when no data is available) on pipe it uses to read the output from child dxc.exe process it creates (and hangs forever trying to read the pipe when we return INVALID_FILE_SIZE). While MSDN explicitly says that "You cannot use the GetFileSize function with a handle of a nonseeking device such as a pipe or a communications device.", if application dares GetFileSize (or NtQueryInformationFile(FileStandardInformation)) actually works for named and unnamed pipes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3776
As @nsivov pointed out, we are currently parsing matrix swizzles (e.g. mat._m12_m32) and creating an hlsl_ir_swizzle for the matrix itself. We are currently allowing shaders that use these to compile even though they are not working.
While our compilation passes don't expect hlsl_ir_swizzles with matrix values, turns out we need them as a parse-time construct because we don't know if they will be used as the lhs of an assignment during parsing, similarly to hlsl_ir_indexes.
This patch adds tests and a pass to lower these matrix swizzles.
Implementing assignments with matrix swizzles is still pending.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/331
This patch set is part of !3303
--
v3: winegstreamer: Create wg_muxer for media sink.
winegstreamer: Implement seeking query for wg_muxer sink pad.
winegstreamer: Introduce new wg_muxer struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3737
With this commit we proof that PixelOffsetMode None and Fast
is implemented correctly.
By changing colour of second pixel of bitmap Source,
the issues with pixel offset appear
for PixelOffsetMode Half and HighQuality.
Extending tests is starting point for further
improvements of implementation pixel offset modes
to match implementation from native gdiplus.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3774
If lparam is null, the current code crashes when it hits the memcpy in pack_user_message.
--
v2: win32u: Correct the packed size of WM_GETDLGCODE when lparam is NULL.
win32u: Add a test for cross-process WM_GETDLGCODE with a NULL lparam.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3755
I wanted to use ._xy element access to make it shorter, but that attempt was crushed by the reality - such indexing apparently compiles but does not produce correct element access loads. I'm going to update once this is fixed.
--
v3: vkd3d-shader/hlsl: Add determinant() function.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/329
--
v2: mshtml: Use query_interface in the dispex vtbl for HTMLPluginsCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLNamespaceCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLMimeTypesCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLAttributeCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLFiltersCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLRectCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLElementCollection.
mshtml: Use query_interface in the dispex vtbl for HTMLDOMChildrenCollection.
mshtml: Use query_interface in the dispex vtbl for StyleSheetRules and
mshtml: Use query_interface in the dispex vtbl for CSS Styles.
mshtml: Use query_interface in the dispex vtbl for HTMLStorage.
mshtml: Use query_interface in the dispex vtbl for HTMLLocation.
mshtml: Use query_interface in the dispex vtbl for builtin constructors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3773
This MR adds support for handling `wl_pointer` devices:
1. Handle enter/leave/(absolute) motion/button/axis events to allow users to interact with applications using such devices, e.g., a mouse.
2. Update the cursor image used for Wayland surfaces based on the Windows cursor bitmap data.
A few notes:
1. A single `wl_seat`/`wl_pointer` is supported for now.
2. Many of the input interactions require window management support that hasn't been implemented yet (e.g., popup positioning, resizing, max/fullscreen).
3. There is some potential for bad interactions between the input event dispatching mechanism and the `win32u` flushing logic for `window_surface` , which can lead to visual glitches. Although I don't think this is blocker for this MR, I would like to start a discussion about the problem and mitigation ideas in a [comment](https://gitlab.winehq.org/wine/wine/-/merge_requests/3686#note_438… below.
Thanks!
--
v2: winewayland.drv: Implement SetCursor using cursor bitmap data.
winewayland.drv: Handle pointer button and scroll events.
winewayland.drv: Handle pointer motion events.
winewayland.drv: Handle pointer focus events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3686
These tests make the ddraw-d3d9 tests pass inside Xephyr with fvwm3 for me. fvwm3 still randomly fails in a lot of places if it is run on a real display. It also fails in Xephyr if I wiggle the mouse too much. Those two issues might even be related. A virtual X server should be enough for CI though.
fvwm2 has a lot of random failures even inside Xephyr or xf86-video-dummy. I will not attempt to fix them.
I tested the SW_SHOWMINNOACTIVE in patches 2 and 3 on Windows XP, Windows 11, the testbot, kwin, openbox. It seems to work without breaking any of those systems. With those things being flaky changes though I can never fully gurantee this though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3746
This patch set is part of !3303
--
v2: winegstreamer: Create wg_muxer for media sink.
winegstreamer: Implement seeking query for wg_muxer sink pad.
winegstreamer: Introduce new wg_muxer struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3737
On Fri Sep 8 06:44:32 2023 +0000, Mohamad Al-Jaf wrote:
> I've removed it, seems like it's not really necessary to test for it.
> Though, I don't understand why Office queries for `IAgileObject`. It's a
> Microsoft program so they should know it's not supported. Minecraft also
> queries for an interface that returns `E_NOINTERFACE`, it seems bizarre.
You should still remove the `broken(...)` condition, it will otherwise let every test succeed silently on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3672#note_44665
On Fri Sep 8 06:50:30 2023 +0000, Henri Verbeet wrote:
> At first sight this looks fine, thanks. Unfortunately I probably won't
> be able to properly review this this week, but I should be able to get
> to it early next week.
> Note that this currently fails the CI though. Probably because it's
> intended to be applied on top of !325, so hopefully that will get
> resolved once those patches actually get committed.
It still fails CI after !325 was merged (and even before - as it was based on top of !325, those commits were part of this branch so testing would just have iterated over those too) - not quite sure what is wrong here...
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/332#note_44664
On Thu Sep 7 13:49:19 2023 +0000, Rémi Bernon wrote:
> I missed this before, but I think the check_interface check is a bit
> pointless as it will always succeed on Windows.
> Something like that would be better (using `check_interface_broken` only
> where it is needed):
> ```suggestion:-14+0
> #define check_interface_broken( obj, iid, supported ) check_interface_(
> __LINE__, obj, iid, supported, TRUE )
> #define check_interface( obj, iid, supported ) check_interface_(
> __LINE__, obj, iid, supported, FALSE )
> static void check_interface_( unsigned int line, void *obj, const IID
> *iid, BOOL supported, BOOL is_broken )
> {
> HRESULT hr, expected_hr, broken_hr;
> IUnknown *iface = obj;
> IUnknown *unk;
> expected_hr = supported ? S_OK : E_NOINTERFACE;
> broken_hr = supported ? E_NOINTERFACE : S_OK;
> hr = IUnknown_QueryInterface( iface, iid, (void **)&unk );
> ok_(__FILE__, line)( hr == expected_hr || broken( is_broken && hr ==
> broken_hr ), "got hr %#lx.\n", hr );
> if (SUCCEEDED(hr)) IUnknown_Release( unk );
> }
> ```
> Or, maybe even better, use the basic `check_interface`, without the
> broken result and remove the broken check for IAgileObject interface
> which probably doesn't really matter on the factory.
I've removed it, seems like it's not really necessary to test for it. Though, I don't understand why Office queries for `IAgileObject`. It's a Microsoft program so they should know it's not supported. Minecraft also queries for an interface that returns `E_NOINTERFACE`, it seems bizarre.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3672#note_44663
This goes on top of !325 (which was already approved).
--
v2: include: Add some misc D3D12 structs/enums.
include: Add some D3D12 raytracing specific structs.
include: Add the D3D12_BARRIER_GROUP struct.
include: Add the ID3D12Tools interface.
include: Add the ID3D12VirtualizationGuestDevice interface.
include: Add the ID3D12Device10 interface.
include: Add the ID3D12Device9 interface.
include: Add the ID3D12ShaderCacheSession interface.
include: Add the ID3D12GraphicsCommandList4 interface.
include: Add the ID3D12MetaCommand interface.
include: Add the ID3D12Heap1 interface.
include: Add the ID3D12Resource{1,2} interfaces.
include: Add the ID3D12Device8 interface.
include: Add the structs D3D12_FEATURE_DATA_D3D12_OPTIONS{6,7}.
include: Add the ID3D12Device7 interface.
include: Add the ID3D12ProtectedResourceSession1 interface.
include: Add the ID3D12Device6 interface.
include: Add the ID3D12DeviceRemovedExtendedData{,1,2} interfaces.
include: Add the ID3D12DeviceRemovedExtendedDataSettings{,1} interfaces.
include: Add the ID3D12Device5 interface.
include: Add the ID3D12StateObjectProperties interface.
include: Add the ID3D12StateObject interface.
include: Add the ID3D12LifetimeTracker interface.
include: Add the ID3D12SwapChainAssistant interface.
include: Add the ID3D12LifetimeOwner interface.
include: Add the ID3D12Device4 interface.
include: Add the ID3D12PipelineLibrary{,1} interfaces.
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/332
This series fixes a few bugs in the d3d tests that cause them to crash on my Windows XP laptop with the r200 GPU (dx8 era).
There are plenty more problems on this GPU on Windows. d3d8:visual hangs the entire system. d3d9:device has some failing tests. d3d9:visual crashes, which is probably good because otherwise it would also cause a kernel panic.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3757