On Tue Feb 27 18:21:26 2024 +0000, Jinoh Kang wrote:
We need a DLL, not already loaded, that forwards to another DLL, also not already loaded[^1]. Most forwarder DLLs forward to known DLLs (e.g., combase.dll, setupapi.dll), which are already transitively loaded at process startup, in some Windows versions or another. Therefore, *all* of the following DLLs are ruled out (assuming we want to test on Windows 7 as well):
graph LR classDef default text-decoration:line-through kernel32_test.exe --> kernel32.dll --> kernelbase.dll --> ntdll.dll kernel32_test.exe --> user32.dll --> gdi32.dll --> win32u.dll --> ntdll.dll user32.dll --> sechost.dll user32.dll --> advapi32.dll user32.dll --> kernelbase.dll user32.dll --> win32u.dll kernel32_test.exe --> advapi32.dll --> kernelbase.dll advapi32.dll --> sechost.dll advapi32.dll --> msvcrt.dll --> ntdll.dll kernel32_test.exe -. "(w7)" .-> ole32.dll kernel32_test.exe .-> shlwapi.dll --> userenv.dll kernel32_test.exe -. "(w7)" .-> sspicli.dll --> secur32.dllOthers are relatively obscure, or are not guaranteed to forward to specific DLLs[^2] (or contain forwarders at all) or even exist at all[^3] across Windows versions. Some others (e.g., ncrypt.dll) are seemingly pinned by some unrelated mechanism once loaded by some other forwarder DLL. There might be something I haven't discovered yet and I can continue scavenging applicable DLLs, but then I wonder if I would end up doing a whack-a-mole here and writing tests that aren't guaranteed to be run on future Windows updates anyway. Alternatively, shall I just skip it on Windows 7? [^1]: We can't test refcounts dropping to zero if someone else is holding the DLL. [^2]: E.g., ole32.dll [^3]: E.g., olepro32.dll, olecli32.dll, combase.dll
Turns out win7 is not the only problem here; for example, shlwapi.dll is already loaded on w10 or later.
How about adding importlib generation support for makedep? Would that be an overkill?