Rantanen
commented
6 years ago It's good to know about the winrt-rust crate. I guess from Intercom's perspective this occupies a similar position as winapi-rs does.
Something I would love to support in such a way that projects depending on both crates could use them together seamlessly - but still something that I don't want to depend on. As I mentioned in #16, Intercom is aiming for Linux compatibility as well so we need to evaluate our dependencies from that point of view.
How I see the three crates currently:
| Crate | Features | Use Case |
|---|---|---|
winapi-rs |
ridl!, constant definitions |
Defining and calling existing COM interfaces |
winrt-rust |
COM interface delegates | Using existing COM interfaces with Rust-like method signatures. |
intercom |
[com_...] attributes, code gen |
Defining new COM interfaces and implementing them |
I don't know what "interoperability" between winrt-rust and intercom would mean. Perhaps implementing the WinRT APIs using Rust so that projects built for winrt-rust could be compiled on other platforms as well?
If this was the case, then it's something very similar to what interoperability between winapi-rs and intercom would be in my eyes:
winapi-rs contains a large amount of COM interface definitions. Being able to take any of these interfaces, that have been already implemented in winapi-rs and doing a [com_impl] for them with intercom.
However the current issue is that intercom is very opinionated on what a COM method looks like. As the primary purpose of intercom is to take existing Rust traits and making these COM-visible, it can do this by dictating on the conventions the COM methods use. For example currently there's no way or plan to allow [in, out] parameters for things like BStr - the BStr to String conversion copies the original string and there is no "write back" logic for handling modifications to the String.
This is not to say that it will never happen. I do hope that one day Intercom would be capable enough to implement the winapi-rs and possibly winrt-rust COM interfaces.
When it comes to BStrs, etc. I don't think making these (intercom::BStr and winrt::BStr) compatible is going to give much value for end users. At least Intercom tries to hide the BStr in its internals. It's used in converting Rust string types into COM-compatible string types and shouldn't be visible to the end user in general.
However if Intercom exposes BStr in the future or we get some other types that are shared between the two (or three, including winapi-rs) libraries, we might need to revisit this.
As a conclusion, I don't think anyone knows what interoperatibility between these crates even means. It might be something that we'll figure out when the first user tries to use these crates in the same project and encounters pain points that we could solve with small changes in our crates. I should probably include a bit about winrt-rust and winapi-rs in the Intercom README.md at some point to raise awareness on our wish to solve any interoperability issues.
Boddlnagg
I'm the main author of the winrt-rust crate, which is somewhat closely related to COM (because WinRT is based on COM). There are some interesting relationships with this crate, for example I'm currently also offering a very simple BSTR wrapper (although that's basically never needed in WinRT and probably should not be part of the winrt-rust crate).
With winrt-rust it's currently not possible to write your own components, only consume the WinRT API (using wrapper code generated by a C# tool). Perhaps the necessary glue code for writing custom components could be (partially) shared by intercom and winrt-rust?
Unfortunately I don't really know if there are any actual use cases of interoperability between classic COM and WinRT (because I've never used classic COM), but I think it's worth discussing anyway ;)