Hacker News Reader

Comment by alkonaut | Hacker News Reader

Never really understood whether WinRT binds me to store apps, sandboxes, appx and so on.

Can I develop a single windows app with this that runs on Windows 10 desktop as a win32 app does (such as a plugin to another application where I can’t can’t decide the deployment model)?

View on HN

WinRT, as in the API/ABI shape, at this point really isn't tied to any aspect of the UWP app model (other than that existing UWP-related APIs tend to be newer and more likely to use it). Third-party WinRT component activation used to depend on app packaging but that dependency was removed last year: https://blogs.windows.com/windowsdeveloper/2019/04/30/enhanc...

In general what used to be various facets of the "monolithic" Win32 vs. UWP divide have been refactored to allow a la carte usage, so not only can you activate your WinRT components without a packaged app, but you can also register your app as "packaged" for runtime purposes without having to install in that format ( https://blogs.windows.com/windowsdeveloper/2019/10/29/identi... ), can install in the packaged format without having to use the sandbox features ( https://docs.microsoft.com/en-us/windows/msix/overview ) can distribute sandboxed apps outside the store ( https://docs.microsoft.com/en-us/windows/msix/app-installer/... ), etc.

The only remaining aspect I'm aware of where there's still a binary decision and coupling is in the windowing model and shell integration; a Win32 process's top-level windows can only be HWNDs and a UWP process's top-level windows can only be CoreWindows. Win32 HWNDs can host both Win32 and UWP UI, but UWP CoreWindows can only host UWP UI; on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture. It would make sense to somehow decouple this facet as well but I'm not aware of any plans to do so.

WinUI 3 is planned to have support for "Win32 app model" apps. I'm not sure if this is strictly "CoreWindow" or another class with different features, but you'll be able to write "native" UWP-Style apps in C++ and deploy them as an unrestricted .exe. They're going to show a demo at Build 2020, I heard.

My understanding is the WinUI 3 Win32 model is still going to be basically doing what you can already do with XAML Islands, just packaged more nicely with wrapper classes and Visual Studio templates and so on, so by itself it doesn't change the underlying HWND vs. CoreWindow situation (just wraps it). There are already Win32 apps, like Windows Terminal, that implement a "UWP" UI by doing their entire UI in one big XAML Island.

Rust/WinRT has really triggered my interest. For someone who hasn't been following Windows development for more than almost two decades, what's a good read to understand the different models of app creation and distribution?

Unfortunately it's a bit of a mess right now for reasons alkonaut mentioned in his post upthread. The official Microsoft doc page -> https://docs.microsoft.com/en-us/windows/apps/desktop/ is maybe an ok starting point for someone with a vague memory of Windows desktop development who's curious about what's new, but I could see someone getting lost in a maze of acronyms and links, especially if you're trying to use it with a newly semi-supported language like Rust

Thanks this is informative. I think my confusion comes from that many things are introduced as walled-off vertical concepts but later backported at least partially. Also there is no lack of terminology confusion when things can be an API, an app-model or both.

I’m a full time windows desktop dev since 15 years now. And I still find these UI and app model frameworks extremely confusing (which is why I haven’t gone near one after WPF).

Yeah, it's definitely confusing for anyone who hasn't been following all the twists and turns (i.e., the vast majority of developers)

> on the other hand, only UWP CoreWindows can make use of UWP shell integration features like fullscreen and picture-in-picture

What are the practical advantages of fullscreening / PIP'ing thanks to UWP as compared to what you can achieve without?

The Shell managed PIP is entirely unique to UWP. In Win32 you can fake it with an always-on-top window, but you don't get the PIP window management gestures out of the box and some other things. From what I recall, where this particularly matters is touch gestures and HoloLens and Windows MR support where Win32 always-on-top is very different from Shell-managed PIP in three dimensions. (Also, Xbox doesn't support Win32 always-on-top.)

I think fullscreening also has some gestures the Shell manages, but I'm not as familiar with them. Similar too that the Shell does very different things in 3D.

There's also the Dual Screen support in CoreWindow that Microsoft has been talking up for Windows "10X".

The future of Win32 is also bound to sandboxing, although we are not yet there.

"How Windows 10X runs UWP and Win32 apps"

https://www.youtube.com/watch?v=ztrmrIlgbIc&list=PLWZJrkeLOr...

WinRT is an improvement of COM, it either runs sandboxed in UWP (its home), or you can access it from Win32 via XAML Islands and Win32/UWP interop.

Right now Win32 applications can still choose between legacy mode, or opt into Win32 sandoxing via MSIX packages.

As Windows 10X shows, it might not be for long.

The minesweeper example from the article is a regular Win32 app. Desktop Win32 apps can call WinRT API’s.

https://github.com/robmikh/minesweeper-rs/blob/master/src/ma...

A lot of WinRT APIs are usable from "normal" desktop win32 apps, but some are restricted to the sandboxed/appx/etc model.

The most prominent of these is probably the XAML GUI stuff, but those are becoming available everywhere in the near future, and being decoupled from the OS itself, to go along with WinUI 3.0

It's a spectrum. You can already use (some) WinRT features on desktop/console win32 apps, even unsandboxed[0].

You can use UWP XAML in win32 desktop apps with a sandbox, and you'll probably be able to use it without a sandbox when WinUI 3 comes out (currently in early preview, they'll probably have a couple sessions about it at Build)

[0] some APIs require your app to have an identity though, and you need the sandbox for that

Reply on news.ycombinator.com