This is slightly different from dlltool but I think it should be compatible. The transition is done by first replacing dlltool with its bugs, and fixing them in separate changes.
I based the ARM / AARCH64 implementation on the existing code around, but I have no idea if it is correct, and dlltool also doesn't include any delay load implementation for ARM.
--
v6: winebuild: Put the delay import descriptor in data section.
winebuild: Fix import hint value for symbols imported by name.
winebuild: Implement delay import lib generation without dlltool.
winebuild: Enable unwind tables by default in PE files.
winebuild: Implement import lib generation without dlltool.
winebuild: Introduce a new --without-dlltool winebuild flag.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1001
... and fix output buffer allocation on the way.
I am not aware of any app which strictly depends on the ApplyControlToken / connection shutdown to be implemented. Yet I saw a few games calling ApplyToken to perform the connection shutdown (similar to what is described in [1]). I once implemented that while debugging something and probably it makes some sense support secure connection shutdown once the app tries to do so (which as I understand is now recommended to do before closing socket).
1. https://learn.microsoft.com/en-us/windows/win32/secauthn/shutting-down-an-s…
--
v2: secur32: Implement ApplyControlToken for SCHANNEL_SHUTDOWN.
secur32: Add semi-stub for ApplyControlToken (schannel).
secur32: Allocate buffer for either ISC_REQ_ALLOCATE_MEMORY or NULL output in schan_InitializeSecurityContextW().
secure32/tests: Add tests for ApplyControlToken (schannel).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1286
Patch 1.
The tests on Windows show that when the timer callback is queued behind the clock time it is queued and executed quite soon with 0-15ms delay which corresponds to default timer granularity. The timeout tolerance in the test is quite bigger to avoid a flaky test. Wine currently may execute the callback right away or delay it indefinitely depending on the time difference and current system time.
Patch 2.
It turns out when the session is paused and then restarted and all the samples were delivered to sample grabber before restart, nothing is going to request the samples again when the session is restarted. I am attaching a test in a patch which hopefully confirms how that should work. I am not including that in the patches as the test involves delays (to make sure all the async events settle at certain points) and inherently flaky. Also, _
IMFStreamSink_GetEvent(stream, ...) in the test crashes on Win7 for some unknown reason.
[0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch](/uploads/58c1738d48b3392e7ec430a0757210d0/0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch)
--
v6: mf/samplegrabber: Handle samples receieved in paused state.
mf/samplegrabber: Process samples in paused state in ignore_clock mode.
mf: Handle timer time behind clock time in present_clock_schedule_timer().
https://gitlab.winehq.org/wine/wine/-/merge_requests/574
Supersedes: https://gitlab.winehq.org/wine/wine/-/merge_requests/789
This MR, with patches from Rémi should fix the no sound issue in media engine and also the black screen issue with MfPlayer.exe.
--
v3: mf: Set media types for output nodes in the media session.
mf: Assume same up and downstream media type for copier creation.
mf/tests: Test for copier node in topology using evr.
mf: Add some topology source node checks in IMFMediaSession_SetTopology.
mf: Always enumerate branch source types for transform nodes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1262
Some shlexec tests timeout on Windows10 (and generate errors as no
action has been executed).
Improve detection of timeout in child program (so that existing
workaround in shell_execute_ex can be triggered).
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1293
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1166