Future of this crate

[rylev]

In light of the windows crate, the future of this crate is in question. We are currently working on subsuming most of the functionality of this crate into the windows crate, which leaves the purpose of a stand alone crate in question.

This is being tracked in microsoft/windows-rs#507.

[MarijnS95]

Ryan Levick (@rylev) has any progress been made towards answering this question?

[rylev]

Progress has been made, but a resolution has not been come to. We are certainly still looking to improve this crate in the short term, but the relationship with the windows crate is still not very clear.

[MarijnS95]

Thanks Ryan Levick (@rylev)! I'll wait for that then before making a move, but would it help to detail my (arguably niche) use-case?

[rylev]

Absolutely!

[MarijnS95]

Ryan Levick (@rylev) Thanks! Besides using windows-rs to call into Windows APIs in a nice way, we have this niche use-case of DXC that natively compiles to Linux and Windows as library and exposes COM objects through a DxcCreateInstance(class_id, r_iid, ppv). We are currently using the ancient com_rs crate to describe the COM interfaces by hand and call into them, but the resulting API is as raw as C++ and this crate requires libuuid.

We hence started looking into and have a working port with com-rs back in the day, but this stagnated right as windows-rs got announced which seems to be superior to com_rs and com-rs in almost every way:

• Newer, and supposedly integrating with or superseding com-rs (but that seems to be backtracked on now);
• Bindings are fully autogenerated: DXC headers are already processed in win32metadata;
• Bindings are much more pretty: pointer-returns are wrapped in Result, riid+ppv pairs are "hidden" behind a template argument, array pointer+count are rewritten to accept slices, refcounting is handled on Drop, et cetera;

This actually works for us (implementation is a little dated tohugh), but with one major caveat: windows-rs doesn't support Linux without some modifications. Most notably:

• Error handling calls into unimplemented!() Windows functions (cannot be linked on Linux) such as SetLastError and GetErrorInfo;
• String handling is provided by windows-rs (which is nice!) but is only written for 16-bit wide-chars. Linux used 32-bit wchars. I've written some patches to utilize widestring (see the linked DXC proof of concept) but that obviously didn't get accepted, though I am open to write a native implementation.

---

All in all I don't see any reason for us to use com-rs, given that we can get 32-bit WCHAR support behind a #[cfg(not(windows))] and some shims (bare-bones default implementations) for those few functions that may be called when errors are handled. We're probably only interested in a pretty string for some well-known values (E_NOINTERFACE) when formatting/unwrapping results.

[demberto]

You probably should remove the note in the README saying this crate is in heavy development, the last commit to this repo was 8 months ago