Support for Windows 7

[kvark]

In theory, our backend's Instance creation would fail if a backend isn't available. This allows us to only enumerate the adapters of the backends exposed on a system.

However, it turns out that D3D12 backend doesn't fail gracefully: running a wgpu-rs example on Windows 7 just fails instantly with a modal dialog saying that "d3d12.dll" can't be loaded. This means we have d3d12 implicitly linked on Windows, which is not what we want.

Technically, it's a problem down the stack: gfx-backend-dx12, winit, etc. But it's also a blocker for using wgpu-native in Gecko, so we should resolve it quickly.

[kvark]

Building with WINAPI_NO_BUNDLED_LIBRARIES environment doesn't appear to fix this.
Any ideas, @retep998, @msiglreith, anybody?

[retep998]

You'll need to modify whatever is calling the function from d3d12.dll to call it using LoadLibrary/GetProcAddress (using libloading for example) instead of calling it directly from winapi.

WINAPI_NO_BUNDLED_LIBRARIES is to solve a completely different problem.

[kvark]

@retep998 isn't it winapi code calling the functions from d3d12.dll?
I was looking for documentation on environment variables like WINAPI_NO_BUNDLED_LIBRARIES but didn't find any.

[kvark]

@retep998 wait, re-reading your message now. Are you basically saying we can't use winapi at all?! Because no matter how many LoadLibrary calls we do at run time, if we have any code that uses D3D12 via winapi, we'll end up with this DLL linking problem at startup.

[kvark]

@msiglreith Dependency Walker, when run on hello-compute, shows two N/A entries followed by a single D3D12SerializeRootSignature entry point. Could this be the one and only freestanding function that forces Rust to implicitly link with d3d12 DLL?

In this case, I suppose the solution is to get this function called via a proc pointer.

[kvark]

I did some digging and found the answers.
We were using the following methods forcing the implicit DLL linking:

• d3d12::D3D12CreateDevice
• d3d12::D3D12GetDebugInterface
• d3d12::D3D12SerializeRootSignature
• dxgi1_3::DXGIGetDebugInterface1
• dxgi1_3::CreateDXGIFactory2

Some of these were used in both "d3d12-rs" and "gfx-backend-dx12". I confirmed that by removing the use of these calls we don't get "d3d12.dll" and "dxgi.dll" linked with missing entries, so the apps can start and safely discover the available backends.

The solution would be to change our code to use LoadLibrary and friends. No winapi changes are required (that's good news). I'll follow up with concrete issues. I think, instead of doing the library loading separately in these crates, we should make sure that d3d12-rs encapsulates that logic fully. @msiglreith let me know how that sounds :)

[msiglreith]

Having some additional entrypoint for these is fine for me.
The HLSL compiler entrypoint probably need to be loaded as well dynamically

[kvark]

gfx fix is coming in gfx-rs/gfx#3069
We'll not be able to pick it up however(!) until Rendy helpers are published. cc @omni-viral

[kvark]

This happened