I'm currently trying to use d3d11 in c. I need to use IID_ globals which need the dxguid lib. Is there any way to load the library at runtime and get these globals from it without linking? I couldn't find any dxguid.dll file and used dumpbin /archivemembers dxguid.lib return a lot of weird paths like d:\os\obj\amd64fre\onecoreuap\windows\directx\misc\dxguid\daytona\objfre\amd64\d3d9guid.obj.

You cannot link to dxguid.lib dynamically. Why would you want that? It is a static library. You just link to it and that's it.

There is one alternative that works for D3D11 and C - if you put#include <initguid.h> as first include, before windows.h and d3d11.h, then it will enable special defines that will make all the IID_xxx globals to be defined "inline" in the headers themselves, no external symbols will be needed. This does not work for any COM API, but it will for d3d11.

When I looked through the source code, I saw a lot of #ifdef for INITGUID and DEFINE_GUID. Can I just #define those things myself?

Also, do you know what does the path d:\os\obj\amd64fre\onecoreuap\windows\directx\misc\dxguid\daytona\objfre\amd64\d3d9guid.obj mean?

Yes, you can define INITGUID yourself. That's the only purpose of initguid.h header - you can open it and look yourself.

Those paths are locations of .obj files when .lib was created. They are completely irrelevant when using .lib file.

1. If I include the initguid.h file, do I still need to load the global GUIDs from the DLL with LoadProcAddr?
2. While looking through the source code, I saw __declspec(selectany) in the DEFINE_GUID macro. What does it do?
3. Why does Microsoft only support this in d3d11 and not other libs?

1. Not sure what you mean by loading global guids. There are no guids in dll's. What are you loading?

2. selectany is this: https://learn.microsoft.com/en-us/cpp/cpp/selectany?view=msvc-170 It is to prevent duplicate symbols when different TU's do include these guids, because they are not define static - otherwise linker will error out with duplicate symbol errors.

3. It used to do that more in older COM code, probably because people who worked on that cared about this. But in newer COM headers there are a lot of other things broken. like not being C ABI compatible, or just not having C syntax available anymore. Because they probably are writing declarations manually instead of depending on automatically generated code.