Feature request: Consider adding interfaces such as IPropertyStore to the sys crate

[fgimian]

Motivation

I personally have found the sys crate to be more natural to use in practice, and the reduced compile times are fantastic.

I think the included functionality is excellent, although with interfaces such as IShellDispatch, IPropertyStore etc. all simply being c_void pointers in the sys crate, it seems impossible to use related functions.

Keeping the sys crate minimal is indeed a wonderful idea, but removal of the interface definitions makes it impossible to use for certain scenarios.

A little explanation of why I find the sys crate more usable is as follows:

• It's much faster to compile
• It represents the original SDK documentation exactly
• There's less inconsistency (e.g. the main windows crate returns Result types for some of the API and BOOLs or other types for various other parts of the API)
• There are less issues with constants (e.g. the main windows crate sometimes takes a u32 as a parameter for constant types and thus you have to use CONSTANT.0 to pass the relevant u32). Some examples of this are CertAddEncodedCertificateToStore(.., dwcertencodingtype, ...), SetEntriesInAclW -> u32, GetFileAttributesW -> u32 which we need to perform bitwise operations on with FILE_ATTRIBUTE_* constants.

Drawbacks

The sys crate could grow in size a little when interfaces are added.

Rationale and alternatives

• It will make the sys crate fully functional for all scenarios
• Other low level libraries like winapi-rs provide implementations for most such interfaces

Additional context

No response

[fgimian]

I suppose this is covered in the FAQ and so I guess this decision has been made with a lot of thought. So if this won't be considered, feel free to close this.

I just think it would be great if the sys package could be used for all scenarios if someone wanted the lowest level API that matched that of the C++ one. 😄

[kennykerr]

There are less issues with constants (e.g. the main windows crate sometimes takes a u32 as a parameter for constant types and thus you have to use CONSTANT.0 to pass the relevant u32). Some examples of this are CertAddEncodedCertificateToStore(.., dwcertencodingtype, ...), SetEntriesInAclW -> u32, GetFileAttributesW -> u32 which we need to perform bitwise operations on with FILE_ATTRIBUTE_* constants.

If you report such cases, they tend to be quickly fixed: https://github.com/microsoft/win32metadata/issues

[fgimian]

There are less issues with constants (e.g. the main windows crate sometimes takes a u32 as a parameter for constant types and thus you have to use CONSTANT.0 to pass the relevant u32). Some examples of this are CertAddEncodedCertificateToStore(.., dwcertencodingtype, ...), SetEntriesInAclW -> u32, GetFileAttributesW -> u32 which we need to perform bitwise operations on with FILE_ATTRIBUTE_* constants.

If you report such cases, they tend to be quickly fixed: https://github.com/microsoft/win32metadata/issues

No worries at all, I'll definitely be reporting all instances of these that I've found over the weekend. Thanks heaps.

Is inclusion of COM interfaces in the sys crate something that's open for consideration or is it simply too much overhead to add to the sys crate? Seeing as how the various pieces of functionality are broken up into separate crates; I was hoping that it would be an opt-in thing anyway, but I understand if it simply doesn't make sense technically.

Cheers
Fotis

[kennykerr]

I have experimented with a lightweight version of COM interfaces but nothing good enough to warrant adding to the windows-sys crate. The main reason the sys crate is much faster to compile is that it contains very few function bodies. But in order to make COM interfaces usable in Rust, you need to wrap those function pointers inside methods and then there's all of the lifetime management and implementation support and you quickly land up with something that looks a lot more like the windows crate. So, my focus has been on streamlining and optimizing the windows crate to make it behave more like the windows-sys crate rather than the other way around.

Regarding all those useless COM APIs in the windows-sys crate, I may just add more of them to the exclusion list to further reduce the size of the windows-sys crate.

[fgimian]

Thanks so much @kennykerr, I'll go ahead and close this one and focus my efforts on reporting any issues I find with the main crate so we can get it as close to perfect as possible.

Cheers
Fotis

[fgimian]

Raised the related issue for wincrypt.h here 😄