While debugging League of Legends I noticed that `LoadLibraryEx()` is invoked with binary filename (non-text) and non-NULL `hFile`.
In Windows such call would return `NULL` with LastError set as `ERROR_INVALID_PARAMETER` but current Wine implementation would try to proceed ahead.
I don't know if this is intentional trick to mess up debugging/reversing tools or if we have some memory corruption before that overwrites filename buffer. But then I can't imagine how `hFile` could have gotten corrupted since shouldn't that be simple static value in register...
Having this MR causes very noticeable difference in LoL:
* without it - process deadlocks
* with it - no deadlock
Also while looking at this, I tried a lot of different flag combinations on Windows 10 and here I implemented so it works exactly like that.
I also implemented test case for non-NULL `hFile` but I didn't bother for other flags since I don't know if we even care about those.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4587
This fixes the layout of the tabcontrol when a font other than the
system font is used.
--
v6: comctl32/tests: Modify test_width to try different fonts
comctl32/tests: Check size initially and after changing padding only
comctl32/tests: Fix tabcontrol tests to work with different fonts
comctl32: Use selected font to determine default min tab width
comctl32: Fix TAB_SetItemSize
comctl32/tests: Add test for setitemsize return value
https://gitlab.winehq.org/wine/wine/-/merge_requests/4484
> I do test , if the program is free, but this one isn't, so cannot test.
In that case, you can simply attach the patch to the Wine-Bug report and ask the user to test it like I did here: https://bugs.winehq.org/show_bug.cgi?id=54623.
> I think it's just fine to add the stub so that user can test it in the next
release to see if it helps workaround the bug and report back.
I don't think this is fine as users often abandon bugs. Another user might file a bug report for another program that happens to call the stub. The stub can make it difficult to pinpoint the cause of a crash or issue, especially since Wine is rife with stubs. Of course, there are functions which are reasonably safe to stub.
However, in this case, it's obvious a stub does not help. Since the function is creating something, it's safe to assume the program might attempt to access the object. Returning failure like E_NOTIMPL is often no different than returning success like S_OK since a lot of programs don't bother to check for failure and assume functions always succeed.
> Apparently you have access to this program, and already knew the answer.
Please share this info in future in bugreport then.
I had access to the program when I was working on it. Well, if you read the info in the bug report you would know the bug started after adding in MediaControl. I sent multiple patches for Roon. I would have sent an MR for a simple stub if it helped.
Also, sharing the info in the bug report is apparently pointless. See the previous bug: https://bugs.winehq.org/show_bug.cgi?id=54623
The info was ignored and an MR created nonetheless: https://gitlab.winehq.org/wine/wine/-/merge_requests/4579
Lastly, I'm not paid to work on Wine. I have no obligation to share anything, especially since a lot of bug reporters are unappreciative and even hostile.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4555#note_54808
Goes atop !477. The last two commits belong to this MR.
--
v3: vkd3d-shader/dxil: Implement the DXIL STORE instruction.
vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction.
tests/shader-runner: Test an uninitialised indexable temp.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498
Goes atop !477. The last two commits belong to this MR.
--
v2: vkd3d-shader/dxil: Implement the DXIL STORE instruction.
vkd3d-shader/dxil: Implement the DXIL ALLOCA instruction.
tests/shader-runner: Test an uninitialised indexable temp.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/498