When `import_dll` function gets `STATUS_DLL_NOT_FOUND` from `load_dll()`, it has no way of distinguishing whether it's a dependency for the dll wasn't found, or the dll itself is missing.
That results in confusing ERR messages, where a dll is found, but wine
claims it isn't. Fix this by moving the print to the actual place that
is aware of whether it's the parent or the child dll haven't been found.
Log before:
0024:err:module:import_dll Library lib2.dll (which is needed by L"Z:\\tmp\\lib1.dll") not found
0024:err:module:import_dll Library lib1.dll (which is needed by L"Z:\\tmp\\a.exe") not found
Log after:
0024:err:module:load_dll Library L"lib2.dll" (which is needed by L"Z:\\tmp\\foo\\lib1.dll") not found
0024:err:module:import_dll Loading library lib2.dll (which is needed by L"Z:\\tmp\\foo\\lib1.dll") failed (error c0000135).
0024:err:module:import_dll Loading library lib1.dll (which is needed by L"Z:\\tmp\\foo\\a.exe") failed (error c0000135).
--------
While it's just about prints, but it costed me hours of wandering *(because if I know where to find the dependency dll, but I see that the main dll is also "not found" despite being "right there", I have to research the latter problem that looks more complicated. But given enough resources applied, it then turns out to be a faux)*.
As a fun fact, I am apparently not the only one to have stumbled upon. Here's a screenshot of a `#english` chat where I asked about a commit title correctness. It's the last place where you'd expect to find someone familiar with WINE, and yet here's a person that had to deal with that exact error as well:

So, I think it's kinda serious problem.
--
v3: ntdll: don't claim to have not found a library that is in place
https://gitlab.winehq.org/wine/wine/-/merge_requests/1166
Although the test has never been observed to fail on Windows, I think the
failure is genuinely a race in the test.
File handles (like events) are signaled in order to mark that an I/O operation
has completed. In this case the I/O operation includes manipulating data on both
ends of the pipe, and as part of that may signal the other end. Internally,
however, the file handle must logically happen *after* all of this processing
has taken place, not least because (given the Windows I/O architecture) it is
the job of the I/O manager, not the IRP handler.
Since the purpose of the test is probably just to check that the file handle
will be signaled after a synchronous I/O operation has completed, we may as well
check it from the client thread, after we know for sure that it has.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=54078
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1879
When an upstream node has not given enough samples to the transform,
we need to request more samples from it to avoid stalling the
pipeline.
This fixes an issue where the intro audio of the game Airborne Kingdom stops playing after a few seconds.
--
v2: mf: Request more samples for transforms when needed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1853
Depending on the theme, if there was a header,
the border ends up painted lower than it should be,
and clipped by the header.
7-Zip file manager, the reason why the offset was added in 5f0dcf79185941c4faff35d1cc9c758160f3a27d in the first place, still renders correctly.
Before:

After:

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1878
The check was dropped in e392e0ac2846edc25610723c19d6a796372017e1, leaving the dwFlags variable unused.
I have no idea if it was indeed unnecessary or if it was dropped by mistake but either we need to keep the check, or we should remove the variable.
--
v2: winex11: Check pixel format flags in X11DRV_wglChoosePixelFormatARB.
opengl32/tests: Test wglChoosePixelFormatARB flags filters.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1828
We get conhost.exe:tty failures on testbot:
- not for version prior to w1064v1909 (these tests require
pseudo-consoles, which are not implemented in these Windows
version).
- for w1064v1909
- not for W10 versions after w1064v1909.
So, we assume that pseudo-console support is immature in this
Windows version: skip all the remaining test at the first
discrepancy point.
I could have maintained a couple of unit tests for this Windows
version, but decided not to:
- it would make the code more complicated (*),
- it doesn't bring value to Wine
- it would be a pain to maintain.
This patch fixes the (remaining) W10 part of bug below.
Support for W11 will be handled in separate patch (and likely with
properly integrating the results from W11, contrary to this patch).
Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=53465
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1873