Support composable classes with overridable methods

[Alovchin91]

Suggestion

Hi,

Let me start with the disclaimer: I do understand that this might be an uncommon scenario, but I hope that you'll be able to find some time to look into it nonetheless, and maybe share your experience.

Besides, I believe that generally, this should be a supported scenario.

Anyway, I've been toying with Windows App SDK and Rust, and I'm happy to say that I've managed to create a very simple app! I have essentially reimplemented this app: https://github.com/sotanakamura/winui3-without-xaml

My original research was into WinUI Islands. I must note that I believe that hosting WinUI components, even if from a C++ DLL, within a Win32 app written in Rust could be a valid scenario. I understand that XAML technology itself is very specific to C#, but some things (like the Islands host) are, from my knowledge, "usual" (non-XAML) components.

Anyway :) Here are a few things that I've noticed.

Composable classes with overridable methods

Probably the most important bit for this specific issue and for the future of windows-rs in general, currently windows-bindgen seems unable to generate bindings for unsealed classes with overridable methods.

To make the app run, I need to inherit from the Application class and override the OnLaunched method. For this, I need to call the factory's CreateInstance method with a pointer to my IApplicationOverrides implementation. However, windows-bindgen generates a simple new() function that doesn't accept any parameters. In the end, I had to write the constructor myself like this:

fn create_app() -> Result<Application> {
    // App implements IApplicationOverrides
    let app = App::new()?.into_object();
    let app_unknown = app.as_interface::<IUnknown>();
    ApplicationFactory(|this| unsafe {
        let mut result__ = core::mem::zeroed();
        (Interface::vtable(this).CreateInstance)(
            Interface::as_raw(this),
            Interface::as_raw(&*app_unknown),
            &mut core::ptr::null_mut(),
            &mut result__,
        )
        .and_then(|| Type::from_abi(result__))
    })

Interesting behaviour of Drop

I'm not sure that this is a correct heading, but I experience a bit of an interesting behaviour with this constructor.

In reality, it does a bit more (see the linked project): it actually saves the resulting Application into a variable and then "inits" the App class with it as follows:

#[implement(IApplicationOverrides)]
struct App {
    application: RefCell<Option<Application>>,
}

impl App {
    fn init(&self, app: Application) {
        self.application.borrow_mut().replace(app);
    }
}

impl Drop for App {
    fn drop(&mut self) {
        log::debug!("App::drop");
    }
}

The interesting thing is that, if I do pass the Application to my App class, the latter doesn't get dropped anymore, and the call to RoUninitialize at process exit causes a violating access error. And if I do manage to manually release it (by casting it to IUnknown and then using the vtable), the Drop gets called but I get an Object has been over-released panic at process exit.

I'm sure I'm doing something wrong here, but I can't quite figure it out. Application is a strange object that cannot be put into a ComObject, and cannot even be cast to IApplication. But I need to save it so I could later call its methods.

Usability of this repo as a dependency

I have to note that using this repo as a git dependency is quite sub-optimal. This is because I would like to use only the newer version of windows-bindgen that is capable of generating composable class constructors, but I end up checking out the whole multi-dozen-megabyte repository. I wish there was a new windows-bindgen release on crates.io.

The sample app

You can find the sample app I've built here: https://github.com/Alovchin91/rust-winui

Note that it uses Git LFS because WinAppSDK's bindings that do compile are ginormous 😅

There are also a couple of patches that I had to apply to the bindings: I couldn't find a good way to make WinAppSDK bindings use the Windows::UI::Xaml::Interop bindings so I do search and replace, and WebView2.Core's bindings generate two overloaded methods with the same name so I have to rename the last one manually.

You'll also have to put all the WinAppSDK's WinMDs into the winappsdk/winmd directory manually as I'm not sure if I can legally "redistribute" them.

[riverar]

We went down this road (https://github.com/microsoft/windows-app-rs) already. Windows App SDK, WinUI, et al are just too heavily tied to .NET and Visual Studio to be practically usable with other languages and toolchains. Not sure there's anything in the request here that would be useful to others but will leave this open for other opinions!

[Alovchin91]

@riverar Thank you very much for the swift response! I can't help but feel that you might've missed some of what I've written 😅 I've mentioned that I do understand that XAML is heavily tied to C# (.NET), but I believe that this story might be more generic (composable types with overridable methods), and that some scenarios (like hosting controls from a .NET assembly in a XAML Island in a native Rust Win32 app, for example) could still potentially be interesting. I truly hope that my message could be read past the lens of WinUI / XAML / WinAppSDK context 🙏

[Alovchin91]

I will try to create a minimal reproducer with a clean IDL tomorrow to disconnect it from XAML. Merry Christmas! 🎄

[Alovchin91]

Okay, here's a "small" sample I've managed to build to demonstrate the issue I'm describing.

test_proj.zip

Here we have a (rather simple) unsealed class with an overridable and a non-overridable methods.

The library implementation is rather simple and the only complication is that our base class knows about its potential overriders and delegates the calls to them if they exist. I suppose that's what C++/WinRT's dispatch_to_overridable is for.

The client app implementation is more of a challenge. Here, I've tried to show 4 options that I came up with:

1. The non-working option. Implementing Class1 and IClass1Overrides simply creates a new "base class".
2. The option we currently have. We can save the base Class1 implementation and call to it, but if somebody casts our implementation to Class1 base, the dispatch won't happen.
3. The "unfinished" option. This one only implements IClass1Overrides. We can create the base Class1 implementation and pass it our overrides implementation, but this doesn't make much sense because our implementation cannot be cast to Class1. This can probably be useful in a limited set of Rust-centric scenarios where inheritance is replaced with composition, but the moment we need to cast to Class1 we're out of luck.
4. The "ideal" option. This one implements both Class1 and IClass1Overrides, and instantiates the base implementation with our overrides. This can be cast to Class1 and will dispatch calls correctly.

Taking 4 as the best option, there are three problems with it:

1. First of all, and that's the topic of this issue, I have to manually re-create the factory function to be able to pass the baseinterface implementation to it. It would be great if this boilerplate could be generated too.
2. I have to reimplement all the non-overridable methods and delegate them to the base class manually. Would've been nice if there was a way to generate those too.
3. There is actually no way right now for me to cast this object to the base implementation. What could be the base implementation (Class1) is in fact the interface. The only way to call the base implementation is to save it somewhere.

Note that, because of problem 3, currently I'm considering a scenario where the Rust WinRT component is used from a different language (e.g. C++) and is cast to the base type. If problem 3 is resolved, this becomes possible within the Rust world, too.

[kennykerr]

Merry Christmas! Whether it directly involves Xaml is not really the issue. The WinRT type system included special concessions specifically to support Xaml. Those capabilities are almost exclusively used by Xaml but can technically be used by any API - originally they were limited to Xaml by both policy and tooling as its just not a good idea. They are exceedingly complicated, costly, and problematic. So whether it is the vastness of the Xaml API surface or the WinRT form of binary composability, it is not supported by windows-bindgen and I have no plans to ever support it. If you are determined to get this working in Rust, your best bet is to write a non-composable wrapper API in either C# or C++ and expose that to Rust developers.

[Alovchin91]

Hi @kennykerr Thank you for the answer! This is a bit sad because that makes Rust feel like a second-class citizen, given that C++ does support overridables 😞

That being said though, I would really appreciate it if you could have a look at my test project and review if what I've done to work around this is sound (specifically the way I work with the factory and its parameters. I also don't quite understand what the third parameter is for). I hope it's not too much trouble as I value your experience a lot 🙏

[kennykerr]

Unsealed classes and overridable methods (both require binary composability) are classic Xaml-style type system elements. In other words, stay away from that stuff. 😉

[Alovchin91]

I'm not a big fan of class inheritance either to be fair, but I can still author them and generate bindings for them 🤷‍♂️ Maybe you could consider explicitly declaring them unsupported, like CsWinRT has done (just error out when windows-bindgen encounters a composable class). That might also give you an idea whether they're used by some of your customers outside of Xaml.

[kennykerr]

I wish there was a new windows-bindgen release on crates.io.

Coming soon: #3418

[Alovchin91]

Thank you for this release!

With the new windows-bindgen, I was finally able to generate package-style bindings for WinUI 3. It didn't work well previously and the generated package-style bindings did not compile.

Speaking of this issue's topic, I still believe there is some merit in having support for WinRT class hierarchies.

If I'm not mistaken, your original decision to stop supporting XAML was due to the fact that the XAML compiler is a complex piece of software and generally, XAML markup is very much a C# technology.

There are however other cases that I believe still deserve attention in Rust, namely:

• Authoring View Models, like I mentioned in another issue Support composable constructors #3242. A common way to do this is to create a number of base helper classes, e.g. ViewModelBase, RelayCommand etc. It's actually the pattern to separate UI (XAML) and logic, but it does depend on class hierarchies.

• Hosting XAML Islands. One could have XAML UI in a C# binary but the host (DesktopWindowXamlSource, WindowsXamlManager ) could live in a Rust app. That was my original research subject. Actually, scratch that. This doesn't need any class hierarchy.

I hope you could consider these limited scenarios some time in the future.

In case you're interested, here are my two projects:

• the bindings -- https://github.com/Alovchin91/winui3-rs
  • probably the most interesting part is here: https://github.com/Alovchin91/winui3-rs/blob/main/winui3/src/xaml_app.rs
• the sample app -- https://github.com/Alovchin91/rust-winui
  • nothing fancy at all

[riverar]

If I'm not mistaken, your original decision to stop supporting XAML was due to the fact that the XAML compiler is a complex piece of software and generally, XAML markup is very much a C# technology.

The decision to stop supporting XAML was driven by a number of factors, one being its overall deep integration with C# and its heavy reliance on reflection within the .NET ecosystem. (C++ support is just a hack.) This issue has intensified recently, as the only supported way to use XAML is now through the Windows App SDK, which requires the use of MSBuild/Visual Studio tooling.