Some experiments with HString wrapper and ComPtr

[Boddlnagg]

This is not meant to be merged!

It shows my progress so far and allows me to share it with you more easily. Note that it requires a local override of winapi-rs with the necessary changes (either my or your PR).

What is currently definitely wrong in my implementation is:

• The copy of the RIDL! macro from winapi. Either mark it as export in winapi or build a custom one with more features (I thought about having a way to automatically assign IIDs to interfaces, in order to get rid of the duplication in lines such as asyncOp.query_interface::<IUnknown>(&IID_IUnknown); and be able to write asyncOp.query_interface::<IUnknown>(); instead (UPDATE: I've added a commit which does extend the macro accordingly. We have to see whether we are able to upstream this to winapi-rs.)
• The implementation of the completion handler. I built a custom COM class with manual reference counting that pretends to be of the right type, but this is probably totally wrong. You said you had already got completion handlers working, so you can just ignore that part of my code. (UPDATE: It seems to be not that wrong actually, so I refactored/simplified it a bit. The only remaining question there is: Which interfaces does the handler support in QueryInterface? My test code reports which interfaces are queried.)

(By the way, I probably won't have much time to work on this during the next weeks.)

[contextfree]

Thanks! I probably won't get a chance to seriously look/work on this until Tuesday or Wednesday.

[Boddlnagg]

Oh, one more comment: Another reason that we probably can't rely on winapi's RIDL macro, is that we sometimes need generic definitions, e.g. IAsyncOperation<T>.

[Boddlnagg]

This might also be helpful: https://github.com/retep998/winapi-rs/issues/145#issuecomment-122168427. It's about how to implement a COM interface from Rust.

[Boddlnagg]

Also please note that my test code still requires a change in winapi: Add #[derive(PartialEq, Eq)] to GUID in guiddef.rs.

[Boddlnagg]

... this last commit renders my previous comment obsolete.

[Boddlnagg]

This is now in a state where it actually starts looking like more than a proof-of-concept. I'd like to have some feedback and then we should get started with the automatic code-generation.

I wonder if we can get rid of this out-pointer-passing in the low-level-bindings already? I think we should generate the impl for the function definitions (which forward to the vtbl) already in such a way that they 1) ... take care of creating the unitialized out-pointers for the return values, check the HRESULT and return Result<T, HRESULT> (or some custom error type) 2) ... already have a snake_case name. (As far as I understand it, language projections should map to the respective naming conventions.)

This is not possible with macros, but should easy with custom codegen, as long as we're careful with possible null return values.