Feature request: COM _Impl types are not mutable

[imgurbot12]

Motivation

Hello, I'm hoping to make use of windows-rs to implement a Windows Credential Provider in Rust.

There are a lot of steps involved when calling the associated interfaces that require the interface to mutate to keep track of information supplied to them in earlier calls, like the CREDENTIAL_PROVIDER_USAGE_SCENARIO.

Until these interfaces have the option to remain mutable it seems nearly impossible to properly design and build an implementation for these interfaces in Rust.

Drawbacks

Obviously not all functions need to be mutable but I'd imagine anything with a Set prefix in the function should follow this standard.

Rationale and alternatives

I'm a relatively new Rust developer but I'm not aware of any alternatives without somehow undoing every single rust security and compiler feature there is to somehow mutate an otherwise immutable object.

Additional context

No response

[imgurbot12]

Hello @kennykerr, I assume because the label was changed from "enhancement" to "question" that I'm likely missing some key-info about implementations and how to go about them.

Is there some documentation regarding how to implement the COM Interfaces appropriately that I missed? Any help is appreciated. Thank you

[kennykerr]

Yeah, sorry I plan to write about it here as it comes up quite often: https://kennykerr.ca/rust-getting-started/

That's the next topic on my list. 😊

Briefly, Rust aliasing rules surrounding &self and &mut self preclude the latter from ever being sound when combined with COM's reference counting model where there may be multiple outstanding references. Here's an example of how to handle this in Rust:

https://github.com/microsoft/windows-rs/blob/master/crates/tests/implement/tests/vector.rs

Basically, you can use something like RwLock to coordinate access to mutable state. Having spent a number of decades writing COM code in C++, I've actually come around to this model and find it far more intuitive as you cannot so easily write incorrect multi-threaded COM in Rust as you can in C++.

[imgurbot12]

Ah ok. If that works then that's great. Thanks!
While I have your attention I'm not quite sure about how to expose those COM interfaces after they've been written. Are there any extra steps to expose them and register them with windows besides simply compiling the project as a DLL?

I noticed you had written this example that included a lot of overhead in-between code that included IDL definitions. Is that necessary for predefined Implementation types?

[kennykerr]

The scaffolding in the linked example is intended for WinRT components. What your component may need depends very much on the API you're implementing and is more a question for those more familiar with this particular authentication API. For that you're better off checking the docs or going over to https://stackoverflow.com/ as I'm not familiar.

[imgurbot12]

Will do. Thanks for the info :)

[riverar]

Perhaps a snippet that might help you as well.

+use std::cell::RefCell;

use windows::{
    core::implement,
    Win32::UI::Shell::{ICredentialProvider, ICredentialProvider_Impl},
};

fn main() -> windows::core::Result<()> {
    #[implement(ICredentialProvider)]
    struct Provider {
+        mutable_state: RefCell<u32>,
    }

    impl Provider {
+        fn new() -> Self {
+           Self {
+               mutable_state: RefCell::new(0),
+           }
+       }
    }

    impl ICredentialProvider_Impl for Provider {
        fn Advise(
            &self,
            pcpe: &core::option::Option<windows::Win32::UI::Shell::ICredentialProviderEvents>,
            upadvisecontext: usize,
        ) -> windows::core::Result<()> {
+           *self.mutable_state.borrow_mut() = 42;
            todo!();
        }

        fn GetCredentialAt(
            &self,
            dwindex: u32,
        ) -> windows::core::Result<windows::Win32::UI::Shell::ICredentialProviderCredential>
        {
            todo!();
        }

        fn GetCredentialCount(
            &self,
            pdwcount: *mut u32,
            pdwdefault: *mut u32,
            pbautologonwithdefault: *mut windows::Win32::Foundation::BOOL,
        ) -> windows::core::Result<()> {
            todo!();
        }

        fn GetFieldDescriptorAt(
            &self,
            dwindex: u32,
        ) -> windows::core::Result<
            *mut windows::Win32::UI::Shell::CREDENTIAL_PROVIDER_FIELD_DESCRIPTOR,
        > {
            todo!();
        }

        fn GetFieldDescriptorCount(&self) -> windows::core::Result<u32> {
            todo!();
        }

        fn SetSerialization(
            &self,
            pcpcs: *const windows::Win32::UI::Shell::CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION,
        ) -> windows::core::Result<()> {
            todo!();
        }

        fn SetUsageScenario(
            &self,
            cpus: windows::Win32::UI::Shell::CREDENTIAL_PROVIDER_USAGE_SCENARIO,
            dwflags: u32,
        ) -> windows::core::Result<()> {
            todo!();
        }

        fn UnAdvise(&self) -> windows::core::Result<()> {
            todo!();
        }
    }

    Ok(())
}

[imgurbot12]

@riverar that helps thank you!

Now I just need to figure out how exposing the object works in windows. I've done basic FFI before but I've never done DLLs or worked with windows like this and COM programming seems so odd.

[tim-weis]

Quick follow-up question here: Would it be sufficient to set the panic strategy to "abort", so as to prevent potential panics from crossing the ABI?

[kennykerr]

I believe that's correct. Related: #1061