WinRT instead of Win32

[davidhewitt]

I have no idea whether this is possible / desirable, but wanted to throw this out there.

I've vaguely had the impression that Microsoft prefers new applications to be written using WinRT rather than Win32.

WinRT has been hard to support in Rust until the recent announcement of winrt-rs: https://github.com/microsoft/winrt-rs

I have no idea how much work it would be to port winit's windows implementation to WinRT, though curious if it potentially offers advatages of WinRT such as easier theming support for winit applications.

[ryanisaacg]

I would be worried about sacrificing compat with older systems, but I don't know the current Windows OS requirements.

[MatusT]

I would be worried about sacrificing compat with older systems, but I don't know the current Windows OS requirements.

WinRT windowing APIs are supported from Windows 8.0. As of January 14, Windows 7 support ended which means that supporting only WinRT is enough to say: "runs on every supported Windows".

Nonetheless, that isn't the problem. WinRT path should and must be reserved for uwp target of Rust itself. There was PR rust-lang/rust#60260 to support this. I don't know how far they got, It seems they merged only gcc version which doesn't make sense to me. Somebody feel free to correct me.

The problem with WinRT windowing APIs (see CoreWindow) is that they must run in sandbox if I remember correctly from reading about It. The create https://github.com/microsoft/winrt-rs doesn't solve this problem in itself. This requires adding supporting stuff to rustc and cargo itself, for example generating manifest file at least.

[jdm]

There are uwp targets for both gnu and msvc triples in rustc now.

[tim-weis]

This feature request is rooted in the false premise, that the classic Win32 windowing system and that of the Windows Runtime were distinct and unrelated implementations. That's not the case, though.

The Windows Runtime's CoreWindow sits on top of the classic Win32 windowing stack. At its core it still relies on an HWND to handle and dispatch input, participate in Alt+Tab switching, and provide a host for its visual representation.

In its current shape, winit provides everything required to host a Windows Runtime-based UI. The Rust/WinRT repo links to a sample application (Minesweeper), that showcases how to host a CoreWindow in an application based on the winit crate.

In other words: winit and Rust/WinRT aren't orthogonal. They are complementary. Implementing Windows Runtime-specific infrastructure in winit is likely going to result in duplication, that eventually no one will be using anymore once Rust/WinRT has stabilized.

[davidhewitt]

Understood. Please close this issue if it doesn't make sense / isn't desirable 👍

[tangmi]

@tim-weis Does winit's Win32 backend allow one to build for a uwp target (and, for example, publish on the Microsoft Store)? If not, would a WinRT backend allow for that?

[tim-weis]

@tangmi The Universal Windows Platform limits the Win32 API surface available to client code. winit's Win32 backend calls into CreateWindowEx to create a window, for example. That API is available to "desktop apps only". I'm sure there are many other API calls that aren't available when targeting the UWP.

A hypothetical backend based around the CoreApplication Windows Runtime type is possible, in theory. That'd still require a lot of supporting infrastructure, from exposing COM interfaces through Rust all the way to implementing a build system that can package the binary artifacts and register it for local debugging. That infrastructure is a large portion of what Rust/WinRT is going to deliver.

Two points are worth noting:

1. You can publish classic Desktop application through the Microsoft Store; this deployment channel isn't limited to the UWP.
2. A classic Desktop application can host (virtually) the entire WinUI stack in a native Win32 window. winit provides the foundational infrastructure for this scenario as it stands today.

[tangmi]

If MS wants apps to move towards WinRT going forward, having winit support seems to me like a "nice to have".

I don't imagine (just guessing, though!) other targets like mobile, xbox, hololens, etc are built on Win32 like the desktop target is, so supporting those platforms with winit would need a WinRT backend. It might be worth it to revisit WinRT support when Rust/WinRT has all the needed interfaces exposed.

[Osspial]

As the current Windows maintainer, I'm not opposed to having a CoreApplication-based backend for Winit, but I have no interest in implementing or maintaining it, since it's essentially a completely distinct platform to the win32 backend.