DxVk is compiled with wchar as 32bit wide while silk.net exposes it as utf16 char

[zznty]

Summary

By default GCC/Clang use wchat_t defined as uint32_t while DXGI bindings use windows convention with wchar defined as utf16 character.

Steps to reproduce

• Platform: Desktop
• Framework Version: .NET 10
• API: DXGI via DxVk

1. Run the repro and observe adapter name printed with each second char being null which suggests that underlying native code uses wider char type

// on linux
Adapter 0: I\0n\0t\0e\0l\0(\0R\0)\0 \0A\0r\0c\0(\0t\0m\0)\0 \0A\07\07\00\0 \0G\0r\0a\0p\0h\0i\0c\0s\0 \0(\0D\0G\02\0)\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

// on windows
Adapter 0: Intel(R) Arc(tm) A770 Graphics

Comments

It seems like an easy fix PR'ing an additional compiler flag to either silk.net build system or dxvk, but from my local testing it seems like during adapters/outputs enumeration, dxvk is causing some sort of OS heap corruption, which in turn causes the runtime to destabilize on next memory alloc during JIT compilation. Even in the referenced simple repro, dxvk is causing factory instance pointer to become zeros and fail, despite it working completely fine on windows native dxgi.

I'd suggest taking a closer look at interop compatibility with dxvk since i'am not an expert in this area.