In theory, if a dll that is part of an XS module is dynamically loaded and has a dependency upon another dll that is already loaded (whether by the main perl.exe, perl5xx.dll, or some other previously loaded XS dll), then you can prevent that loaded dependency from being 'reused', by adding a xxx.dll.local file in the same directory as the xxx.dll.

Hm. That's as clear as mud. I'l try again :)

perl.exe uses perl5x.dll which uses dependee.dll.

Module MyXS.pm uses MyXS.dll uses dependee.dll. But it may need a different version of it to perl5x.dll.

In the normal way of things, when MyXS.dll is runtime dynamically loaded as a result of use MyXS; statement, when the OS loader is loading MyXS.DLL, it sees it dependency upon dependee.dll, see that the process already has (a copy of) that loaded, and doesn't look further.

However, if whilst loading MyXS.dll, it see a file MyXS.dll.local in the same directory, it *should* then ignore the existing in-memory copy of dependee.dll and look for (another copy) of it in the same directory as MyXS.dll, and use that for doing the fix-ups.

That, by every interpretation I can find is what should happen. But ... I cannot make it work!

myApp\myApp.c
myApp\myApp.exe

myApp\myDll.c
myApp\myDLL.dll

myApp\Dep.c
myApp\Dep.dll

myApp\Ext\ExtDll.c
myApp\Ext\ExtDLL.dll
myApp\Ext\ExtDLL.dll.local

myApp\Ext\Dep.c
myApp\Ext\Dep.dll
[download]

MyApp.exe uses myDll.dll uses (myApp\)Dep.dll.

At runtime, MyApp.exe LoadLibs Ext\ExtDll.dll which uses (myApp\Ext\)Dep.dll.

The presence of myApp\Ext\ExtDLL.dll.local should force the OS loader to look in MyApp\Ext for Dep.dll when fixing up ExtDll.dll's dependencies. It doesn't:

depends64 -c -ot:MyApp.depends -pb myapp.exe ext\ExtDLL.dll
[... snip lots ...]
Started "c:\test\myapp\MYAPP.EXE" (process 0x1194) at address 0x000000
+0140000000.  Successfully hooked module.
Loaded "c:\windows\system32\NTDLL.DLL" at address 0x0000000077A50000. 
+ Successfully hooked module.
Loaded "c:\windows\system32\KERNEL32.DLL" at address 0x000000007792000
+0.  Successfully hooked module.
Injected "c:\perl64\bin\DEPENDS.DLL" at address 0x0000000075030000.
Loaded "c:\test\myapp\MYDLL.DLL" at address 0x0000000180000000.  Succe
+ssfully hooked module.
Loaded "c:\test\myapp\DEP.DLL" at address 0x0000000000140000.  Success
+fully hooked module.
Entrypoint reached. All implicit modules have been loaded.
LoadLibraryExA("ext\ExtDLL.dll", 0x0000000000000000, 0x00000000) calle
+d from "c:\test\myapp\MYAPP.EXE" at address 0x000000014000103F.
Loaded "c:\test\myapp\ext\EXTDLL.DLL" at address 0x0000000000160000.  
+Successfully hooked module.
LoadLibraryExA("ext\ExtDLL.dll", 0x0000000000000000, 0x00000000) retur
+ned 0x0000000000160000.
GetProcAddress(0x0000000000160000 [c:\test\myapp\ext\EXTDLL.DLL], "boo
+t") called from "c:\test\myapp\MYAPP.EXE" at address 0x00000001400010
+92 and returned 0x0000000000161000.
Exited "c:\test\myapp\MYAPP.EXE" (process 0x1194) with code 0 (0x0).
[download]

The significant bit of that is that there is no Loaded "c:\test\myapp\Ext\DEP.DLL" ... line :( Which means that MS docs are either misleading or just outright wrong.

It is also (theoretically) possible to attach a manifest to the XS dll that would force the OS loader to look for its dependencies in the same directory first. But the whole manifests thing just gives me a headache, so I haven't (re-)explored that this time.

All of which means ... please forget I said anything and carry on as you were.