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:
![Screenshot_20221026_023411](/uploads/55552d7c335ef5ce0b507f61adacbb00/Screenshot_20221026_023411.png)
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