> on Windows, the rpath mechanism doesn't exist

It seems we can locate a dependent assembly up to two directories up from a DLL using a relative path. According to MSDN [1], this is supported in Windows 7+. 3.7 no longer supports Vista, so this can potentially be used for extension modules in 3.7. I tested that it works in Windows 10, at least.

[1]: https://msdn.microsoft.com/en-us/library/aa374182

Create a "<name>.2.config" file for the module (e.g. "myextension.pyd.2.config"), and include a "probing" path in this file. This can specify up to 9 relative directories that can be up to two levels above the module. For example, the following adds "..\.libs" to the DLL's private assembly search path:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <configuration>
      <windows>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <probing privatePath="..\.libs" />
        </assemblyBinding>
      </windows>
    </configuration>

Add dependent assemblies to the module's #2 embedded manifest. For example, here's a dependency on 64-bit "myassembly" version 1.0.000.1234:

      <dependency>
        <dependentAssembly>
          <assemblyIdentity name="myassembly"
                            version="1.0.000.1234"
                            type="win32"
                            processorArchitecture="amd64" />
        </dependentAssembly>
      </dependency>

I this case the assembly is a directory with the given assembly name that contains an "<assembly_name>.manifest" file (e.g. "myassembly.manifest"). This manifest lists the assembly DLLs that are in the directory. For example:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <assemblyIdentity name="myassembly"
                          version="1.0.000.1234"
                          type="win32"
                          processorArchitecture="amd64" />
        <file name="mylib1.dll" />
        <file name="mylib2.dll" />
    </assembly>

The loader will look for the assembly in WinSxS, the module's directory, a subdirectory named for the assembly, and then the private probing paths that were added by the module's config file.