https://bugs.winehq.org/show_bug.cgi?id=50293
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Austin English from comment #3)
(In reply to Zebediah Figura from comment #2)
This is an awful lot of stub DLLs to add. What's the benefit of native dxdiag?
A fair point. Builtin is basically a stub.
dxdiag itself (used to be) popular for users to gather the state of their systems, and to verify that the system was in a good state for DirectX applications, see e.g., https://support.nexon.net/hc/en-us/articles/204335909-How-to-create-a-DxDiag... Report-in-Windows.
Yeah, I guess that was not a great question per se. I think native dxdiag certainly does have some value, but it's not clear to me that the "DirectX Files" tab has any value. After all, all of that information is faked; none of it actually exposes anything about the host system (or about the functionality of Wine code, really.)
Note that it doesn't check for _all_ dlls, (i.e., it doesn't look for comctl32/user32), it's only looking for DirectX affiliated dlls. While we can't guarantee that each one is used by some games, it seems reasonable that at least some games look for each of those dlls).
That said, given that it's 2021 and most of the dlls haven't gotten bug reports mean that those dlls may not be needed (or we aren't getting bug reports about it)..
I think most of them are basically internal DLLs required by other parts of the DirectX runtime, and so not something user space would ever access. A couple of them I do recognize as potentially having documented and user-accessible parts (dsdmoprp, arguably qdv and qedwipes), but I don't think there's much point in adding stubs like this—missing DLLs or COM objects are usually quite clear in logs.