`windows-core::GUID::new` should call UuidCreate directly rather than bounce through CoCreateGuid

[Robo210]

Suggestion

CoCreateGuid is in ole32.dll, and is a simple forwarder to UuidCreate in rpcrt4.dll. Swapping GUID::new to call UuidCreate directly would allow people to use GUIDs for things outside of COM without needing to link against the COM libraries.

ole32.dll is not always available in every Windows edition, but rpcrt4.dll currently is. It would be nice for the GUID class to not statically link to ole32.dll for those of us targeting the smaller Windows editions.

[riverar]

Sounds reasonable.

Can confirm on my system that CoCreateGuid forwards to combase.dll by way of api-ms-win-core-com-l1-1-0 and the implementation unconditionally calls rpcrt4!UuidCreate. (This also means the GUIDs from GUID::new are type 4 and not guaranteed to be globally unique.)

[kennykerr]

No objection to this targeted fix but generally speaking this will be a bit of a whack-a-mole as other APIs crop up that may not be available on different Windows editions. Still, happy to make the change if it unblocks adoption for you.

[Robo210]

The thought of playing whack-a- mole does concern me. I have a hunch though that the number of thin wrappers like CoCreateGuid is quite limited, and the number of exports that purely forward to another dll is larger but easily knowable. And I believe if it went a step further and linked against an API Set rather than a lib, the latter case could be handled easier (aka I know I need a bunch of functions officially exported from advapi32 that are actually hosted elsewhere, and advapi32 is usually first in the chopping block for the smaller Windows editions).

I was surprised that the crate uses named dlls rather than API Set names. There's probably some compat issues with older versions that don't support API Sets, but it also means newer, smaller OS versions need the reverse forwarders, which also aren't always available even when the needed API Set is.

My immediate concern though is that I need to call ETW functions that take a GUID parameter but I never actually call 'new'. As I understand it the linker must be able to resolve all references in the obj (e.g. to ole32.lib) before the optimizer can strip out the new function as unused and drop the ole32 dependency. And if it fails to optimize it away, then my program will fail to launch on any edition without COM support, even though I don't need or want COM support in the first place. All so I can pass a simple GUID struct to a function.

[riverar]

I was surprised that the crate uses named dlls rather than API Set names. There's probably some compat issues with older versions that don't support API Sets, but it also means newer, smaller OS versions need the reverse forwarders, which also aren't always available even when the needed API Set is.

Yep. We took a look at API Sets multiple times (e.g., microsoft/win32metadata#2065), but the API Sets owners steered us away from it—they noted API Sets lack proper down-level support and recommended that alternative platforms without standard libraries should add reverse forwarders for seamless operation.

[Robo210]

That makes sense, and from the API Set owners perspective probably continues to make sense as long as OneCore is the smallest target that everyone can depend on. But when other teams decided OneCore was far too large and started to drastically cut from it, the reverse forwarders were among the first pieces to go. And then other teams decided Rust was the mandated language for code running in said editions... I'm not sure there is a workable solution here that makes everyone happy, especially for public and private SDKs together.

To get back on topic though, I have workarounds (define the functions myself rather than through windows-rs so I carefully control the libs I pull in), so I wouldn't consider myself blocked even if you don't want to change GUID::new. I think this particular function is an easy win, but if it sets an unwelcome precedent for things then I'd understand not changing it.

[kennykerr]

Please take a look at #3656

[Robo210]

Thanks!